[FFmpeg-devel] [PATCH] RTSP muxer, round 2
Wed Jan 13 09:03:11 CET 2010
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
> 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.
More information about the ffmpeg-devel