Converting from YUVJ to YUV lose contrast

[sghpunk]

I am trying to transcode video from my Nicon D90 mjpeg to x264.
And output video contrast is lower than input.
I use ffmpeg-HEAD-27614b1

Command line:
ffmpeg.exe -threads 2 -an -i input.mkv -f matroska -vcodec libx264 -profile main -preset fast -cqp 27 -y x264-low_contract_yuv.mkv > enc.log 2>&1

ffmpeg version UNKNOWN, Copyright (c) 2000-2011 the FFmpeg developers
  built on May 19 2011 17:41:01 with gcc 4.5.2
  configuration: --prefix=/mingw --disable-static --enable-shared --enable-gpl --enable-version3 --disable-doc --enable-postproc --disable-network --enable-memalign-hack --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libmp3lame --enable-libspeex --enable-libvorbis --enable-libx264 --enable-pthreads --enable-frei0r --extra-cflags='-mthreads -mtune=nocona -march=nocona -msse3 -m80387 -mfpmath=387 -O2 -fgnu89-inline -Wno-error=missing-prototypes' --extra-ldflags='-Wl,--enable-auto-image-base -Wl,--enable-auto-import' --extra-libs=-ldl --cpu=nocona
  libavutil    51.  2. 1 / 51.  2. 1
  libavcodec   53.  5. 0 / 53.  5. 0
  libavformat  53.  0. 3 / 53.  0. 3
  libavdevice  53.  0. 0 / 53.  0. 0
  libavfilter   2.  5. 0 /  2.  5. 0
  libswscale    0. 14. 0 /  0. 14. 0
  libpostproc  51.  2. 0 / 51.  2. 0
[matroska,webm @ 00b70280] Estimating duration from bitrate, this may be inaccurate
Input #0, matroska,webm, from 'input.mkv':
  Metadata:
    MAKER           : NIKON CORPORATION
    MODEL           : NIKON D90
    CREATION_TIME   : 2011-05-05 07:47:28
    ENCODER         : Lavf53.0.3
  Duration: 00:00:05.04, start: 0.000000, bitrate: N/A
    Stream #0.0: Video: mjpeg, yuvj422p, 1280x720, PAR 1:1 DAR 16:9, 24 fps, 24 tbr, 1k tbn, 24 tbc (default)
Incompatible pixel format 'yuvj422p' for codec 'libx264', auto-selecting format 'yuv420p'
[buffer @ 00b83e00] w:1280 h:720 pixfmt:yuvj422p tb:1/1000000 sar:1/1
[ffsink @ 003efee0] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out'
[scale @ 00b95920] w:1280 h:720 fmt:yuvj422p -> w:1280 h:720 fmt:yuv420p flags:0xa0000004
[libx264 @ 00b60540] using SAR=1/1
[libx264 @ 00b60540] using cpu capabilities: MMX2 SSE2 SSE3 Cache64
[libx264 @ 00b60540] profile Main, level 3.1
[libx264 @ 00b60540] 264 - core 114 - H.264/MPEG-4 AVC codec - Copyleft 2003-2011 - http://www.videolan.org/x264.html - options: cabac=1 ref=2 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=6 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=1 keyint=250 keyint_min=24 scenecut=40 intra_refresh=0 rc=cqp mbtree=0 qp=27 ip_ratio=1.40 pb_ratio=1.30 aq=0
Output #0, matroska, to 'x264-low_contract_yuv.mkv':
  Metadata:
    MAKER           : NIKON CORPORATION
    MODEL           : NIKON D90
    CREATION_TIME   : 2011-05-05 07:47:28
    encoder         : Lavf53.0.3
    Stream #0.0: Video: libx264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 1k tbn, 24 tbc (default)
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
frame=   10 fps=  0 q=27.0 size=      33kB time=10000000000.00 bitrate=   0.0kbits/s    
...CUT...
frame=  121 fps=  5 q=-1.0 Lsize=     864kB time=4.96 bitrate=1427.9kbits/s    
video:863kB audio:0kB global headers:0kB muxing overhead 0.173612%
frame I:1     Avg QP:24.00  size: 33897
[libx264 @ 00b60540] frame P:41    Avg QP:27.00  size: 10846
[libx264 @ 00b60540] frame B:79    Avg QP:28.66  size:  5118
[libx264 @ 00b60540] consecutive B-frames:  6.6% 11.6% 22.3% 59.5%
[libx264 @ 00b60540] mb I  I16..4: 44.1%  0.0% 55.9%
[libx264 @ 00b60540] mb P  I16..4:  7.9%  0.0%  4.9%  P16..4: 42.7% 10.5%  3.3%  0.0%  0.0%    skip:30.7%
[libx264 @ 00b60540] mb B  I16..4:  3.9%  0.0%  0.6%  B16..8: 30.6%  7.4%  0.3%  direct: 8.4%  skip:48.7%  L0:41.1% L1:53.7% BI: 5.2%
[libx264 @ 00b60540] coded y,uvDC,uvAC intra: 29.7% 47.0% 14.1% inter: 8.7% 11.9% 0.1%
[libx264 @ 00b60540] i16 v,h,dc,p: 31% 31% 24% 14%
[libx264 @ 00b60540] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 20% 20%  5%  7%  7%  6%  6%  3%
[libx264 @ 00b60540] i8c dc,h,v,p: 63% 18% 16%  3%
[libx264 @ 00b60540] Weighted P-Frames: Y:2.4% UV:2.4%
[libx264 @ 00b60540] ref P L0: 75.4% 24.6%
[libx264 @ 00b60540] ref B L0: 80.3% 19.7%
[libx264 @ 00b60540] ref B L1: 94.1%  5.9%
[libx264 @ 00b60540] kb/s:1401.04

