rtsp regression

[Carl Eugen Hoyos]

The sample stream from ticket #3222 cannot be decoded since 0a5da9cc / c6f1dc8e

$ ffmpeg -i rtsp://strm01.novotempo.org.br/radionovotempo-vivo out.wav
ffmpeg version N-59032-g3dbf9af Copyright (c) 2000-2013 the FFmpeg developers
  built on Dec 12 2013 23:44:02 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      52. 58.100 / 52. 58.100
  libavcodec     55. 45.101 / 55. 45.101
  libavformat    55. 22.100 / 55. 22.100
  libavdevice    55.  5.102 / 55.  5.102
  libavfilter     3. 92.100 /  3. 92.100
  libswscale      2.  5.101 /  2.  5.101
  libswresample   0. 17.104 /  0. 17.104
  libpostproc    52.  3.100 / 52.  3.100
[mp3 @ 0x282d8a0] Header missing
    Last message repeated 51 times
[rtsp @ 0x2827900] decoding for stream 0 failed
[rtsp @ 0x2827900] Could not find codec parameters for stream 0 (Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, 2 channels, s16p, 256 kb/s): unspecified frame size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
rtsp://strm01.novotempo.org.br/radionovotempo-vivo: could not find codec parameters

[GstBlub]

I tested this stream with the last ffmpeg releases and found that it was last working with ffmpeg 1.1.7 "Fire Flower".

I suspect this commit introduced this bug: ​http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=2326558d5277ec87ba6d607a01ec6acfc51c694c

[Carl Eugen Hoyos]

Why do you think that my original report was wrong?

[GstBlub]

Replying to cehoyos:

Why do you think that my original report was wrong?

I don't, but I'm not as familiar with git. Is your reference to "0a5da9cc / c6f1dc8e" the same commit I linked to? If so, I apologize, I'm just not as familiar with git.

[Carl Eugen Hoyos]

Replying to GstBlub:

Replying to cehoyos:

Why do you think that my original report was wrong?

I don't, but I'm not as familiar with git. Is your reference to "0a5da9cc / c6f1dc8e" the same commit I linked to?

Not exactly, no.
Testing again, I can reproduce my original findings.

[GstBlub]

I just wanted to point out the last release that it was still working, in hope it might be helpful trying to track down the root cause.

[GstBlub]

I tracked down what broke it: ​http://git.videolan.org/?p=ffmpeg.git;a=commit;h=c6f1dc8e4cd967ae056698eafb891a08003c211c

What is happening is that in libavformat/utils.c in read_frame_internal() we're checking st->need_parsing, and if this value is non-zero we'll call parse_packet. Prior to this particular change, need_parsing was set in libavformat/rtpdec.c in ff_rtp_parse_open(). This change removes this code and instead moves it into libavformat/rtpdec_mpeg12.c. However, the code there is never called for this stream, so need_parsing is never initialized. Because this stream has an ID3 header, it then doesn't parse the ID3 header and subsequently can't ever find the mpeg header.

But it isn't actually using that depayer, it's trying to use the x-asf-pf depayer specified by the SDP:

Breakpoint 15, ff_rtp_handler_find_by_name (name=0x7fffffff5da0 "x-asf-pf", codec_type=AVMEDIA_TYPE_AUDIO) at libavformat/rtpdec.c:102
102         for (handler = rtp_first_dynamic_payload_handler;
(gdb) bt
#0  ff_rtp_handler_find_by_name (name=0x7fffffff5da0 "x-asf-pf", codec_type=AVMEDIA_TYPE_AUDIO) at libavformat/rtpdec.c:102
#1  0x000000000059d497 in sdp_parse_rtpmap (s=0x1a349e0, st=0x1a3a2c0, rtsp_st=0x1a39d00, payload_type=96, p=0x7fffffff6192 "/1000")
    at libavformat/rtsp.c:219
#2  0x000000000059e586 in sdp_parse_line (s=0x1a349e0, s1=0x7fffffff60d0, letter=97, buf=0x7fffffff6180 "rtpmap:96 x-asf-pf/1000")
    at libavformat/rtsp.c:492
#3  0x000000000059ee6e in ff_sdp_parse (s=0x1a349e0,
    content=0x1a381a0 "v=0\r\no=- 201401171205450711 201401171205450711 IN IP4 127.0.0.1\r\ns=<No Title>\r\nc=IN IP4 0.0.0.0\r\nb=AS:258\r\na=maxps:3223\r\nt=0 0\r\na=control:rtsp://strm01.novotempo.org.br:554/radionovotempo-vivo/\r\na=eta"...) at libavformat/rtsp.c:623
#4  0x00000000005a60e6 in ff_rtsp_setup_input_streams (s=0x1a349e0, reply=0x7fffffffc3b0) at libavformat/rtspdec.c:597
#5  0x00000000005a27e6 in ff_rtsp_connect (s=0x1a349e0) at libavformat/rtsp.c:1757
#6  0x00000000005a6524 in rtsp_read_header (s=0x1a349e0) at libavformat/rtspdec.c:690
#7  0x00000000005cd5ba in avformat_open_input (ps=0x7fffffffdf90, filename=0x7fffffffe8af "rtsp://strm01.novotempo.org.br/radionovotempo-vivo",
    fmt=0x0, options=0x1a25968) at libavformat/utils.c:544
#8  0x0000000000407e32 in open_input_file (o=0x7fffffffe0e0, filename=0x7fffffffe8af "rtsp://strm01.novotempo.org.br/radionovotempo-vivo")
    at ffmpeg_opt.c:801
#9  0x000000000040f794 in open_files (l=0x1a1e0d8, inout=0xf44f57 "input", open_file=0x407769 <open_input_file>) at ffmpeg_opt.c:2506
#10 0x000000000040f8f8 in ffmpeg_parse_options (argc=6, argv=0x7fffffffe628) at ffmpeg_opt.c:2543
#11 0x0000000000420b3e in main (argc=6, argv=0x7fffffffe628) at ffmpeg.c:3433

The x-asf-pf depayloader resolves to ff_ms_rtp_asf_pfa_handler... the troubling part is that that structure is declared and registered, but no where defined. A grep ff_ms_rtp_asf_pfa_handler * -R over the entire source tree yields only this:

libavformat/rtpdec_formats.h:extern RTPDynamicProtocolHandler ff_ms_rtp_asf_pfa_handler;
libavformat/rtpdec.c:    ff_register_dynamic_payload_handler(&ff_ms_rtp_asf_pfa_handler);

[Carl Eugen Hoyos]

Replying to GstBlub:

I tracked down what broke it: ​http://git.videolan.org/?p=ffmpeg.git;a=commit;h=c6f1dc8e

I thought I did that?

[GstBlub]

Again, sorry I'm not as familiar with git. I guess I wasted my time.

[GstBlub]

Patch that fixes the bug

[Carl Eugen Hoyos]

Fixed by Martin Storsjö since c1333a76