2018-04-30 14:42 GMT+02:00, Marton Balint <c...@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 <c...@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. >> 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. Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
