Opened 10 years ago

Closed 9 years ago

#527 closed defect (fixed)

NellyMoser codec reports zero frame size and bitrate

Reported by: Alexander 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 by Carl Eugen Hoyos, 10 years ago

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

comment:2 by Alexander, 10 years ago

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 by Alexander, 10 years ago

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 by jjlee3, 10 years ago


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

comment:5 by jjlee3, 10 years ago

Sorry again!

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

comment:6 by jjlee3, 10 years ago

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

comment:7 by ericma, 9 years ago

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 by Carl Eugen Hoyos, 9 years ago

Could you provide a backtrace when it hangs?

in reply to:  8 comment:9 by ericma, 9 years ago

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 by ericma, 9 years ago

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 by Michael Niedermayer, 9 years ago

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 by Alexander, 9 years ago

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 by Carl Eugen Hoyos, 9 years ago

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 by Elon Musk, 9 years ago

Component: avcodecavformat
Keywords: rtmp added; codec removed
Status: newopen

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 by Carl Eugen Hoyos, 9 years ago

Is this problem still reproducible with current git head?

comment:16 by Alexander, 9 years ago

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

comment:17 by Carl Eugen Hoyos, 9 years ago

Resolution: fixed
Status: openclosed
Note: See TracTickets for help on using tickets.