redo-ing 2nd pass

[aramo]

Hi all,

I'm using divx4.12, gknot 023beta and decomb 4.05 [31-Oct-02]

I've just completed a conversion of ST the Motion Picture [Region 2] and noticed several long runs within the movie where keyframes are combed [1/2 frame from old scene + 1/2 frame from new scene]. I'm about to try a 2nd pass only using
decomb
Telecide(guide=2,post=false)
I've aleady checked by loading the avs file into vdub and this correctly fixs the combed keyframes. As I'm doing this on a P2-300 it will take some time.

My question is, if the 1st pass had combed keyframes written to the log file will this not yield wildly inaccurate figures for a 2nd pass only run where the combed keyframes have been removed?

Should I do the entire [1st + 2nd pass] movie again?

[hakko504]

If you change anything except bitrate (by less than 20%) you must redo both passes.

So in this case where you have added a line to the .avs, the answer is most definitely: YES, you must redo both passes.

[aramo]

Thank you Hakko,

I was aware modest changes in bitrate were allowed .. so wishfull thinking, and the thought of saving 12 hours, got the better of me :)

[len0x]

Originally posted by aramo
I'm using divx4.12, gknot 023beta and decomb 4.05 [31-Oct-02]


I just wonder - is there a reason for that ? :)
(I mean using DivX 4.12...)

[aramo]

Fair question, it's possibly sloppy thinking on my part but ...

I'm more concerned with replaying on low powered hardware than avi file size file. A P2-350 or Transmeta Crusoe as used in a Fujitsu Siemens Lifebook P-2020 will replay 608x336, 672x304 or 512x384 divx412 + mp3/ac3 avis without problems. On average movies take between 1100 and 1400 MBs or approx 12MB/min, I'll go down to about 10MB/min for long movies.

I've friends with P4s and fast AMDs but they are not very interested in tweaking so I'm at a disadvantage when it comes to making direct visual inspections to compare 4.12 to 5.0x - I'm assuming throwing an extra MB or two per min at a 4.12 gives similar quality to a 5.0x.

If you think I'm way off base I'd like to know.

[len0x]

Originally posted by aramo
If you think I'm way off base I'd like to know.

It all comes down to the dshow filter you're using to play divx with...
I personally find 5.0.5 filter much faster than any other pure divx filters (and you can set postprocessing to mimimum) on playing even divx 3.11 stuff...

Alternatively you can use ffdshow (which also performs well)

[aramo]

Well Len0x, I read your post a few times and realised I didn't understand a word of it :(

Are you saying that divx5.05; all other things being equal; requires less CPU than divx4.12 for playback?