Martin Storsjö <[email protected]> added the comment: It may work for some RTP urls, but not for all. It would not, for example, work in a case where the SDP actually would contain parameters necessary for receiving the streams.
Given the way demuxers and protocol handlers are handled in libavformat, if you just specify rtp://.. as source and nothing else, the framework will try to read data blindly from that URL (receiving the raw, undecoded packets) and try to probe which demuxer gives the highest score for that data, making a demuxer read this raw unpacketized data. You might ask why we don't do the unpacking/depacketization at the protocol level then, and the reason is that it isn't really doable at that level for all RTP formats, although it might work for mpegts. For mpegts, it might work on the raw "bytestream" level, but for most other formats, we need to work at the AVPacket level, and thus within a demuxer itself. What actually could work, though, would be to add another demuxer that matches all rtp:// urls, just like the RTSP demuxer matches all rtsp:// urls. This would try to blindly receive packets from that URL, and once a packet is received, check the payload type from the packet, try to construct a fake SDP for that stream, and then hand it over to the SDP demuxer. This could work for these mpegts streams, and for some audio streams (everything that uses fixed payload types and don't require any extradata passed via the SDP could work this way). ________________________________________________ FFmpeg issue tracker <[email protected]> <https://roundup.ffmpeg.org/issue2280> ________________________________________________
