ffmpeg hangs while trying to play live FLV stream with Speex

[Alexander]

Summary of the bug:
When trying to play a live audio RTMP stream that uses the Speex codec, ffmpeg never starts playing until the stream is aborted at the source.

How to reproduce:

1. Set up a streaming server like Red5, Wowza, etc. with a simple "live" application that distributes streams.
2. Create an outgoing RTMP stream that streams the microphone:

   ffmpeg -f alsa -i hw:0,0 -acodec libspeex -ab 42200 -ar 16000 -ac 1 -f flv 'rtmp://127.0.0.1:1935/live live=1'
   

3. Try to play back this stream:

   ffmpeg -v verbose -i 'rtmp://127.0.0.1:1935/live live=1' -ac 2 -ar 44100 -f alsa plug:dmix
   

Nothing will happen until the ffmpeg instance from step 2 is killed, then all buffered audio will start playing.


When using the 'nellymoser' codec instead in step 2, the stream will start playing (after a while):

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

Tested with current Git snapshot from ​git://source.ffmpeg.org/ffmpeg.git:

ffmpeg version 1.1.git-acaee26 Copyright (c) 2000-2013 the FFmpeg developers
  built on Mar 28 2013 15:08:58 with gcc 4.4.5 (Debian 4.4.5-8)

Most ironic is that one of the reasons why we currently use Speex, is that older versions of ffmpeg used to freeze on NellyMoser streams, and not on Speex. Now it is exactly the other way round.

[Carl Eugen Hoyos]

If you believe this is a regression, please find the change introducing the bug.

[Carl Eugen Hoyos]

Is a rtmp server necessary to reproduce this problem or is it also possible without?

[Alexander]

The version we previously used with successful Speex live stream playback was 0.8.4.

The fact that it is a live stream seems an essential part of the problem, therefore an RTMP server is probably essential. The problem may be the lack of a proper Speex header in the RTMP stream.

[Carl Eugen Hoyos]

Replying to DrLex:

The version we previously used with successful Speex live stream playback was 0.8.4.

Please use git bisect to find the offending commit.
This is sometimes not trivial, I will assist you!

[Carl Eugen Hoyos]

One simpler thing you could do is of course to provide a backtrace when FFmpeg hangs.

[Alexander]

This is a backtrace of where the ffmpeg from step 3 hangs:

#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb7db93d1 in recv () at ../sysdeps/unix/sysv/linux/i386/socket.S:61
#2  0xb7e1e3c5 in RTMPSockBuf_Fill () from /usr/lib/librtmp.so.0
#3  0xb7e20458 in ?? () from /usr/lib/librtmp.so.0
#4  0xb7e20530 in RTMP_ReadPacket () from /usr/lib/librtmp.so.0
#5  0xb7e233d8 in RTMP_GetNextMediaPacket () from /usr/lib/librtmp.so.0
#6  0xb7e234ab in ?? () from /usr/lib/librtmp.so.0
#7  0xb7e23fe5 in RTMP_Read () from /usr/lib/librtmp.so.0
#8  0x080dc533 in retry_transfer_wrapper (transfer_func=<optimized out>, 
    size_min=<optimized out>, size=<optimized out>, buf=<optimized out>, 
    h=<optimized out>) at libavformat/avio.c:274
#9  ffurl_read (h=0x889a900, buf=0x88b8c24 "", size=1076)
    at libavformat/avio.c:307
#10 0x080de398 in fill_buffer (s=0x88a88a0) at libavformat/aviobuf.c:425
#11 0x080de4b7 in avio_r8 (s=0x88a88a0) at libavformat/aviobuf.c:471
#12 0x080f5dbc in flv_read_packet (s=0x889a3e0, pkt=0xbfffe844)
    at libavformat/flvdec.c:656
#13 0x081b478f in ff_read_packet (s=0x889a3e0, pkt=0xbfffe844)
    at libavformat/utils.c:787
#14 0x081b75ae in read_frame_internal (s=0x889a3e0, pkt=0x889a3e0)
    at libavformat/utils.c:1432
#15 0x081b8b0d in avformat_find_stream_info (ic=0x889a3e0, options=0x88a8aa0)
    at libavformat/utils.c:2873
#16 0x08076c3d in open_input_file (o=0xbfffee28, 
    filename=0xbffff4a8 "rtmp://10.100.1.5:1935/voicedemo live=1")
    at ffmpeg_opt.c:815
#17 0x08073ba5 in open_files (l=<optimized out>, inout=<optimized out>, 
    open_file=<optimized out>) at ffmpeg_opt.c:2470
#18 0x08073ee0 in ffmpeg_parse_options (argc=12, argv=0xbffff2b4)
    at ffmpeg_opt.c:2507
#19 0x08087aa0 in main (argc=12, argv=0xbffff2b4) at ffmpeg.c:3317

[Carl Eugen Hoyos]

Your backtrace does not necessarily indicate a bug in FFmpeg, don't you agree? What happens if you compile without librtmp?

[Alexander]

The trace I gave was obtained by simply interrupting the program wherever it happened to be. The fact that the break happened in librtmp is simply because it spends most of its time there.

Adding breakpoints reveals that the real infinite loop not in librtmp. It is the one at libavformat/utils.c:2811. The correct way to get out of that loop is at line 2855, and this is never reached unless the source stream is interrupted.

If I compile without librtmp, I get:

[rtmp @ 0x9d7dcc0] Unknown connect error (unsupported authentication method?)
[rtmp @ 0x9d7dcc0] Server error: Connection failed: Application folder ([install-location]/applications/) is missing.

This does not make any sense because the applications folder is where it should be, and it works with librtmp and every other rtmp-aware program. The Wowza logs reveal that the application name "live" is not inside the request. If I search for this issue, all I find are recommendations to compile with librtmp. This looks like another bug that was never reported because everyone sticks to librtmp.

[Michael Niedermayer]

Replying to DrLex:

Adding breakpoints reveals that the real infinite loop not in librtmp. It is the one at libavformat/utils.c:2811. The correct way to get out of that loop is at line 2855, and this is never reached unless the source stream is interrupted.

Can you try to find out whats the difference between nelly moser and speex, why one is stuck in the loop
and the other exits?
Id look into it myself but ive no rtmp server setup ...

[Michael Niedermayer]

Fixed in 5312c319be98c63b8e59695222a13068a0dbc7ab