VLC PLayer rendering HEVC MKV file really strangely...

[Lathe]

... and yet, both KM Player and MPC-HC player render the file just fine. I will list below the MediaInfo for the video file and I will post snapshots of both players below.

Also BDRB chokes on the original HEVC file trying to convert it to x264. And, in using Clever FFMpeg, it is converting the file to x264 AVC, BUT... the resulting MKV file as it's converting plays EXACTLY the same way on both players and I have NO bloody idea why...???

Also, after rendering the file to x264, for some reason it seems to play ever so slightly jerky, damnedest thing...

Appreciate any insight or thoughts about this, thanks!

General
Unique ID : 202976396382864838426451038748639539652 (0x98B3D4FCA01849B45B2AE20204C0B1C4)
Complete name : G:HEVC.file.mkv
Format : Matroska
Format version : Version 4
File size : 3.94 GiB
Duration : 1 h 40 min
Overall bit rate : 5 618 kb/s
Frame rate : 23.976 FPS
Encoded date : 2024-09-08 08:25:09 UTC
Writing application : mkvmerge v87.0 ('Black as the Sky') 64-bit
Writing library : libebml v1.4.5 + libmatroska v1.7.1

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 40 min
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 0)
Bit depth : 10 bits
Writing library : x265 3.6+1-aa7f602f7:[Windows][GCC 13.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=4 / numa-pools=24 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-eob / no-eos / no-hrd / info / hash=0 / temporal-layers=0 / no-open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=6 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=32 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=25 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-2:-2 / no-sao / no-sao-non-deblock / rd=3 / selective-sao=0 / early-skip / rskip / rskip-edge-threshold=0.030000 / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / splitrd-skip / rdpenalty=0 / psy-rd=1.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=-1 / crqpoffs=-1 / rc=abr / bitrate=4800 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=0.80 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=1 / chromaloc-top=0 / chromaloc-bottom=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass / no-mcstf / no-sbrc
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

This is how VLC Player renders the file:



This is how the MPC-HC Player renders it:

[ProWo]

Hi Lathe,
you could try to render it to h264, 8 bit.


[Attachment 83967 - Click to enlarge]

[Lathe]

Hi Lathe,
you could try to render it to h264, 8 bit.


[Attachment 83967 - Click to enlarge]

Yessir! That is exactly what I did with your fine program... At least I THINK that is what I did. But, it's not your program that is at fault (at least yours loaded and processed it, BDRB choked on the HEVC file) But yeah, that is pretty much what I did. I guess it has something to do with how VLC Player is interpreting it or something, it's kind of weird. That's why I was hoping that someone like you or other experienced people would see the snapshots and recognize what was going on.

BTW, since I wasn't doing an HDR-SDR conversion, it didn't offer the 'Various' choices where I would normally select 8-bit. So, I was GUESSING that it must automatically convert it to 8 bit when converting to AVC, is that right? I'm out of my depth here as to why the picture is being rendered that way... Yes, I just checked the resulting MKV file with MediaInfo, and it has an 8-bit depth.

***EDIT

Maybe I'll try an older version of VLC Player because I had not noticed that in the past.

[ProWo]

So, I was GUESSING that it must automatically convert it to 8 bit when converting to AVC, is that right?

No, if the source is 10 bit and you leave the pixel format at auto, then the encode ist done with the source bit depth, in this case 10 bit.
if you want 8 bit, you have to select it explicitly.

[poisondeathray]

Check your renderer and output settings. eg. Maybe you are using different renders between VLC and MPCHC

Also, after rendering the file to x264, for some reason it seems to play ever so slightly jerky, damnedest thing...

If the encode was 10bit AVC, that is not HW accelerated and could be "jerky" on some systems. In contrast, 10bit420 HEVC is commonly accelerated by modern GPUs

[Lathe]

Ah, well, thank you both for the input, I really appreciate it! Just trying to get a handle on what's going on and understand it. I also have a full 1080 Blu-ray of the film ('DANGER DIABOLIK') and that is also played very contrasty and grainy, but it does play smoothly. It's just weird how it's almost like VLC Player is rendering it looking like this, which I almost don't mind because it looks super detailed and vibrant and I don't really mind all the grain that much. But, the other players eliminate all that contrasty look and grain on playback where it looks like a totally different film.

Definitely mysterious... 😊

[Lathe]

Well, I went ahead and ran the Shout Factory Blu-ray through BDRB to shrink it to fit a BD, and burned it to Blu-ray and it played perfectly fine on my OPPO. As an experiment I also had tried the HEVC file (which I got in trouble for ) and VLC played both the file and the resulting M2ts file from BDRB exactly the same with with exaggerated contrast and super grainy. So, it simply must just be something about VLC rending this movie that way for some mysterious reason. But, as long as I have the Blu-ray backed up and burned to disc and it plays fine on my OPPO then everything is okay...

[jagabo]

It's full range vs. limited range problem. Something or someone didn't treat the source properly. Or maybe the source is flagged incorrectly.

[Lathe]

It's full range vs. limited range problem. Something or someone didn't treat the source properly. Or maybe the source is flagged incorrectly.

I don't know what the 'Full Range / Limited Range' means, but yeah, I figured that the 'Jerky' part was due to some kind of error in the encoding.

But... that still doesn't explain (and I honestly don't think anything ever will... ) that VLC was simply playing both the HEVC 'encode' and the actual Blu-ray M2ts file exactly the same way, whereas none of the other players played it that way. Definitely weird... One of those Great Anomalies of life...

