Lagarith codec producing larger filesize with smaller resolution?

[BozQ]

I have been using Lagarith to compress video losslessly.
And I've noticed that when I resize the video from 640x480 to 320x240, the filesize actually increases.
Is this actually a common behaviour among lossless video codecs?

Please note, I only wish to ask about the filesize issue.
I am perfectly fine with the smaller resolution as I need to use it for something else.
If you must know, I am doing the compressing with VirtualDubMod.

Thanks for any assist.

[poisondeathray]

normal behaviour if your original video was compressed (e.g. xvid)

otherwise can use a lossy codec like xvid/divx etc...

[BozQ]

The original video is lossless 640x480

[poisondeathray]

What kind of lossless ? use mediainfo if you don't know

Did you account for audio?

[BozQ]

Lagarith 640x480 to Lagarith 320x240

[poisondeathray]

Lagarith YV12 or Lagarith RGB ?

Is there a colorspace conversion? ie. Did you use fast recompress mode in vdub / vdubmod ?

[BozQ]

Both definitely RGB.
And Full Processing Mode. Lagarith won't work in Fast Recompress mode anyway.

[poisondeathray]

Are you sure that the source is RGB? Open up in avisynth script and use info()

If you resize in the script, you eliminate the need to use vdub resizing and can use fast recompress mode
(there is quality loss if you go YV12=>RGB=>YV12 when using full processing mode in vdub from the colorspace conversion)

Lagarith will work in fast recompress, if you don't do any filtering (not full processing mode)

And as you know , RGB will consume way more bitrate than YV12 ....

How much bigger filesize or bitrate is your 320x240 compared to original ?

What other filtering other than internal resize in vdubmod are you using?

[BozQ]

For the same 4 minute clip, the 640x480 Lagarith RGB file is 900MB.
But the 320x240 file is 1.82GB.

But I think I'm on to something here.
It looks the resize filter mode is the reason it's affecting the file size. I tend to use Lanczos3 and I've tried compressing again with Nearest Neighbour filter mode and the filesize is smaller now. Around 680MB.

Does different resize filter modes affect lossless encoding in such manner?

[poisondeathray]

Yes definitely

eg. Lanczos is sharper , and can cause artifacts & ringing , eg. bilinear is smoother

Sharper detail and artifacts require more bitrate to encode than blurrier content. But the magnitude of this effect pales in comparison to colorspace RGB 4:4:4 vs. YV12 4:2:0

So from the filesizes you've given, I strongly suspect your original clip was YV12

Try this in fast recompress mode

AVISource("input.avi")
LanczosResize(320,240)

[BozQ]

I see. Thank you very much poisondeathray. You've been very helpful.
I'll give it a whirl again!

[Gavino]

Sharper detail and artifacts require more bitrate to encode than blurrier content. But the magnitude of this effect pales in comparison to colorspace RGB 4:4:4 vs. YV12 4:2:0
So from the filesizes you've given, I strongly suspect your original clip was YV12

Going from YV12 4:2:0 to RGB 4:4:4 would double the bits per pixel, but the downsizing reduces the number of pixels to 1/4. So wouldn't you still expect the filesize to be halved rather than doubled (0.9 to 1.8Gb)?

[poisondeathray]

Sharper detail and artifacts require more bitrate to encode than blurrier content. But the magnitude of this effect pales in comparison to colorspace RGB 4:4:4 vs. YV12 4:2:0
So from the filesizes you've given, I strongly suspect your original clip was YV12

Going from YV12 4:2:0 to RGB 4:4:4 would double the bits per pixel, but the downsizing reduces the number of pixels to 1/4. So wouldn't you still expect the filesize to be halved rather than doubled (0.9 to 1.8Gb)?

