Beginner: VOB to x265 conversion ends up in crappy color

[Wader8]

Hello

I'm no way an expert on codecs and conversion, but I know the basics and I'm not an ordinary PC user so I learn fast.

I know there's many fine tuning with these these 2 codecs but I am not very familiar with most of them. I'm sure I'm not doing all those things to make sure color is transferred over properly.



I will start reading up here, and I just made this thread in an attempt someone could at least help me with some quick tips to know up start and point me into the right direction, if it's even worth x265 over x264 at this time I don't know.

I did some conversion which was totally different and didn't involve this codecs, right now this project for the 1 week or so involves just a few DVD that I need for archival, and that concat and preferrably reconvert to a more modern codec as well as save on space, but space isn't that important, i don't need heavy compression, so that's the tertiary priority, first is to get rid of the split-file natrue of DVDs (which i think is clutter I really don't want to deal with on a big archival disc I want it all sorted nice and low filesystem complexity, but that's pretty easy with simple concat.

////////////////// Processing: VTS_CON ////////
----------------- /////////////////// ---------

ffmpeg version N-76137-gb0bb1dc Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 5.2.0 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable
-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --e
nable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-am
rnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --
enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-
libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid
 --enable-lzma --enable-decklink --enable-zlib
  libavutil      55.  4.100 / 55.  4.100
  libavcodec     57.  7.100 / 57.  7.100
  libavformat    57.  8.102 / 57.  8.102
  libavdevice    57.  0.100 / 57.  0.100
  libavfilter     6. 12.100 /  6. 12.100
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.100 /  2.  0.100
  libpostproc    54.  0.100 / 54.  0.100
Routing option strict to both codec and muxer layer
[mpeg @ 0000000000604d20] max_analyze_duration 5000000 reached at 5000000 microseconds st:0
Input #0, mpeg, from 'VTS_CON.vob':
  Duration: 01:41:46.37, start: 0.540000, bitrate: 6070 kb/s
    Stream #0:0[0x1e0]: Video: mpeg2video (Main), 1 reference frame, yuv420p(tv, bt470bg), 720x576 [SAR 64:45 DAR 16:9], 7500 kb/s
, 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x80]: Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s
[Parsed_fps_1 @ 0000000000606680] fps=25/1
[graph 0 input from stream 0:0 @ 0000000000617600] w:720 h:576 pixfmt:yuv420p tb:1/90000 fr:25/1 sar:64/45 sws_param:flags=2
[graph 1 input from stream 0:1 @ 0000000002d5b780] tb:1/48000 samplefmt:fltp samplerate:48000 chlayout:0x60f
[audio format for output stream 0:1 @ 0000000002d5b900] auto-inserting filter 'auto-inserted resampler 0' between the filter 'Pars
ed_anull_0' and the filter 'audio format for output stream 0:1'
[auto-inserted resampler 0 @ 0000000002d5b9c0] ch:6 chl:5.1(side) fmt:fltp r:48000Hz -> ch:6 chl:5.1 fmt:fltp r:48000Hz
x265 [info]: HEVC encoder version 1.8+1-5dcc9d3a928c400b
x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features       : 8 / wpp(9 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut       : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-16.0 / 0.60
x265 [info]: tools: rect rd=4 psy-rd=0.30 rdoq=2 psy-rdoq=1.00 signhide tmvp
x265 [info]: tools: strong-intra-smoothing deblock sao
Output #0, mp4, to 'VTS_FIN-crf.mp4':
  Metadata:
    encoder         : Lavf57.8.102
    Stream #0:0: Video: hevc (libx265), 1 reference frame ([35][0][0][0] / 0x0023), yuv420p, 720x576 [SAR 64:45 DAR 16:9], q=2-31,
 25 fps, 12800 tbn, 25 tbc
    Metadata:
      encoder         : Lavc57.7.100 libx265
    Stream #0:1: Audio: aac ([64][0][0][0] / 0x0040), 48000 Hz, 5.1, fltp, 192 kb/s
    Metadata:
      encoder         : Lavc57.7.100 aac
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video (native) -> hevc (libx265))
  Stream #0:1 -> #0:1 (ac3 (native) -> aac (native))
