help: major Vegas 10 compression bug

logiquem wrote on 6/8/2011, 11:41 AM
Hi all,

I use Vegas since about 10 years and never saw this bug yet.

When you render in DV or Mpeg (interlaced or not), you get very nasty compression artefacts around some regions. Uncompressed avi do not show any problems.

This bug is specific to Vegas 10. You can easily see it in the screen capture here:
http://dl.dropbox.com/u/4344076/test/Vegas10dbug.png

Check "aliqua" "ulando" and "commodo" words in the image file...

Rendering (best setting and no resize) has been tested with external images, various fonts and also internal vegas editor (the sample file). The problem is the same with any source and is even worse with colour images (gost coloured artefacts, doubled lines and so on...).

Any idea?

Comments

amendegw wrote on 6/8/2011, 12:42 PM
Boy, that is strange. Can you drop you're veg in your public dropbox & see if others can duplicate?

Also, can you give us a screenprint of the render settings that produced this glitch?

Finally, what Media Player are you observing this in?

...Jerry

System Model: Alienware Area-51m R2
System: Windows 11 Home
Processor: Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz, 3792 Mhz, 8 Core(s), 16 Logical Processor(s)
Installed Memory: 64.0 GB
Display Adapter: NVIDIA GeForce RTX 2070 Super (8GB), Nvidia Studio Driver 527.56 Dec 2022)
Overclock Off

Display: 1920x1080 144 hertz
Storage (12TB Total):
OS Drive: PM981a NVMe SAMSUNG 2048GB
Data Drive1: Samsung SSD 970 EVO Plus 2TB
Data Drive2: Samsung SSD 870 QVO 8TB

USB: Thunderbolt 3 (USB Type-C) port Supports USB 3.2 Gen 2, DisplayPort 1.2, Thunderbolt 3

Cameras:
Canon R5
Canon R3
Sony A9

logiquem wrote on 6/8/2011, 1:45 PM

>Boy, that is strange. Can you drop you're veg in your public dropbox & see if others can duplicate?

I will do it tomorrow

>Also, can you give us a screenprint of the render settings that produced this glitch?

Render setting at best. Only Vegas text, standard NTSC project

>Finally, what Media Player are you observing this in?

Actually, what you saw is a Vegas screen cap.
John_Cline wrote on 6/8/2011, 2:07 PM
This is likely an artifact of the 4:1:1 and 4:2:0 color sampling of DV and MPEG2. Neither particularly likes high contrast text using solid color backgrounds. You might try adding a a tiny bit of noise or texture to the background and see if that helps.
rs170a wrote on 6/8/2011, 2:22 PM
Make sure your blacks are no lower than 16-16-16 and your whites are no higher than 235-235-235.

Mike
farss wrote on 6/8/2011, 2:41 PM
That is not good at all. I'd be sending this off to SCS immediately.
The only thing I can think of causing those artifacts is a bug in the code. Definately not anything to do with chroma sampling or levels as the same character produces different artifacts depending on where it is in the frame. A good example is the first "o" and the first "m" in the word "commodo". Subsequent "m" and "o" are perfect.
There's also of course the fact that V9 doesn't produce these artifacts.

The only question I'm unsure of is this happening in the encode or the decode? As V10 is being used for both it could be either. Regardless of what the answer is neither the encode or decode should be doing this.

Bob.
Robert Johnston wrote on 6/8/2011, 10:35 PM
I see problems with 32-bit. Arial, 36, Bold.

EDIT: Disregard. I get the same artifacts in Premiere Elements 9.

Intel Core i7 10700K CPU @ 3.80GHz (to 4.65GHz), NVIDIA GeForce RTX 2060 SUPER 8GBytes. Memory 32 GBytes DDR4. Also Intel UHD Graphics 630. Mainboard: Dell Inc. PCI-Express 3.0 (8.0 GT/s) Comet Lake. Bench CPU Multi Thread: 5500.5 per CPU-Z.

Vegas Pro 21.0 (Build 108) with Mocha Vegas

Windows 11 not pro

logiquem wrote on 6/9/2011, 6:37 AM
Another test here... Check the comparaison between original image png file and DV render in V9 and v10 and Uncompressed render in V10. Everything rendered with the same render and project settings (NTSC interlaced best).

Unacceptable results in V10, as you can see...
farss wrote on 6/9/2011, 6:52 AM
"Another test here...

Not seeing anything down here??

Bob.
amendegw wrote on 6/9/2011, 7:23 AM
I'm going to go out on a limb and make a WAG. Do you have an outline specified on the text? I'm guessing it might have something to do with that.

