Big test (and performance/bug report) comparing VP22 to VP 19

jonnymomovies wrote on 8/2/2024, 1:17 AM

Hello, and thank you for reading. This post describes several issues (both bugs and performance lower than expected) that I have discovered so far in using VP22. It's a long (and very thorough) post, but my hope is that I can come out of this with better future results, and the devs can hopefully glean some knowledge using a real-world example and make some improvements.

Disclaimer. These are my tests and my results with documentation. I hope/believe that there could easily be something I am missing and if I sound sad it's because I was hoping for BIG gains using the new VP22 engine. I am not here to trash VP22 or VP in general. I am here to provide tested feedback and to learn what I could do better on in settings.

First. the scenario.

COMPUTER SPECS (consistent throughout ALL tests referenced in this post):

CPU: Intel core i7 4790K @ 4.0 GHZ

GPU: ASUS RTX 4070 Ti SUPER w 16 GB VRAM on latest NVIDIA Studio driver

16 GB system RAM

Windows 10

Project files (original OOC and proxy files) on a very new Crucial SSD, rendered to an internal NVME SSD (not same SSD as program install or Windows install)

QSV is off in settings (and renders were all HEVC using NVENC, no QSV) to make sure that I lean on the GPU (strongest part of my system) and can be sure I am not "confusing" anything. Trying to isolate GPU performance as an aid to Vegas.

For context, this project was filmed in 10-bit HEVC. Filmed in 6K "open gate" (3:2) on a Panasonic S5iiX using VLog at 29.976 fps.

The following details about the edit are provided for analysis by devs and other users to help with troubleshooting/performance improvements, but I am NOT looking to fight about whether my methods for the edit are how everyone else would do it in terms of STYLE (tips are of course welcome but the real point here is to show what I have discovered about VP22 vs VP 19 in terms of performance and bugs and can show empirically).

The edit:

For edit, I cropped to from the original 3:2 open gate down to a 17:9 image (to get full side to side stage coverage) using "Pan/Crop," added a lightly-applied Sharpen (because even at stopped down and high res, far away people in a high-detail scene benefitted from it), and had two identical video tracks but one was stacked on top of the other, very slightly offset horizontally by a couple pixels with some Bezier masking added (why is a long story). I knew this would result in a 16:9 render with very slight letterboxing on the top and bottom, and this was intentional. I placed a solid color (black) underneath the video tracks in order to totally ensure that my crops (in case I decided to reframe later, which I never ended up wanting or needing to do as I remained happy with the crop result) would always have the same consistent black borders on top and bottom. Whether or not this was strictly necessary is not really relevant, but I am posting this fact for FULL disclosure to aid in analysis of results. There were also many text items on the very top track of the project to demarcate sections of the show. Simple text, nothing fancy, no effects on the text.

In order to achieve the desired look but save on processing power, I went into the Color Grading panel on the original source track, used an input LUT designed for VLog cameras, and added a store-bought Look LUT on the back end as well. Once I got that pretty much how I wanted the project to look, I exported those settings as a Custom "Look LUT," then turned off color grading on the source tracks, then applied my newly made LUT (saved of course in .cube format) to the Video Bus only. Last step in this regard after much time staring at it editing cuts/transitions (but before rendering) was to also add a slight curves adjustment to the Master Video track (or bus, however you want to call it). So to be clear and to sum up, when editing and rendering:

- NO Color Grading was on the two source tracks (remember I turned it all off on the source track(s) after creating the LUT I applied to the master), only sharpen (and some Bezier masking on the top copy in addition to it being shifted horizontally by a couple pixels, to mask a couple teeny tiny flashy dots in a couple places caused by venue lighting).

The render(s):

- Renders (in both VP19 and VP22) were done using the HEVC NVENC template, at 3840 x 2160 @29.976 fps, "high quality" profile, full-resolution render quality "Best," Rec.709, Limited, VBR highest 40,000,000, average 30,000,000, 320 kbps AAC for audio.

I always wanted to use NVENC either way to (theoretically) leverage what SHOULD be the massive power of this RTX 4070 Ti Super. I honestly would rather render to h264 AVC (still using NVENC), BUT the only template Vegas has that puts out 10-bit is HEVC, and I also didn't want the file size to be completely ridiculous (it is a LONG show that is going to end up on Vimeo). The full show at these rates will be about a 27 HOUR render. I can only imagine what it would be if using H264.

