question: faster encoding..?

[_seth]

here goes: is there any way of doing a one pass (100%) quality based encode, and still write a motion-log file? so i can add all the timeconsuming resize/cleanup filters in the first pass, and then in the second pass transcode the first-pass encode using the motion-log to reach my desired filesize. not running any filters for the second pass should save a lot of time. if it's possible, will this method affect the quality of the encode compared to a standard 2-pass encode?

[wotef]

1-pass doesn't generate a stats file, and even if it did, you'd only save time if you recompressed the lossy file - not a good idea at all

in certain cases (depending on the speed of the filters you choose), it's faster all-in to save your filtered video to an intermediate lossless format before doing a two-pass on the already-filtered (but lossless) video - basically, the time-saving is as your thread identifies, gained through not applying slow filters more than once

for fast filters, though, the equation may change, ymmv!

[Cantide]

Hi,
You could achieve this result if you, uncheck Discard 1st pass in the Xvid Config and compress the resulting file in the Second Pass.
I did a few experiments with that some time back, it is definitely faster but the quality was not as good (the result of 1st pass is 100% quality=Quantizer 2 but still it is not lossless).
IMHO the reason for those problems is that because of the lossy compression the stats file you created in the first pass does not exactly fit the material you use in the second pass.

Cheers
Cantide

[vinouz]

Maybe it's time someone implements an option to make the first pass save with constant quant 1 (even if internally it performs its calculation on using quantizer 2 it can save a different bitstrean. That 'fork' would take less overhead time than the one taken by a full prealable huffyv12 encode (before 1st pass, for saving filtered), and also 2 huffyv12 decodes (1st pass and 2nd pass) would be replaced by one xvid quant1 decode (2nd pass)).

And if quant1 isn't enough for quality, to also save this 'forked' stream with some HQ matrix (for ex Andreas 78er, or that we could choose, or maybe the divided-by-two matrix of the one choosen, in order to have the same kind of quantization artifacts generated [if it doesn't raise overflow errors also...]).

Syskin, Koepi, what do you think of it ? Would it be too hard to implement ?

[spyder]

I don't really think this would be useful. It would still result in lower quality IMO. Though I am no MPEG4 guru, I don't think using quant 1 is a good idea for temporary data between passes.

[_seth]

thanks for the input.
the reason for asking is that i recently encoded a movie, and the 1st pass alone took about 16 houres due to the filtering (4-5 is normal). my audio/video encoding tools are located on a different os/partition, and i need my computer for other activities.

i'll try to be more specific:
let's say i'm encoding something to xvid 640x272 with 750 bitrate. can i do the 1st pass at 800-1000 bitrate (being sure the peak bitrate is high enough), and use the 1st pass result together with the logfile to transcode it to my desired bitrate (750)?

i'll try what Cantide suggested (uncheck discard 1st pass in the xvid config and compress the resulting file in the 2nd pass). if this doesn't work i'll have to consider a hardware upgrade ;) .

[mf]

Tip: if you have the HD space (a few gigs per movie), filter to a lossless codec like huffyuv or VBLE. You can find them by using the search function. This will in essence create a 3-pass encoding scheme, but your two last passes will probably speed up considerably.

[BoNz1]

Originally posted by mf
Tip: if you have the HD space (a few gigs per movie), filter to a lossless codec like huffyuv or VBLE. You can find them by using the search function. This will in essence create a 3-pass encoding scheme, but your two last passes will probably speed up considerably.

I think this has been discussed before on the xvid.org forums by the developers, except I can't find the thread right now. What they were talking about doing is creating a sort of "dummy" first pass and also write to huffyuv at the same time and then in the second pass to encode the huffy. This would obviously save a ton of time since the filtering would all be done in the first pass like you explained, only problem is you would need a really really big HD, especially for like say a 2hr movie. I am not sure though if this would be any faster than what you suggested though mf, I think the difference in speed might be minimal, compared to doing it your way by hand, ;)

[ChristianHJW]

What i am suggesting is certainly no good for a 1 CD rip, but for a 2 CD rip you may test anamorphic encoding into matroska container without any resizing.

