On 12/14/17, wm4 <nfx...@googlemail.com> wrote: > 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...
color range via api, either buffersink or buffersrc are optional and not mandatory. It is ffplay issue that it ignores color range, comming from AVFrame itself. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
