DivX5.0 resize and crop filter

[kheperi]

I understood from most articles about DivX5.0 that we shouldnt use anything but a few options of the codec. I'm not completely shure if that includes the resize and crop filter too, but up to now i didnt use them.

The use of those filters would have an advantage for me. Since i use VFAPI i cant use fast repack as long as i use filters.
So yesterday i did a test with a chapter of a dvd (Merlin. Has really very good image quality) to see if there where any troubles.

Hmm i have to say that i didnt use cropping, since it was a 4:3 ratio movie and it used the complete dvd resolution (no black bars to crop).
But its not a bad idea anyway to test the features seperately, so in case of problems i can be shure what option caused them.

I did the chapter both with vdub and codec resizing. The second one i did using fast repack.
Both resulting files turned out to be exactly the same size (187.752.448 bytes). I didnt expect that since i thought that not using the rgb-yuv conversion would cause at least some difference.

But anyway, the resize filter seems to work perfect. No problems found what so ever.
The speed advantage of using fast repack was not impressive though. full processing took 146 mins (both passes) and fast repack took 129. Ummm isnt that 11.6% improvement?

Next experiment: both resizing and cropping.

(few typo's fixed)

[griffy]

I have found that the crop and resize work perfectly in DIVX 5.

The process I used to follow was:

Smartripper
DVD2AVI
VFAPI
AC3 to Ogg using HeadAC3he (now starting to use Ogg Machine)
DivX Bitrate Calculator 2.4.2
Virutal Dub using resize filter to crop and resize, which meant I had to use Full Processing mode.
Graphedit to mux AVI & Ogg

With DIVX 5 I use the resize filter in Virtual Dub to get the cropping values (top, bottom etc etc) then remove the filter select Fast Recompress and let the codec do the work.

oh, and just a personal opinion, if your not using Ogg yet your Mad, it is sooooo much better than MP3.

[kheperi]

cropping seems to work perfect too. Funny thing is that nomatter what is cropped the resulting filesize comes out exactly the same, up to the last byte.
That wonders me since in my last test i cropped just a random number of lines from all sides and resized again to 640x480. So the picture size was the same, but the content wasnt!
To research this further i'll do a test with a different chapter but with the same settings (and same amount of frames). See if its still the same size then... I cant believe that, since if that would be the case size predictability would be nothing less then perfect.

Now testing: resizing + cropping + preprocessing source (normal)
Hmm i notice while the first pass is running its not really much slower then without using preprocessing. Maybe a little bit. Strange again because i thought that this filter includes the very slow temporal smoother. Is it only active during the second pass? oh well i'll know within a few hours :-)

[kheperi]

update:

seems the preprocessing filtering is safe to use too. Not that i would use it that much...

And again... the output file is EXACTLY the same size again although i this time cropped using different values and used the preprocessing filter (normal).

By the way i only use B-frames. not the other 2 mpeg4 options. And sharp bicubic with all experiments sofar.

Next experiment:
Another part of the movie, but the same amount of frames. I also changed from sharp bicubic to normal bicubic. I keep the framesize at 640x480 (codec resizing). No cropping.

[kheperi]

another update. Last one i think.

I tried another part of the movie. Exact same amount of frames (31159).
The filesize i end up with is not the same!
I cant understand what happens here. I tried the first clip 3 times with different settings that change the content of the frames (only cropping and preprocessingfilters settings changed) but i got 3 times EXACTLY the same filesize.
But with another clip i do get a different filesize.
Why?

Not much difference though.

I did some math:
calculated filesize:
1200 (Kb/s) / 25 (pal) / 8 * 31159 = 186.954.000 bytes

The first 3 experiments i got 187.746.304 bytes
This last experiment i got 185.077.760 bytes
Well its close but not perfect.

Anyway i quit this thread. or i would have to change the name. I hope someone found my experiments usefull. Well at least i did :-)
Seems to me that resize, crop and preprocessing are safe to use options in the Divx5.0 codec. And thats usefull for VFAPI users.

(typos fixed)