Press [q] to stop, [?] for help
No more output streams to write to, finishing.me=01:41:45.13 bitrate=1360.3kbits/s
frame=152659 fps= 12 q=-0.0 Lsize= 1018256kB time=01:41:46.36 bitrate=1366.0kbits/s
video:870519kB audio:143313kB subtitle:0kB other streams:0kB global headers:1kB muxing overhead: 0.436329%
Input file #0 (VTS_CON.vob):
  Input stream #0:0 (video): 152659 packets read (4234228734 bytes); 152660 frames decoded;
  Input stream #0:1 (audio): 190824 packets read (341956608 bytes); 190824 frames decoded (293105664 samples);
  Total: 343483 packets (4576185342 bytes) demuxed
Output file #0 (VTS_FIN-crf.mp4):
  Output stream #0:0 (video): 152659 frames encoded; 152659 packets muxed (891411212 bytes);
  Output stream #0:1 (audio): 286236 frames encoded (293105664 samples); 286237 packets muxed (146752998 bytes);
  Total: 438896 packets (1038164210 bytes) muxed
[Parsed_fps_1 @ 0000000000606680] 152660 frames in, 152659 frames out; 1 frames dropped, 0 frames duplicated.
x265 [info]: frame I:   2416, Avg QP:12.72  kb/s: 4204.88
x265 [info]: frame P:  36706, Avg QP:17.32  kb/s: 2332.94
x265 [info]: frame B: 113537, Avg QP:21.64  kb/s: 725.47
x265 [info]: Weighted P-Frames: Y:5.9% UV:2.9%
x265 [info]: consecutive B-frames: 10.3% 4.0% 11.4% 33.6% 40.6%

encoded 152659 frames in 12551.65s (12.16 fps), 1167.05 kb/s, Avg QP:20.46
[aac @ 00000000006058a0] Qavg: 565.242



Press any key to continue . . .

I was using the latest zeranoe winx64 ffmpeg release for this. It took 3.4 Hours for the full test run to finish with these settings.

[hello_hello]

I'm no ffmpeg expert but it's hard to compare screenshots when they're not the exact same frame (I assume they're not given you can see more of the guy on the left in the tight screenshot). The exact same player would be good too. MPC-HC has an option to allow it to run more than one instance of the player at a time (under Player in options). It's Navigation menu lets you navigate to a specific frame. Try comparing the two that way (and use the EVR or VMR9 renderer, under Playback/Output).
Theoretically, the colour shouldn't change due to re-encoding. YV12 in, YV12 out, and nothing changes in between. It's possibly a playback issue.

If the video's actually interlaced, I'd consider de-interlacing to 50fps progressive rather than 25fps as motion should look smoother. I don't know how to de-interlace that way using Yadif and ffmpeg but it should be possible.

[KarMa]

For reasons I don't fully understand, MPC-HC has more color variances and color adjustments. Try just using VLC only for your comparisons. I can never get VLC and MPC-HC to agree on color even when messing with MPC-HC settings.

[Wader8]

Oh lol the reason why i used VLC is because deinterlace didn't work in MPC-HC, turns out i have to enable it in LAV decoder.

I am not deeply familiar with this color variances in different applications but I've seen it and didn't recall this time, so if these apps all are different, what the heck is the correct color then ?

The frames aren't exactly the same yes but after posting I went to check it again and there is not much difference in those sorrounding frames other than movement of the camera.

EDIT: I cannot open this VOB with MPC-HC with EVR even trying both yadif interlace options in LAV.

EDIT2: VLC can't play HEVC ...

i was also using 2.1.5 Ricewind VLC, now upgrading to 2.2.1

