8->10->8 bit YUV tests

Random chit-chat and anything that doesn't belong elsewhere
Post Reply
Deleted User 13735

8->10->8 bit YUV tests

Post by Deleted User 13735 »

This is only going to interest a couple of people, so I'll skip the lengthy background and explanations.

Test setup was simple:

-- Reference encoders were Sony 8- and 10- bit raw YUV wrapped AVI, the most accurate we've tested over the years.
-- Reference source is a static Belle-Nuit chart.
-- Encodes in Handbrake were done at Baseline.
-- We were looking for mathematical, not necessarily perceptual losses, so PSNR is reasonably adequate to detect aggregate increases (or decreases) in Q-noise.
-- All PSNRs are referenced to the Source, not to each other.
-- The PSNR is 100% for 10-bit upconversions made in 8- and 32- bit float workspaces comparatively, proving no color-depth alchemy takes place; 0's are merely substituted for the last two bits, according to my partners.

1. Reference source is YUV 8 bit (100 MB)
2. mp4 from Handbrake PSNR 47.67, 54 KB (not bad)
3. convert to 10-bit YUV with no filtering PSNR 44.20 (oh it went down not up), 132 MB
4. next mp4 from Handbrake PSNR 43.62 (still not bad but not an improvement), 49 KB

This is enough to persuade me to truncate further testing and discussion. Call it an "early fail."
The tests were replicated from scratch to rule out settings errors, and the results were identical.

Conclusions:
1. 8 bit mp4 from Handbrake does not benefit measurably from upconverting to 10 bit YUV
2. Subsequent downconverting to 8 bit causes even more losses (I theorized this a couple of years back)
3. Net losses from the two-generation process were 4%.
2. Handbrake needs 10 bit encoding to be ready for the new formats, but NOT for the reasons being bandied about the internet.
3. Handbrake DOES benefit from being fed 10-bit native source over 8 bit source, and outperforms MainConcept in that arena, from the tests linked in the other thread. Upconverting native 8-bit to pseudo 10-bit source causes losses, not gains.

Image
Djfe
Bright Spark User
Posts: 178
Joined: Tue May 13, 2014 8:01 pm

Re: 8->10->8 bit YUV tests

Post by Djfe »

again, thx for publishing your tests!
mduell
Veteran User
Posts: 8206
Joined: Sat Apr 21, 2007 8:54 pm

Re: 8->10->8 bit YUV tests

Post by mduell »

musicvid wrote:1. Reference source is YUV 8 bit (100 MB)
2. mp4 from Handbrake PSNR 47.67, 54 KB (not bad)
3. convert to 10-bit YUV with no filtering PSNR 44.20 (oh it went down not up), 132 MB
4. next mp4 from Handbrake PSNR 43.62 (still not bad but not an improvement), 49 KB

This is enough to persuade me to truncate further testing and discussion. Call it an "early fail."
Isn't this an apples to oranges comparison? The output PSNR or output file size should be the same to actually compare them, otherwise all you've confirmed is that you can get higher quality with a larger file size, which was already known.
Deleted User 13735

Re: 8->10->8 bit YUV tests

Post by Deleted User 13735 »

I see your point, but the only way I can see to control that is with a fixed bitrate.
Unfortunately, a still image rarely obeys bitrate instructions, since frame generation is already at idle, save for an occasional bump called an I-frame.

We are working with two different sources here, the first generation and the third.
But in this case the complexity of the source determines the file sizes; the reference source ostensibly being more complex.

The smaller mp4 file is 81 Kbps, the larger at 88.6 Kbps overall. Moving the RF slider around would be unlikely to make a difference.
So what other suggestions do you have? Length being the same, bitrate is the only variable left. If I "were" able to fix the bitrate, what would that bitrate be?
mduell
Veteran User
Posts: 8206
Joined: Sat Apr 21, 2007 8:54 pm

Re: 8->10->8 bit YUV tests

Post by mduell »

Change your rate control target rather than method until you hit the same PSNR or bitrate?
Deleted User 13735

Re: 8->10->8 bit YUV tests

Post by Deleted User 13735 »

I previously found out that their is no minimum rate control available in x264.
One can actually set the minimum bitrate in MainConcept h264. Maybe 'cause it needs it more :wink:

Maybe I'll try a couple of tests at RF=1. My NLE won't accept Hi10P, so RF=0 is out of the question.
Deleted User 13735

Re: 8->10->8 bit YUV tests

Post by Deleted User 13735 »

