[FFmpeg-devel] [PATCH] SDP muxer

[Stefano Sabatini]

On date Wednesday 2008-11-26 21:32:02 +0000, Luca Abeni encoded:
> 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).

What about a struct in AVStream?

It could be allocated and set only if the muxer is of some given type
(implementable through a flag) then a function could parse the
filename and fill it in av_new_stream()

Maybe something like AVUrl may do the trick.
 
> >>> 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

Doh! I really meant AVFormatContext!

> 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.

I wonder if this feature could be useful in the RTP muxer too,
implementing the same logic for assigning the port to the various
elementary streams.

It makes sense to me for example define something like this:
ffmpeg -i test.mpeg -f rtp rtp://localhost:5004

where the resulting RTP output format also contains a video stream.
 
> >> 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.

I'll soon apply it.

Regards.
-- 
FFmpeg = Frenzy and Faboulous Magic Patchable Exciting Glue