[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