ffmpeg -v 9 -loglevel 99 -i input.mkv > v9.log 2>&1

ffmpeg version UNKNOWN, Copyright (c) 2000-2011 the FFmpeg developers
  built on May 19 2011 17:41:01 with gcc 4.5.2
  configuration: --prefix=/mingw --disable-static --enable-shared --enable-gpl --enable-version3 --disable-doc --enable-postproc --disable-network --enable-memalign-hack --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libmp3lame --enable-libspeex --enable-libvorbis --enable-libx264 --enable-pthreads --enable-frei0r --extra-cflags='-mthreads -mtune=nocona -march=nocona -msse3 -m80387 -mfpmath=387 -O2 -fgnu89-inline -Wno-error=missing-prototypes' --extra-ldflags='-Wl,--enable-auto-image-base -Wl,--enable-auto-import' --extra-libs=-ldl --cpu=nocona
  libavutil    51.  2. 1 / 51.  2. 1
  libavcodec   53.  5. 0 / 53.  5. 0
  libavformat  53.  0. 3 / 53.  0. 3
  libavdevice  53.  0. 0 / 53.  0. 0
  libavfilter   2.  5. 0 /  2.  5. 0
  libswscale    0. 14. 0 /  0. 14. 0
  libpostproc  51.  2. 0 / 51.  2. 0