MPC-HC is version 1.7.6 July 2014. With LAV 0.62.0.0 but this will have to wait, i do maintain my PC in good order and I don't want to slap things on in a few minutes on the fly just to get something half-working, I am currently in the basement with this PC since im renovating my room upstairs, I have to log all my settings and I have MADVR and all the configs setup with this MPC-HC and I don't want to break something and not knowing how it was set up. That's just how I do things, slower and as manual as possible so I don't rely on the automatic processes of "importing configurations" i rather do it clean and good, so I definitely don't want to install a new MPC-HC directly over this setup.

[LigH.de]

I could imagine two reasons:

a) One player is using the Hardware Overlay renderer, therefore the other player can't use it as well at the same time. Overlay and any other desktop renderer may have different colorimetry ranges.

b) The MPEG-2 video in the DVD Video will probably be decoded using ITU-R BT.601 (a.k.a. Rec601) colorimetry. If the conversion to HEVC changed it, or the player believes for any other reason that HEVC has to be decoded in BT.709 (a.k.a. Rec709) colorimentry instead, this will result in a slight hue shift. It may be useful to verbosely set up libx265 to use "Rec601", but I am not sure which of several command line options (maybe two of them) should be added.

[Wader8]

Well it appears like Enhanced Video Renderer (EVR) has this hue problem.

previous screenshots also have flux over them unfortunately, because of the way it works, I obviously don't notice it when I view it on the web either.

[theewizard]

there is only one perfect way to compare them

use only one player
goto the same frame
take a snapshot using the screen capture built into the player

do it again with the new converted file
compare the images in your favorite image viewing program

you can NOT accurately compare color, using different players and different render's side by side

[Wader8]

I'll keep this in mind next time, thanks.

[hello_hello]

Oh lol the reason why i used VLC is because deinterlace didn't work in MPC-HC, turns out i have to enable it in LAV decoder.

I am not deeply familiar with this color variances in different applications but I've seen it and didn't recall this time, so if these apps all are different, what the heck is the correct color then ?

I'm still running XP and use the VMR9 (renderless) rederer with MPC-HC and I can open multiple instances of the player without it causing colour differences. Older renderers mightn't work the same way, but I often have several instances of MPC-HC opening video at the same time (sometimes the source along with different Avisynth scripts for comparison) and the colours are fine.

Have you checked your video card's settings and disabled any of it's video enhancing, colour altering crap? If it's set to change the picture in any way it'll most likely do so for MPC-HC and not VLC. I think if the video card is set to adjust the picture (Nvidia calls it using the Nvidia settings rather than using the player's settings) MPC-HC's own colour adjusting option will no longer work. VLC has colour adjustment options of it's own and while I don't dully understand why, I assume because VLC uses it's own renderer it's not effected by the video card settings and it's own adjustment controls always work. At least that's how it works for me. The video card settings may or may not work when using MadVR. I can't remember, but for me, with any image altering stuff disabled in the video card, player and/or renderer (in the case of MadVR at least) the image should look exactly the same. It does for me, regardless of the renderer I use with MPC-HC and it looks the same as VLC. If the video card is set to expand limited range video to full range (16-235 to 0-255) that's probably a good thing and an exception to disabling all the video card's options. It should ensure the video luminance levels display correctly in most players with all renderers.

You don't need to install a new MPC-HC. Just doenload the portable bersion, unzup it, and run it. There's an option to tell it to save it's settings to an ini file rather than the registry. Enable that, and you should be able to play around without effecting the "installed" MPC-HC's settings. I have MPC-HC in a few different folders, each using it's own ini file with different settings.

I don't understand the "flux" reference. There appears to be some sort of colorimetry difference, but I'm not getting my head around those screenshots (apart from using a different renderer/player). When you look at the encoded video with MPC-HC/MediaInfo (via File/Properties), does it show anything relating to colorimetry?