VideoHelp Forum

Try DVDFab and download streaming video, copy, convert or make Blu-rays,DVDs! Download free trial !
+ Reply to Thread
Results 1 to 11 of 11
Thread
  1. This question has been asked, and in theory, answered numerous times, with the topic usually popping up as it related to x264 vs x264 10-bit. The generally accepted answer is that even with an 8-bit source there are benefits to encoding to 10-bit because, the argument goes, of smoother color gradients due to higher precision math. This seems like a reasonably conclusion, and in fact I admit I am guilty of offering this advice in the past.

    However, a recent discussion with a sparing partner on this forum led me to start rethinking this position, especially as i watched him tap dance around the offer he made and I accepted only for him to back out of with silly objections.

    One of the objections revolved around the source I proposed for his test and his claims that since some of the encoders to be tested support 10-bit encoding and some don't, that it would unfairly penalize the 8-bit encoders by using a 422 10-bit source.

    Despite mocking him, I spent some time thinking about this and no matter with way I look at it, I can't escape one very simple reality, it probably doesn't matter whether or not you encode to 8-bit or 10-bit because the final encode will be viewed in nearly all cases on an 8-bit monitor, which means that the 10-bit encoding needs to somehow be mapped to an 8-bit display.

    In order to display a true 10-bit image, you need a video card, drivers and monitor that support true 10-bit output. But most monitors only support 8-bit, some support a pseudo 10-bit output, and as far as I know there are no consumer tv's that currently support 10-bit output.

    Further compounding my skepticism is that some, if not all, non-pro encoding front ends, such as handbrake, despite being able to output a 10-bit or 10/12-bit video (in the case of x265), the internal processing is still done in 420 8-bit.

    So I decided to perform a test, using the source named BMPCC6K_Wedding.mov, from here:

    https://www.blackmagicdesign.com/products/blackmagicpocketcinemacamera/workflow

    The source is ProRes, 1034 Mb/s, 6144x3456, 24fps, 422 and I used the latest build of Handbrake on Manjaro, with all the updates.

    When you load this in Handbrake, it automatically crops it 448 top and bottom to 6144x2560 and I outputted it as 1920x1080 storage resolution, 2592x1080 2.40:1 display resolution.

    I considered outputting it at 6k, but the reality is that most people don't even have a 4k monitor, much less a 6k monitor, at 1080p, it should give us a realistic idea of the benefit to an end user in encoding to bit depths higher than 8-bit.

    As a side note, for $2500, this camera is one hell of a value, 13 stops, capable of recording to RAW or ProRes, full 6k resolution, if I were running a streaming site, with unique content, I would author and stream in 5k as a way of differentiating my site from competitors. Fun fact, there is an "adult" site that sells it's movies at resolutions up to 5k, though I strongly suspect it's 4k that's been upscaled.

    What I did was encode the first one to x264 with CRF 22, then did a 2 pass encode for x264 10-bit and x265 8/10/12-bit. As you will note, in some case the encoder missed the target bit rate slightly.

    Just for fun, I did a few higher quality encodes as well, at 6k, with x264 CRF 16 and i tried to match the bit rate with NVENC HEVC but it fell short of the target bit rate by a bit, I will be uploading those shortly as there seems to be a problem with the forum accepting those uploads at the moment.

    If anyone has access to any commercial encoders, Main Concept, Sony AVC, Apple, Ateme, or a Turing card and wants to join in the fun, feel free to run your own test.
    Image Attached Files
    Quote Quote  
  2. Why would you select a source that needs to be fixed, is cropped, resampled, resolution and chroma and God know what more is done behind scenes, so there is no original available for direct comparison?

    Videos (as posted) 1,4 and 6 need to have cut first frame to be in sync with the rest. (using ffms2 as source plugin)

    nvenc smooths out stuff, h265 keeps more detail (10 and 8 bit), x264 is behind, trying also keep details but cannot keep up like x265 does.
    To not include an original is kind of faux-pas though.
    What is always missing is time it took to encode.
    vapoursynth script:
    Code:
    import vapoursynth as vs
    from vapoursynth import core
    
    input1=r'F:/BMPCC6K_Wedding nvenc hevc.mkv'
    clip1 = core.ffms2.Source(input1)[1:] #first frame cut
    
    input2=r'F:/BMPCC6K_Wedding x265 10-bit.mkv'
    clip2 = core.ffms2.Source(input2)
    
    input3=r'F:/BMPCC6K_Wedding x265 12-bit.mkv'
    clip3 = core.ffms2.Source(input3)
    
    input4=r'F:/BMPCC6K_Wedding x264 10-bit.mkv'
    clip4 = core.ffms2.Source(input4)[1:] #first frame cut
    
    input5=r'F:/BMPCC6K_Wedding x265.mkv'
    clip5 = core.ffms2.Source(input5)
    
    input6=r'F:/BMPCC6K_Wedding x264.mkv'
    clip6 = core.ffms2.Source(input6)[1:] #first frame cut
    
    from vnp15 import Preview
    Preview([clip1,clip2,clip3,clip4,clip5,clip6])
    frames 539 (counting from zero) , brides forehead, png's are in RGB of course cropped: core.std.CropAbs(clip, width=240, height=134, left=502, top=236), then zoomed in the picture using nearest resize, so points get just bigger:
    Image Attached Thumbnails Click image for larger version