Yes, your math is correct. There must be something else going on in addition to the resize algorithm (I don't think that alone can account for the difference)

[jagabo]

I wouldn't use Nearest Neighbor resizing for anything but specific purposes. It will deliver terrible moire artifacts and jaggy edges. Use Precise Bilinear instead if you want a non-sharpening, non noise enhancing resizing filter.

[BozQ]

Hi guys.

First of all, let me thank all of you for chipping in to help. I really appreciate it.
Let me explain my video source. And I apologise if this will infringe any copyright rules of this forum.

My video source actually comes from a SEGA Genesis emulator called KEGA Fusion.
http://www.eidolons-inn.net/tiki-index.php?page=Kega

It is able to capture full motion video with its own custom codec. (KEGA Video Codec or KGV1)
It's not customizable and it always "captures" in 640x480 at 60 progressive (not interlaced) frames per second. This codec is able to compress very well, losslessly at very small filesize, but the codec is not suitable for any form of editing.

So my first step is to compress it with Lagarith at 640x480.
I've did further expriment since my last post here, and I have noticed that compressing it in LAGS RGB gave me the smallest file size. Since the game's native resolution isn't 480 anyway, I've reduced it to 240, it's close-to-native resolution. (It's actually 320x224, but it is letterboxed to 320x240 compensate for the 4:3 TV format)

When I used VDubMod, I originally used Lanczos3 to resize it to 240, but after playing it it further, that seemed to be the main reason why the filesize actually increased. I've yet to test every filter mode, but so far, resizing to 320x240, with Nearest Neighbour Filter Mode and LAGS RGB seems to be the "sweet spot" for my editing usage.

So I hope this clears up a lot of any misunderstanding.

Once again, thanks for all your response. I did learn a few important lesson about video encoding.

[jagabo]

Some VirtualDub resizing samples:

https://forum.videohelp.com/topic372866.html#2003886

Those were enlarging, not shrinking but the idea is the same.

[BozQ]

That's a great guide jagabo!
But well, bandwidth is probably a bigger issue than image quality here. Since I'm actually going to share the video with friends, and I doubt they would notice the quality differences.

Also, I have done used the preview mode in VDubMod and I really noticed very minor if not zero differences using nearest neighbour. And it seems to offer me the lowest filesize when compressed in LAGS. So I guess I shall stick to this workflow for now.

Thanks anyway!

[jagabo]

Could you use the Video -> Snapshot Source Frame function in VirtualDubMod to export a few sample frames from you 640x480 source as PNG? I'd like to take a look at them. I'm curious about why Lagarith would generate much bigger files from the 640x480 source than the 320x240 reduced version.

[BozQ]

Could you use the Video -> Snapshot Source Frame function in VirtualDubMod to export a few sample frames from you 640x480 source as PNG? I'd like to take a look at them. I'm curious about why Lagarith would generate much bigger files from the 640x480 source than the 320x240 reduced version.

Here ya go. Three snapshots.
This is the original KGV1 video shots. Before any transcoding to other codecs is done.
Do you need consecutive frames? Or anything else? Let me know.

sk.zip

[jagabo]

Thanks BozQ. I see what's going on. Your 640x480 source files are nearest neighbor 2x enlargements of the 320x240 rendered games. This is one of those cases where a nearest neighbor resizing back down to half size works best!

[BozQ]

Oh wow! How do you even tell it's a nearest neighbour enlargement?

Hmm. Let's see, maybe I should try learning to convert this to an 60i NTSC DVD.

[jagabo]

It was pretty obvious just looking at them. But to be sure I opened an image in an editor and zoomed in. It was obvious that all four pixels in each 2x2 block were identical.

Say you have a 2x2 array of pixels:

10 20
30 40

a 2x (each axis) nearest neighbor enlargment would result in a 4x4 array:

10 10 20 20
10 10 20 20
30 30 40 40
30 30 40 40

ie, each pixel is simply doubled in width then doubled in height.

A nearest neighbor 1/2 (both axis) downsize would simply take every other pixel horizontally and every other line vertically. Starting with the above 4x4 array we would restore the exact same image that we started with.

[BozQ]

I see. That's great piece of information there too!