NEW: DNxHD 444 now opens in Handbrake

Back to post

Comments

Laurence wrote on 3/5/2014, 10:56 AM
Is there any case where Vegas actually renders 10 bits with actual data in the two least significant bits? My understanding is that if it's a smart-renderable ten bit format with data in these last two bits and it is smart-rendered, that these last two bits will be preserved. That in all other cases a ten bit container will just fill those last two bits with zeros. Is that correct?
videoITguy wrote on 3/5/2014, 11:00 AM
a 10 bit codec like that of Cineform renders to 10bits -but if the timeline is forcing only 8bits from sources, the 10bits are filled with extrapolation, not zero filled.
musicvid10 wrote on 3/5/2014, 11:21 AM
Whatever the case, it's working.
Laurence wrote on 3/5/2014, 11:34 AM
It's been a while since I studied this, but here goes the best of what I can remember. Vegas is one of the few programs that uses the now outdated VFW. VFW has a maximum resolution of 8 bits of color. Thus, while Vegas itself can manipulate color data with more precision, and in fact does so when you use the 32 bit option, the data being passed to and from it and any file being read or written gets truncated to 8 bits because of the limitations of VFW. I am busy right now so it will be a while before I can actually look this up and confirm it. It is quite possible that I am thinking about limitations of a previous version of Vegas or VFW rather than the current ones.

I agree that it working now is a good thing. Where I disagree is in the idea that using 10 bit color would have any benefit for a Vegas based work flow. This is one of those instances where I would just love to be wrong.
musicvid10 wrote on 3/5/2014, 11:51 AM
8 bit YUV intermediate from Vegas shows identifiable banding.
10 bit YUV intermediate from Vegas shows almost no banding.
So the bits are coming from somewhere. I doubt they're being extrapolated.

Vegas does not "exclusively" use vfw decoders. b-frame AVC / h.264 is but one example of source that cannot decode using vfw. I'm not certain that all decoders default to 8 bit in Vegas regardless of source. This can be tested, but it's not consistent with my impressions.
NormanPCN wrote on 3/5/2014, 12:12 PM
Vegas is one of the few programs that uses the now outdated VFW. VFW has a maximum resolution of 8 bits of color.

Vegas only uses Video for WIndows to decode AVI files, or encode an AVI file and nothing else. Excluding Quicktime, everything else is under direct Sony control and they can do and support whatever they want.
Laurence wrote on 3/5/2014, 12:18 PM
That is good news indeed. I must have remembered this from a Cineform discussion then since that would indeed have the VFW limitations. In this particular instance, we would be encoding DNxHD through Quicktime, so I assume that that would mean that color would indeed be 10 bits. Even with 8 bit source material that could translate into smoother gradients after color correction. I still expect that Handbrake would merely truncate them rather than dithering as it created its 8 bit output. I don't expect to see a lot of difference between an 8 bit format truncated from 10 bits in Handbrake than I would a format that was 8 bits to begin with.
NormanPCN wrote on 3/5/2014, 1:07 PM
Vegas does not install any codecs into any Windows video subsystem. Vfw, DirfectShow, Media Foundation. As far as I can tell using Gspot and/or searching the registry.

The Sony 10-bit YUV codec listed under Video for windows is probably bypassing Vfw.

Sony 10-bit YUV uses a FOURCC or v210 (AJA Video Systems Xena). I can find no reference to this 4CC on my system. Windows Media player, Media Player classic and Quicktime cannot play the file. I think this is evidence that no codec is installed into Vfw, or any subsystem for this format. And that seems to indicate Vegas is probably bypassing Vfw for this codec and should not have legacy Vfw limitations.

There is precedent for Vegas bypassing a system and handling something specific directly. Quicktime MOV files from DSLRs bypass quicktime. They say so on their website. These are Quicktime MOV files with AVC video and PCM or AAC audio.
musicvid10 wrote on 3/5/2014, 9:07 PM
Although well beyond the scope of this thread, some clarification is needed at this juncture.

-- Sony YUV is a VFW codec, as are several other 10-bit-capable renderers in Vegas, both natively and from third parties.
-- Cineform will render to both AVI (vfw) and MOV (qt32lib) formats.

