On 12/8/17, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Fri, Dec 8, 2017 at 10:46 AM, Paul B Mahol <one...@gmail.com> wrote:
>> Signed-off-by: Paul B Mahol <one...@gmail.com>
>> ---
>> libavcodec/mjpegdec.c | 18 +++++++++---------
>> libavcodec/mjpegenc.c | 4 ++--
>> libavcodec/mjpegenc_common.c | 5 +----
>> tests/fate/vcodec.mak | 21 ++++++++++++++-------
>> 4 files changed, 26 insertions(+), 22 deletions(-)
>>
>> diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
>> index d2fcb8e191..5f7b685e56 100644
>> --- a/libavcodec/mjpegenc.c
>> +++ b/libavcodec/mjpegenc.c
>> @@ -415,7 +415,7 @@ AVCodec ff_mjpeg_encoder = {
>> .close = ff_mpv_encode_end,
>> .capabilities = AV_CODEC_CAP_SLICE_THREADS |
>> AV_CODEC_CAP_FRAME_THREADS | AV_CODEC_CAP_INTRA_ONLY,
>> .pix_fmts = (const enum AVPixelFormat[]) {
>> - AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
>> AV_PIX_FMT_NONE
>> + AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P,
>> AV_PIX_FMT_NONE
>> },
>
> This will basically break everyone encoding mjpeg right now, since it
> suddenly only accepts different formats without any common-ground
> before/after.
> Furthermore, there is no replacement for the indication that this
> encoder wants full-range data, which the old pixfmts indicated.
So I will add .color_range to AVCodec
0 means encoder supports both.
Is that ok?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
