Lossless output smaller than original

[jriker1]

Subject kind of says it however I have a 45 minute clip that is 1.8GB and has an average bitrate of 5,130 Kbps.

I run it thru the following script:

import ("D:\Program Files (x86)\AviSynth 2.5\QTGMC-3.32.avsi")
DirectShowSource("D:\Conversion\2 - Working\Rodgers\title00.mkv")
AssumeTFF()
QTGMC(preset="Slow")

I run it thru VirtualDub with settings:

Video > Fast Recompress
Audio > Direct Stream Copy
Video > Compression > Lagarith > Mode YUY2


Resulting file is 559 MB and it says the overall bitrate is only 1,559 Kbps.

If I look at the file in MediaInfo where the above info came from says Compression Mode: Lossless.

Any idea what's going on here? Note original source comes off a DVD.

Thanks.

JR

EDIT: I just saw a potential problem. Entire clip is black. When I scroll thru the source file in VirtualDub it's there and shows everything so not sure why the output is black. Took about 3 hours to render and guessing most of the file size is the audio output.

[StainlessS]

Is that your usual habit, ie does it usually work correctly,

Video > Fast Recompress
Video > Compression > Lagarith > Mode YUY2


Presumably shows YV12 in VDub File Information window.

Suggest try something other than Lagarith (eg HuffYUV or UT_Video[better than Lagarith]).
Also might want to turn on Menu/View/Show Decompressed Output/ to see if shows as black (which it most likely will).

Very mysterious.

EDIT: Might also want to take a peek at Menu/Video/Video color Depth/ just to see that its not set to something stupid.
(dont know what it is usually set to, guessing "Same as decompression format").

EDIT: might also want to try alternative VDub, eg VDubMod if you have it, just a few seconds.

[jriker1]

Decompressor line shows video is YUY2

JR

[creaothceann]

import ("D:\Program Files (x86)\AviSynth 2.5\QTGMC-3.32.avsi")
why...

[colours]

Note original source comes off a DVD.

Do not use DirectShowSource. Try DGIndex instead, and maybe that'll help with your issues.

Other than that, I second StainlessS' suggestions.

[jriker1]

Thanks for your replies. Couple things:

HuffYUV is out as I am on Win 7 64-bit and can't get it working beyond the encoding. No decoding so can't open it up after it was created. Sure Lagarith is good. Lossless is lossless no unless it's a final file? I also have MagicYUV but can use UT_Video if there is a good reason to and will work universally in my system.

My files are MKV so I can pull out the individual movies on the DVD and not deal with one big file. I will however use ffmpeg to copy the mkv content to a vob and go from there with you suggestion StainlessS. I do know the footage is telecine and when I use

tfm(mode=5,pp=0,slow=1)
tdecimate(cycle=5)

there are still some interlace artifacts after using it so not sure if in d2v it will work better. Thinking:

d2v="file.d2v"
MPEG2Source(d2v=d2v,cpu=0,idct=5)
TFM(d2v=d2v, pp=0)

Above from cihub I think so not sure what is necessary or not.

I think Handbrake can get rid of the interlacing completely from testing but not sure what detelecine tool it's using so don't like not knowing nor know if there are better tools.

creaothceann, I'm using that because I was deinterlacing. No talk about why are you doing this. I'm not using it now as I am of the belief my content is telecined not pure interlaced.

Thanks for the help. Stay tuned tomorrow for me to test it.

JR

[bxyhxyh]

Suggest try something other than Lagarith (eg HuffYUV or UT_Video[better than Lagarith]).


Wait, so it means that Lagarith is not actually lossless or?
I always use lagarith when it comes to YV12 videos on VD. Should i change it?

[foxyshadis]

No, Lagarith is just old and inactive, not quite abandoned. It still mostly works, and it's still usually smaller than anything but x264 and FFV1 (but faster, obviously). MagicYUV and utvideo are much faster, smaller than huffyuv but larger than Lagarith. They're also better at handling more pixel formats than Lagarith.

Huffyuv should only be used for compatibility, it doesn't compete on any other measure with the newer formats. x264 lossless can usually take advantage of highly optimized hardware and software decoders, and it's usually the smallest, but it's also usually the slowest of all to create.

What you use just depends on what tradeoffs are best for you.


As for the broken encode this thread is about, I'm guessing that forcing YUY2 for a YV12 video might be breaking it somehow, and it's certainly unnecessary when it gains nothing over the input, combed or not. (Lagarith supports YV16, if you must upsample, use that!)

[jriker1]

