[FFmpeg-devel] [PATCH 4/5] avutil/pixdesc: add AV_PIX_FMT_FLAG_ALPHA to AV_PIX_FMT_PAL8
Marton Balint
cus at passwd.hu
Mon Apr 30 23:44:22 EEST 2018
On Mon, 30 Apr 2018, Carl Eugen Hoyos wrote:
> 2018-04-30 14:42 GMT+02:00, Marton Balint <cus at passwd.hu>:
>>
>> On Wed, 25 Apr 2018, Michael Niedermayer wrote:
>>
>>> On Tue, Apr 24, 2018 at 09:05:00PM +0200, Marton Balint wrote:
>>>> Signed-off-by: Marton Balint <cus at passwd.hu>
>>>> ---
>>>> doc/APIchanges | 3 +++
>>>> libavcodec/tests/imgconvert.c | 4 ----
>>>> libavutil/pixdesc.c | 3 +--
>>>> libavutil/pixdesc.h | 8 ++------
>>>> libavutil/tests/pixdesc.c | 4 ----
>>>> libavutil/version.h | 2 +-
>>>> 6 files changed, 7 insertions(+), 17 deletions(-)
>>>
>>> this with the rest of the patchset seems not to break anything
>>> so no objections from me
>>
>> Thanks, will apply soon.
>
> Please do.
Applied the series.
>
>>> i was wondering though if when a 2nd PAL8 is introduced which will
>>> be with alpha
>>>
>>> PAL8 and PAL8A seemed a natural choice name wise
>>> iam mentioning this as if these 2 would be used then the addition of alpha
>>> to PAL8 would have to be undone.
>>> so it would make sense to first decide if the new format will be with or
>>> without alpha
>>
>> Keeping in mind compatibility, I think it is better if the new format gets
>> to be the one without alpha (PAL8_NO_ALPHA or whatever), even if that not
>> fits fully in the existing naming convention.
>
> I wanted to agree but applications have to learn about the new
> format in any case since with your suggestion, we would have
> to change most pal decoders.
Yeah, changing the pixel format of a codec will always be a suprise for
API users unless they are using a filter chain or swscale to get a fixed
pixel format in which case the change should be transparent enough.
Regards,
Marton
More information about the ffmpeg-devel
mailing list