On Mon, 30 Apr 2018, Carl Eugen Hoyos wrote:
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.
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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