[jagabo]

Players can be set to always assume full range, always assume limited range, or switch depending on what's flagged in the metadata.

Full range 8 bit video the YUV to RGB conversion assumes Y=0 is full black (RGB=0,0,0) and Y=255 is full white (RGB=255,255,255). Limited range assumes Y=16 is full black, and Y=235 is white. Then it's the job of the YUV to RGB converter adjust the range upon conversion. Ie, Y=16 becomes RGB 0,0,0, Y=235 becomes RGB 255,255,255. Y values outside that range don't lead to valid RGB values.

With 10 bit video full range is Y=0 to Y=1023, limited range Y=64 to Y=940.

[Lathe]

Players can be set to always assume full range, always assume limited range, or switch depending on what's flagged in the metadata.

Full range 8 bit video the YUV to RGB conversion assumes Y=0 is full black (RGB=0,0,0) and Y=255 is full white (RGB=255,255,255). Limited range assumes Y=16 is full black, and Y=235 is white. Then it's the job of the YUV to RGB converter adjust the range upon conversion. Ie, Y=16 becomes RGB 0,0,0, Y=235 becomes RGB 255,255,255. Y values outside that range don't lead to valid RGB values.

With 10 bit video full range is Y=0 to Y=1023, limited range Y=64 to Y=940.

That is very interesting... I kind of see what you mean about the colour ranges. So, say with VLC specifically, how would one check or set these ranges? Do you happen to know? And also, I don't know if this also involves say how VLC was rendering this particular film, in any format, where it showed it with exaggerated contrast and super grainy, as is shown in the captures above. I don't know if that behaviour would fall under these colour ranges that you are referring to.

[Lathe]

Okay, it's official...

I'm an idiot...

Yep, that's about it, pure and simple... I felt my penance should at least be coming back here and telling everyone, NOT that it would especially be a particularly big surprise...

Okay, here goes... and, I'm telling you this is not going to be easy. *sigh... I checked and for some TOTALLY bizarre reason, the VLC visual effects filter had the 'Sharpen' setting checked and it was cranked way up... I know, unbelievable. No F'n wonder nobody knew what the hell I was talking about. I swear, it is shocking that I can even get through the day without serious damage to myself.

Okay, uh... next time hopefully BEFORE I go spouting off to everyone, I will, uh *cough... check the damn settings first. I'm going to go and hide under some rock now...

[Alwyn]

You're forgiven!

[Lathe]

Thank you Father...

[Sharc]

Players can be set to always assume full range, always assume limited range, or switch depending on what's flagged in the metadata.

Once we are at it, here a comparison MPC-HC vs VLC. Scratching my head why VLC outputs different RGB values for certain colors (blue component in the VLC figures). Can't be a 601 vs 709 matrix issue IMO (?). The differences can hardly be spotted by eye though, so it doesn't really hurt. Just wondering.
Any thoughts?

[Lathe]

Players can be set to always assume full range, always assume limited range, or switch depending on what's flagged in the metadata.

Once we are at it, here a comparison MPC-HC vs VLC. Scratching my head why VLC outputs different RGB values for certain colors (blue component in the VLC figures). Can't be a 601 vs 709 matrix issue IMO (?). The differences can hardly be spotted by eye though, so it doesn't really hurt. Just wondering.
Any thoughts?

Very interesting!

[jagabo]

That's a difference in the rendering device. Different players are using different renderers using different hardware and settings. In VLC go to Tools -> Preferences -> Video -> Output. Try the different renderers. Windows GDI (VLC will do the color conversion in software) should give the correct results. Also use your graphics card's setup applet to check/change video properties. Disable all "enhancements" and "auto adjust" settings.

[Lathe]

That's a difference in the rendering device. Different players are using different renderers using different hardware and settings. In VLC go to Tools -> Preferences -> Video -> Output. Try the different renderers. Windows GDI (VLC will do the color conversion in software) should give the correct results. Also use your graphics card's setup applet to check/change video properties. Disable all "enhancements" and "auto adjust" settings.

Sounds like a good suggestion, thanks! I'm also thinking of following the other previous suggestion of just staying with the MPC-HC player, although I'm really used to using VLC.

[jagabo]

MPCHC has the same mechanism for changing renderers. So you can probably get just as bad results from it.

[Lathe]

MPCHC has the same mechanism for changing renderers. So you can probably get just as bad results from it.

Hmmm, thanks!

[Sharc]

That's a difference in the rendering device. Different players are using different renderers using different hardware and settings. In VLC go to Tools -> Preferences -> Video -> Output. Try the different renderers. Windows GDI (VLC will do the color conversion in software) should give the correct results. Also use your graphics card's setup applet to check/change video properties. Disable all "enhancements" and "auto adjust" settings.

Ahhh! The renderers! I totally forgot about this variable in the equation, as with my current setup/configuration MPC-HC always delivered the expected results for various color manipulation tests. Now out of curiosity giving VLC a shot and ugggh ......
Thanks for pointing this out.

[jagabo]

On my computer, the Direct3D11 renderer delivers slightly wrong colors. The Direct3D9, DirectX, Open GL, and Windows GDI renderers are all good. Automatic ends up using Direct3D11.

[Sharc]

^^^^
Exactly the same here.

[Lathe]

That's good to know guys, thanks!