NEW: DNxHD 444 now opens in Handbrake

musicvid10 wrote on 3/3/2014, 10:26 PM

I've been working with lu_zero, a determined libav developer, for what seems like a year now, and DNxHD 10 bit 444 Mb/s (actually 4:2:2) now opens in Handbrake, and probably any frontend using the newest libav 10 libraries. Implementation by ffmpeg should come at some point as well, if it's not already there.

What this means for Vegas editors includes:
Flawless transfer of 10 bit source to Handbrake with reduced decoder mangling.
Reduced color banding in gradients.
More accurate reporting of grading from 32 bit float projects.
Stunning output from CG and Animation sources.

** Disclaimer: If your video source doesn't meet the criteria just above, it is unlikely that you will see much difference in the output. Most video is
[EDITED]

By way of explanation, Handbrake output is still 8 bit 4:2:0 x264. However, its internal engine converts 10 bit 4:2:2 source much better than can be done in Vegas, visibly reducing subsampling artifacts and banding. This, along with the acknowledged decomb and resizing advantages Handbrake already has to offer, make it a natural for first-tier editors who are encoding for mass delivery.

The codec was developed for Arri Alexa acquisition, but is a very worthy intermediate for editors, given improved door-to-door compatibility.
In all fairness, the same can be accomplished with a 10 bit Sony YUV intermediate from Vegas, but at three times the file size [edited].

You need a Handbrake nightly build and Avid LE 2.3.8 or better in order to play with this new import capability.
http://forum.handbrake.fr/viewtopic.php?f=11&t=15901
http://avid.force.com/pkb/articles/en_US/download/Avid-Codecs-LE-2-3-9

Back to post

Comments

Laurence wrote on 3/6/2014, 2:33 PM

So would we all agree that Vegas is 8 bits RGB, and that that is captured more accurately in non RGB formats at 10 bits, hence the advantage of using 10 bit formats even though Vegas is technically 8 bits?

musicvid10 wrote on 3/6/2014, 8:17 PM

I don't have the physical tools to be able to confirm or deny that conclusion. It's easy to spot 8 bit that's been expanded, but ten bit that's been confined is a bit more elusive, somewhat of a moving target from my impressions at this point.

I do know that the results are guiding my choices, I am thankful for small victories, and I will continue to pursue the holy grail as 10 bit acquisition becomes more accessible to the consumer. In the meantime, the thread titled "Raw and 16-bit" seems related.

[Addendum]
It is fascinating to see that David Newman, who I respect immensely, says that ten bit YUV is essentially interchangeable with 8 bit RGB, which just happens to be a large component of my current inquiry. If so, the compelling impression I've gained from my tests is that libav (Handbrake) is much better at doing this accurately than Vegas' internal engine. It's most apparent when comparing gradients rendered both ways. I've known that for a year or so, and I am excited to have a new tool to do this in about a third of the space that was needed before, respecting the choice of workflows. Thanks for the link.

So, I'm going to let this discussion be what it is, and continue testing the things I can quantify through results. In the meantime, DNxHD 444 rocks. More to come . . .

Laurence wrote on 3/7/2014, 4:56 PM

More specifically, that it takes 9 bits of YUV to accurately represent 8 bits of color. So I would expect to see 9 significant bits of color data and a zero in the last bit space. 1 bit difference is twice as much color resolution so it really is a big deal. I am absolutely certain this is why you are getting the results you are in spite of my being technically correct about Vegas being limited to 8 bit color. A few years ago I remember some spirited conversations about the loss when going from YUV to RGB. Using ten bits for the YUV encode avoids this loss.

What I'm trying to figure out now is how the XDcam mpeg2 compression encodes and if their is an advantage to using the 50Mbps 10bit XDcam mxf format for intermediates after all. A lot of times I bake color correction into my XDcam intermediates, so there likely is a difference, especially on the gradients.

MikeLV wrote on 3/7/2014, 6:04 PM

Ok, now that that's all settled, for the rest of us who don't have a clue what you're talking about, what does this mean for the Vegas to Handbrake workflow? =)

Laurence wrote on 3/7/2014, 6:27 PM

Do exactly what MusicVid suggests and ignore my tech rambling. I'm still going to do my own experimentation and further research because I am weird that way, but if you actually want to get something done with the best quality right now, Musicvids new workflow is currently the best there is.

Just to ramble on a bit more, I believe that Handbrake is working at 8 bits RGB. That when it uses a 10bit YUV codec it is actually getting the equivalent of 9 bits of YUV color out of it. That one bit gives it twice the color resolution which as you can see from Musicvid's examples translates into quite a bit smoother gradients.

