Grass Valley HQX (in Vegas Pro 8 bit only)?

IIRC. Slow rendering (relatively) and not great (scrubbing) performance in Vegas.

Sure? On my system in VP17 the HQX render and scrubbing performance is even bit better than CineForm.

Imho - if not 10 bit output is needed, HQX is one of the best options beneath CineForm.

No, not 100% sure. I tested various codecs over the years, and singled out cineform and DNXHD as best performing for my use-case. It's worth another look. Thanks! 😀

Admission: part of the problem may be resolved by upgrading my hardware, which is something I plan to do in the new year.

OK. That looks promising. Did a quick render of 30 clips out of Resolve (encodes almost as fast as cineform) then "bulk" dragged into Vegas - no problems. Scrubs well in trimmer, reads timecode properly (XML back to resolve works perfectly) …. will need to "stress test" with more clips / resolutions / f-rates, but yeah... THANKS!

@Marco.

Do you know if there is a possibility to get Vegas/Resolve to work with a 10 bit version of Grass Valley HQX ?

(for future needs.)

In Vegas Pro there is no way to use the 10 bit of HQX because of the given VfW limitations of Vegas Pro (CineForm is the very exception, probably because it once was natively integrated into Vegas Pro).

...Yes, the two main issues for cineform appear to be occasional BLACK FRAMES and ASSERTION ERRORS from the Windows runtime component (occurs if you try to load too many files at once). I don't know which is worse - in general one can manage both, but it is a hassle.

For other / future readers: I found that using the cineform encoder/decoder pair from Davinci Resolve gave no black frames, but often yielded an assertion error. Other versions of the codec are the reverse. In the end I would suggest sticking to the download of the last version Gopro published - which can be found on Dr. Zens' moviestudiozen website...

@Kinvermark As I'm starting to investigate VEGAS<>Resolve workflows, I just did a quick survey of Cineform x64 codec versions on my machine. In ascending order of version, not date:

CFHDDecoder64.dll

• 9.2.0.689, 2 Mar 2017 from GoPro Quik 2.3.0.5383
• 9.2.1.108, 8 Nov 2019 from Resolve 16.2.1
• 9.2.1.690, 16 Mar 2017 from C:\Program Files (x86)\CineForm\Tools\

CFHDEncoder64.dll

• 9.2.1.108, 8 Nov 2019 from Resolve 16.2.1
• 9.2.1.690, 2 Mar 2017 from GoPro Quik 2.3.0.5383
• 9.2.1.690, 16 Mar 2017 from C:\Program Files (x86)\CineForm\Tools\

I'm not sure where the codecs in C:\Program Files (x86)\CineForm\Tools\ came from, and they are also in C:\Program Files (x86)\GoPro\Tools\. It seems to me that the GoPro Studio/Quik installers put versions of these codecs in all these locations:

• C:\Program Files\GoPro\GoPro Desktop App
• C:\Program Files (x86)\GoPro\Tools
• C:\Program Files (x86)\CineForm\Tools

Furthermore, I don't appear to still have the Quik 2.3.0.5383 installer, nor can I easily find it online. Perhaps it was an "in-app" update or something. All a bit confusing, and always has been where Cineform codecs are concerned. But my Quik version is later than the one on MovieStudioZen, and amongst these codecs, it's possible I might have a version of the decoder that offers the best compromise between black frames and assertion errors. Haven't actually tested yet.

@NickHope

Hi Nick,

My setup is the same as yours: 9.2.1.690 are latest file versions located in the \tools\ subdirectory. I also don't know where they came from and don't have that quik 2.3 installer. It's a mystery! (I have installed / uninstalled / re-installed so many times I have totally lost track.)

FWIW, the suggestion by Marco to use Grass Valley HQX from Resolve is a good one: timecode comes across and the files perform well in Vegas Pro. However, this all depends on your workflow and how perfectionist you are about preserving footage quality.

To (over) simplify: you either push "treated" footage from Resolve into Vegas for editing and finishing, or you edit footage in Vegas and then send to Resolve via FCP7 XML for finishing. The former is more straightforward and robust, but means rendering more "treated" footage than you will ultimately use. The latter is much more prone to problems reconnecting the footage (timecode is essential) and you are limited to a simple timeline with crossfades (no fx or special transitions, but pan/crop motions do work.) So, YMMV. Good luck :)