After having previously (last week) done several versions of the exact same material/ same render settings on VP19 in order to test the effects of different options like "legacy GPU rendering" on/off, and then (today)hoping to achieve faster renders with my RTX 4070 Ti Super, but with the hoped-for benefits of VP22 as described (one of the MAIN reasons I upgraded to VP22 was the described engine/render/playback improvements, particularly for NVENC renders and for editing playback of HEVC, which this project was both shot and rendered in), and screenshotting the results (performance, specs like render time, CPU usage, memory usage, average FPS, render times, etc) today after installing VP22, I did the following:

- made a copy of the project to test with VP 22, and got all my program settings for VP22 to match how they were in VP 19

- I rendered the same exact material with the exact same render settings in VP 22 with the intent of seeing whether Vegas Pro 22 really is significantly faster as advertised due to the new engine.

Here are my conclusions, and ALSO a couple bugs/performance issues I have noticed about VP22 as compared to VP19.

Conclusion 1: no noticeable increase in playback performance while editing. It's that simple. It still struggles. It struggles at Preview quality: half and full, and it struggles HARD when preview is set to Good (half or full). Just like it did in VP 19. I know that 10-bit HEVC is a lot to ask, but with a RTX 4070 Ti Super (yes I know my CPU is a little dated but not THAT bad), i figured at the very least that VP 22 would struggle less than VP19, being that is supposed to be a strong point of VP22's new engine/decoders.. It was the same. Like, the exact same. If there was any improvement it is not detectable. Color grading off...still struggles. In VP22 just like in VP19.

I have "enable experimental HEVC" on in VP22 (is that a mistake?), and I of course have the 4070 selected for GPU rendering, optimization on, all that. And in my NVIDIA control panel, it is set up correctly there too. And I even went into Task Manager (in both my VP19 and VP 22 tests) and made sure Vegas was set to High Priority, and had no other apps running during any of these tests.

Conclusion 2: VP 22 is only very slightly better than VP19 when rendering HEVC using NVENC with all settings the same.

All tests were renders of a 2 minute 6 second clip of the exact same thing with the exact same settings.
Results of VP 19 test, only difference between these two renders depicted in the picture (both in VP 19) being trying legacy HEVC on and then off:

https://drive.google.com/file/d/1QpMyuw_IIBVXFNl3D8lH0Vn-lxJi-cG1/view?usp=sharing