So after a lot of playing with the slider, I got the file sizes nearly even --54 and 56 MB, which "should" have placed the second in a better light.
Unfortunately, it did not. PSNR from the 10 bit -> mp4 encode was 43.9.
I had a feeling changing RF would give paradoxical results, and neither approach showed any improvement, but degradation instead from what appears to be increased edge noise.

So at least until Rodeo drops in and offers his impression, I'm sticking with my first results and conclusions.
Encoding a 10 bit intermediate from 8 bit source does more harm than good at least where Handbrake x264 is concerned.
mduell
Veteran User
Posts: 8206
Joined: Sat Apr 21, 2007 8:54 pm

Re: 8->10->8 bit YUV tests

Post by mduell »

musicvid wrote:1. Reference source is YUV 8 bit (100 MB)
2. mp4 from Handbrake PSNR 47.67, 54 KB (not bad)
3. convert to 10-bit YUV with no filtering PSNR 44.20 (oh it went down not up), 132 MB
4. next mp4 from Handbrake PSNR 43.62 (still not bad but not an improvement), 49 KB
musicvid wrote:So after a lot of playing with the slider, I got the file sizes nearly even --54 and 56 MB, which "should" have placed the second in a better light.
Wait, you're jumping all over orders of magnitude here...
rollin_eng
Veteran User
Posts: 4859
Joined: Wed May 04, 2011 11:06 pm

Re: 8->10->8 bit YUV tests

Post by rollin_eng »

mduell wrote:
musicvid wrote:1. Reference source is YUV 8 bit (100 MB)
2. mp4 from Handbrake PSNR 47.67, 54 KB (not bad)
3. convert to 10-bit YUV with no filtering PSNR 44.20 (oh it went down not up), 132 MB
4. next mp4 from Handbrake PSNR 43.62 (still not bad but not an improvement), 49 KB
musicvid wrote:So after a lot of playing with the slider, I got the file sizes nearly even --54 and 56 MB, which "should" have placed the second in a better light.
Wait, you're jumping all over orders of magnitude here...
I thought this was just 5th grade math :wink:
Deleted User 13735

Re: 8->10->8 bit YUV tests

Post by Deleted User 13735 »

Mduell,
Yes, I set out to rule out as many many uncontrolled variables as possible. Matching output bitrate/size complicates things, and I'm not sure that is desirable considering the two Reference YUV encodes have different fingerprints. Since a target bitrate is irrelevant with a still, and I already tried a ratetol switch, I can't seem to match them any closer. But the insignificant differences in psnr resulting from increasing the bitrate on the second sample seem to bear out my original findings. Thanks for keeping me on my toes.

So, unless you can suggest a different method, I'm calling this a wrap. "Jumping over orders of magnitude" was exactly my objection to this 8->10->8 nonsense when I first read about it.

Permission to lock is implicit.
Deleted User 13735

Re: 8->10->8 bit YUV tests

Post by Deleted User 13735 »

As evidence of Handbrake's superiority in dithering 10 bit source to 8 bit delivery, I ran these tests some time back.
Top is MainConcept in Vegas, bottom is Handbrake.
Image
Image
Deleted User 11865

Re: 8->10->8 bit YUV tests

Post by Deleted User 11865 »

I'm no dithering expert, but the Vegas screenshot looks a bit odd to me (blockiness isn't something I'd naturally associate with poor dithering, but maybe I'm quite off the mark). Could there be something else going on?
User avatar
JohnAStebbins
HandBrake Team
Posts: 5726
Joined: Sat Feb 09, 2008 7:21 pm

Re: 8->10->8 bit YUV tests

Post by JohnAStebbins »

Rodeo wrote:I'm no dithering expert, but the Vegas screenshot looks a bit odd to me (blockiness isn't something I'd naturally associate with poor dithering, but maybe I'm quite off the mark). Could there be something else going on?
I believe pattern dithering can cause this effect. Pattern dithering is where you sample the strength of a signal in a block, then basically apply a pre-dithered pattern to the block that has the same strength. Works adequately for dithering print where the DPI is high and the blocks are small. But not so good on video.
Deleted User 11865

Re: 8->10->8 bit YUV tests

Post by Deleted User 11865 »

Good to know, thanks!
Deleted User 13735

Re: 8->10->8 bit YUV tests

Post by Deleted User 13735 »

In addition, banding and moire in brighter colored areas appear slightly reduced with authentic 10 bit source to Handbrake than with identical 8 bit source (both 4:2:2).
This REALLY surprised me.
Post Reply