Vegas detects wrong colour depth for certain codecs

RogerKroksleiven wrote on 9/3/2016, 9:53 AM

I have experienced that Sony Vegas Pro 10 detects wrong colour depths for avi clips using the lagarith lossless codec, x264vfw codec and xvid codec. For instance, when importing a 1280x720 24 bit RGB lagarith lossless clip into Vegas, the media tab under file properties shows that the clip is 32 bit RGB:

Can anyone confirm/disconfirm that this is or is not the case for other versions of Vegas?

The reason I am pointing this out, is that this issue seems to prevent smart rendering of these types of clips.

The odd thing about this is that if you render the clip out as an avi file with the lagarith lossless codec and import the rendered clip back into Vegas, it detects the correct colour depth. It seems as if Vegas only detects the correct colour depth for the lagarith lossless codec if the clip is produced by Vegas itself.

Comments

Musicvid wrote on 9/3/2016, 1:58 PM

Lagarith  is buggy in the way it reports a lot of things.

That said, all that 32 bit indicates is the presence of an alpha channel -- completely irrelevant unless there is alpha content. Ignore it.

NickHope wrote on 9/3/2016, 11:24 PM
The reason I am pointing this out, is that this issue seems to prevent smart rendering of these types of clips.
 

If Vegas can smart render Lagarith, x264vfw and Xvid, it's news to me. This is the list of smart render formats from the VP13 help file:

  • DV AVI

  • DV MXF

  • IMX MXF (IMX 24p MXF is not supported for no-recompress rendering)

  • XAVC Intra MXF

  • HD MXF

  • MPEG-2 (for files such as those from HDV and DVD camcorders)

  • Panasonic P2

  • XDCAM EX supports smart rendering across the following formats:

    • SP 18.3 Mbps CBR 1280x720p to/from XDCAM EX and HDV HD-1

    • SP 25 Mbps CBR 1440x1080i to/from XDCAM EX, XDCAM HD, and HDV HD-2

    • HQ 35 Mbps VBR 1440x1080 to/from XDCAM EX and XDCAM HD

    • HQ 35 Mbps VBR 1280x720p to/from XDCAM EX

    • HQ 35 Mbps VBR 1920x1080 to/from XDCAM EX

However ChrisDolan (SCS) said here that there a few others (e.g. several AVI subtypes), so maybe it is possible. Anyone know?

RogerKroksleiven wrote on 9/4/2016, 5:25 AM

Musicvid
It could be that Lagarith is buggy, but it does not explain why it works all fine if the Lagarith clip is produced by Vegas, right?

Nick Hope
I thought so too, that Lagarith, x264vfw and Xvid were not able to smart render. However, take a look at this clip:

Maybe Vegas just thinks it can smart render these clips, but are still not actually able to do it? However, over on the Creative Cow forum, Wayne Waag mentioned that you can smart render both UT Video and Magic YUV codec in AVI.

It would be very interesting to see a list of all the subtypes of AVI that can smart render, as mentioned by ChrisDolan (SCS).

Musicvid wrote on 9/4/2016, 6:29 AM

If you are interested in finding out why there is a difference, post MediaInfo (that is a specific utility) details for the file and the one rendered in Vegas, along with uploads of pristine examples of each to a legit fileshare (NOT Youtube).

Besides Vegas, even the open-source libraries (ffmpeg, libav) have had lots of trouble with Lagarith and its flags in the past.

How another application writes the flags is not a huge deal to Vegas -- it gets it right 99% of the time, but GIGO still rules in some instances. In the meantime, you might try playing with UT and Magic YUV, as many here are using. That said, the visually lossless intermediates these days are so good that I only use the mathematically lossless codecs for testing, as we started doing here:

https://www.vegascreativesoftware.info/us/forum/intermediates-part-i-seven-lossless-codecs--84932/?page=2

In any event, if you will be using any of the AVI vfw codecs, continue doing so in RGB colorspace. YUV encoding is lossy, and in that category you have many better compression options. All of the codecs I tested in the link above are in RGB.

NickHope wrote on 9/4/2016, 7:18 AM

@RogerKroksleiven Great illustration! I've learnt something.