Name:	06_x264_clip_06_[240, 134, 502, 236]_frame_0000539.png
Views:	16
Size:	269.3 KB
ID:	50416  

    Click image for larger version

Name:	05_x265_clip_05_[240, 134, 502, 236]_frame_0000539.png
Views:	13
Size:	279.9 KB
ID:	50417  

    Click image for larger version

Name:	04_x264 10-bit_clip_04_[240, 134, 502, 236]_frame_0000539.png
Views:	11
Size:	277.7 KB
ID:	50418  

    Click image for larger version

Name:	03_x265 12-bit_clip_03_[240, 134, 502, 236]_frame_0000539.png
Views:	10
Size:	284.9 KB
ID:	50419  

    Click image for larger version

Name:	02_x265 10-bit_clip_02_[240, 134, 502, 236]_frame_0000539.png
Views:	12
Size:	282.9 KB
ID:	50420  

    Click image for larger version

Name:	01_nvenc hevc_clip_01_[240, 134, 502, 236]_frame_0000539.png
Views:	17
Size:	259.4 KB
ID:	50421  

    Last edited by _Al_; 6th Oct 2019 at 19:52.
    Quote Quote  
  3. Atta boy! I thought you ran away!

    Does handbrake support the full 10bit pipeline yet?

    1) The math is 100% sound for the accuracy component, and you can verify this in real test. You can reproduce accurate 8bit RGB colors with 10bit YUV . But not with 8bit YUV . Just check some color bars . Is color accuracy important ? Or does it "matter" if on the 8bit monitor RGB values are +/- 3 vs. +/- 0 ? Probably not for the typical user. It's probably more important for web designers who embed videos. Things such as logos, trademarks are a bit "off" with 8bit. But the problem is, browser support is for proper 10bit video is currently WIP. It plays, but it's truncated to 8bit right now. If you want , I can upload a demo in this thread or another if you don't want it polluted. You need to use an accurate player like MPCHC or MPV . VLC truncates to 8bit too

    2) For the banding and compression discussion , it's easier to see with gradients . Would you like a demonstation ? Same deal let me know this thread or another? A good clip is the Lighthouse of the Pacific clip, with the blue skies. That's the 8bit 4:2:0 source used to encode the retail BD from. Full permissions from the author for testing. Basically, does 10bit encoding help, even in the 8bit source scenario ?

    3) I'll try to upload some Meridan encodes in another thread over the next few days. Sneaker made a sample for testing in another forum , so no 300GB DL's. He converted to 1920x1080 8bit 4:2:0 but since that's a standardized source, none of those other variables come into play. One issue is that it's a bit atypical since it's "59.94p" , and the motion and shutter blur looks awkward compared to a traditional theatrical production, so it's probably not representative, but it's just another data point for fun . I'll do the legacy encoders AVC first when I have time, since that was requested first in the other thread, and add more gradually. Others can contribute too with others like SVT HEVC/AV1/VP9 , that SIF, NVEnc (hopefully Turing), or I'll try gradually add to them with what I have available
    Quote Quote  
  4. Originally Posted by _Al_ View Post
    Why would you select a source that needs to be fixed, is cropped, resampled, resolution and chroma and God know what more is done behind scenes, so there is no original available for direct comparison?

    To not include an original is kind of faux-pas though.
    I linked to the original, everyone is free to download any and all the ProRes or RAW samples.

    As for the rest, professional video is never used as is straight from the camera, prior to the editing it's color graded, debayered, denoised, sharpened, etc, as pros usually shoot "flat" in order to avoid "baking in" information in the source so as to allow maximum creative flexibility during the producing.

    If you were shooting your own project you most definitely would crop because there are likely to be elements, such as a boom mike, extras, camera men, props, etc that a viewer is not meant to see. This is why I laugh when people complain about UHD blu-rays not being authored from a 4k master, it doesn't matter because even if the whole movie is shot in 4k and mastered in 4k, there always some cropping, reframing, stabilizing, before being resized back up to 4k for the master.

    A good look at what goes on is here:

    https://jonnyelwyn.co.uk/film-and-video-editing/the-making-of-gone-girl/

    This is also one of the reasons I oppose so called "psy optimizations", the author of the content spent lots of time and money to create an end product and then people want to use an encoder that "decides" which part of each frame should be given priority.

    Just silly.
    Quote Quote  
  5. Originally Posted by poisondeathray View Post
    Does handbrake support the full 10bit pipeline yet?
    No and I doubt it ever will. In fact, I strongly suspect that ffmpeg (I know HB is not based on it) does not support a full 10-bit pipeline.

    Unfortunately I switched to using Linux as my primary OS years ago, and the video tools available are not as robust as Windows or OSX.

    I can't seem to find that Lighthouse of the Pacific clip, the clips that are similar to what you describe all require they be purchased.

    Feel free to post any test encode in this thread.
    Quote Quote  
  6. Originally Posted by sophisticles View Post
    Originally Posted by poisondeathray View Post
    Does handbrake support the full 10bit pipeline yet?
    No and I doubt it ever will. In fact, I strongly suspect that ffmpeg (I know HB is not based on it) does not support a full 10-bit pipeline.
    I think HB used to use libav, but some versions switched to ffmpeg ?

    ffmpeg does for sure . 100% certain

    If you insert an 8bit filter somewhere, then it might get truncated .

    Unfortunately I switched to using Linux as my primary OS years ago, and the video tools available are not as robust as Windows or OSX.
    But in some ways better . Linux benchmarks are always faster , sometimes much faster. Not just video; other areas too


    I can't seem to find that Lighthouse of the Pacific clip, the clips that are similar to what you describe all require they be purchased.
    Lighthouses of the Pacific, from Stacey Spears (The same one from "Spears and Munsil" fame ), sneaker uploaded a lossless x264 version here to reduce filesize
    https://mega.co.nz/#!osdxQbCR!vim8f5gAD5nf0w0jf-vEAA3mGySmEOoZQOH_GE3Z2uw

    Not an "exciting" clip , but lots of blue skies prone to blocky banding, and don't forget to check out the fades - encoders love fades .

    Feel free to start on it if you have time, I'll do some encodes with Apple/MC/Vegas AVC in another thread , and contribute here too if time permits
    Quote Quote  
  7. To illustrate the 10bit vs 8bit YUV color accuracy for 8bit RGB :

    1) Start with known R,G,B values. Test charts are easy because they have big bars of colors you can test. Or offical SMPTE HD bars
    eg. https://www.belle-nuit.com/test-chart

    I converted to YUV444 (Rec709) , because I didn't want the effects of subsampling intefering with results

    I chose VP9 here because both 8bit and 10bit 444 configurations are supported by modern HTML5 browsers natively. There is the aformentioned 10bit truncation to 8bit issue, but development team for Mozilla for sure, and probably Chrome, are working on implementing the correct 10bit YUV => 8bit RGB conversion (albeit slowly). The emphasis for browser code is speed on multiple platforms, not quality. But when it's done you can use these same test videos in the browser to check.

    You need a color picker, many to choose from eg. instant eyedropper is a good one , with a portable version
    http://instant-eyedropper.com/

    I like MPV, and this should be good on linux too. MPCHC also works for Win. Some players emphasize the "speed" over proper 10bit YUV => 8bit RGB conversion, such as VLC , so you 'll get the errors

    If you check the colors, they are off by +/-3 in the 8bit YUV version, but accurate in the 10bit YUV version. e.g. "Green" is 16,180,16 in original RGB, and 10bit YUV when properly converted to 8bit RGB for display ; but something 16,179,14 in 8bit YUV version (or possibly more off in the browser) . All the colors will be off a bit, but hardly noticable to average person, especially from a distance. ie. this is mostly academic for the end user scenario. And "color perception" in humans is much less important anyways than luma .

    But for stages earlier in the pipeline, it's almost "mandatory" for professional work . In general you need 2 more bits to express all the colors, it's important for post production, grading, VFX, greenscreen etc.. . So if delivery is 8bit , you need 10bit . For 10bit UHD BD, HDR streams, Netflix, 12bit intermediates are common

    (FYI, The version I uploaded is modified, with "superbright" Y=255 (or Y-1023 in the 10bit version) and "superdark" patches Y=0 , so you can test for clipping in various workflows, but it's unrelated to this discussion)
    Image Attached Files
    Quote Quote  
  8. Originally Posted by sophisticles View Post

    This is also one of the reasons I oppose so called "psy optimizations", the author of the content spent lots of time and money to create an end product and then people want to use an encoder that "decides" which part of each frame should be given priority.

    Just silly.
    But any encoder already decides which part of each frame should be given priority regardless of psy optimizations

    If you had near unlimited bitrates , no constraints, then you can do what the author wants perfectly. Compression is about compromises


    Psy optimizations are in every high end pro encoder . Ateme was pioneer in this long before x264 . Mainconcept has them too .

    Netflix values psy and perceptual optimizations, they realized this when testing and building their current batch of models for human perception. This is why we have VMAF, and their next development round is geared directly towards improving this

    But whether or not you "like" a particular encoders' implementation of various psy optimization strategies is going to vary from person to person.

    You can do some tests, change some values , etc... rinse, repeat . For example, x264 is weak around shadow areas , flat areas. Prone to banding along gradients. It's original AQ mode 1 implementation shifts bits to those areas from edges. The side effect is lower quality edges around objects, frame edges when AQ is high. AQ can be considered a type of psy opt. Trade offs.

    Some encoders have the same or similar "name" for a particular optimization, but the effect is drastically different. In short, each encoder reacts very differently to the various psy options
    Quote Quote  
  9. "Lighthouse" using GTX 1660 Ti (Turing) HEVC vs x264. 8 bit and 10 bit for each. ~3000 kbps.

    Code:
    nvencc64 -c hevc --vbrhq 0 --vbr-quality 25.5 --max-bitrate 100000 -u quality --output-depth 10 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel --fps 24 --sar 1:1 --log lighthouse_turing_hevc_10bit.txt --avhw -i "lighthouse_lossless.mp4" -o lighthouse_turing_hevc_10bit.265
    nvencc64 -c hevc --vbrhq 0 --vbr-quality 26 --max-bitrate 100000 -u quality --output-depth 8 --lookahead 32 -b 5 --ref 7 --nonrefp --aq --aq-temporal --bref-mode middle --mv-precision q-pel --fps 24 --sar 1:1 --log lighthouse_turing_hevc_8bit.txt --avhw -i "lighthouse_lossless.mp4" -o lighthouse_turing_hevc_8bit.265
    
    avs2pipemod -y4mp lighthouse.avs | x264.exe - --demuxer y4m --bitrate 3000 --preset veryslow --tune film --output-depth 8/10 -o lighthouse_x264_8/10bit.264 --pass 1/2
    Image Attached Thumbnails Click image for larger version

Name:	330_turing_hevc_8bit_.png
Views:	43
Size:	1.04 MB
ID:	50425  

    Click image for larger version

Name:	330_turing_hevc_10bit_.png
Views:	43
Size:	1.22 MB
ID:	50426  

    Click image for larger version

Name:	330_x264_8bit_.png
Views:	29
Size:	1.11 MB
ID:	50427  

    Click image for larger version

Name:	330_x264_10bit_.png
Views:	30
Size:	1.22 MB
ID:	50428  

    Image Attached Files
    Quote Quote  
  10. @sneaker: How about downloading the 6k source I linked to, and doing an NVENC AVC and HEVC encoding with that Turing of yours, maybe encode some of the other 4k and 6k samples as well.

    Thanks.
    Quote Quote  
  11. Originally Posted by sophisticles View Post
    This is also one of the reasons I oppose so called "psy optimizations", the author of the content spent lots of time and money to create an end product and then people want to use an encoder that "decides" which part of each frame should be given priority.

    Just silly.
    I eagerly await your samples showing how psy decreases the quality compared to --no-psy (x264).
    Quote Quote  



Similar Threads