btw, a link to a .veg would really be nice.

...Jerry

Edit: Bad guess! Obviously, we would not see the glitches in the teacup handles (in the images of the next post) if the problem was in text outlining.

System Model: Alienware Area-51m R2
System: Windows 11 Home
Processor: Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz, 3792 Mhz, 8 Core(s), 16 Logical Processor(s)
Installed Memory: 64.0 GB
Display Adapter: NVIDIA GeForce RTX 2070 Super (8GB), Nvidia Studio Driver 527.56 Dec 2022)
Overclock Off

Display: 1920x1080 144 hertz
Storage (12TB Total):
OS Drive: PM981a NVMe SAMSUNG 2048GB
Data Drive1: Samsung SSD 970 EVO Plus 2TB
Data Drive2: Samsung SSD 870 QVO 8TB

USB: Thunderbolt 3 (USB Type-C) port Supports USB 3.2 Gen 2, DisplayPort 1.2, Thunderbolt 3

Cameras:
Canon R5
Canon R3
Sony A9

farss wrote on 6/9/2011, 7:52 AM
Maybe this will help others see what the problem is:



Now I've had a quicj go at trying to repo the problem in V10 64 and cannot get it to happen. That's not to say it isn't there of course. I have no clue as to where this could be coming from, I'm inclined to suspect a bug in the DCT compression algorithm as boths DV and mpeg use it but that's a really wild guess.

Bob.
farss wrote on 6/9/2011, 8:00 AM
Oh dear, now that is really bad and it looks like something I've seen posted here by others. I think it was the charts in the YouTube tests that were showing that same chroma bleed. At the time I thought it was just due to the chorma subsampling and ignored it. Seems like there really is a problem if it's not happening in V9 and is happening in V10.

No one here can fix this for you, you REALLY need to get SCS to look into it. They should be able to repo this easily enough.

Bob.
Rain Mooder wrote on 6/9/2011, 1:13 PM
Yep, those look like individual macroblocks that have the wrong DCT/frequency
coefficients. There's a bug in the encoder or a bug in the decoder. Might try
the file with a different DV/MPEG-2 decoding method like VLC to see if the
fault is in the decoder, otherwise blame Mainconcept.

It is definitely a codec bug since Vegas proper does not know about
macroblocks and it can't malfunction to make those low frequency DCT
errors.

On the downside, SCS is taking between 14 and 20 days to have problems
looked at by a level 0 tech so the probability of your problem getting fixed
this month is close to zero. None of my bugs in 10d are getting resolved but
after a month at least someone has sent me a "your problem is very important
to us" email.

You might want to start looking for alternate work flows using different codecs. I'd
probably try rendering an AVI using a non-mainconcept codec (Huffy/Lagarith/Cineform) and then load your file into Vegas 9 and render out.
fldave wrote on 6/9/2011, 1:14 PM
Looks like it was converted to jpg internally.

Are the Text events the exact same size? Project properties exactly the same? Best/Full, don't stretch image to fill preview before the capture?

(sorry, still running 8.0c here)
amendegw wrote on 6/9/2011, 2:25 PM
I've been trying to duplicate this in 10.0d, 64bit with limited success (or is that failure?). First render to MainConcept mpg looks perfect. However, with a render to DV I mightsee something (look in the space between the "a" & "b", and what about the "o" in commodo? Edit:Looking closely, there also appears to be some problems with the "i" & "s" in "quis"):


...Jerry

System Model: Alienware Area-51m R2
System: Windows 11 Home
Processor: Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz, 3792 Mhz, 8 Core(s), 16 Logical Processor(s)
Installed Memory: 64.0 GB
Display Adapter: NVIDIA GeForce RTX 2070 Super (8GB), Nvidia Studio Driver 527.56 Dec 2022)
Overclock Off

Display: 1920x1080 144 hertz
Storage (12TB Total):
OS Drive: PM981a NVMe SAMSUNG 2048GB
Data Drive1: Samsung SSD 970 EVO Plus 2TB
Data Drive2: Samsung SSD 870 QVO 8TB

USB: Thunderbolt 3 (USB Type-C) port Supports USB 3.2 Gen 2, DisplayPort 1.2, Thunderbolt 3

Cameras:
Canon R5
Canon R3
Sony A9

logiquem wrote on 6/10/2011, 5:52 AM
Absolutly no stretching and best rendering option in the native image or Veg text format.

This is clearly a codec bug (looks like maroblock misinterpretation or something) I never saw before in any version of Vegas prior to 10.

The compression bug seems to occurs randomly and is related to internal fonts and external images. This is realy major, unacceptable and must be adressed by Sony.