[FFmpeg-devel] [PATCH v16 15/16] avcodec/subtitles: Migrate subtitle encoders to frame-based API and provide a compatibility shim for the legacy api

Andreas Rheinhardt andreas.rheinhardt at outlook.com
Sat Nov 27 12:27:01 EET 2021


Soft Works:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Andreas
>> Rheinhardt
>> Sent: Saturday, November 27, 2021 11:04 AM
>> To: ffmpeg-devel at ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH v16 15/16] avcodec/subtitles: Migrate
>> subtitle encoders to frame-based API and provide a compatibility shim for the
>> legacy api
>>
>> Soft Works:
>>>
>>>
>>>> -----Original Message-----
>>>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Andreas
>>>> Rheinhardt
>>>> Sent: Friday, November 26, 2021 4:09 PM
>>>> To: ffmpeg-devel at ffmpeg.org
>>>> Subject: Re: [FFmpeg-devel] [PATCH v16 15/16] avcodec/subtitles: Migrate
>>>> subtitle encoders to frame-based API and provide a compatibility shim for
>> the
>>>> legacy api
>>>>
>>>> You ported all subtitle encoders at once; this has the downside of
>>>> making the diff bigger and reviewing harder,
>>>
>>> Nah, the changes are always the same, that's simple and straightforward.
>>>
>>
>> But they are in one big commit and that alone makes it harder. Of course
>> the combined diff is not bigger, but actually smaller (see below) when
>> porting everything in one commit.
>>
>>>> but the advantage of
>>>> simplifying the compatibility code, because one knows that one does not
>>>> need to care about the case of an encoder implementing the old API. Yet
>>>> weirdly you didn't take advantage of this. You also did not remove
>>>> AVCodec.encode_sub.
>>>
>>> Are you saying I do not need to keep the compatibility layer for "legacy"
>>> subtitle encoders?
>>>
>>> I thought it's mandatory to keep it, but I'd be glad to remove..
>>>
>>
>> You need to keep the external API around for a while and this will force
>> some internal compatibility layer; but you also added unnecessary
>> internal compatibility layers: In both your new
>> avcodec_encode_subtitle2() as well as the old avcodec_encode_subtitle()
>> you do not need to care about what happens if the encoder implements the
>> old encode_sub API, because it no encoder implements said API any more.
> 
> So there don't exist any external encoders that would need to be supported?
> That's what I had thought.
> 

Of course not. sizeof(AVCodec) is not part of the public API/ABI; to
quote from codec.h: "No fields below this line are part of the public
API. They may not be used outside of libavcodec and can be changed and
removed at will." All the function pointers are below that line and are
private, so you can't create an AVCodec of your own outside of lavc.
(Of course, you could do so in a fork, but you don't have to worry about
forks here.)

This is the same with e.g. AVFilter etc. The only exception is the
lavf-lavd mess.

- Andreas


More information about the ffmpeg-devel mailing list