[FFmpeg-devel] [PATCH] RTSP muxer, round 2

[Martin Storsjö]

On Wed, 13 Jan 2010, Michael Niedermayer wrote:

> On Tue, Jan 12, 2010 at 03:05:01PM +0200, Martin Storsj? wrote:
> > 
> > Would a change like the attached one be ok? (The patch is against the 
> > combined result of the patch series, but shows the new utility functions.)
> > 
> > For initializing the AVCodecContext, I'd say its best to leave it up to 
> > each occasion of chained muxers - in this case simply referring to the 
> > codec context of the master is the easiest, but in some other cases one 
> > may want to copy most of it but change some fields. In that case, we'd 
> > probably need some kind of avcodec_context_copy(), to copy/initialize the 
> > fields correctly.
> 
> sounds like a scarily fragile mess
> having a struct that sometimes is a copy that needs to be freed and sometimes
> not
> I really wanted chained (de) muxers to become th basis of several things
> what you describe does not sound like its useable for any of that
> example, one wants to mux dv video & audio in dv and that in avi or
> mpeg ps in mov. (these silly formats exist sadly ...)
> or even mux rtsp in mov ;) (this one hopefully doesnt exist ...)
> your 2 functions just dont do that, the surrounding code is missing
> also lav* private API has ff_ prefixes not av_

Hmm, then I think what we're doing here differs a bit from what you're 
aiming at with chained muxers.

With "chained muxers" in this setup, we don't write the output from the 
"RTSP muxer" into an RTP muxer - RTSP only is the connection setup 
protocol, that sets up several RTP sessions. So we've got a 
AVFormatContext for RTSP, with n AVStreams. Internally, this creates n 
AVFormatContexts for RTP, one for each of the streams. The RTSP write 
packet function simply writes the packet into the correct RTP 
AVFormatContext. So it isn't a case of writing the output of one muxer 
into another, just keeping track of the RTP sessions and sending packets 
to the correct streams.

> and if you choose to keep this stuff in rtsp i dont mind but i think
> it is a huge mess. And this might be less than fun to maintain because
> the AVStream API can change and this can easily break the copy hacks
> in rtsp without anyone noticing

Yes, it may easily break - I personally think that my first approach with 
using the RTP muxer internally wouldn't have had that problem, but this 
approach has other advantages.

But without a better suggestion on how to abstract this cleanly (Luca A/B, 
Ronald?) I think it's better to leave it like this for now. When there are 
more examples of chained muxers, it's much easier to abstract out the 
common parts that should be shared.

> and at the least, i guess AVMetadata AVChapters AVProgram copying is
> missing but probably alot more

None of them really are relevant to RTSP/RTP, I think.

// Martin