[NULL @ 00b70280] Format matroska,webm probed with size=2048 and score=100
st:0 removing common factor 1000000 from timebase
[mjpeg @ 00b7b700] buffer too small, expanding to 73330 bytes
[mjpeg @ 00b7b700] marker=d8 avail_size_in_buf=73330
[mjpeg @ 00b7b700] marker parser used 0 bytes (0 bits)
[mjpeg @ 00b7b700] marker=db avail_size_in_buf=73328
[mjpeg @ 00b7b700] index=0
[mjpeg @ 00b7b700] qscale[0]: 3
[mjpeg @ 00b7b700] index=1
[mjpeg @ 00b7b700] qscale[1]: 6
[mjpeg @ 00b7b700] marker parser used 132 bytes (1056 bits)
[mjpeg @ 00b7b700] marker=c0 avail_size_in_buf=73194
[mjpeg @ 00b7b700] sof0: picture: 1280x720
[mjpeg @ 00b7b700] component 0 2:1 id: 0 quant:0
[mjpeg @ 00b7b700] component 1 1:1 id: 1 quant:1
[mjpeg @ 00b7b700] component 2 1:1 id: 2 quant:1
[mjpeg @ 00b7b700] pix fmt id 21111100
[mjpeg @ 00b7b700] marker parser used 17 bytes (136 bits)
[mjpeg @ 00b7b700] marker=c4 avail_size_in_buf=73175
[mjpeg @ 00b7b700] class=0 index=0 nb_codes=12
[mjpeg @ 00b7b700] class=1 index=0 nb_codes=251
[mjpeg @ 00b7b700] class=0 index=1 nb_codes=12
[mjpeg @ 00b7b700] class=1 index=1 nb_codes=251
[mjpeg @ 00b7b700] marker parser used 418 bytes (3344 bits)
[mjpeg @ 00b7b700] escaping removed 115 bytes
[mjpeg @ 00b7b700] marker=da avail_size_in_buf=72755
[mjpeg @ 00b7b700] component: 0
[mjpeg @ 00b7b700] component: 1
[mjpeg @ 00b7b700] component: 2
[mjpeg @ 00b7b700] marker parser used 72639 bytes (581110 bits)
[mjpeg @ 00b7b700] marker=d9 avail_size_in_buf=3
[mjpeg @ 00b7b700] mjpeg decode frame unused 3 bytes
[matroska,webm @ 00b70280] All info found
[matroska,webm @ 00b70280] Estimating duration from bitrate, this may be inaccurate
Input #0, matroska,webm, from 'input.mkv':
  Metadata:
    MAKER           : NIKON CORPORATION
    MODEL           : NIKON D90
    CREATION_TIME   : 2011-05-05 07:47:28
    ENCODER         : Lavf53.0.3
  Duration: 00:00:05.04, start: 0.000000, bitrate: N/A
    Stream #0.0, 1, 1/1000: Video: mjpeg, yuvj422p, 1280x720, 1/24, PAR 1:1 DAR 16:9, 24 fps, 24 tbr, 1k tbn, 24 tbc (default)
At least one output file must be specified

Seems like contrast loosing when converting a pixel format from yuvj422p to yuv420p.
I tryed to encode same video from mplayer yuv4mpeg raw file and in this case contrast on output video is the same.

I cannot find mplayer ftp server to upload samples. Where can I upload it?

[sghpunk]

OS Windows XP SP3 32bit

[sghpunk]

And upload.ffmpeg.org not responding...

[Carl Eugen Hoyos]

Is the problem also reproducible with the following command line?

ffmpeg.exe -an -i input.mkv -qscale 2 low_contrast_yuv.mkv

You can use ​http://www.datafilehost.com/ to upload samples.

(Did you build FFmpeg yourself or did you download your executable?)

[sghpunk]

Ok, I upload input file ​http://www.datafilehost.com/download-dfec691e.html
Output file: ​http://www.datafilehost.com/download-a3c7345e.html

And, yes with command line:

ffmpeg.exe -an -i input.mkv -qscale 2 low_contrast_yuv.mkv

The same problem, low contrast. Here is encoding log:

ffmpeg version UNKNOWN, Copyright (c) 2000-2011 the FFmpeg developers
  built on May 19 2011 17:41:01 with gcc 4.5.2
  configuration: --prefix=/mingw --disable-static --enable-shared --enable-gpl --enable-version3 --disable-doc --enable-postproc --disable-network --enable-memalign-hack --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libmp3lame --enable-libspeex --enable-libvorbis --enable-libx264 --enable-pthreads --enable-frei0r --extra-cflags='-mthreads -mtune=nocona -march=nocona -msse3 -m80387 -mfpmath=387 -O2 -fgnu89-inline -Wno-error=missing-prototypes' --extra-ldflags='-Wl,--enable-auto-image-base -Wl,--enable-auto-import' --extra-libs=-ldl --cpu=nocona
  libavutil    51.  2. 1 / 51.  2. 1
  libavcodec   53.  5. 0 / 53.  5. 0
  libavformat  53.  0. 3 / 53.  0. 3
  libavdevice  53.  0. 0 / 53.  0. 0
  libavfilter   2.  5. 0 /  2.  5. 0
  libswscale    0. 14. 0 /  0. 14. 0
  libpostproc  51.  2. 0 / 51.  2. 0