I don't have Lagarith installed but for what it's worth I was just able to smart render a MagicYUV file (originally rendered in VirtualDub) in V10, V12 and V13. It gets reported by each version as 1920x1080x24. I used MagicYUV v1.2rev0. The 32-bit codec got used in V10 and the 64-bit codec in V12 and V13.

More about MagicYUV in this thread. Biggest benefit for me is the decode speed (= smoother playback). It's donation-ware but worth it for me. I have had occasional glitches/crashes with it in Vegas in the past, but then I think I also did with other 3rd party AVI codecs.

RogerKroksleiven wrote on 9/4/2016, 7:59 AM

I guess my problem with Vegas could be either how Lagarith works or how it is treated by my recording software (DxTory). Here is the MediaInfo for one clip produced by DxTory and one produced by Vegas:

DxTory clip:

General
Complete name                            : lag24.avi
Format                                   : AVI
Format/Info                              : Audio Video Interleave
File size                                : 76.6 MiB
Duration                                 : 15 s 4 ms
Overall bit rate                         : 42.9 Mb/s
Original source form/Distributed by      : Video:Lagarith Lossless Codec Audio:Speakers (Realtek High Definition Audio)
Writing application                      : DxtoryCore ver2.0.0.122

Video
ID                                       : 0
Format                                   : Lagarith
Codec ID                                 : LAGS
Duration                                 : 14 s 867 ms
Bit rate                                 : 41.7 Mb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 30.000 FPS
Color space                              : RGB
Bit depth                                : 8 bits
Bits/(Pixel*Frame)                       : 1.508
Stream size                              : 73.9 MiB (96%)

Audio
ID                                       : 1
Format                                   : PCM
Format settings, Endianness              : Little
Format settings, Sign                    : Signed
Codec ID                                 : 1
Duration                                 : 15 s 4 ms
Bit rate mode                            : Constant
Bit rate                                 : 1 536 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 48.0 kHz
Bit depth                                : 16 bits
Stream size                              : 2.75 MiB (4%)
Alignment                                : Aligned on interleaves
Interleave, duration                     : 929  ms (27.88 video frames)

Vegas clip:

General
Complete name                            : lag24 vegas render.avi
Format                                   : AVI
Format/Info                              : Audio Video Interleave
File size                                : 164 MiB
Duration                                 : 14 s 867 ms
Overall bit rate                         : 92.4 Mb/s
TCOD                                     : 0
TCDO                                     : 148666666

Video
ID                                       : 0
Format                                   : Lagarith
Codec ID                                 : LAGS
Duration                                 : 14 s 867 ms
Bit rate                                 : 90.6 Mb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 30.000 FPS
Color space                              : RGB
Bit depth                                : 8 bits
Bits/(Pixel*Frame)                       : 3.277
Stream size                              : 161 MiB (98%)

Audio
ID                                       : 1
Format                                   : PCM
Format settings, Endianness              : Little
Format settings, Sign                    : Signed
Codec ID                                 : 1
Duration                                 : 14 s 867 ms
Bit rate mode                            : Constant
Bit rate                                 : 1 536 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 48.0 kHz
Bit depth                                : 16 bits
Stream size                              : 2.72 MiB (2%)
Alignment                                : Aligned on interleaves
Interleave, duration                     : 33  ms (1.00 video frame)
Interleave, preload duration             : 33  ms

My question now is: Why is the size of the Vegas produced clip so much larger, when in reality it is almost the same as the original (the duration is slightly different)?

It seems like it is the audio that is causing the difference in duration, but that should not be able to make a difference of ~ 90 MiB, right?

Former user wrote on 9/4/2016, 8:06 AM

The bitrate on your vegas clip is almost twice the rate of the original. That is why it is a larger file.

RogerKroksleiven wrote on 9/4/2016, 8:25 AM

You are right. Too bad I can't control the bitrate in Vegas for rendering to avi and lagarith

NickHope wrote on 9/4/2016, 8:59 AM

