Announcement

Collapse
No announcement yet.

DivX problem... kinda

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DivX problem... kinda

    I recorded two episodes of The Simpsons. Both are about the same length, same size, same everything. I used VirtualDub to compress each one using DivX Fast Motion at 800 Kbps and 90 Crispness. The only difference between the two is a blur filter. The one without blur came out 156MB, while the one with blur is 76MB. Should bluring cause this major decrease in size?
    Gigabyte GA-K8N Ultra 9, Opteron 170 Denmark 2x2Ghz, 2 GB Corsair XMS, Gigabyte 6600, Gentoo Linux
    Motion Computing M1400 -- Tablet PC, Ubuntu Linux

    "if I said you had a beautiful body would you take your pants off and dance around a bit?" --Zapp Brannigan

  • #2
    -----------------------------------------
    The one without blur came out 156MB, while the one with blur is 76MB. Should bluring cause this major decrease in size?
    -----------------------------------------

    This is pure speculation on my part, but I have also seen this effect, although not to that extent. I usually grab 45-minutes shows from television and set the bitrate such that the resulting file will be exactly 322 MB (to fit 2 per CDR). Most of the time, the file is around 310-322 MB (it never goes over the limit set by the bitrate). However, sometimes the file size will be as low as 260 MB. I've noticed that this seems to happen more often on "darker" captures, so I suspect that if the MPEG-4 compressor doesn't need the bitrate you've assigned it to maintain quality, it doesn't bother using it. I haven't noticed a real quality decrease on those smaller files (except that was reflected in the source video, such as darkness).

    I suspect that blurring offers the compressor a lot of leeway in terms of how much data is has to use to replicate that kind of video. If you can, I'd be interested in seeing what it came up with if you set the bitrate to 3000 or 6000 and re-encoded the blurry video. When I did tests like that here, the videos used far less than 6000 kbits/sec (although they did increase in size from the 920-ish ones that produced the 260 MB files, presumable because some parts of the video needed > 920 kbits/sec to be considered "good" by the compressor, and since I had told it basically "knock yourself out" with the bitrate, it used it when necessary.

    Anyone with more experience with the MPEG-4 standard, please feel free to educate us!

    Comment


    • #3
      Hi there,

      what you dicovered is the main difference between the low-motion and the fast-motion codec. The fast-motion, which you used for your captures, does not try to maintain the bitrate you specify. It will drop to whatever it thinks is necessary at minimum and will shoot up again if you've got more action going on in the video.

      On the other hand the low-motion codec will always hover around the specified bitrate and will therefore maintain the same picture quality throughout the whole video. So, low-motion is much more predictable when it comes to calculating file sizes.

      Regards,
      Thorsten

      Comment

      Working...
      X