Yeah, even if you are working with 8 bit source footage, render it out from Vegas at 10 bits DNxHD and use that for your Handbrake source. That will give you twice the color resolution of the old way which was actually losing some of the precision of Vegas' 8 bit RGB color and avoids loss from the RGB to YUV conversion.

MikeLV wrote on 3/7/2014, 7:23 PM

And to be clear, what exactly is this new workflow?

Laurence wrote on 3/7/2014, 11:01 PM

Render out to 10 bit version of DNxHD 444 from Vegas. Newest version of Handbrake will accept this. You will get 9 out of those 10 bits in the YUV (which is twice the color resolution) in your Handbrake render which means your gradients will be twice as smooth and moire free. Musicvid has communicated directly with the Handbrake developers in order to make this stunning jump in quality happen.

musicvid10 wrote on 3/7/2014, 11:03 PM

Mike, this is an announcement of DNxHD 444 support in Handbrake, and nothing else.
Lots of work remains to be done, and you are welcome to join in the testing and share your results. I'm currently looking at some chroma differences, more to come.

MikeLV wrote on 3/8/2014, 6:35 PM

Thanks, and trust me, you don't want me involved in your testing as I probably only understand about half of one percent of the technical items you guys get into, 10bit, 9bit, YUV, I have no clue what any of that means and my plate is too full to begin to try and understand it. I don't know why people get offended when I offer to pay them to make a tutorial.. I'd gladly make a donation for your efforts in the Handbrake tutorial, musicvid10 as I appreciate the work you've done.

musicvid10 wrote on 3/9/2014, 10:40 PM

Here's what is possible with no special treatment. Just a DNxHD 444 intermediate from a 32 bit float project in Vegas to Baseline in Handbrake.

Note that, as a still, only the bit depth and chroma subsampling come into play here. Things like bitrate, profiles, b-frames, motion estimation, etc. are completely irrelevant. Actual bitrate is only around 200 Kbps, as expected.

I can detect a "tiny" bit of banding toward the reds, from the expansion from 709 back to playback levels, but little else, and nothing like I'm used to seeing. There is a small gamma boost in the output that I am looking into. Let me know your reactions.

Those "bands" around the brightest blue are in the Vegas-generated media. I'll be working on a 16-bit gradient in Photoshop that should give us an even clearer picture of banding reduction.

VidMus wrote on 3/10/2014, 2:03 AM

A while back I was playing around with 10 bit and rendering with Sony AVC and I noticed how much better the results were. Making the video the highest possible quality before rendering makes a huge difference! So I am not surprised at how well it works for mp4 no matter how ones work-flow is.

Still, it took way more time than I wanted, in fact a HUGE amount of time so I will stick to the old 8 bits for now.

When looking at commercial DVD's, TV and the internet videos, 10 bit and no more banding is so nice but I doubt if the industry will embrace it anytime soon because of the time and money it takes to produce. And I personally do not have the time and/or money to work with it.

Time is money and I need to get my projects out now not many hours from now!

Just the same, great work musicvid10

musicvid10 wrote on 3/10/2014, 10:41 AM

Funny that those are exactly the same arguments made when Mpeg-2 made its debut for consumer use, when Vegas was just getting off the ground.

10- and 12-bit UHDTV broadcasting is already here. 2014 FIFA will be broadcast in 12-bit. The sets have been around for a couple of years. PS4 will play 10-bit video natively. Consumer camcorders (most notably GoPro) acquire 10-bit.

Yes, it's slower. Every major industry advance carries time collateral. It's not for everybody (oh, I guess I said that).

The results, even for 8 bit mp4 delivery, are stunning. And its here now, in a much smaller package, for free. Still a work in progress, I might add once more.

MikeLV wrote on 3/10/2014, 12:30 PM

What are you talking about when you refer to 8 bit, 10 bit? Is this a setting somewhere to improve quality, or it's unrelated to encoding?

musicvid10 wrote on 3/10/2014, 2:26 PM

It's the number of allocated uncompressed bits per color channel for each pixel, which determines the number of discrete colors possible in the output.

Banding and posterization are the result of too few bits.
Google "bit depth" for more information.

musicvid10 wrote on 3/10/2014, 2:38 PM

Here's Shirley in 8 bits per channel (24 RGB):

Here's Shirley with not very many bits (<1):

musicvid10 wrote on 5/27/2015, 9:20 PM

Here's a new set of tests showing that upsampling 8 to 10 bit does no good whatsoever as far as Handbrake is concerned. There are a few persistent blogs that claim that it does some good, but none of them had any supporting tests, only theories and conjecture.

http://forum.handbrake.fr/viewtopic.php?f=14&p=151132#p151132