Maybe DxTory uses an older, less efficient version of the codec (I'm assuming it installs Lagarith rather than you). Maybe you could hack the DxTory installation by manually dropping in the same version of the Lagarith .dll file, if that is shown.

Musicvid wrote on 9/4/2016, 2:10 PM

Writing application                      : DxtoryCore ver2.0.0.122

Oh . . . DXTORY. Wish you had said that earlier. Its own website will help you with that better than any of the editing or encoding communities. People often scratch their heads over it at the Handbrake forum, too.

The writing engine is so far off the mark for most decoders you'll likely end up home-rolling your own solution, but keep digging and post back with your conslusions. You seem to have a clue.

PeterDuke wrote on 9/6/2016, 2:05 AM

If Vegas can smart render Lagarith, x264vfw and Xvid, it's news to me. This is the list of smart render formats from the VP13 help file:

.....

However ChrisDolan (SCS) said here that there a few others (e.g. several AVI subtypes), so maybe it is possible. Anyone know?

I rendered an AVCHD clip without audio to Lagarith in Vegas 13 and it took 55 secs.

I then rendered that clip to Lagarith. Vegas said "no recompression required" and it took 16 seconds.

The command FC /B reported that the two rendered files were identical.

I then added an overlay at the start of the timeline and re-rendered. "No recompression" appeared after the overlay portion had been processed, and the rendering took 21 secs.

So Vegas can smart render Lagarith.

RogerKroksleiven wrote on 9/6/2016, 1:20 PM

I think I might have found something useful as to why Vegas detects wrong colour depth, in particular for the x264vfw codec. Through testing with MediaInfo, I can see that Vegas will fail to detect the correct colour depth if the video clip lacks proper MediaInfo for colour space and chroma subsampling. Unfortunately, this does not seem to be the case with Lagarith (maybe this has something to do with RGB and YUV?). The clips I have tested that fail are all produced by DxTory or Bandicam. These programs are apparently unable to properly write media info for colour space and chroma subsampling into the video clip. Still, it could also be the codec's fault. I know too little about metadata, media tags and media info (all the same?), but I guess there are several ways to store and read it, which might explain why VLC Media Player is able to detect the colour depth correctly while Vegas is failing.
Here is a comparison of correct and incorrect MediaInfo:

I haven't had the time to test many different codecs, so please fill me in with media info from your favourite codecs.

Please let me know if there is a simple way to append media info to video clips.

Maybe DxTory uses an older, less efficient version of the codec (I'm assuming it installs Lagarith rather than you)

No, DxTory does not install Lagarith, I did it myself. I can also see that it uses the same version as I installed.

I then rendered that clip to Lagarith. Vegas said "no recompression required" and it took 16 seconds.
...
So Vegas can smart render Lagarith.

I believe you, it can smart render Lagarith. However, what puzzled me is the time it took to smart render. 16 seconds to not really do anything with it? I have had similar results myself though. I guess Vegas is using a slow seeking method.

Musicvid wrote on 9/6/2016, 2:06 PM

24 vs. 32 bit has absolutely nothing to do with color or bit depth. Both are 8 BITS PER CHANNEL.

RGB = 3 channels x 8 bits = 24 bits 

RGBA = 4 channels x 8 bits = 32 bits.

That's all it is, and this has nothing to do with 16- or 32- bitS PER CHANNEL color sampling, which yours are not.. Your smart-rendering observations notwithstanding, the number of channels reported (3 vs. 4) seems kind of trivial, unless there is actual alpha content, which again your screen captures are not..

In the same light, the ID TAGS that are reported as a courtesy and picked up by MediaInfo are entirely unrelated to the HEADER FLAGS that are seen by the decoder. These are two separate items.

That's why I asked for pristine samples, because it might be interesting to see what's in the files.

Appearances are often deceiving and people arrive at the wrong conclusions; even I and the pros on this forum get fooled...

Unless you are quite handy with a hex editor and want to conform the headers yourself, your observations need to be taken up with the people who wrote the encoding engine, not the downstream decoders.

Best of luck, and let us know where you get with DxTory, who has given many people the impression by now that they may not know what they're doing.

 

RogerKroksleiven wrote on 9/8/2016, 7:05 AM

When I installed the Lagarith lossless codec, it installed both a 32-bit and 64-bit version. I noticed now that DxTory uses the 32-bit codec while Vegas uses the 64-bit codec. Is this a problem? Will they cooperate?

Here is some (quite laggy) DxTory Lagarith example footage (RGBA, RGB, YUY2 and YV12):
http://www.mediafire.com/download/6qqb16hiecxyxat/Lagarith_Footage.zip

DxTory, the writing application, seems to be the problem. I tried to import a lagarith clip recorded with CamStudio into Vegas, and the colour depth was identified correctly.