[issue2277] RTP parser not invoked for rtp:// URLs
Martin Storsjö mar...@martin.st added the comment: FWIW, a demuxer that handles receiving raw rtp:// URLs without having a local SDP description was committed in SVN rev 25527. -- substatus: wont_implement - implemented FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2277
[issue2277] RTP parser not invoked for rtp:// URLs
Martin Storsjö mar...@martin.st added the comment: Hi, Thanks for locating the bug, I'll have a look at it shortly. As for this issue, there is no duplication between rtpproto and rtpdec, both of them are used in the full setup, at different levels. rtpproto is the main handler of rtp:// urls, which doesn't do much other than receive (or send) udp packets, but over two different ports, for RTP and RTCP separately. This is used as input within the RTSP and SDP demuxers, and may be used as output with the RTP muxer. So yes, as you noticed, if you just receive data straight over rtp:// without invoking a demuxer that calls the rtpdec code, it won't do what you want. You wouldn't use the rtp:// protocol handler directly except for when sending with the RTP muxer. As you also noticed, if you either receive it over RTSP or if you provide a SDP file that describes the stream, the proper rtpdec depacketizer will be used. And it has to be said, that your case with mpeg2ts over RTP is one of the very special cases where a container format itself is sent over RTP, where it actually almost would work to let the demuxer itself receive it from the rtp:// proto handler. And none of the maintainers have access to such streams to test for compliance. I'm closing this issue with won't implement, since this does work just as it is intended to, although it is a bit non-obvious. -- status: new - closed substatus: new - wont_implement FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2277
[issue2277] RTP parser not invoked for rtp:// URLs
New submission from Robert Schlabbach rober...@gmx.net: It appears that when using an RTP input URL, the input is _not_ passed through the RTP parser, but instead the raw packets still containing the (unparsed) RTP header are directly passed to the contained protocol handler, such as mpegts. I haven't figured out the exact code paths, so far I can tell that in: libavformat/mpegts.c the function read_packet() gets buffers that start with the RTP header rather than the MPEG-2 TS sync byte. As the RTP header may contain the same byte value as the MPEG-2 TS sync byte, MPEG-2 TS synchronization is erroneous. E.g. using the command line: ./ffprobe rtp://239.35.129.11:1 to probe an RTP/UDP stream containing MPEG-2 TS exhibits this behavior. I'm actually wondering if there is any scenario in which the RTP parser actually gets invoked? -- messages: 12164 priority: normal status: new substatus: new title: RTP parser not invoked for rtp:// URLs type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2277
[issue2277] RTP parser not invoked for rtp:// URLs
Robert Schlabbach rober...@gmx.net added the comment: Ok, I've figured out the data path now: libavformat/mpegts.c - read_packet() - libavformat/aviobuf.c - get_buffer() - libavformat/aviobuf.c - fill_buffer() - libavformat/avio.c - url_read() - libavformat/rtpproto.c - rtp_read() So the packet read from the socket via recvfrom() in libavformat/rtpproto.c is copied to the buffer that libavformat/mpegts.c passed _without ever being parsed_. How to change this so that the RTP parser functions in libavformat/rtpdec.c come into play? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2277
[issue2277] RTP parser not invoked for rtp:// URLs
Robert Schlabbach rober...@gmx.net added the comment: Further investigation reveals that the RTP parser in rtpdec.c is invoked from rtsp.c and apparently through playing SDP files. So I created a simple SDP file for the same RTP/UDP multicast stream as in the first message above: v=0 c=IN IP4 239.35.129.11 m=application 1 RTP/AVP 33 And the result is - even WORSE! This parser does more harm than good. It's absolutely broken. So to summarize my assessment: 1. There are currently two completely different pieces of code for handling RTP/UDP multicast input 2. The rtp:// protocol handler (rtpproto.c/h) is bogus as it does not parse RTP at all. It is actually only a UDP protocol handler. 3. The RTP parser for SDP (rtsp.c, rtpdec.c) is severely broken and provides even worse results than not parsing RTP at all. 4. This is a complete mess, and I don't even know where to start fixing it. As the code in rtsp.c/rtpdec.c looks rather messy, I'd be more inclined to start with rtpproto.c and implement a new, working RTP parser from scratch there. Then again, rtsp/rtpdec.c supports protocols that rtpproto.c doesn't, so making that more universal solution work might allow doing away with the double rtpproto.c. Any guidance on how to proceed at this point? Which solution do the maintainers favor? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2277
[issue2277] RTP parser not invoked for rtp:// URLs
Robert Schlabbach rober...@gmx.net added the comment: Update: I've located the bug in rtpdec.c which broke RTP/UDP multicast streaming via SDP files, and submitted a patch under issue #2280. I'll leave this issue to its original purpose, which is what to do about the rtp:// URL protocol handler, which does not go through the RTP parser. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2277
