[FFmpeg-devel] [PATCH 10/24] avcodec/mjpegdec: replace YUVJ pixel formats

[wm4]

On Wed, 13 Dec 2017 20:56:30 +0100 (CET)
Marton Balint <cus at passwd.hu> wrote:

> On Wed, 13 Dec 2017, Michael Niedermayer wrote:
> 
> > On Wed, Dec 13, 2017 at 11:59:26AM +0100, Paul B Mahol wrote:  
> >> Signed-off-by: Paul B Mahol <onemda at gmail.com>
> >> ---
> >>  libavcodec/mjpegdec.c                | 18 +++++++++---------
> >>  libavcodec/tdsc.c                    |  2 +-
> >>  tests/fate/vcodec.mak                |  4 ++--
> >>  tests/ref/fate/api-mjpeg-codec-param |  4 ++--
> >>  tests/ref/fate/exif-image-embedded   |  2 +-
> >>  tests/ref/fate/exif-image-jpg        |  2 +-
> >>  6 files changed, 16 insertions(+), 16 deletions(-)  
> >
> > this breaks ffplay playing a mjpeg in avi
> >
> > ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec mjpeg -t 0.5  -qscale 1 mjpeg.avi
> > ./ffplay mjpeg.avi
> >
> > the output of ffplay looks darker than it should be  
> 
> FFplay does not specify the needed range for its buffersink. If there is a 
> way to specify allowed combinations (e.g. YUV+limited, YUV+unspecified, 
> RGB+full, RGB+unspecified), then this probably can be fixed.
> 
> (As far as I know SDL also does not specify the range of the used 
> pixel formats, but I think YUV is always limited range there, and 
> RGB is always full range)

If a lavfi API user suddenly has to specify the range manually (instead
just over AVFrame), then this is a compatibility issue too. (I'm
talking about non-J pixfmts in both cases.) Poor Paul...