View Full Version : HEVC washed out
djloewen
30th January 2019, 17:39
Hi there, I'm sure there's a simple answer to this but I've been scouring the interwebs for hours and have failed to find it. I have an HEVC video from my own personal collection that I'm trying to re-encode using Megui. No matter what I do the results appear 'washed out'. My understanding is that this is the result of a 10-bit video stream being played 8-bit without dithering?
I've tried indexing the file with DGindexNV, and with FFMSindex. I have left the DG settings as default, I've also tried them with fulldepth=true, followed by ConvertBits(10) and also ConvertBits(8) (using avisynth+). No matter what I do, I can't seem to produce the correct colour results.
I'm quite sure the problem is happening somewhere very early in the process, because even loading up the file for indexing in DGindexNV, the preview already looks washed out. Can someone please help and tell me what I'm missing? Thanks in advance.
Link to a 50MB (5 second) sample, in case it helps:
https://1drv.ms/u/s!An6uYjdKlOMXm49T5hr588cWrZEuZg
lvqcl
30th January 2019, 18:12
That is the result of HDR video.
You can try something from this thread: http://forum.doom9.org/showthread.php?t=175125
excellentswordfight
30th January 2019, 18:15
Without looking at that source, it sounds like this is an HDR/sdr issue, and not an 8bit/10bit issue (although they go a bit hand in hand).
Can you post the mediainfo data from that file?
djloewen
30th January 2019, 18:32
Mediainfo: 3840*2160 (16:9), at 23.976 (24000/1001) FPS, HEVC (main 10@L5.1@High) (HDR10).
So yes it is HDR which I thought was synonymous with 10-bit colour depth, I guess not? So what I should be trying to do is tonemap HDR to SDR, and keep the 10-bit depth, is that correct?
videoh
30th January 2019, 20:54
That would be reasonable, but it depends on your goals.
Blue_MiSfit
31st January 2019, 01:48
HDR is not synonymous with 10 bit. In the context of video encoding a-la HDR10 it does require 10 bit encoding, but you can absolutely have 10 bit video that is SDR.
Don't tone map as part of encoding. If you want to watch HDR10 content on an SDR display, use MadVR during playback. It will tone map for you. However, you may or may not like the results. Tone mapping is evil without creative guidance :) Interestingly, Dolby Vision was designed to solve some of these problems in various ways.
djloewen
31st January 2019, 17:12
Thanks for the replies everyone. I've done a bunch of reading and I'm going to try encoding the video as HDR. I won't be able to actually try it until Saturday, but here's my plan, please let me know if I'm missing something:
-Use DGindexNV / DGdecNV as the source, with fulldepth=true, followed by ConvertBits(10) (with Avisynth+).
-Use x265 with the following commands:
--crf 18
--repeat-headers
--vui-hrd-info
--y4m
As well as the following copied from MediaInfo of the source:
--master-display
--colorprim
--colormatrix
--transfer
--range
--max-cll
Then mux to an mp4 container (I know many people prefer mkv but mp4 should work?)
Any suggestions or glaring omissions? (for example, will I have problems if I don't specify --max-luma 1023?) Thanks!
benwaggoner
31st January 2019, 20:29
HDR is not synonymous with 10 bit. In the context of video encoding a-la HDR10 it does require 10 bit encoding, but you can absolutely have 10 bit video that is SDR.
You can even kind of do HDR in 8-bits with sufficiently advanced dithering. Windows does 8-bt RGB when connected to a 2160p60 HDR display over HDMI 2.0, because there isn't enough bandwidth for 10-bit RGB. It works reasonably well, although there is a ton of math going on underneath, and tone mapping to precisely match the display's known characteristics.
Note the Cyberlink UHD Blu-ray player forces output to be 10-bit 4:2:2 or 4:2:0 when playing. Since tone mapping isn't appropriate there (the TV is going to do its own anyway), optimal quality requires preencoded video go out as is.
EDIT: That said, ENCODING HDR as 8-bit is highly fraught for the same reasons. It would require a super-good dithering algorithm, and a bitrate and encoder that can accurately preserve that dithering. 10-bit HDR would be a lot easier to encode, and would look good at lower bitrates.
I've tested what HDR looks like if the 10-bit just gets truncated to 8-bit without dithering, and it is very weird and terrible.
Boulder
1st February 2019, 20:19
Thanks for the replies everyone. I've done a bunch of reading and I'm going to try encoding the video as HDR. I won't be able to actually try it until Saturday, but here's my plan, please let me know if I'm missing something:
-Use DGindexNV / DGdecNV as the source, with fulldepth=true, followed by ConvertBits(10) (with Avisynth+).
-Use x265 with the following commands:
--crf 18
--repeat-headers
--vui-hrd-info
--y4m
As well as the following copied from MediaInfo of the source:
--master-display
--colorprim
--colormatrix
--transfer
--range
--max-cll
Then mux to an mp4 container (I know many people prefer mkv but mp4 should work?)
Any suggestions or glaring omissions? (for example, will I have problems if I don't specify --max-luma 1023?) Thanks!
Don't use ConvertBits(10), if your source is decoded to 16 bits, do all processing in 16 bits and just set --input-depth 16 --output-depth 10 --dither in the x265 command line to dither internally down to 10 bits. Also --hdr-opt is recommended for HDR sources.
djloewen
2nd February 2019, 00:42
Thanks again for the suggestions. I'm resizing to 480p for now while I experiment. The first file worked fine but was in 8 bit, I didn't specify an output depth but I expected it to output at 10 if the input was 10? The second encode was made with Boulder's inclusions. It's 10 bit as expected, and the video bitrate is much lower (514kbps vs 882kbps). I remember finding a post explaining why that happens, I'll try to find it again but if anyone happens to know the link, pls share :).
The other annoyance is that seeking to a random spot halfway through the video took ~60 seconds before it started playing. Questions:
1.) Is this normal?
2.) Will it be much worse at 4k?
3.) Is there a way around it?
Thanks!
sneaker_ger
2nd February 2019, 00:50
No, that's not normal. Maybe your (mp4?) muxer or demuxer/player is broken (often with open-gop). Ways around it: use working muxer/player or disable open-gop.
djloewen
2nd February 2019, 18:32
Ah yes, --no-open-gop fixed the issue. Thank you! Now to try it at 4k resolution :).
benwaggoner
4th February 2019, 19:31
Thanks again for the suggestions. I'm resizing to 480p for now while I experiment. The first file worked fine but was in 8 bit, I didn't specify an output depth but I expected it to output at 10 if the input was 10? The second encode was made with Boulder's inclusions. It's 10 bit as expected, and the video bitrate is much lower (514kbps vs 882kbps). I remember finding a post explaining why that happens, I'll try to find it again but if anyone happens to know the link, pls share :).
You should definitely explicitly set --profile to what you want it to be; Main for 8-bit or Main10 for 10-bit.
10-bit isn't normally significantly smaller than 8-bit in HEVC (there was a bigger 10-bit advantage in H.264). But settings like CRF can do different things at different bit depths.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.