I am not sure though if it really could be a speed advantage, for sure not with all the options i turned on ( VHQ = 4 , Q-PEL, 5 b-frames ) etc, as the higher number of pixels ( 720 x 432 ) will more than eat away the small speed advantage from not having to use a resizing filter, but with your 1 pass quality based encoding it may be an option to test.

Latest mkvmerger binaries will allow you to set the corresponding AR flag in the matroska track header when transmuxing your AVI into MKV, and both mplayer on Linux and TCMP with matrosks CDL plugin will read the flag and auto-correct AR for playback.

Dont forget to use h.263 quants ....

EDIT : sorry, i misunderstood your intentions. You are not aiming to make a 1 pass encoding, you would like to make the 2nd pass from your 1st pass AVI. Thats possible in principal, but not recommended, and was discussed ages ago already ( for nandub, in the old nandub forums ), as you would add a lot of noise from reencoding another encode ...

[mf]

Chris: this is now not the place to confuse ppl by pimping matroska. Just a hint.

And recompressing your first pass will probably not get you your desired filesize. Already compressed material is more compressible than original, so you'll probably get an undersize at much lower quality than if you did normal 2pass.

[ChristianHJW]

I made a test to see if any speed improvement could be achieved by anamorphic encoding. Clea result : NO !

Only when disabling all extra functions and using default options in stable release, and when source was a SVCD ( PAL, 480 x 576 ) the anamorphic encoding could gain a little speed advantage, and that was only 15%. On my SMP machine all anamorphic encodings are simply much slower, as resizing/filtering can be done with the 2nd CPU from the SMP.

Sorry for having bothered you with that ..... and of course my special apologies to mf, my personal 'anti-pimping' watchdog, for having stolen his precious time ( again ) ....

[mf]

Originally posted by ChristianHJW
Sorry for having bothered you with that ..... and of course my special apologies to mf, my personal 'anti-pimping' watchdog, for having stolen his precious time ( again ) ....
Well actually I heard about it from Koepi, and as far as I got it, you only nearly evaded a strike.
And food for thought: is annoying other people all the time really worth those extra users? Can't you find more normal ways to get your product used?

[trbarry]

I think this has been discussed before on the xvid.org forums by the developers, except I can't find the thread right now. What they were talking about doing is creating a sort of "dummy" first pass and also write to huffyuv at the same time and then in the second pass to encode the huffy. This would obviously save a ton of time since the filtering would all be done in the first pass like you explained, only problem is you would need a really really big HD, especially for like say a 2hr movie. I am not sure though if this would be any faster than what you suggested though mf, I think the difference in speed might be minimal, compared to doing it your way by hand,

I wonder if this could just be done by having an Avisynth filter that wrote its output to HuffYV12? This filter would be placed at the end of your script, saving data exactly the way it was being presented to vdub or whatever.

Then you could say "discard first pass" in Xvid but use the temp file on the 2nd pass, with no filters. But I can't predict at all what the net time savings would be. It seems it might be substantial in some cases.

- Tom

[Sigmatador]

edit: a doublepost ^^ sorry

[Sigmatador]

Originally posted by trbarry Then you could say "discard first pass" in Xvid but use the temp file on the 2nd pass, with no filters. But I can't predict at all what the net time savings would be. It seems it might be substantial in some cases.


ohhh good idea ^^

using a filtering prepass with vble on a "reasonable" script and the "best" xvid options, i can reduce the encoding time by 20-30%. (and much more with heavy deinterlacing script ^^ ) but requires a lot of free spacedisk.

With this filter, it can improve again the encoding speed, but there's 2 problems:
-vble encoding is so fast, but decoding .... "bofbof" :D and marc doesn't want to see vble code anymore
-marc doesn't release his source code ... :sly:

[vinouz]

well. But I think a 2pass-1st pass option by side of 'discard first pass results' could be 'q1 encode as first pass result'. As this would be quicker than using vble (one pass less), and the quality would be good enough (don't forget the source was MPEG-2 which theoretically can't beat q1 in quality).