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.
Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or try DVDFab Passkey and copy Blu-ray and DVDs! :)
+ Reply to Thread
Results 1 to 23 of 23
normal behaviour if your original video was compressed (e.g. xvid)
otherwise can use a lossy codec like xvid/divx etc...
The original video is lossless 640x480
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?
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?
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
I see. Thank you very much poisondeathray. You've been very helpful.
I'll give it a whirl again!
Originally Posted by poisondeathray
Originally Posted by Gavino
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.
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.
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.
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 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!
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.
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:
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.
I see. That's great piece of information there too!