On Wed, 13 Dec 2017 20:56:30 +0100 (CET) Marton Balint <c...@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 <one...@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... _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel