VideoHelp Forum
+ Reply to Thread
Results 1 to 23 of 23
Thread
  1. Member
    Join Date: Mar 2009
    Location: Singapore
    Search Comp PM
    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.
    Quote Quote  
  2. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    normal behaviour if your original video was compressed (e.g. xvid)

    otherwise can use a lossy codec like xvid/divx etc...
    Quote Quote  
  3. Member
    Join Date: Mar 2009
    Location: Singapore
    Search Comp PM
    The original video is lossless 640x480
    Quote Quote  
  4. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    What kind of lossless ? use mediainfo if you don't know

    Did you account for audio?
    Quote Quote  
  5. Member
    Join Date: Mar 2009
    Location: Singapore
    Search Comp PM
    Lagarith 640x480 to Lagarith 320x240
    Quote Quote  
  6. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    Lagarith YV12 or Lagarith RGB ?

    Is there a colorspace conversion? ie. Did you use fast recompress mode in vdub / vdubmod ?
    Quote Quote  
  7. Member
    Join Date: Mar 2009
    Location: Singapore
    Search Comp PM
    Both definitely RGB.
    And Full Processing Mode. Lagarith won't work in Fast Recompress mode anyway.
    Quote Quote  
  8. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    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?
    Quote Quote  
  9. Member
    Join Date: Mar 2009
    Location: Singapore
    Search Comp PM
    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?
    Quote Quote  
  10. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    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)
    Quote Quote  
  11. Member
    Join Date: Mar 2009
    Location: Singapore
    Search Comp PM
    I see. Thank you very much poisondeathray. You've been very helpful.
    I'll give it a whirl again!
    Quote Quote  
  12. Member
    Join Date: Jul 2009
    Location: Spain
    Search Comp PM
    Originally Posted by 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)?
    Quote Quote  
  13. Member
    Join Date: Sep 2007
    Location: Canada
    Search Comp PM
    Originally Posted by Gavino
    Originally Posted by 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)
    Quote Quote  
  14. 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.
    Quote Quote  
  15. Member
    Join Date: Mar 2009
    Location: Singapore
    Search Comp PM
    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.
    Quote Quote  
  16. Some VirtualDub resizing samples:

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

    Those were enlarging, not shrinking but the idea is the same.
    Quote Quote  
  17. Member
    Join Date: Mar 2009
    Location: Singapore
    Search Comp PM
    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!
    Quote Quote  
  18. 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.
    Quote Quote  
  19. Member
    Join Date: Mar 2009
    Location: Singapore
    Search Comp PM
    Originally Posted by 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.
    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
    Quote Quote  
  20. 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!
    Quote Quote  
  21. Member
    Join Date: Mar 2009
    Location: Singapore
    Search Comp PM
    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.
    Quote Quote  
  22. 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.
    Quote Quote  
  23. Member
    Join Date: Mar 2009
    Location: Singapore
    Search Comp PM
    I see. That's great piece of information there too!
    Quote Quote  



Similar Threads