-- This thread is about DNxHD 444 in MOV format. Sony YUV was mentioned for comparison purposes, since it was the only comparable 10 bit route to libav before this new feature was added. Cineform is not an option for that purpose, and I sense that Cineform will not be supported in libav or ffmpeg anytime soon.

As soon as I can get my hands on some suitable footage (GoPro, anyone?) for comparison tests, I'll post them here. Until then, I am excited that such a route now exists for advanced Vegas editors, in a third of the space that was necessary before. The quality from initial tests has been beyond anything I expected.

Laurence wrote on 3/5/2014, 11:26 PM
According to this discussion on the Avid site, QuickTime writes are also limited to 8 bits.

http://community.avid.com/forums/p/96816/654841.aspx

Laurence wrote on 3/5/2014, 11:37 PM
Here's an Adobe discussion which suggests that if you want to go beyond 8 bit color, you need to render out an Image sequence:

http://forums.adobe.com/thread/1315992

The good news is that it's not a Vegas limitation. Avid and Adobe users are stuck at 8 bits as well.

Does anyone know if Vegas XDcam mxf renders can be a full actual 10 bits?
videoITguy wrote on 3/6/2014, 12:24 AM
Laurence, I MUST caution you on this discussion. While your post references are interesting, I think you are reading in a skim mode and taking what you perceive off the top. Please be very careful at summarizing conclusions. The actual thread references are about several matters of some greater complexity than it might first appear.

I am posting this cautionary note because if forum members just take your summaries stated in this space as factual conclusions, they will be entirely misled.
Laurence wrote on 3/6/2014, 7:44 AM
Those threads are dealing with the same truncating issues even if the contexts are different.

I am particularly interested in this subject because the new Panasonic GH4 in addition to 4k also does 10 bit color. My main camera is a GH3 and I have a growing collection of micro 4/3 lenses, so I have been following the GH4 closely. I can live without 4k but boy is that 10 bit color tempting. Not just for smooth gradients but for the extra latitude in correcting color. I have my real doubts however that I would in any instance be actually able to use those last two bits. This sort of information is hard to find. I am quite sure that I cannot use 10 bits in an AVI format without going outside of Vegas to something like the color correction in Cineform. I strongly suspect that the Apple QuickTime extensions that are used on Windows PCs are also 8 bit only. I am not sure about the Sony YUV and XDcam mxf formats. They may well do 10 bits even if AVI and QuickTime renders do not. Again, I would love to be proven wrong about this. I want to be wrong. I really do.
musicvid10 wrote on 3/6/2014, 8:21 AM
Anyone care to comment on the results, or share their own?
[sigh]
Laurence wrote on 3/6/2014, 9:56 AM
No question that 10 bit gradient looks excellent. The question is why.
videoITguy wrote on 3/6/2014, 12:16 PM
Laurence, I can see you would be a student in Aristotles class, and I appreciate your doggedness quality. However, you missed the boat bigtime when I called you on quoting references out of context. Then you refuted that statement.

Here is how your great teacher from Greece would have handled your class participation and discussion. "Laurence, your question is a good one, and since it is rhetorical in nature, try to answer your question with the facts that you have before you."
Laurence wrote on 3/6/2014, 12:45 PM
I really don't think I was dodging the question. My point is that I know AVI encodes truncate 10 bit color down to 8 bits. I wondered if QuickTime encodes also truncate in the same way. If they did I fingered that this would show up in discussions on the Avid and Adobe forums. I did a quick search and found discussions that seem to confirm that that is indeed the case. Yes the context is different, but the essence of the question is the same. Are the PC version of the QuickTime extensions that Vegas uses capable of going beyond eight bits of color? As much as I would like it to, I don't believe that it does. This is more than an academic question to me because if it did, I would update my workflow. I don't want to just star using a 10 bit QuickTime DNxHD workflow with larger file sizes and slower renders until I am really sure there is an actual benefit. Right now my 35 MBps XDcam mp4 format is really fast, gives me relatively small file sizes and looks every bit as good as what I was getting with DNxHD QuickTime renders into Handbrake. So far I am not convinced that those extra bits are anything but truncated zeros.
videoITguy wrote on 3/6/2014, 12:57 PM
Laurence, you can do as you please, and the workflow that works for you is as valid as it gets.

For myself, I have enjoyed the benefits of Cineform 10bit in both Avi and Quiktime containers ( just takes a rewrap between containers) as holding the same info for complex compositing - something I really appreciate about using VegasPro.