Result of the same exact material and render setting in VP22 (but in VP22 there doesn't appear to be anything to try in regards to "legacy HEVC, however, I did have "enable experimental HEVC" on):

https://drive.google.com/file/d/1EZHz26Zuwznm7oYYBoJBqOrSBBveX3_i/view?usp=sharing

As you can see, the render time is very very similar. Not exactly the big speed upgrade I hoped for with the new engine. About the only benefit I can see from this test (and to be fair that slight reduction in render time might be solely attributable to the fact that I accidentally rendered a selection that was one second shorter at 2 minutes 5 seconds of material as opposed to the 2 minutes 6 seconds in VP 19 version) is that it was about 0.25 to 0.5 fps faster average. But in all cases it was around 2-3 fps average speed.

Also note: in VP19, Legacy HEVC off used slightly more CPU but way less disk usage (no idea why) than legacy HEVC on. Legacy ON was roughly 2-3 minutes faster but still took about 10 times as long to render as the length of the file.

And note that VP 22 did not fare much better in render time...slightly better than VP19 with "legacy HEVC" on, by about 2 minutes 20 seconds total improvement, but not a huge upgrade. Still over 20 minutes to render a 2 minute file.

Here is the Media Info showing, and I guess, comparing (although they are basically identical files, with one BIG caveat discussed below in another conclusion, see my immediate reply post about "conclusion 5") the file outputs resulting from rendering in VP19 (with legacy HEVC ON), and rendering in VP22 (experimental HEVC enabled):

https://drive.google.com/file/d/1TLFODT8oNiq9WK4WTAQf5O8lXgUC4b6x/view?usp=sharing

Conclusion 3 (bug report): VP22 has a bug in preview (NOT present in VP19), but will thankfully render without the bug.

See links just below this conclusion for evidence. I show it happening in VP22, but NOT happening in VP 19.

In VP 19, my 17:9 crop (in edit) shows properly at all levels of preview, and it renders as expected... 16:9 file with slight letterbox on top and bottom as intended/expected. In VP 22, the preview, IF set to "Preview" quality, distorts the image. Maybe distort is not the right word, but as you can see, it displays the content with SIDE letterboxes and fills from top to bottom (not correct!), but I found that when you change the preview quality to "Good" it thankfully fixes itself (reminder, there IS supposed to be slight letterboxing on top and bottom because the crop is 17:9 but the project/render are both 16:9)... whereas in in VP 19, it just looks right the whole time in all preview qualities.

VP19, no bug

https://drive.google.com/file/d/1X7HWzghwnmrBeARFC-ER1aR4NZSb611W/view?usp=drive_link

VP 22, bugged (watch what happens when preview quality is changed back and forth between "Preview" and "Good")

https://drive.google.com/file/d/1q8IqpOPflSeQYiesGwFDU5ZHPFwrfzKl/view?usp=sharing

Scary, but at least it does work out ok if you export a cap, and also ok when you render.

Conclusion 4 (possible bug?): VP22 lost the CG settings from VP19 (copy of same project, same drive, same files) and I had to manually redo them

Reminder for context: I saved my Color Grading settings as a Look LUT (in both versions) and also had the identical curves setting in both versions.

When I made a copy of my VP 19 project file so that I could test same in VP22, stored on the same SSD and using all the same source files, I was excited that it imported into VP22 fine and at first everything seemed great. But then I noticed two things: the preview bug noted in conclusion 3, and that for some reason, the VP22 version did not have the Look LUT in it/applied to it on the Master Video track/bus/whatever you want to call it.

I was able to go get the Look LUT I created from my PC (same location as VP19 project) and manually add it into the VP22 version the same way in the same place, but I was scared for a moment when I looked at the screen and saw that the color grading from the VP19 version was initially not present in the VP22 version. Good thing I had saved it as a Look LUT (.cube) and had not just had it as a manual group of settings, cause replicating all that by hand would have been rough.

The result was not a game breaker cause I was able to fix it, but I hope this is useful knowledge to the devs and to any users who may experience this as well.

THANK YOU so much to anyone who made it through this post. I repeat again that I am still a big fan of Vegas, and still intend to use it. And I hope this commentary is helpful! I will be happy to provide further info to any questions to the extent possible and have a few more screenshots if even more detail is need. Devs, please feel free to reply or message me if any of this is of interest to you for further discussion. Users, I welcome your comments/questions.

Back to post

Comments

jonnymomovies wrote on 8/3/2024, 1:08 AM

The least I could do after you did all that is give you some more test materials...even shot 3 profiles...although I doubt that would affect the bug but why not provide it, right?

5 second 3:2 sample in HLG...
https://drive.google.com/file/d/1KUFoocVREI-yIOPURiRp8MxKVespxTZl/view?usp=drive_link

5 second 3:2 sample in VLog...

https://drive.google.com/file/d/1HNCx8AS8tKosP7pWBPsnaalkPZ60Kz4I/view?usp=drive_link

5 second 3:2 sample in "natural"...

https://drive.google.com/file/d/1K1maPwv0mXYmUHKssznDsW_HCuz8ytyL/view?usp=drive_link

It may or may not matter, but for clarity's sake when I was working on tis I created proxies first, then set about to do crops/edits etc...

And just to be 100% sure for a chance at reproducing the bug from my OP....I will restate for convenience of reading and testing, I cropped to 17:9 in the edit, but the project is 16:9 and therefore the expected preview (and render result) should be 16:9 with top and bottom thin letterbox. As you see in my original tests, the preview changed to a weird side letterbox and filled from bottom to top with content when on preview settings lower than "good" but looked as expected when I switched to good or higher. And that was only in VP22, no such occurrence in VP19

jonnymomovies wrote on 8/3/2024, 1:24 AM

While you guys chew on those, I will share an "aha" I just had while re-reading earlier responses...that maybe someone can confirm makes sense or not...I suppose by rendering to Rec. 709 I am by definition not doing anything that could produce a final result that is HDR? Is that a sensible statement?

Again, at the time of my original post my two main objectives here were to provide a performance comparison from VP19 to VP22 regarding playback performance overall with HEVC sources, and render performance using NVENC (with the absolutely lovely side effect that I am now massively benefitting due to having learned a LOT about several topics via everyone's comments) and to report this preview bug thing....but I am definitely not too proud to admit that I have questions like these as I digest and learn...if I understand correctly, one can shoot HDR and render to Rec 709 (giving up the specific characteristics of HDR while still being 10 bit result), but you cannot render Rec 709 and have the result be HDR even if you shoot HDR. Is that accurate?

RogerS wrote on 8/3/2024, 1:31 AM

Re camera settings, please set it exactly the way you did with the file that had a preview proxy problem.

(I see you just posted files; will test in a bit)

jonnymomovies wrote on 8/3/2024, 1:43 AM

The VLog one is an EXACT match in every single respect (save for White Balance) to the source file that was used in the session that produced the preview-shape bug in VP22 (but did not in VP19). The original was at 4000K, this one I shot tonight was at 3200 (the "indoor" preset if you will)

If you believe WB could matter here, I will reshoot another sample at 4000K.

That aside, other than changing the WB, on these other 2 of the three samples, the only difference between shoot day (for that project) and tonight is that for each sample the profile was altered. To be super clear:
same format, same framerate, same ISO, same lens, everything.

Just shot three different profiles tonight "in case" even though I doubt that would affect the shape of the preview.

I suppose if we wanted to be SUPER scientific and do a total recreation of every single aspect, I would need to do the 4000K WB, and also import these into VP19, proxy, then crop, then playback whilst switching preview quality

and then do the same thing in VP22.

For convenience I repeat here that renders were correct size shape in all respects in both programs...it is only during preview,,, specifically at "preview" quality or less,(in edit sessions) in VP 22 that the weird thing occurred

Wolfgang S. wrote on 8/3/2024, 1:45 AM

While a conversion from SDR (rec709) to HDR is technical possible, this is different to shooting to log. With log you capture the full dynamic range what the sensor of the camera can capture - while if you shoot in SDR the dynamic range will be limited.

However, if your PC is capable for HDR is the question. Not really.

jonnymomovies wrote on 8/3/2024, 1:46 AM

While a conversion from SDR (rec709) to HDR is technical possible, this is different to shooting to log. With log you capture the full dynamic range what the sensor of the camera can capture - while if you shoot in SDR the dynamic range will be limited.

However, if your PC is capable for HDR is the question. Not really.

An excellent point but I do still currently stand by my decision to shoot VLog for the reasons outlined in detail in the longer reply above, dynamic range in the scenes, "safety", future-proofing,need to shoot at high ISO and flexibility in post being chief among them.

To be clear I am not trying to sound defensive (and also I do not believe you are criticizing this decision), just trying to be ultra clear in my responses. It's the least I can do with all you guys putting this much effort into your replies!

Your doubts about my PC are entirely fair. I can build a new PC (once this Intel mess gets cleaned up) but I can't go back in time and reshoot, so my decisions for the capture were based on getting the capture that gave me the best chances of success now and in potential future re-renders.

RogerS wrote on 8/3/2024, 1:56 AM

While you guys chew on those, I will share an "aha" I just had while re-reading earlier responses...that maybe someone can confirm makes sense or not...I suppose by rendering to Rec. 709 I am by definition not doing anything that could produce a final result that is HDR? Is that a sensible statement?

if I understand correctly, one can shoot HDR and render to Rec 709 (giving up the specific characteristics of HDR while still being 10 bit result), but you cannot render Rec 709 and have the result be HDR even if you shoot HDR. Is that accurate?

I think you are missing a few things.

The first is that your camera is capturing a range of brightness and colors beyond that of "HDR" of which HDR10 is a current standard for output. That is reasonable and future proofs your work to some extent.

What you do with that extended range is up to you.

You gave up on achieving actual HDR as soon as you applied a SDR and Rec709 LUT and worked on a non-HDR project. I think that is the right choice if you don't have a 1000 nit HDR monitor for color correction and given the age of the system.

10-bit output is just a way to ensure better gradations/color transitions with wider gamut and high dynamic range output files. You can render SDR/Rec 709 at 10-bit precision though I challenge you to see any difference, and the streaming services you use may just ignore the 10-bits and share it as 8 bit anyway.

jonnymomovies wrote on 8/3/2024, 2:00 AM

You're expressing it a lot more accurately than I was able to from a technical POV and again teaching me, but I do think we are same page overall...it sounds like you agree with my capture decisions and now it's all about learning the best way(s) to process said footage and you also provide more meaningful info about WHY to make certain choices in post for a given result.

RogerS wrote on 8/3/2024, 2:05 AM

I downloaded the vlog sample.

First impressions: it actually plays back well on my laptop (7th gen Intel CPU with GTX 1050) at preview/ full which I didn't expect.

Step 2: I created a proxy.

Step 3: adjusted project settings to UHD 29.970p.

Step 4: was going to play with pan crop but that wasn't even necessary.

Best full (original file):

Preview/full (proxy):

So bug confirmed.

General
Complete name                  : P1000954 VLog.MOV
Format                         : MPEG-4
Format profile                 : QuickTime
Codec ID                       : qt   2011.07 (qt /pana)
File size                      : 151 MiB
Duration                       : 6 s 6 ms
Overall bit rate               : 211 Mb/s
Frame rate                     : 29.970 FPS
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

Video
ID                             : 1
Format                         : HEVC
Format/Info                    : High Efficiency Video Coding
Format profile                 : Main 10@L6@High
Codec ID                       : hvc1
Codec ID/Info                  : High Efficiency Video Coding
Duration                       : 6 s 6 ms
Bit rate                       : 203 Mb/s
Width                          : 5 952 pixels
Height                         : 3 968 pixels
Display aspect ratio           : 3:2
Frame rate mode                : Constant
Frame rate                     : 29.970 (30000/1001) FPS
Color space                    : YUV
Chroma subsampling             : 4:2:0
Bit depth                      : 10 bits
Bits/(Pixel*Frame)             : 0.287
Stream size                    : 145 MiB (96%)
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC
Color range                    : Full
Color primaries                : BT.709
Transfer characteristics       : BT.709
Matrix coefficients            : BT.709
Codec configuration box        : hvcC

Audio #1
ID                             : 2
Format                         : PCM
Format settings                : Big / Signed
Codec ID                       : lpcm
Duration                       : 6 s 6 ms
Bit rate mode                  : Constant
Bit rate                       : 1 152 kb/s
Channel(s)                     : 1 channel
Sampling rate                  : 48.0 kHz
Bit depth                      : 24 bits
Stream size                    : 845 KiB (1%)
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

Audio #2
ID                             : 3
Format                         : PCM
Format settings                : Big / Signed
Codec ID                       : lpcm
Duration                       : 6 s 6 ms
Bit rate mode                  : Constant
Bit rate                       : 1 152 kb/s
Channel(s)                     : 1 channel
Sampling rate                  : 48.0 kHz
Bit depth                      : 24 bits
Stream size                    : 845 KiB (1%)
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

Audio #3
ID                             : 4
Format                         : PCM
Format settings                : Big / Signed
Codec ID                       : lpcm
Duration                       : 6 s 6 ms
Bit rate mode                  : Constant
Bit rate                       : 1 152 kb/s
Channel(s)                     : 1 channel
Sampling rate                  : 48.0 kHz
Bit depth                      : 24 bits
Stream size                    : 845 KiB (1%)
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

Audio #4
ID                             : 5
Format                         : PCM
Format settings                : Big / Signed
Codec ID                       : lpcm
Duration                       : 6 s 6 ms
Bit rate mode                  : Constant
Bit rate                       : 1 152 kb/s
Channel(s)                     : 1 channel
Sampling rate                  : 48.0 kHz
Bit depth                      : 24 bits
Stream size                    : 845 KiB (1%)
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

Other
ID                             : 6
Type                           : Time code
Format                         : QuickTime TC
Duration                       : 6 s 6 ms
Bit rate mode                  : Constant
Frame rate                     : 29.970 (30000/1001) FPS
Time code of first frame       : 13:54:03;21
Time code of last frame        : 13:54:09;20
Time code, stripped            : No
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

jonnymomovies wrote on 8/3/2024, 2:13 AM

While we're at it, the OTHER reason (I knew I forgot something) I shot VLog was to make it easier to match up later when I do my second edit that will involve a second (handheld) angle. As stated above, everything discussed up to this point was shot on a S5iiX...but the handheld was on a GH6 so shooting both in VLog gives me the best chance to match them (not sure what better I could do to prepare for a future match other than ALSO using RAW, which is just not an option at these resolutions with my gear and no way would my cards or SSDs be able to do that for 6 hours even if they could shoot RAW onto them in general)

I don't feel like anyone is on my case here about shooting VLog, or about shooting in HEVC...I'm just talking about it because this discussion has grown (very productively) to encompass so much about color and formats and other aspects beyond the scope of the preview bug report.

jonnymomovies wrote on 8/3/2024, 2:17 AM

I downloaded the vlog sample.

First impressions: it actually plays back well on my laptop (7th gen Intel CPU with GTX 1050) at preview/ full which I didn't expect.

Step 2: I created a proxy.

Step 3: adjusted project settings to UHD 29.970p.

Step 4: was going to play with pan crop but that wasn't even necessary.

Best full (original file):

Preview/full (proxy):

So bug confirmed.

General
Complete name                  : P1000954 VLog.MOV
Format                         : MPEG-4
Format profile                 : QuickTime
Codec ID                       : qt   2011.07 (qt /pana)
File size                      : 151 MiB
Duration                       : 6 s 6 ms
Overall bit rate               : 211 Mb/s
Frame rate                     : 29.970 FPS
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

Video
ID                             : 1
Format                         : HEVC
Format/Info                    : High Efficiency Video Coding
Format profile                 : Main 10@L6@High
Codec ID                       : hvc1
Codec ID/Info                  : High Efficiency Video Coding
Duration                       : 6 s 6 ms
Bit rate                       : 203 Mb/s
Width                          : 5 952 pixels
Height                         : 3 968 pixels
Display aspect ratio           : 3:2
Frame rate mode                : Constant
Frame rate                     : 29.970 (30000/1001) FPS
Color space                    : YUV
Chroma subsampling             : 4:2:0
Bit depth                      : 10 bits
Bits/(Pixel*Frame)             : 0.287
Stream size                    : 145 MiB (96%)
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC
Color range                    : Full
Color primaries                : BT.709
Transfer characteristics       : BT.709
Matrix coefficients            : BT.709
Codec configuration box        : hvcC

Audio #1
ID                             : 2
Format                         : PCM
Format settings                : Big / Signed
Codec ID                       : lpcm
Duration                       : 6 s 6 ms
Bit rate mode                  : Constant
Bit rate                       : 1 152 kb/s
Channel(s)                     : 1 channel
Sampling rate                  : 48.0 kHz
Bit depth                      : 24 bits
Stream size                    : 845 KiB (1%)
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

Audio #2
ID                             : 3
Format                         : PCM
Format settings                : Big / Signed
Codec ID                       : lpcm
Duration                       : 6 s 6 ms
Bit rate mode                  : Constant
Bit rate                       : 1 152 kb/s
Channel(s)                     : 1 channel
Sampling rate                  : 48.0 kHz
Bit depth                      : 24 bits
Stream size                    : 845 KiB (1%)
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

Audio #3
ID                             : 4
Format                         : PCM
Format settings                : Big / Signed
Codec ID                       : lpcm
Duration                       : 6 s 6 ms
Bit rate mode                  : Constant
Bit rate                       : 1 152 kb/s
Channel(s)                     : 1 channel
Sampling rate                  : 48.0 kHz
Bit depth                      : 24 bits
Stream size                    : 845 KiB (1%)
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

Audio #4
ID                             : 5
Format                         : PCM
Format settings                : Big / Signed
Codec ID                       : lpcm
Duration                       : 6 s 6 ms
Bit rate mode                  : Constant
Bit rate                       : 1 152 kb/s
Channel(s)                     : 1 channel
Sampling rate                  : 48.0 kHz
Bit depth                      : 24 bits
Stream size                    : 845 KiB (1%)
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

Other
ID                             : 6
Type                           : Time code
Format                         : QuickTime TC
Duration                       : 6 s 6 ms
Bit rate mode                  : Constant
Frame rate                     : 29.970 (30000/1001) FPS
Time code of first frame       : 13:54:03;21
Time code of last frame        : 13:54:09;20
Time code, stripped            : No
Encoded date                   : 2024-08-03 05:52:28 UTC
Tagged date                    : 2024-08-03 05:52:28 UTC

I'm sad it exists, but I am glad (and thankful) that you reproduced it. I agree, the crop wasn't even necessary to see it...it's clear from your caps that the display "shape" changed when you changed preview settings.

Any theories to why?

RogerS wrote on 8/3/2024, 2:23 AM

My theory is that VEGAS proxy files are always XDCAM 720p and 16:9 and the same framerate and then converted to whatever the media actually is when used.

They maybe forgot to do the multiplication needed to correct for the aspect ratio for non 16:9 source files with the new decoder.

Why I think that is that the proxy file itself looks totally fine when you change the extension and open it in a media player but the Mediainfo says 16:9.

-----

Nobody's arguing about shooting Vlog in situations with tricky lighting where you have to match cameras. Log can store much of the color data as raw without the huge storage penalty. The only gentle criticism is to do the conversion from log to gamma 2.2 in high-bit mode (32-bit full ACES off or on) to get the most out of your 10-bit original and reduce the potential for banding and posterization in the final render. This is way more important than whether that render itself is to a 10-bit or 8-bit file.

jonnymomovies wrote on 8/3/2024, 2:48 AM

I will study this reply very closely, certainly accept the constructive criticism (which is indeed gentle and is presented in a very helpful way) and commit to doing a lot of follow up research on log to gamma, ACES in general (and specifics) and whatever flows from that. Thank you, again!

FWIW I did have a successful (see below for details) render of the first half of this 2-part deliverable out of VP 19, a week or so before getting VP22 and going down the road that led to this thread. Happily, and this is why I call it successful, the amount (or really, lack of) banding and posterization, given that it was done with my less sophisticated methods of LUT use and a little curve as outlined in detail above( in it was not bad at all, and I and the few who have seen it so far find it generally pleasing to watch and the edits all worked etc, I look forward to applying the knowledge you are all imparting (and using the better speeds possible with VP22 and easier playback when editing) to do another re-render of that first deliverable, with a potentially even better result if I can learn and apply what you are teaching me here.

I also call it successful because although it was PAINFULLY long (as you could infer from the posts way above when I gave all those screencaps of render times comparing VP19 with legacy HEVC on and off, and VP 22 with "experimental HEVC" [dumb on my part as discussed to have that on], all using NVENC to result in HEVC 10 bit from my weak CPU/RAM but strong. likely bottlenecked GPU), just the fact that it completed the render and didn't crash was a win, right? We all know what I mean, we've all had a long render fail at some point most likely. So just having a decent pleasing to watch overall render of the first portion of the deliverable was a win. I can work on wat I am being taught here and maybe get an even BETTER result but I must admit the first one (buried in the discussion of the OP)

That said, again,
I will study this reply very closely, certainly accept the constructive criticism (which is indeed gentle and is presented in a very helpful way) and commit to doing a lot of follow up research on log to gamma, ACES in general (and specifics) and whatever flows from that. Thank you, again, again!

fr0sty wrote on 8/3/2024, 2:52 AM

While we're at it, the OTHER reason (I knew I forgot something) I shot VLog was to make it easier to match up later when I do my second edit that will involve a second (handheld) angle. As stated above, everything discussed up to this point was shot on a S5iiX...but the handheld was on a GH6 so shooting both in VLog gives me the best chance to match them (not sure what better I could do to prepare for a future match other than ALSO using RAW, which is just not an option at these resolutions with my gear and no way would my cards or SSDs be able to do that for 6 hours even if they could shoot RAW onto them in general)

I don't feel like anyone is on my case here about shooting VLog, or about shooting in HEVC...I'm just talking about it because this discussion has grown (very productively) to encompass so much about color and formats and other aspects beyond the scope of the preview bug report.

I often shoot VLOG for the same reasons, plus it's better than shooting HLG if HDR is my target format, you can grade it further, and it captures the max dynamic range of the camera (other than shooting RAW).

As for your HDR question, I'll break it down.. HDR consists of 2 core components (a bit more there's metadata involved as well, but I'm going to keep this simple)...

1. 10 bit video that allows for up to 1000 nits (for HDR 10, Dolby Vision uses 12 bit and can go much higher).

2. Rec2020 color space, which can reproduce a far wider gamut of colors than Rec709 (see below image, both are sometimes called "BT2020" and "BT709").

When you shoot VLOG/VGamut, you're actually shooting at an even wider color gamut than Rec2020 (see below image).

So, in order to record and render to HDR, you must shoot at least 10 bit video that is shot in Vgamut (which VLOG uses) or a similar log color profile like S-Log, CLog, etc. depending on your camera manufacturer. Some cameras also support recording to HLG, which also uses Rec2020, but it's limited vs. VLOG, as it doesn't reproduce highlights as well. The benefit of using HLG, however, is it will look normal when viewed on a non-HDR TV, whereas HDR10 won't always, the colors and contrast will be off. So you trade some quality for backwards compatibility. Because of the limited highlights, it isn't recommended to shoot HLG if you plan on color grading the resulting footage.

Once you get it into VEGAS, putting it into 32 bit full range or HDR mode enables the ACES color space (which has a gamut that is even wider than the human eye is capable of seeing, see the above chart again). This doesn't up-convert the color at all, but it does ensure that you don't lose any color information while working on it.

ACES only works if it knows the color space of your media, so you then must right click on the media in your project media pool, go to "properties", and then under color space, specify that it is "VLog/VGamut". You should instantly notice, like applying a LUT, the colors go from desaturated and low contrast, to looking normal. This is your starting point for your color grading process.

If you choose to render with HDR mode turned off, you default to the Rec709 (or sRGB, which is very similar) color space, so while you might be able to render to a 10 bit format, and utilize the 0-1023 shades from pure black to pure white or any of the 3 primary colors (vs. 16-235 for limited range SDR), you're still restricted to the color gamut of Rec709, so it isn't true HDR. Enabling HDR mode turns on the Rec2020 color space, which converts the Vgamut that you shot in to Rec2020, and you get true 10 bit Rec2020 HDR output from the resulting file, which will properly display if played back on an HDR TV or uploaded to a platform like Youtube that supports HDR.

The above explanation is a bit simplified, it ignores HDR metadata and YUV color compression that is used, but it'll get you most of the way to a full understanding.

jonnymomovies wrote on 8/3/2024, 3:09 AM

Thank you so much! Studying.

I alluded to this before, but historically, I've been a "shoot what you want to see" guy (often driven by necessity of quick turnaround times and the fact that I also do a LOT of live event work and streaming work in addition to promotional. corporate, educational, some narrative/music videos,) That is not AT ALL to say people who get way more into this realm of applied color/render science are wasting their time or wrong about anything, in fact, the stuff you guys are teaching me now is a look at where I want to ultimately get to. A worthwhile goal. Growth opportunity!

Truly understanding the truth and science about working with color in post (except my knack for doing cool effect-y stuff in music vids and being able to do passable very light adjustments to stuff that was well shot "naturally" in the first place) is a definite area for me to grow into and this thread has provided a golden opportunity for that. This is an incredible thread in my opinion, so very helpful and can really pay off if I study and apply it, particularly to projects that are a little more artsy or nuanced. Such value here for the journey. I'm always trying to learn, read, watch, listen, practice, etc. and work all the time too, but to have a personal example given and evaluated thusly, and having so many people providing their specific recs and just straight knowledge along the way, is a gift, and one that I do not take lightly.

And hey, I helped successfully get a bug ID'd with others' help, learned so much already from all you guys, and VP22 is really growing on me as well! What a win!

jonnymomovies wrote on 8/9/2024, 1:11 PM

I wanted to mention…I’ve just built a new, much more modern PC and installed VP22 on it and am now in a much better position to implement the things I learned from this thread.

Thanks again everyone!

Wolfgang S. wrote on 8/9/2024, 1:41 PM

Post your suggestion for the hardware components.

jonnymomovies wrote on 8/9/2024, 1:50 PM

My new build:

i9-12900K

ASUS 4070 Ti Super OC edition (which is no longer bottlenecked as opposed to how it was in my old system)

64 GB of RAM

Samsung 990 Pro NVME drives

NZXT Kraken AIO cooler

It has absolutely crushed everything I've thrown at it so far. I can run best/ Full preview with color grade on a 4K project using 6K HEVC source files and still have a smooth preview unless I introduce crazy FX on top of that. The combination of the new build and the new VP 22 engine is proving quite fruitful thus far.

12th generation Intel chip is a massive upgrade over what I had before(i7-4790K from 2014) and although it's technically not the latest/greatest, at least I don't have to worry about all the problems that people are having recently with 13th and 14th gen Intel chips. Plus they had a really great bundle at the local store that allowed me to save hundreds on the combination of the chip and motherboard.

Howard-Vigorita wrote on 8/9/2024, 2:10 PM

@jonnymomovies Fwiw, if you want to compare vp19 with vp22, you should start with default Vegas File I/O preferences for both and not try and force them to match. Specifically, vp19 uses legacy-hevc as it's default which no longer appears as an option in vp22 but is in fact its internal default if don't mess with the check-boxes. Unchecking it in vp19 corresponds more to checking experimental-hevc in vp22, which lowers quality to increase performance. Also, vp19 was optimized to use an igpu for decoding, if available, while vp22 seems optimized to confine both timeline and decoding within the same gpu. I think those defaults are getting me better editing and playback performance with vp22 while not sacrificing render quality compared to vp19. I think those settings will probably also impact Aces similarly, but I don't do hdr in my projects.

RogerS wrote on 8/9/2024, 4:53 PM

Excellent choice of hardware and I'm glad you are happy with the performance.