[matroska,webm @ 00b70280] Estimating duration from bitrate, this may be inaccurate
Input #0, matroska,webm, from 'x264-low_contract_yuv_input.mkv':
  Metadata:
    MAKER           : NIKON CORPORATION
    MODEL           : NIKON D90
    CREATION_TIME   : 2011-05-05 07:47:28
    ENCODER         : Lavf53.0.3
  Duration: 00:00:05.04, start: 0.000000, bitrate: N/A
    Stream #0.0: Video: mjpeg, yuvj422p, 1280x720, PAR 1:1 DAR 16:9, 24 fps, 24 tbr, 1k tbn, 24 tbc (default)
Incompatible pixel format 'yuvj422p' for codec 'mpeg4', auto-selecting format 'yuv420p'
[buffer @ 003eff60] w:1280 h:720 pixfmt:yuvj422p tb:1/1000000 sar:1/1
[ffsink @ 00b604a0] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out'
[scale @ 00ba7e60] w:1280 h:720 fmt:yuvj422p -> w:1280 h:720 fmt:yuv420p flags:0xa0000004
Output #0, matroska, to 'low_contrast_yuv.mkv':
  Metadata:
    MAKER           : NIKON CORPORATION
    MODEL           : NIKON D90
    CREATION_TIME   : 2011-05-05 07:47:28
    encoder         : Lavf53.0.3
    Stream #0.0: Video: mpeg4, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 1k tbn, 24 tbc (default)
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
...CUT...
video:3980kB audio:0kB global headers:0kB muxing overhead 0.048334%

And result output file: ​http://www.datafilehost.com/download-12f6e2a2.html
I build ffmpeg myself.

[Carl Eugen Hoyos]

