Dum question about 2 pass?

[trbarry]

Maybe this isn't the right forum for it and I'll obviously betray my ignorance no matter where I post it. But lots of interesting developers hang out here, so I'll try anyway.

I don't understand DivX and Xvid 2-pass. It seems it does it twice, to take advantage of info gained on the first pass and get the size right on the 2nd try. I can agree it certainly seems to always work better on either Xvid or DivX than any single pass.

But why is it done like it is? It does not keep enough information on the first pass so you have to go through the same, say, DVD2AVI, Avisynth, IVTC, filters, etc., all over again.

Wouldn't it just be more efficient to write a complete bigger file with the min quantizer, or max bit rate, or whatever. Then the second pass could operate just from that file and the log file, shrinking the size somewhat more precisely. Maybe it could operate somewhat like ReMPEG if that sort of approach works for mpeg4.

Even at a high bit rate the IO on the second pass would probably be much lower because the XviD file would typically be smaller. And it might avoid all the other baggage and overhead. The motion search would be already done and maybe also much of the DCT.

Is there something about mpeg4 that makes it hard to shrink in place?

Just another dumb idea. ;)

- Tom

[Koepi]

Hi Tom,

this idea isn't new, in fact, some threads below this (or on the next page) you'll find it :)

The major reason NOT to do it this way is the quality loss that you'd experience. Another main reason for that is the space needed for that intermediate file.

If you want to save some time, apply your filters, settings etc and save the result as a HUFFYUV and then do a 2 pass ;) (you have to calculate a break even point for every filter setting and fps on your machine though ;) )

But you sure know that compressing something 2 times is always _BAD_! The resulting movie will lack quality (we had to see how stable the codec bahves when compressing it's own results...).

Just my thoughts why it's better to do it the lossless way :)

Regards,
Koepi

P.S.: you might want to find that old thread because there were some very nice explanations why that is a bad idea... for example the generated stats file would be inaccurate since compressability did change....

[trbarry]

Darn! :(

I'll go look for that other post. I wonder how ReMPEG gets away with it? But I've never actually used that.

It sure seems like it would be possible to dump enough info into the log file to make this work but I've never written a (re)mpegx encoder, so who knows? It's beyond anything I'll probably try to tackle by myself anyway. "ReCore"

But thanks.

- Tom

[trbarry]

Grrrrrr....

I searched back to the beginning and didn't find it. Anybody remember the title?

- Tom

[Koepi]

I searched this forum and new a/v formats as well - the thread has been deleted during restructuring, sorry :-/

Regards,
Koepi

[trbarry]

Koepi -

Thanks. I thought something like that.

This has got me curious so I think I'll go try and find out about how ReMPEG does it. It sure seems it would be quick and nifty to be able to do a largish 1-pass with an enhanced log file and then fine tune the size later using ReXviD.

It's true you don't want to re-compress multiple times because of losing resolution. But I'm not sure you couldn't selectively increase the quantifiers or otherwise decrease the bits some places without having the cumulative loss problems.

But again, I don't claim any competence in this area.

- Tom