Opened 5 years ago

Closed 4 years ago

#527 closed defect (fixed)

NellyMoser codec reports zero frame size and bitrate

Reported by: DrLex Owned by:
Priority: normal Component: avformat
Version: unspecified Keywords: nellymoser rtmp
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


While trying to play live streams that use the NellyMoser? ASAO codec, we noticed that every player that uses libavformat for this (e.g. ffplay, mplayer, vlc) will freeze until the stream is interrupted. It will then play all audio that was buffered in the meantime.

We traced this down to enc->frame_size being set to zero in get_audio_frame_size() in libavformat/utils.c when trying to parse the stream. If we force frame_size to some value larger than 1, the stream will play.

Probably related is that the bitrate for Nellymoser streams is reported as zero as well. Yet it is easy to know the bitrate for this codec once the sampling rate is known: it is twice the sampling rate.

We did not further look into this because it was easier to switch our stream source to Speex, but it does not seem too hard to fix.

Change History (17)

comment:1 Changed 5 years ago by cehoyos

Assuming it also fails, please add complete, uncut output of ffmpeg -i source out.wav

comment:2 Changed 5 years ago by DrLex

There is not much to see in the output but here goes anyway:

ffmpeg -i "rtmp:// live=1" out.wav
ffmpeg version 0.8.4, Copyright (c) 2000-2011 the FFmpeg developers
  built on Sep 26 2011 17:37:01 with gcc 4.4.5
  configuration: --prefix=/usr --enable-librtmp --enable-ffplay --enable-debug --disable-stripping
  libavutil    51.  9. 1 / 51.  9. 1
  libavcodec   53.  7. 0 / 53.  7. 0
  libavformat  53.  4. 0 / 53.  4. 0
  libavdevice  53.  1. 1 / 53.  1. 1
  libavfilter   2. 23. 0 /  2. 23. 0
  libswscale    2.  0. 0 /  2.  0. 0

Some quick debugging reveals that it never exits the for loop in av_find_stream_info() unless the stream is aborted at the source.

comment:3 Changed 5 years ago by DrLex

If it is of any use, this is the output that follows when killing the stream at the source:

[flv @ 0x9c4f360] Estimating duration from bitrate, this may be inaccurate
Input #0, flv, from 'rtmp:// live=1':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0.0: Audio: nellymoser, 22050 Hz, mono, s16
Output #0, wav, to '/home/drlex/out.wav':
    encoder         : Lavf53.4.0
    Stream #0.0: Audio: pcm_s16le, 22050 Hz, mono, s16, 352 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
size=     124kB time=00:00:02.87 bitrate= 352.9kbits/s    
video:0kB audio:124kB global headers:0kB muxing overhead 0.034652%

comment:4 Changed 5 years ago by jjlee3


Last edited 5 years ago by jjlee3 (previous) (diff)

comment:5 Changed 5 years ago by jjlee3

Add the following code before avcodec_open2 doesn't help.

    c->sample_rate = 44100;
    c->channels = 1;
    c->sample_fmt = AV_SAMPLE_FMT_S16;
Version 0, edited 5 years ago by jjlee3 (next)

comment:6 Changed 5 years ago by jjlee3

Sorry for confusion, I should check 3rd output parameter of avcodec_decode_audio3 not c->frame_size.

comment:7 Changed 4 years ago by ericma

Has a fix for this problem been integrated in to FFMPEG yet? I'm running in to this exact problem and don't have the luxury of changing the audio codec away from Nellymoser ASAO.

comment:8 follow-up: Changed 4 years ago by cehoyos

Could you provide a backtrace when it hangs?

comment:9 in reply to: ↑ 8 Changed 4 years ago by ericma

Replying to cehoyos:

Could you provide a backtrace when it hangs?

I don't know how to provide you with a backtrace. I'm running this in a Mac OS X terminal window.

Following the advice of the original post, I did manage to hack something together that allows me to transcode this stream properly. It's certainly not the desired method, since I'm hardcoding a value for the enc->frame_size to 1024.

comment:10 Changed 4 years ago by ericma

It looks like my hack doesn't really work that well. I'm transcoding an input stream from FMS and outputting it to Wowza. There are these pauses in the transcoding that take long enough (12 seconds) for Wowza to completely deconstruct the stream and then create it again when FFMPEG starts transcoding.

When this happens, the "size= xxxxkB time=xx.xx bitrate= xxx.xkbits/s" is frozen. Then the numbers start changing, signifying that the transcoding has started again.

This is the same with hardcoded frame sizes of 1024, 512, and 256.

comment:11 Changed 4 years ago by michael

Someone, please provide a complete testcase so this can be reproduced. I think this would improve the chances that someone will look into this in case this problem hasnt been fixed yet

comment:12 Changed 4 years ago by DrLex

The test is pretty simple in theory, an example of a command that triggers the problem can be found above. The biggest problem however is getting an FLV stream that uses the NellyMoser? codec. In an attempt to give you something ready-to-use, I have just wasted an hour trying in vain to create such a stream with ffmpeg and ffserver. I believe it would be much simpler and more reliable to use Wowza Media Server with a free developer license. It should be pretty simple to configure Wowza to redistribute audio streams. Or, use any other streaming server of your liking. Then, send the stream to the server with something like:

ffmpeg -f alsa -i hw:0,0 -acodec nellymoser -ar 22050 -ac 1 -f flv 'rtmp://'

And then you can run
ffmpeg -i "rtmp:// live=1" out.wav

However, I have wasted enough time on this for the time being, especially considering that the solution is of no use anymore to me. So if anyone wants to do the small effort of documenting how to get a basic Wowza or other server demo setup working, the few people that are still required to work with the ASAO codec will be thankful.

comment:13 Changed 4 years ago by cehoyos

Can you confirm that the two command lines you posted still fail with current git head?
If yes, please post complete, uncut console output.

comment:14 Changed 4 years ago by richardpl

  • Component changed from avcodec to avformat
  • Keywords rtmp added; codec removed
  • Status changed from new to open

The only way to know sample rate for this codec is from packet size.
So bug is in rtmp, probably missing some code that handle this codec properly.

comment:15 Changed 4 years ago by cehoyos

Is this problem still reproducible with current git head?

comment:16 Changed 4 years ago by DrLex

No, current versions of ffmpeg and ffplay now play these streams.

comment:17 Changed 4 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from open to closed
Note: See TracTickets for help on using tickets.