[FFmpeg-devel] [PATCH] Add an RTSP muxer
Luca Abeni
lucabe72
Tue Jan 5 11:41:19 CET 2010
Hi Martin,
On 05/01/10 00:09, Martin Storsj? wrote:
[...]
>> 0003-5 is for Luca (A).
>> 0006-0007 appear to touch upon a deeper issue, I'd just add the
>> AVFormatContext (that's not ic, right?) to the struct instead. This is
>> a bit ugly. You're removing ic in 0014, which I think is a bad idea.
>> I'd drop these two and convert ic into being the AVFormatContext that
>> you take pb from and use as a log context. (That's how the RTP/RTSP
>> demuxer parts work.)
>
> That unfortunately doesn't really work like that (straight away in my
> current design, at least) for the rtp muxers. In the RTSP/RTP demuxers,
> the RTSP demuxer owns URLContexts where it reads packets, and if packets
> are received, they are fed to RTPDemuxContexts for parsing. The
> RTPDemuxContexts thus never actually touch the actual RTP streams that are
> owned by the RTSP demuxer. (Or did I understand this incorrectly?)
I think you correctly understand the demuxer. The fact is that we have
an RTP muxer, but we have no RTP demuxer. So, receiving and sending RTP
packets work in two different ways, according to different designs.
I am obviously biased, but I like the RTP muxer design better. I think
that using a muxer API instead of directly accessing some internal
functions is a cleaner and more flexible approach. And it allows to
reduce the number of dependencies without introducing too many "#ifdef"s.
> The RTP muxers on the other hand send out the actual rtp packets deep
> inside the packetization routines. So they're not exactly symmetrical in
> their design... Calling the RTP muxers with the RTSP AVFormatContext won't
> work.
Right. I believe the RTSPStream structure should contain a pointer to
the AVFormatContext representing the RTP muxer (which is initialised in
the "write_header" function). So, the RTSP "write" function should just
find the correct AVFormatContext and call the RTP write method passing
such an AVFormatContext as a parameter.
I am writing this without having actually tried this approach, and the
devil usually is in the details... So, maybe I am missing something
obvious. But I think something like the approach described above should
work. I'll experiment a little bit with it in the next weekend.
Thanks,
Luca
More information about the ffmpeg-devel
mailing list