Opened 5 years ago

Closed 14 months ago

#225 closed defect (invalid)

Converting from YUVJ to YUV lose contrast

Reported by: sghpunk Owned by:
Priority: normal Component: swscale
Version: git-master Keywords: YUV/YUVJ contrast
Cc: cyan.spam@gmail.com, sxxe@gmx.de Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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?

Attachments (6)

out001.jpg (71.6 KB) - added by cehoyos 5 years ago.
Mplayer_shot.png (426.1 KB) - added by sghpunk 5 years ago.
Mplayer2 different contrast
KMP_yuvj_input.JPG (75.4 KB) - added by sghpunk 5 years ago.
KMPlayer input mjpeg normal contrast
KMP_x264-low_contract_yuv_output.JPG (79.5 KB) - added by sghpunk 5 years ago.
KMPlayer output x264 low contrast
Mplayer_input_yuvj.png (558.6 KB) - added by sghpunk 5 years ago.
Mplayer2 input mjpeg normal contrast
Mplayer_x264_yuv_low_contrast.png (483.6 KB) - added by sghpunk 5 years ago.
Mplayer2 output x264 low contrast

Download all attachments as: .zip

Change History (33)

comment:1 Changed 5 years ago by sghpunk

OS Windows XP SP3 32bit

comment:2 Changed 5 years ago by sghpunk

And upload.ffmpeg.org not responding...

comment:3 Changed 5 years ago by cehoyos

  • Priority changed from important to normal
  • Reproduced by developer unset
  • Status changed from new to open

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?)

comment:4 Changed 5 years ago by 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.

Changed 5 years ago by cehoyos

comment:5 Changed 5 years ago by cehoyos

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.

Changed 5 years ago by sghpunk

Mplayer2 different contrast

comment:6 Changed 5 years ago by 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.

Changed 5 years ago by sghpunk

KMPlayer input mjpeg normal contrast

Changed 5 years ago by sghpunk

KMPlayer output x264 low contrast

Changed 5 years ago by sghpunk

Mplayer2 input mjpeg normal contrast

Changed 5 years ago by sghpunk

Mplayer2 output x264 low contrast

comment:7 Changed 5 years ago by 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.

comment:8 Changed 4 years ago by richardpl

  • Component changed from undetermined to swscale

comment:9 Changed 4 years ago by 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.

comment:10 follow-up: Changed 4 years ago by richardpl

there is -vf colormatrix filter

comment:11 in reply to: ↑ 10 Changed 4 years ago by 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 reduces range and adapts to it by expanding the pixel range to 0-255 ?

Version 1, edited 4 years ago by sperate (previous) (next) (diff)

comment:12 Changed 4 years ago by heleppkes

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.

comment:14 Changed 3 years ago by michael

where can i find input.mkv to reproduce this?

comment:16 Changed 3 years ago by michael

  • Resolution set to worksforme
  • Status changed from open to closed

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

comment:17 Changed 3 years ago by 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.

comment:18 follow-up: Changed 3 years ago by dtombs

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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%

comment:19 Changed 3 years ago by dtombs

  • Cc cyan.spam@gmail.com added

comment:20 in reply to: ↑ 18 Changed 3 years ago by cehoyos

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

comment:21 Changed 3 years ago by dtombs

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%

comment:22 Changed 3 years ago by cehoyos

Is the problem you see only reproducible with vp8 output?

comment:23 Changed 3 years ago by dtombs

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     

comment:24 Changed 2 years ago by 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?

comment:25 Changed 19 months ago by KlausW

  • Cc sxxe@gmx.de added

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

comment:26 Changed 15 months ago by richardpl

What about lutyuv filter?

comment:27 Changed 14 months ago by michael

  • Resolution set to invalid
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.