Opened 4 years ago

Closed 3 years ago

#2409 closed defect (fixed)

ffmpeg hangs while trying to play live FLV stream with Speex

Reported by: DrLex Owned by:
Priority: important Component: undetermined
Version: git-master Keywords: rtmp speex regression
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Change History (10)

comment:1 Changed 4 years ago by cehoyos

  • Component changed from avformat to undetermined
  • Keywords rtmp speex regression added; Speex RTMP removed
  • Priority changed from normal to important

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

comment:2 Changed 4 years ago by cehoyos

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

comment:3 follow-up: Changed 4 years ago by DrLex

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.

comment:4 in reply to: ↑ 3 Changed 4 years ago by cehoyos

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!

comment:5 Changed 4 years ago by cehoyos

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

comment:6 Changed 4 years ago by DrLex

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

comment:7 Changed 4 years ago by cehoyos

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

Version 0, edited 4 years ago by cehoyos (next)

comment:8 follow-up: Changed 3 years ago by DrLex

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.

comment:9 in reply to: ↑ 8 Changed 3 years ago by michael

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 ...

comment:10 Changed 3 years ago by michael

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