Robert Schlabbach <[email protected]> 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 10000 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 <[email protected]> <https://roundup.ffmpeg.org/issue2277> ________________________________________________