Cineform was one of the first 'hollywood" suppliers to provide direct evidence of the comparison between 8 bit and 10bit as digital intermediates in a workflow for NLE. I believe that was nearly 8 years ago, so it is not news.

As for Adobe Premiere, you can experience 10 bit processing quite easily, more so than the locked-up iterations of VegasPro.

I cannot say enough about Avid supporting the industry, and I am glad that Musicvid is exploring some of it's lesser known options that few others tread into.

NormanPCN wrote on 3/6/2014, 1:18 PM
Anyone care to comment on the results, or share their own?

I don't know as 10-bit workflow will ever mean anything to me directly, but I think it is awesome you have documented a 10-bit workflow and showed real results. This is what forums are good for. We read and absorb tidbits of info for immediate and/or for future use. I am just a hack with a mountain bike and a GoPro, but I have fun and learn things every day. Thanks.

Laurence wrote on 3/6/2014, 1:24 PM
Are you color correcting in Vegas or in Cineform? For awhile I was experimenting with color correcting in the Cineform software since the changes made in it were actually ten bit and would show up in Vegas. During the Vegas render they would be truncated to eight bits, but at least it was ten bit workflow up to then. In fact, the discussions on the Cineform forum at DVinfo.net that I participated in a few years back are what Made me aware of these limitations. Yes Vegas has changed much in the past few generations, but have VFW and QuickTime? I am glad for MusicVid's work as well and he may well be onto something very positive. The rendered gradients are indeed quite convincing. It just goes against my understanding. Musicvid and I have been knocking around ideas like this for quite a few years and I doubt he is taking any offense at my sincere doubts and questions. I certainly have the greatest respect for him and his contributions to this forum. I just need to be more convinced before I change my workflow.
royfphoto wrote on 3/6/2014, 1:26 PM
The problem with Cineform is that since being bought by GoPro they have not kept their encoder up to date. Any .mov file recorded by a DSLR is not recognized (in WIN 8) and the GPSP interface does not recognize MFX (only HD Link). I am using ClipToolz Convert to convert to ProRes. Cineform was my standard for a long time but support since the GP buyout is non existent.
Laurence wrote on 3/6/2014, 1:42 PM
Ok, this thread cleared it up for me. Yes Vegas works at 8 bits of color but that is 8 bits of RGB color, not YUV. 8 bits of RGB color is about the same as 9 bits of YUV color, and thus working at 10 bits will preserve this extra bit of quality when going translating between formats:

http://www.dvinfo.net/forum/cineform-software-showcase/99286-more-cineform-questions-regarding-8-bit-vs-10-bit.html

David Newman's relevant post is as follows:

We disabled the 8-bit encoding option some time ago for good reasons. Even though Vegas is an 8-bit application, its use of video systems RGB benefits for increases encoding precision. 8-bit RGB is approximately equivalent to 9-bit YUV, and most compressors like CineForm use YUV for internal data storage (it is more effecient.) So converting 8-bit RGB to 10-bit YUV and compressing that guarantees a very accurate construction back to RGB when needed.
__________________
David Newman -- web: www.cineform.com
blog: cineform.blogspot.com -- twitter: twitter.com/David_Newman
Laurence wrote on 3/6/2014, 2:06 PM
Just to make it clearer using Cineform as an example. Cineform is a YUV format. Vegas works with RGB. Every time you read or write a Cineform video, it is being converted on the fly between RGB and YUV. When you use 10 Cineform, this translation from YUV to RGB happens in a very accurate way since it would take 9 bits of YUV to really handle the 8 bit RGB. Thus working at 10 bits gives a more accurate YUV representation of the 8 bit color that Vegas is using. That would explain why Musicvid's rendered gradient looks so much better, and why using 10 bit precision on any video format that uses YUV is a good idea. Yes, this is going to change my workflow and help me eek out a little more quality. Thanks Musicvid. It makes sense now.
musicvid10 wrote on 3/6/2014, 2:29 PM
DNxHD is Y'CbCr, or "YUV" in street language. Don't confuse the colorspace with the levels flag. YUV cannot be mathematically lossless, but it can come darn close.

Cineform can set to be either YUV or RGB, as can Huffy, Lagarith, UT and a few others I believe, even Debugmode.