[FFmpeg-devel] [PATCH] Add an RTSP muxer

[Martin Storsjö]

Hi Luca,

On Mon, 4 Jan 2010, Luca Abeni wrote:

> On 04/01/10 16:11, Martin Storsj? wrote:
> > Here's a stab at a RTSP muxer, tested with a Darwin Streaming Server
> > setup.
> 
> First of all, thanks for contributing this muxer!
> 
> Then, there are a lot of patches, and I currently have not much time for
> reviewing them... I promise to review all the rtpenc.c and sdp.c patches in
> the next weekend.
> 
> My first impression (but it might be wrong):
> - I tend to think that patch 02/24 is not needed (I think it's better to avoid
> passing host names to avf_sdp_create(), so that sdp.c does not need to resolve
> the address).

Ok, that would require some further modifications to the RTSP code, 
though.

> - Patch 03/24 looks ok. But maybe avf_sdp_create() should just fail if the
> destination address is not "rtp://"
> - I still have to think about patch 04/24.

In the RTSP/RTP setup procedure, the destination port isn't known when 
creating the SDP, so port will inevitably be 0 here. And as far as I can 
see from the SDP specs in RFC, a c= line is mandatory - the current code 
in sdp.c leaves out this line if n_files == 1 and port <= 0.



> - I need to better understand your rtpenc.c patches. Well, I understand what
> the patches do, but I do not understand why all those changes are needed (for
> example, patch 10/24 says "Use the AVStream st member from RTPMuxContext
> instead of AVFormatContext->streams[0]", but it does not explain why. BTW, I
> just noticed that the "st" field of RTPMuxContext seems to be unused...).

> It seems that your goal is to use the rtpenc code without using an 
> output format context... Why? Cannot the RTSP muxer create one or more 
> proper RTP muxers, and use them, instead of exposing some of the RTP 
> muxer internals?

Yes, that was my goal. I wasn't really sure how to chain the muxers, to 
connect the AVStream* that the user set in the RTSP AVFormatContext to the 
internal RTP AVFormatContexts (just simply copy the pointers?), and thus I 
thought using RTPMuxContext directly would be leaner.