@Kinvermark When I render a Grass Valley HQX (or HQ) AVI (or MOV) file from Resolve and bring it to the VEGAS timeline, I get an increase in contrast, even if I select "video" levels in my Resolve render settings. "Full" levels gives even more contrast. I can crudely correct it the required amount with a "Computer RGB to Studio RGB" Levels FX, but don't really want to use that as a workflow in production.

This happens whether my source media is DV AVI, HDV M2T, or UHD MP4.

In Resolve its luminance matches the original.

Have you found a way for that not to happen?

Uncompressed YUV AVI does match luminance with the original in VEGAS but is obviously enormous. It's not truly lossless after the roundtrip either, but good enough.

Meanwhile, all my Cineform renders from Resolve fail (in Resolve) with "The video format is not supported". I've tried at Full HD as well as those formats mentioned above.

So at the moment, to get footage back to VEGAS, it's looking like either a) uncompressed AVI export (probably with a subsequent batch-render to MagicYUV or other intermediate format), or b) just exporting a LUT for each clip to use on my original footage in VEGAS.

Have you found a way for that not to happen?

As usual, found the answer right after posting. To maintain the levels with Grass Valley HQX, I needed to select "Full" Data Levels in the Resolve clip attributes, and "Video" Data Levels in the render settings.

The result is lossy but it's not detectable to my eyes, so this might be a workable solution.

I'm interested if you can successfully render Cineform from Resolve. If so, what resolution, settings etc.?

Also...

So, keeping mind the intermediate could be incoming or outgoing: Sony YUV equivalent from Resolve is huge and shows errors, and XAVC-I from resolve has other issues - that at the moment I can not remember, maybe trimmer scrubbing performance in Vegas, timecode?) I realize that some of this is very workflow specific, but I rely on smooth trimmer scrubbing for fast editing, and that works best with certain kinds of codecs.

I don't see a way to render XAVC-I from Resolve. Do you?

And by "Sony YUV equivalent", did you mean the uncompressed options? Sony YUV is compressed, IIRC.

Sony YUV is uncompressed 4:2:2, better known as "V210". At least that kind of Sony YUV offered in Vegas Pro.

This Vegas render template...

... produced this result.

The files are large and get worse as the pixel dimensions and frame rate increases.

Sony YUV holds the unquestioned accuracy benchmark for 422 and 420 encoding in my playbook. Has been for a decade.

Trouble is, it's 65 times larger than UT 422, my current go-to intermediate, and now my screencap favorite.

Resolve offers 3 uncompressed AVI render formats: RGB 10-bit, YUV 422 8-bit, and YUV 422-10-bit. The RGB 10-bit won't open in VP17.

Tomorrow I'll try and do some comparative testing of those two YUV formats vs the Grass Valley AVI formats for bringing intermediates back to VEGAS from Resolve. And I'll try to devise a way to compare the quality of just copying over a LUT instead of rendering an intermediate (at first glance, the 33 and 65 point 3D cube LUTs lose more quality than rendering Grass Valley HQX). I'll use wwaag's Render Quality app. If any Resolve users know of other formats I should throw in, please shout. XAVC isn't an option. Pity I can't get Cineform to render.

@NickHope

Haven't had any problems rendering cineform from any version of Resolve, in any normal format (HD, UHD, various video frame rates.) I don't use any special settings - just render as AVI. So, not sure what the issue is.

Maybe depends on your source footage? Alpha channel? Just guessing...

As for Grass valley contrast shift - yes, I did notice that too, but didn't care as I was only using the files for proxy editing, then exporting the timeline back (via FCP7 XML) back to Resolve for grading and finishing.

@NickHope

I didn't think Sony YUV did as well as I expected when I ran it through Wayne's Render Quality Metric tool.

Date: 2020/05/09  16:17:14  
Description: Sony YUV FHD 29.97p High Complexity
Frames Processed: 899
Processing Speed: 0.56 fps
Mean Squared Error: 4.03
Peak Signal to Noise Ratio: 49.417
Structural Similarity Metric: 0.9713

I was expecting numbers closer to 1 and 99.

@john_dennis I had a look at that, I think I'd need @Musicvid to explain all the in's and outs of it.

I hadn't bothered with the Sony codecs previously. In VFW there are 2 Sony YUV lossless/uncompressed codecs and 1 un-compressed RGB codec.

