Martin Storsjö <[email protected]> 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 <[email protected]> <https://roundup.ffmpeg.org/issue2277> ________________________________________________
