[FFmpeg-devel] [PATCH 1/2] lavf: add AVOption support for muxers

Martin Storsjö martin
Sat Jan 1 23:15:27 CET 2011


On Sun, 2 Jan 2011, Anssi Hannula wrote:

> On 01.01.2011 22:56, Martin Storsj? wrote:
> > On Sat, 1 Jan 2011, Anssi Hannula wrote:
> > 
> >> On 01.01.2011 22:18, Martin Storsj? wrote:
> >>> On Sat, 1 Jan 2011, Anssi Hannula wrote:
> >>>
> >>>> On 01.01.2011 21:01, Michael Niedermayer wrote:
> >>>>> On Sat, Jan 01, 2011 at 06:15:08PM +0200, Martin Storsj? wrote:
> >>>>>> On Sat, 1 Jan 2011, Michael Niedermayer wrote:
> >>>>>>
> >>>>>>> applications using private fields are writtenm in the knowledge that they will
> >>>>>>> stop working the next commit to ffmpeg
> >>>>>>
> >>>>>> What about applications registering muxers/demuxers of their own? In that 
> >>>>>
> >>>>> They should submit them to us and not do that :)
> >>>>> That said iam not against keeping the next parameter at a constant location
> >>>>> i just dont care too much about it
> >>>>
> >>>> Wouldn't applications registering their own muxers break anyway?
> >>>> If added after the "next" field, the new "priv_class" field would be
> >>>> outside the application-provided AVOutputFormat when checked by
> >>>> av_set_parameters().
> >>>
> >>> No, it can be solved relatively cleanly, check how we did it for 
> >>> av_reigster_protocol2.
> >>
> >> What I meant is that simply keeping "next" field at a constant location
> >> doesn't solve the issue alone.
> > 
> > Ah, yeah. True.
> > 
> >> Adding a new function that takes a size parameter would obviously allow
> >> self-registered muxers to continue to work.
> > 
> > Are you interested in trying to keep the ABI unbroken, and willing to try 
> > to incorporate this into your patchset? If not, I can try to wrap 
> > something together, within a few days.
> 
> Not really.
> 
> > Or is there any need at all for this? Those users that do deep integration 
> > of lavf (mplayer, VLC, XBMC etc), do any of them register 
> > muxers(/demuxers) of their own?
> 
> At least not those three.
> 
> > If not, there's not much need for it in 
> > practice. The same was added to AVCodec some time ago, without any similar 
> > ABI fallback, and nobody seems to have complained yet at least.
> > 
> > On the other hand, I'd think such complaints would come only later when 
> > binary distribution maintainers start using newer lavf versions. But a 
> > ABI-compatible register function can be fixed later if really needed, too.
> 
> I just looked over the 67 packages that are linked against the ffmpeg
> shared libraries in Mandriva. None of them registered their own codecs.
> The only package registering formats was libavdevice, which is part of
> ffmpeg. 4 packages registered their own protocols (motion,
> gmerlin-avdecoder, audacious-plugins, deadbeef).

Ok, that's valuable information. Thanks for taking the time to look into 
it.

I'd say disregard this then. If needed, it can well be added later (and 
since noone outside of the lib needs to use "next", its location shouldn't 
matter).

// Martin



More information about the ffmpeg-devel mailing list