I have a FHD and a UHD source clip to match/do the render quality comparison. What I do is I used the 3 different lossless codecs mentioned above in a quick test using ffmpeg. I then chose the one that gave the best result and did the test using HORQ tool.

The 3 codecs return 3 different file sizes. In the case of the FHD comparison test I found that the smallest file gave the best quality result. "Sony YUV Codec" probably 8 bit.

In the case of the UHD comparison test  I found that the middle sized file gave the best quality result. "Sony 10 bit YUV Codec".

I'm guessing that the best results achieved may be when you match as close as possible the source file, 8 or 10 bit, with the output codec type, 8 or 10 bit.?

My UHD source file is 10 bit 422, matched/rendered with Sony 10 bit 422 codec.

My FHD source file is 8 bit 420, matched/rendered with Sony 8 bit 422 codec.

The FHD quality comparison gave the very highest result.

From what I can make out, with mediainfo's help ...

The 2 Sony Codecs give Lossless 422 8 bit and 10 bit YUV.

The non Sony Uncompressed codec gives 422 8 bit. RGB.

I've added in the results at the top of both tables below.

@NickHope

This probably isn't an issue for your immediate concern, but another downside of Sony YUV is that Avisynth cannot decode such files. Here's the error it produces: "[avisynth @ 0000017f4c07a7c0] AVISource: couldn't locate a decompressor for fourcc UYVY". Interestingly enough, they can be decoded using an internal de-compressor in VirtualDub2.

These numbers, which I've posted before, were obtained from MSU QMT,

and the wwaag QMT2 numbers were quite a bit lower, until I set the interval to 8 frames. Spot checks then came in nearly identical.

I got Cineform rendering working in Resolve (embarrassing user error... don't even ask... too long in lockdown!).

With reference to my search for a good round-tripping workflow from VEGAS, for colour correction and grading in Resolve, here are my results for uncorrected/ungraded AVI files exported from Resolve 16.2.1, then compared in VP17 with the original 4:2:0 8-bit UHD (Panasonic GH4). Descending order of quality from the top.

Of note:

• 10-bit uncompressed YUV worse than 8-bit, for 8-bit source.
• Cineform quality worse than Grass Valley HQX, which appears mostly due to a slight rise in luminance at the bright end. Which makes it easy to eliminate as a contender for me. I suppose there *might* be a setting somewhere that I've missed.
• The Cineform encoders 9.2.1.108 and 9.2.1.690 render exactly the same.
• Data levels are crucial to get right both in Resolve clip attributes and render attributes, and Grass Valley HQX behaves differently from the others.
• LUTs are the same whether exported at full or video levels.

So my 3 contenders are:

1. Uncompressed YUV 422 8-bit (with a subsequent render to MagicYUV).
2. 65-point cube LUT export for each clip.
3. Grass Valley HQX.

So I did some colour adjustments in Resolve, exported LUTs and rendered. Without a proper BlackMagic monitoring setup (yet) that I could screengrab UHD from, I can't think of an accurate way to compare the quality loss. All 3 contenders are visually the same to my eyes. If I had to bet on it, I would say that the videoscopes shift most for #1 (uncompressed), and as it loses in terms of hassle, playback, and storage, I'll eliminate that.

Playback is zippy (29.97fps) for both options #2 and #3.

LUT transfer (#2) is simple if you grade lots of footage exactly the same (track or project-level), and of course it uses less storage than intermediates, but it's a hassle to apply at event-level if you grade every clip individually. A scripting guru might be able devise a script to apply the appropriate LUT to the appropriate event, since Resolve automatically writes the media file name into the LUT name. That would be cool. But overall this workflow would be a bit error-prone.

Otherwise Grass Valley HQX (#3) seems a pretty clear winner for as a traditional intermediate. I hope large quantities of it play nicely with VEGAS.

Nice work Nick!

Some thoughts:

1) HQX does have a 10 bit variant, but I don't think Resolve renders it, and Vegas cannot read. Maybe something for the future?

2) Would be nice to test ProRes performance, but that can only come from Resolve on a Mac. That may also change - lot's of complaining in the Blackmagic forums.

3) LUT workflow would miss out on many "grading" features, such as tracked windows, stabilization, noise reduction...

4) You said "round trip from Vegas." What are you sending to Resolve from Vegas?

5) Still images: maybe not relevant to you, but I find these difficult to deal with as Resolve exports ALWAYS change the names (zeroes added) and need to be TIFF.