Thank you all. I will start using MagicYUV, already installed, and see how that goes. Starting to think my problem was a fluke. Probably chalk it up to watching the first minute or two of encoding and make sure VDub is showing the estimated file size is going to be in gigs and not megs. Now hopefully I will get some takers on my telecine thread as the materials I originally wrote about here took a twist and holding me up.

Thanks again.

JR

[TCmullet]

I have had and am having problems with Lagarith too. In most contexts using the default of "RGB (default)" works. But I tried YV12 again lately. Caused Vdub to blow up in middle of a run. Then discovered when I convered a Lag. Yv12 file to Lag. RGB, that YV12 takes less space!! (Caused me a space problem as I hadn't budgeted for a bigger RGB file. Also did a test, RGB-YV12, then back, and the final did not equal the original in size.

Even Lag RGB cannot be used for what I think is characterized by an app scrubbing back and forth wildly. Forced me in one situation to convert from Lag to Hufyuv JUST so I could run the video through a certain app that barfed at Lag. (It didn't barf at the codec, but failed to process.)

I realize this is muddy.

I actually tried a few days ago to email the author who says he welcomes bug reports. Haven't heard back yet, but he could be out of town or something.

[jriker1]

Yeah, I did have a couple cases when I selected Lag the screen went black on the output preview. Staying away from HuffYUV as I think it's really old and compatibility is crap especially with newer OS and 64-bit systems. Just doesn't work. From what I hear it only encodes, doesn't decode which matches my situation. Still using Lag at the moment as I'm a stickler of sticking with something when you start with it and it was working, but think I need to bite the bullet and switch. That's assuming when I encode in MagicYUV in VDub that it opens in Premiere. Haven't tested yet. Still putzing around with Lag but unlike you TCmullet using YUV for my DVD content.

JR

[colours]

Then discovered when I convered a Lag. Yv12 file to Lag. RGB, that YV12 takes less space!!

RGB24 has three 8-bit channels with no subsampling, so each pixel is 24 bits uncompressed. YV12 has three 8-bit channels, two of which are subsampled at one-quarter rate, so each pixel is 12 bits uncompressed.

It shouldn't be surprising that lossless compression of an input with less information would lead to a smaller output. Furthermore, even disregarding the chroma subsampling, converting between YCbCr and RGB is lossy, so I'm not really sure what exactly you're trying to accomplish.

[TCmullet]

Yeah, I did have a couple cases when I selected Lag the screen went black on the output preview. Staying away from HuffYUV as I think it's really old and compatibility is crap especially with newer OS and 64-bit systems. Just doesn't work. From what I hear it only encodes, doesn't decode which matches my situation. Still using Lag at the moment as I'm a stickler of sticking with something when you start with it and it was working, but think I need to bite the bullet and switch. That's assuming when I encode in MagicYUV in VDub that it opens in Premiere. Haven't tested yet. Still putzing around with Lag but unlike you TCmullet using YUV for my DVD content.

JR
I'm using all 32-bit video software to avoid the 64-bit incompatibilities that hit at times. (Others have concurred that this is wise.) Given that, then I must point out that Hufyuv works in each case that Lagarith failed me. (But Huf gives much bigger files, drat.) There's one situation where I create a file in lag, then convert it to huf. Sometimes the problem was allowing null frame compression, sometimes not. Will consider those newer lossless codecs mentioned.

[TCmullet]

RGB24 has three 8-bit channels with no subsampling, so each pixel is 24 bits uncompressed. YV12 has three 8-bit channels, two of which are subsampled at one-quarter rate, so each pixel is 12 bits uncompressed.

It shouldn't be surprising that lossless compression of an input with less information would lead to a smaller output. Furthermore, even disregarding the chroma subsampling, converting between YCbCr and RGB is lossy, so I'm not really sure what exactly you're trying to accomplish.
Whaddaya mean "less information"? Lagarith is lossless no matter which format (color space), so if it's out there in one lossless format and I convert to another lossless format, then what can be lost?? Are you saying that YV12 is lossy to begin with (when RGB was converted to YV12)?

Are you saying that the AviSynth command "ConvertToYV12()" is inherently lossy??????

[colours]

Are you saying that the AviSynth command "ConvertToYV12()" is inherently lossy??????

In short, if your source isn't already Y8 or YV12, yes.

[creaothceann]

if it's out there in one lossless format and I convert to another lossless format, then what can be lost?

YV12 has "chroma subsampling", i.e. the resolution of the color plane is reduced. (http://www.animemusicvideos.org/guides/avtech/colorspace.html) So converting from RGB to YV12 is lossy.