[FFmpeg-devel] [PATCH] lavc: add new API for iterating codecs and codec parsers

Rostislav Pehlivanov atomnuker at gmail.com
Sun Dec 24 14:39:21 EET 2017


On 24 December 2017 at 11:43, Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Sun, Dec 24, 2017 at 02:31:16AM +0100, wm4 wrote:
> > On Sun, 24 Dec 2017 02:06:40 +0100
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> >
> > > If you and others agree we can also easily maintain support for user
> apps
> > > to register codecs. The only thing needed is to make the array bigger
> and
> > > add codecs which arent ours in there as long as there is space.
> > > doing this would be very easy, a atomic integer pointing to the begin
> of
> > > the free space which is atomically increased for each register is all
> that
> > > is needed
> >
> > Not sure how often I repeated this (specifically for you), but:
>
> why are you so upset ? We have different oppinions here or we misunderstand
> each other.
>
>
> >
> > - users can't provide AVCodec, because it would require accessing
> >   internal API and private ABI unstable fields
>
> That is expected without there being an effort to design a public API
> for external codecs.
>
> Point being, this doesnt matter.
> One can still maintain an external codec register it and use it.
> It would need to be rebuild for each libavcodec version and would
> occasionally need to be changed like any internal codec.
> But it would not be harder than maintaining a codec inside ffmpeg.
>
> Especially if one targets a release like 3.4.x it would be close to 0
> work to have a external codec that is registered compared to having it
> internal
>
>

Stop derailing the thread, both of you. We're not going to support external
codecs now,
nor in the future. This has been discussed before. Much of the work that
would be done on
supporting external codecs is better spent with a disassembler on some
binary of a yet
another H264/HEVC copy.


More information about the ffmpeg-devel mailing list