Vegas 15 levels issue while rendering with SonyAVC encoder

fifonik wrote on 1/24/2018, 2:50 AM

Looks like something broken in Vegas 15 related to video levels while rendering with Sony AVC encoder.
Video from Panasonic X920 camcorder. Media info:

ID                                       : 4113 (0x1011)

Menu ID                                  : 1 (0x1)
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.2
Format settings                          : CABAC / 2 Ref Frames
Format settings, CABAC                   : Yes
Format settings, RefFrames               : 2 frames
Format settings, GOP                     : M=3, N=30
Codec ID                                 : 27
Duration                                 : 7 s 975 ms
Bit rate mode                            : Variable
Bit rate                                 : 23.3 Mb/s
Maximum bit rate                         : 25.0 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 59.940 (60000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.187
Stream size                              : 22.1 MiB (94%)


I created a new project "V13", in Vegas 13, dragged to the project a single video file, matched project property to video property then changed pixel format to 32-bit (video level) and rendered it with Sony AVC. All good, in player resulting video looks exactly as original video (screenshot attached).

Created a copy of the project file in explorer as "V15", opened it in Vegas 15, pressed Ctrl + S to converted to Vegas 15 format, then rendered it with Sony AVC encoder. Fail: resulting video looks like someone added Computer RGB to Studio RGB conversion before rendering.

At the beginning I tried to create Vegas 15 project from the scratch with the same results. Only then I decided to open the project created in Vegas 13 to be sure that they are exactly the same.

Previews and scopes looks exactly the same in Vegas 13 and Vegas 15.

 

Then I created a new project, dropped original and two resulted videos on separate tracks and clicking solo button per track one by one. Scopes for original video looks like Vegas 13 Sony AVC rendered video, scopes for Vegas 15 Sony AVC rendered video looked squashed (as after "Computer RGB to Studio RGB" conversion). Added Levels with preset "Studio RGB to Computer RGB" to the Vegas 15 rendered video -- voila, scopes are as they should be.

 

I tried to render videos with Vegas 13 Mainconcept AVC and Vegas 15 Magix AVC encoders -- everything is OK.

So my questions:

- Is it known bug?

- If it is know bug, are there ETA for bug fix?

- If not, should I create bug report somewhere or this does not change anything? (I have experience with sending bug reports related to previous Vegas versions to Sony. They have not done anything about bugs I sent them...)

- Are there any workaround (other than not to use Sony AVC encoder)?

 

Some screen shots (with project and encoders settings, layout with scopes, player):

 

Link to archive with source video, project files, resulting videos and attached screen shots (~70MB):

https://www.dropbox.com/s/ueul6jrpdpc2csq/Vegas%2015%20Video%20Levels.zip?dl=0

 

Thanks.

Last changed by fifonik

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

Comments

Marco. wrote on 1/24/2018, 4:29 AM

Yes, I think it is (kind of) a known bug. "Kind of" because I already reported something similar when rendering to XDCAM EX. But I thought XDCAM EX would be the only render format affected. I didn't know it also occurs when rendering to Sony AVC.

I will check this and report but this will last a while, so it would be great if you also could send a bug report.

Beside that – is there a certain reason you use floating point instead of 8 bit as pixel format? In my experience most of the time when people use floating point in Vegas Pro, actually there is no need for and the overall better choice would be using an 8 bit project.

fifonik wrote on 1/24/2018, 5:09 AM

Thanks for your answer and for pointing at pixel format. I'm confirming that changing pixel format to 8-bit solves the issue with Sony AVC encoder.

 

I use Sony AVC encoder for rendering drafts only as it is fast and by my tests gave better and more stable results than Mainconcept (one of my bug reports to Sony was about Mainconcept encoder issues. It was not reported as fixed so I'm not using the encoder any longer. Unfortunately, I do not know if the bug is still exist).

 

I use 32-bit pixel format as I'm using external encoder (through frame server) for final renders where I have ready to use scripts. I do remember that long time ago (Vegas 11 era) I played with different pixel formats for my SD video projects and found some detectable differences (32 bits gave better results) and then decided to use it "by default" for all my projects. It is possible that my tests was not absolutely correct these days (I just started with video editing then) or my perfectional-ism forced me to believe in this. I do not have the test project I used for the comparation.

 

P.S. I'll send a bug report about the issue.

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

Pashi wrote on 1/24/2018, 5:12 AM

It is one more option from my WISHLIST - selectable - full or video - levels when rendering. Now all we have is to add Computer RGB to Studio RGB before rendering.

Marco. wrote on 1/24/2018, 5:32 AM

Floating point won't provide any advantage in this case, but worse playback and longer render times instead. I'd really recommend using 8 bit instead.

fifonik wrote on 1/24/2018, 5:34 AM

2 Cornico: You suggestion is about levels in preview. I do not care about preview as I'm using scopes while tuning levels (However, it would be really-really good to have working preview in one-monitor setup. Can I vote for the feature somewhere?).

The bug is not about preview, it's about levels that are changed in rendered video.

Last changed by fifonik on 1/24/2018, 5:42 AM, changed a total of 1 times.

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

fifonik wrote on 1/24/2018, 5:41 AM

> Floating point won't provide any advantage in this case, but worse playback and longer render times instead. I'd really recommend using 8 bit instead.

It is possible.

However, If I understand correctly, we can also get slightly better results with 32-bit pixel format when we use chains in filters (as the results after the first filter is not rounded up and used as-is by second filter etc). And I always have chains in filters for almost every part of my project.

I would prefer not to loose any bit of quality if possible without a reason (this is why I use external x264 encoder).

I agree, that speed is much better with 8-bits pixel format. Unfortunately, I cannot work on my project in 8-bits and then switch it in 32-bits before the final render as some filters give completely incorrect results in this case. Well, it used to be this way when I checked. It is possible that in Vegas 15 such issues are fixed already.

Last changed by fifonik on 1/24/2018, 5:44 AM, changed a total of 1 times.

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

Pashi wrote on 1/24/2018, 5:46 AM

You suggestion about levels in preview. I do not care about preview as I'm using scopes while tuning levels (However, it would be really-really good to have working preview in one-monitor setup. Can I vote for the feature somewhere?).

The bug is not about preview, it's about levels that are changed in rendered video.

It's very old issue between almost all editing software and video players. Quicktime shows video too gray, Media Player Home classic in default too contrasty. But there is an option in MPHC to choose levels - 16-235 or 0-255. There is also problem with color matrix - when you upload your footage to Vimeo or Youtube you can see noticeble color shift.

fifonik wrote on 1/24/2018, 6:17 AM

I do not have issues with my videos videos in any player with default settings (including MPC, QT, uploading to youtube, vimeo, etc).

It does not mean that is no such issues at all. However, if the video made correctly, such issues are minimal.

 

In my case everything worked fine in Vegas 11, 12, 13. But in Vegas 15 it does not work fine any longer with absolutely the same workflow if 32-bits pixel format and SonyAVC encoder is used (it works fine in other cases). For me this means that there is something not good in Vegas 15.

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

Marco. wrote on 1/24/2018, 7:27 AM

Yes, these (preview and floatpoint render levels) are two completely different things and while the floatpoint thing quite probably is a bug, the preview thing is just one possible (and appreciated by many Vegas users) way of internal processing of video levels.

Wolfgang S. wrote on 1/24/2018, 1:20 PM

Well, I have here a project with 10bit Hypergamma footage from my FS7. Was editing that in 32bit mode - and had to render it to AVC. The Sony Encoder failed since the levels were changed. So I took the MAGIX AVC Encoder and that worked fine.

Musicvid wrote on 1/24/2018, 7:16 PM

However, If I understand correctly, we can also get slightly better results with 32-bit pixel format when we use chains in filters (as the results after the first filter is not rounded up and used as-is by second filter etc).

With 8 bit source, no one has been able to demonstrate a measurable effect. The reason is that the source is not upsampled in a 32 bit project; it's just full of air, which can't be graded.

fifonik wrote on 1/25/2018, 1:19 AM

With 8 bit source, no one has been able to demonstrate a measurable effect

 

- Open Vegas, create a new "32-bit video levels" project

- Add checkerboard media generator to time line, set the first colour to 0.5, 0.5, 0.5, 1 and the second colour to 0.9, 0.9, 0.9, 1

- Add to the checkerboard fragment "Levels" filter twice

- For the first instance of "Levels" filter in the chain set "Input end" to 0.5 (some colours are moving outside of 8-bits colours range)

- For the second instance of "Levels" filter in the chain set "Output end" to 0.5 (so you simply reverting everything back)

You should see squares in preview and four lines in scopes

Now switch the project properties to 8-bit pixel format. You will not see squares in preview any longer and only one line will be shown in scopes (128). Switch project back to 32-bit pixel format and you will see squares again.

 

While working with 32-bit pixel format the range during calculations is not ended up on white colour. So if one filter in chain moves colours "above white" the colour is not clipped before the second filter in chain.

The same thing can easily happen when you are working with normal video (not media generated as in the demo) and using a few filters in chain. You can minimize it's effect by using specific filters order. However, I prefer to set project to 32-bit video levels pixel format and do not even think about possibility of the issue.

 

Here is the quote from Vegas help:

When using 8-bit input/output, the 32-bit floating point (video levels) setting can prevent banding from compositing that contains fades, feathered edges, or gradients.

Last changed by fifonik on 3/1/2018, 6:18 PM, changed a total of 3 times.

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

fifonik wrote on 1/30/2018, 9:17 PM

The issues is reported. Ticket#2018012417003314

Thank you for your message. I have tested this and gotten the same result on our end. I have sent a bug report of to our dev team so that it may be addressed in a future update/release of the software.

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

Musicvid wrote on 1/30/2018, 11:41 PM

You should see squares in preview and four lines in scopes

Now switch the project properties to 8-bits. You will not see squares in preview any longer and only one line will be in scopes (128). Switch it back and you will see squares again.

Got renders?

Marco. wrote on 1/31/2018, 3:46 AM

@fifonik These are cases where I would also use float point processing. Sometimes.

One thing to take care of, for 8 bit outputs it would only help if your signals exceed the range from 0-1. But usually I carefully control the levels via scopes and try to avoid leaving the range from 0-1. Then there's no need for float point processing when your project would finally leave as an 8 bit video.
(And just to avoid confusing others: if the output is 8 bit or any other integer processing type, this recover of clipping only works inside this very float point project before rendering.)

The other thing to take care of is, not all of the plug-ins completely support float point processing, e.g. if you use Color Curves this would likely break the advantages mentioned above because Color Curves just cuts everything beyound 0-1, even within float point projects.
So as an example, in a float point project you could clip your signal with the contrast slider of "Brightness & Contrast" and exactly recover with a second "Brightness & Contrast" plug-in. But once you put "Color Curves" in between the two "Brightness & Contrast" plug-ins, there is no way to recover clipping even if you did not touch the curve.

I left banding out here because it is a even more complex area.

fifonik wrote on 1/31/2018, 4:09 AM

Agree.

I'm aware that not every filter supports 32-bit processing and levels are truncated by such filters (almost in the same way as in 8-bit processing, not worse).

I also aware that everything that out of range will be lost after encoding.

However, for me 32-bit processing looks better as in some cases there is no [multiple] data loss in the filter chains.

So the overall quality is never getting worse. The speed is (this can be vital for 4K editing).

 

In 8-bit processing, with more than two filters in chain to prevent the levels trimming I have to control levels (with scopes) after each filter applied. For example, is I already applied two filters and then I'd like to tune the first filter in the chain, I must disable the second filter before the changes because in other case the scopes will not show me correct levels.

The situation becoming worse if I have not only two filters on event, but media filter, track filter, output filter etc.

It's just harder and harder to manage the situation.

So for myself I decided to use 32-bit processing to rid of at least some trimmings.

I'm not forcing others to do the same. I'm not telling that this is the only 'right' way.

I'm just pointing on the possible issue that could be partially solved by switching to 32-bit processing.

Last changed by fifonik on 3/1/2018, 6:14 PM, changed a total of 1 times.

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

Musicvid wrote on 1/31/2018, 6:31 AM

(And just to avoid confusing others: if the output is 8 bit or any other integer processing type, this recover of clipping only works inside this very float point project before rendering.)

Thank you finally for the reality check, @Marco.

That's a pretty big if, since 8 bit is the only deliverable format to the overwhelming majority of consumers. To me, the outlying bits from grading 8 bit source in a bigger space are best described as slop. Analagous to adding a high-pass filter after the leveling step. Effect.on the histo is the same.

It is actually encouraging to see new users making independent inquiries, even if down these same well-traveled roads that were cleared over a decade ago.

It is the indifference arising from uncritical thinking and absence of any testing protocols or opportunity for independent verification, that imprison these theories in murk and speculation, since the conduit is lacking to reveal them in the light of day.

fifonic could do his fellow third-generation video hobbyists a big service by backing his preferred methods, in addition to his troubleshooting observations (nice job!) with source and render visuals, instead of revisiting common thought processes that are "almost" right. Just saying.

But then, we are playing to a different house than previously, and there's.nothing like some good old street-level hype and superstition to sell.your product in the 21st century.

The most shameful cause of consumer disinformation in this century is that critical reasoning skills and scientific methodology are not taught in the schools past ninth grade (if that), the result being that executive function and metacognitive skills in so many individuals never develop past that point. Witness the shocking tendency of intelligent 30-somethings to live with their parents, pursue gaming instead of working, and who have become emotionally stunted by the excesses of our pro-entitlement, anti-survival culture. Hatchery raised, color added.

https://www.cnn.com/2018/05/22/us/judge-rules-son-must-move-out-new-york-trnd/index.html

fifonik wrote on 2/21/2018, 3:38 AM

This is sad that the levels issue was not fixed in VP15 build 311 :(

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

Nick Hope wrote on 5/25/2018, 5:37 AM

Although only XDCAM-EX is mentioned in the release notes for VEGAS Pro 15 Update 5 (build 361), it also seems to fix this issue for Sony AVC.

Can others please test and confirm?

fifonik wrote on 5/25/2018, 6:33 AM

Looks like levels issue for 32-bit pixel format projects rendered using Sony AVC encoder is fixed (tested with my test project).

Thanks.

Camcorder: Panasonic X920

Desktop: MB: MSI B350M PRO-VDH, CPU: AMD Ryzen 1600, RAM: G'Skill 16 GB DDR4 2400, Graphics card: MSI RX470 4GB, SSD: Samsung 850 EVO SATA 250MB, HDDs: Seagate & Toshiba 2TB, OS: Windows 10 64-bit 1809

NLE: Vegas Pro 11, 12, 13, 15

Musicvid wrote on 6/7/2018, 9:01 PM

For the first instance of "Levels" filter in the chain set "Input end" to 0.5 (some colours are moving outside of 8-bits colours range)

- For the second instance of "Levels" filter in the chain set "Output end" to 0.5 (so you simply reverting everything back)

 

My big deal about the scientific method is excluding the Pygmalion Effect completely (5 up), not in designing tests that appear to support my conjectures.

That all said, your test ignores the collateral impact of Vegas' dirty pattern dither, because you did not follow through and render an 8 bit lossless file from your float project. I did that too, and found it completely negated any theoretical effects of doing what you hope to accomplish. That's the conservative version.

IF I had 10 bit source in a float project with grading, I would render a 10 bit lossless intermediate and dither to 8 bit in x264/265. Using Vegas to render a downsampled file would be a course of last resort in my workflow. Again, the statement from Magix is hypothetically correct, and does not necessarily foretell real-world outcomes. You can't make a silk purse from a pig's ear. Been there.

But you've got a great mind and that's why I bother to point out possible pitfalls in methodology. By all means, keep inquiring, you've already touched on some areas I haven't revisited in some time. Unfortunately, forum software doesn't allow critical image inspection but I'll upload them anyway. Keep up the good work; a couple of other old-timers seem impressed, too. 😉

                                                                                                     

Marco. wrote on 6/8/2018, 4:22 AM

Actually being able to completely restore data which is beyond the 0 - 1 luma range is the main reason I use float-point projects for complex compositing. And this is impossible to do within integer 8 point projects. But there seems to be an issue within VP15 which I need to further investigate before I might show an example which easily shows the difference between integer 8 bit and float-point in regard of preserving data beyond 0 - 1.