[FFmpeg-devel] [PATCH] SDP muxer

[Luca Abeni]

Hi,

Stefano Sabatini wrote:
[...]
>> But looking at Aurelien's email it seems that AVStream->filename cannot 
>> be used in this way... So the patch is not good (and I think the SDP 
>> muxer should be designed to work in a different way, since I suspect it 
>> cannot use AVStream->filename).
> 
> Yes, so the problem is to store the destination address of the stream,
> which is different for each stream so it can't be simply specified in
> the AVFormatContext.

Yes, this is the real problem when implementing an SDP muxer. I have no 
good ideas for addressing it; I remember seeing proposals about storing 
all the destination addresses in the URL, or using some metadata in 
AVFormatContext, adding fields to AVFormatContext, etc... But I do not 
remember any idea that fully convinced me (I believe the key point is to 
make something that is not really SDP/RTP specific).


>>> Also in the code we're assuming that an RTP AVOutputStream may contain
>>> more than one AVStream, does this make sense?
>> I do not know... In the definition of AVOutputStream in ffmpeg.c I see 
>> that it contains a pointer to a single AVStream: where is this "more 
>> than one AVStream" assumption? 
> 
> Sorry I really meant AVOutputStream

This is intended. avf_sdp_create() is designed to be both flexible and 
easy to use. If every RTP stream has a different destination address, 
then the only possible solution is to use an array of AVFormatContexts, 
and each of them has only one stream. But an RTSP server generally uses 
a single destination address (and allocating the ports as p, p+2, etc... 
  is reasonable), so in this case a single AVFormatContext (with 
multiple streams) can be used, simplifying the caller. ffserver uses 
this feature, for example.


>> Sorry, no. sdp_write_header is ok. If you really hate this name, or you 
>> want to use it for different things, this can be changed in something 
>> like sdp_write_session_level_description.
> 
> Mmh, afterall I begin to see the logic into those names, please check
> the attached patch to see which of the remaining renamings I'm doing
> make sense to you.

This one looks ok.


				Luca