I am unable to reproduce your problem:
I extracted the jpeg's from your input file (ffmpeg -i yuvj_input.mkv -vcodec copy out%03d.jpg), converted the result to different formats (ffmpeg -i out001.jpg -qscale 2 out.avi and ffmpeg -i out001.jpg out.png), but the images all look very similar to me.
What software are you using to display the videos (or how do you know the contrast is different?
Can you also reproduce the problem with ffplay out001.jpg (and with ffplay yuvj_input.mkv)?

Concerning your compilation: I believe your extra-cflags affect the performance of the resulting binary negatively, if this is wrong, please report it, so we can fix the build process.

[sghpunk]

Mplayer2 different contrast

[sghpunk]

I do the same, as you described.
And I can say... It is more complicated, than I thought...
(ffmpeg -i out001.jpg out.png) - No differences, as you say.
And here (ffmpeg -i out001.jpg -qscale 2 out.avi) begins a ... gm ... magic ))
When I play out.avi with mplayer2 (​http://www.mplayer2.org/), there is difference between jpg and avi (avi is less contrast), but when I play out.avi with KMplayer, there is no contrast differences... Only little white balance, but it is not so important.
So. I don't understand, maybe it is mlayer2 bug, or ffmpeg bug but not in that place that I thought. (Because mplayer2 use the same ffmpeg for decoding video).
I attached a screenshot with two opened mplayer2 windows (left - input file with normal contrast, right - output file with low contrast), seems like on this screenshot contrast differences looks good. (If not, you can in gimp test a color value in same white places on image, and see the difference).
But I still cannot understand, why when i use yuv4mpeg raw file for encoding there is no contrast differences in mplayer2.

About compiler options, I not test it so deep, I do this later, and maybe you can recommend what test I can perform to be sure is that options efficient or not.

[sghpunk]

KMPlayer input mjpeg normal contrast

[sghpunk]

KMPlayer output x264 low contrast

[sghpunk]

Mplayer2 input mjpeg normal contrast

[sghpunk]

Mplayer2 output x264 low contrast

[sghpunk]

Seems like I was wrong, when say, that contrast in KMPlayer is the same.
Contrast in KMPlayer is different to. In previous test I just looked at screen, but KMplayer video renderer just render latest rendered pucture in both opened KMPlayer instances when on pause.
Now I does "Save frame..." with KMplayer and vf=screenshot with mplayer2.
So you can see different contrast on attached pictures.

[sperate]

I have the same problem.

yuvj420p pixels are encoded from 0 to 255.
When converted to yuv420p AVI (mpeg4 and libxvid) the range is reduced to 16 - 235, thus we can notice a loss of contrast.
When converted to yuv420p MP4 (libx264) the output range stays untouched (0 - 255).

A way to skirt this "problem", which I don't know if it is one actually, is to use the option

-vf mp=eq=0:0

It's an equaliser filter used to adjust brightness and contrast ported from mplayer.
As you can see it does no modification to the values of contrast and brightness but helps leaving untouched the pixel values range.

Having seen that, i figured out a lot of divx movies (maybe all) and all the videos downloaded from youtube or dailymotion had a pixel range between 16 and 235 which led to bad contrast on the vast majoroty of computer video players. AND THIS FOR LONG TIME NOW !!

The trick i'm using to recover a good constrast is to use Media Malyer Classic which offers different pixel shaders including one to go from 16-235 to 0-255.

I find it so SILLY that we're looking at poor constrast videos on our computer screens for such a long time without almost no alternative !!!

Regards.

[Elon Musk]

there is -vf colormatrix filter

[sperate]

Replying to richardpl:

there is -vf colormatrix filter

Yes, but this tends to become complicate as we only need to deal with luminance.

The real question is :

As there are so many videos with pixel ranges from 16 to 235, corresponding to old analog video standards and the necessity to pass synch signals under 0V and to avoid bursts in the image due to nervous response on the line, do we have to encode AVI's with 0-255 output range or do we need to have players that detects this reduced range and adapts to it by expanding the pixel range to 0-255 ?

[Hendrik]

Some short facts on the topic:

• 99.9% of all content is encoded as 16-235
• TVs (and other consumer electronic devices) usually operate in 16-235
• PC monitors use 0-255

So knowing this, you need to expand the 16-235 to 0-255 when watching video on a PC monitor (or a TV configured for 0-255).
Many PC video players are capable of this, they just need to be told if you watch content on a PC monitor or a TV.

[Dennis]

Related? ​http://ffmpeg.org/trac/ffmpeg/ticket/1636

[Michael Niedermayer]

where can i find input.mkv to reproduce this?

[Carl Eugen Hoyos]

Uploaded to ​http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket225/

[Michael Niedermayer]

I cannot reproduce this, the h264 file looks the same as the input. I assume this has been fixed. If not please reopen and explain how to reproduce it

[DonMoir]

You can set the dynamic range on at least some video cards. With NVIDIA, under Adjust video color settings. Some cards might default to full range (0-255) and some might not. So a reason it could vary what users might see.

[David]

I can no longer reproduce this using H.264 as it seems ffmpeg supports yuvj for H.264 now and no conversion is done.

I can however reproduce by transcoding to VP8 with the following command line:

ffmpeg -threads 2 -an -i yuvj_input.mkv -vb 1k -y webm-low_contrast.webm > enc_webm.log 2>&1

which produces the following output:

ffmpeg version 0.10.7-6:0.10.7-0jon1~raring Copyright (c) 2000-2013 the FFmpeg developers
  built on Jul 15 2013 21:27:34 with gcc 4.7.3
  configuration: --arch=amd64 --disable-stripping --enable-pthreads --enable-runtime-cpudetect --extra-version='6:0.10.7-0jon1~raring' --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --enable-bzlib --enable-libdc1394 --enable-libfreetype --enable-frei0r --enable-gnutls --enable-libgsm --enable-libmp3lame --enable-librtmp --enable-libopencv --enable-libopenjpeg --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-vaapi --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-libcdio --enable-x11grab --enable-libx264 --shlibdir=/usr/lib/x86_64-linux-gnu --enable-shared --disable-static
  libavutil      51. 35.100 / 51. 35.100
  libavcodec     53. 61.100 / 53. 61.100
  libavformat    53. 32.100 / 53. 32.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 61.100 /  2. 61.100
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0.  6.100 /  0.  6.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, matroska,webm, from 'yuvj_input.mkv':
  Metadata:
    MAKER           : NIKON CORPORATION
    MODEL           : NIKON D90
    CREATION_TIME   : 2011-05-05 07:47:28
    ENCODER         : Lavf53.0.3
  Duration: 00:00:05.04, start: 0.000000, bitrate: 14463 kb/s
    Stream #0:0: Video: mjpeg, yuvj422p, 1280x720, SAR 1:1 DAR 16:9, 24 fps, 24 tbr, 1k tbn, 1k tbc (default)
Incompatible pixel format 'yuvj422p' for codec 'libvpx', auto-selecting format 'yuv420p'
[buffer @ 0x181a420] w:1280 h:720 pixfmt:yuvj422p tb:1/1000000 sar:1/1 sws_param:
[buffersink @ 0x1819f40] auto-inserting filter 'auto-inserted scale 0' between the filter 'src' and the filter 'out'
[scale @ 0x181f080] w:1280 h:720 fmt:yuvj422p -> w:1280 h:720 fmt:yuv420p flags:0x4
[libvpx @ 0x182bf20] v1.1.0
Output #0, webm, to 'webm-low_contrast.webm':
  Metadata:
    MAKER           : NIKON CORPORATION
    MODEL           : NIKON D90
    CREATION_TIME   : 2011-05-05 07:47:28
    encoder         : Lavf53.32.100
    Stream #0:0: Video: vp8, yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, 1 kb/s, 1k tbn, 24 tbc (default)
Stream mapping:
  Stream #0:0 -> #0:0 (mjpeg -> libvpx)
Press [q] to stop, [?] for help
frame=  121 fps=  9 q=0.0 Lsize=     187kB time=00:00:05.04 bitrate= 304.5kbits/s    
video:186kB audio:0kB global headers:0kB muxing overhead 0.701462%

[Carl Eugen Hoyos]

Replying to dtombs:

ffmpeg version 0.10.7

Please test current git head, if you are unable to compile, please find static binaries on ​http://ffmpeg.org/download.html

[David]

Yes, same issue. Here's the new log. I also upped the bitrate to avoid too much quality degradation there bit it still looks bad.

ffmpeg version N-55933-g8da23be Copyright (c) 2000-2013 the FFmpeg developers
  built on Aug 31 2013 16:51:13 with gcc 4.7 (Ubuntu/Linaro 4.7.3-1ubuntu1)
  configuration: --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-x11grab --enable-shared
  libavutil      52. 43.100 / 52. 43.100
  libavcodec     55. 29.100 / 55. 29.100
  libavformat    55. 15.100 / 55. 15.100
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 82.102 /  3. 82.102
  libswscale      2.  5.100 /  2.  5.100
  libswresample   0. 17.103 /  0. 17.103
  libpostproc    52.  3.100 / 52.  3.100
Input #0, matroska,webm, from 'yuvj_input.mkv':
  Metadata:
    MAKER           : NIKON CORPORATION
    MODEL           : NIKON D90
    CREATION_TIME   : 2011-05-05 07:47:28
    ENCODER         : Lavf53.0.3
  Duration: 00:00:05.04, start: 0.000000, bitrate: 14463 kb/s
    Stream #0:0: Video: mjpeg, yuvj422p(pc), 1280x720, SAR 1:1 DAR 16:9, 24 fps, 24 tbr, 1k tbn, 1k tbc (default)
[swscaler @ 0xc86040] deprecated pixel format used, make sure you did set range correctly
[libvpx @ 0xcadc00] v1.1.0
Output #0, webm, to 'webm-low_contrast.webm':
  Metadata:
    MAKER           : NIKON CORPORATION
    MODEL           : NIKON D90
    encoder         : Lavf55.15.100
    Stream #0:0: Video: vp8 (libvpx), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, 1000 kb/s, 1k tbn, 24 tbc (default)
Stream mapping:
  Stream #0:0 -> #0:0 (mjpeg -> libvpx)
Press [q] to stop, [?] for help
frame=  121 fps=6.3 q=0.0 Lsize=     626kB time=00:00:05.04 bitrate=1016.6kbits/s    
video:624kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.208650%

[Carl Eugen Hoyos]

Is the problem you see only reproducible with vp8 output?

[David]

That is the only way I have been able to reproduce it when doing a transcoding so far, since transcoding to vp8 involves the YUVJ -> YUV conversion.

I have also reproduced the contrast loss when using ffplay. If I play the original yuvj_input.mkv using ffplay I get the contrast loss but if I play with mplayer it's full contrast.

Here's output from ffplay, note the "deprecated pixel format" warning.

$ ffplay yuvj_input.mkv 
ffplay version N-55933-g8da23be Copyright (c) 2003-2013 the FFmpeg developers
  built on Sep  7 2013 14:51:01 with gcc 4.7 (Ubuntu/Linaro 4.7.3-1ubuntu1)
  configuration: --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-x11grab --enable-shared
  libavutil      52. 43.100 / 52. 43.100
  libavcodec     55. 29.100 / 55. 29.100
  libavformat    55. 15.100 / 55. 15.100
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 82.102 /  3. 82.102
  libswscale      2.  5.100 /  2.  5.100
  libswresample   0. 17.103 /  0. 17.103
  libpostproc    52.  3.100 / 52.  3.100
Input #0, matroska,webm, from 'yuvj_input.mkv':KB sq=    0B f=0/0   
  Metadata:
    MAKER           : NIKON CORPORATION
    MODEL           : NIKON D90
    CREATION_TIME   : 2011-05-05 07:47:28
    ENCODER         : Lavf53.0.3
  Duration: 00:00:05.04, start: 0.000000, bitrate: 14463 kb/s
    Stream #0:0: Video: mjpeg, yuvj422p(pc), 1280x720, SAR 1:1 DAR 16:9, 24 fps, 24 tbr, 1k tbn, 1k tbc (default)
[swscaler @ 0x7f89681e8700] deprecated pixel format used, make sure you did set range correctly
   0.66 M-V:  0.035 fd=   0 aq=    0KB vq=  440KB sq=    0B f=0/0     

[mantler]

I arrived at this thread because I'm trying to figure out the correct AVColorRange for AV_PIX_FMT_YUVJ*P formats. The handle_jpeg method in libswscale/utils.c uses 1 (corresponding to AVCOL_RANGE_MPEG) when changing yuvj to yuv, and I'm wondering if it should instead use AVCOL_RANGE_JPEG? AVCOL_RANGE_MPEG is a compressed range compared to AVCOL_RANGE_JPEG, and I suspect this is what is causing the contrast issues you're referring to?

[KlausW]

Hi,
i have the same problem of contrast loss as described here.
It happens while using the delogo and vidstabtransform filters (They do the color space conversion).

So far i was able to skirt the problem by using the mplayer filter "mp=eq=0:0".
The "trick" is mentioned above.

Sadly with the latest ffmpeg (2.6) release this mplayer filter does not exists anymore, it's now a native filter "eq" which acts totally different and can not be used to skirt the problem anymore. (At least i was not able to figure out how)

Does anyone know how else i could avoid the contrast loss?

kind regards,
Klaus

[Elon Musk]

What about lutyuv filter?

[Michael Niedermayer]

The yuvj_input.mkv file is identified as using yuvj and correctly converted by ffmpeg.
mplayer seem not to support yuvj formats (see fmt-conversion.c

    // YUVJ are YUV formats that use the full Y range and not just
    // 16 - 235 (see colorspaces.txt).
    // Currently they are all treated the same way.

Thus mplayer displays every file that is identified as yuvj as if it was yuv and thus shows higher contrast than players supporting yuvj. If now such yuvj file is converted to yuv mplayer shows a differece but this is not because theres something faulty in the convertion, both in and output look similar in players supporting yuvj.

Now to make this a bit more complex, it could very well be that some files are misidentified as yuvj when actually they should be yuv but thats a whole different issue and if you suspect thats the case for some file, please open a seperate bug report for that.
This bug report has become very unwieldy with all kinds of somewhat related information making it
hard to find if issues remain in some cases. Opening new terse reports each with a clear reproduceable testcase should make fixing any remaining issues much easier and faster.