Encoding Duration

[acro29]

Hello.

So far. I always encoded Xvid 2 Pass mod all my videos.
it took around 30 min for the first pass. and 1 hour or so for the second.
the results seemed as they should to me.

Not long ago I have started encoding using x264...
and the results are mcuh much better then with Xvid' the problem is that it takes so much time to encode XD. about 6 to 8 hours... Oh my O.O...I with my bad luck, dont have that time >_>.

so my quetion is there a possibilty to use the Xvid 1st pass.stats file with the second pass of x264...I didnt have the time to test it yet, though... shouldn't there be any "side effects" on the stream doing so ?

Also I wouldlike to know what is the meaning of lossles pass....
I get it....crappy setting with the encoder. but what exactly does this mean?
what part of my setting should I change?. wheater in Xvid or x264.

cheers ACro.

[Dark Shikari]

Hello.

So far. I always encoded Xvid 2 Pass mod all my videos.
it took around 30 min for the first pass. and 1 hour or so for the second.
the results seemed as they should to me.

Not long ago I have started encoding using x264...
and the results are mcuh much better then with Xvid' the problem is that it takes so much time to encode XD. about 6 to 8 hours... Oh my O.O...I with my bad luck, dont have that time >_>.Sounds like you're using vastly higher settings than you need to.

so my quetion is there a possibilty to use the Xvid 1st pass.stats file with the second pass of x264...I didnt have the time to test it yet, though... shouldn't there be any "side effects" on the stream doing so ?Xvid firstpass files are totally different from x264 firstpass files and are completely useless for that purpose.
Also I wouldlike to know what is the meaning of lossles pass....
I get it....crappy setting with the encoder. but what exactly does this mean?What do you mean? Lossless mode means the output is the same as the input.

[cogman]

Yep, like Dark Shikari said, your settings are much higher then you need them to be. Try enabling turbo mode, lowering your reference frames to maybe 3, changing your motion estimation to hex (3 is it?) and increasing your b-frames to 16. That should help a bit with the speed with a not too bad drop in quality.

If you really want good quality, though, use CRF mode and put it around 18-20. The advantage is that it is a single pass encode, the disadvantage is that it is impossible to predict the resultant file size.

[cogman]

also, how are going about encoding your video? Are you using Megui, CLI, staxrip, ect? And what version of x264 do you have? You will want the latest Cef build as it has all the goodies patched in and should be fairly fast.

BTW, Welcome to doom9, these guys are great and very helpful. so follow their advice and pass it on :)

[Sharktooth]

i'd like to see the commandline parameters you used ;)

[acro29]

Thenx ^____^.

at first I have tried using simple parameters.... Now I encode with VirtualDub and use the defult setting of x264..
I have the latest codecs... I also try encoding with MeGUI yet its also very slow.....and the outcome is very bad.

mayby I should just go back to using Xvid >_>.

[Dark Shikari]

Thenx ^____^.

at first I have tried using simple parameters.... Now I encode with VirtualDub and use the defult setting of x264..
I have the latest codecs... I also try encoding with MeGUI yet its also very slow.....and the outcome is very bad.

mayby I should just go back to using Xvid >_>.Virtualdub isn't meant to encode with x264--AVI does not properly support B-frames, which are an integral part of H.264.

You're really not helping yourself--you're not giving us the settings you're using or anything, while complaining about the results. :rolleyes:

[acro29]

Sorry. T_T.

But MeGUI realy isnt doing much, the file size is realy not what is suposed to be.

here are the screens

http://i20.photobucket.com/albums/b216/acro29/ratecontrol.jpg

http://i20.photobucket.com/albums/b216/acro29/frames.jpg

http://i20.photobucket.com/albums/b216/acro29/more.jpg

[cogman]

is that megui? if so, it is a freaking old version and you REALLY need to get the latest greatest edition :)

You should set threads to 0 as x264 should be able to choose your threads pretty well. While it should give you a fairly good speed, you really do want at least 3 reference frames. B-Frames you want 16 (where it says bframe max) (x264 should choose how many you actually use) and you want to use it as a reference as well.

Seriously though, if that is megui you need to get .Net framework 2.0 and the latest version from here (http://sourceforge.net/project/showfiles.php?group_id=156112)

[acro29]

lol. thats virtualdub.

Thenks for the fixes, I shall try them next time to see how it affects the speed.

[foxyshadis]

x264 VFW and CLI both use the same rate control, so I'm not sure how you're expecting size to change dramatically if you encode with one instead of the other. MeGUI has a simple bitrate calculator to take care of all of that, anyway.

[tyee]

I'm getting about 1.9fps encoding speed right now for x.264. Is this about right for an older P4 2.8GHz machine? Oh, I'm encoding to 720p,but I tried 1080p yesterday and it was also about 2.0fps but that was without resizing and not adding borders.

BTW, how do I add borders in MeGUI? I just did it manually into the avs file, but did I miss something in the program that does it for us?

[Dark Shikari]

I'm getting about 1.9fps encoding speed right now for x.264. Is this about right for an older P4 2.8GHz machine? Oh, I'm encoding to 720p,but I tried 1080p yesterday and it was also about 2.0fps but that was without resizing and not adding borders.

BTW, how do I add borders in MeGUI? I just did it manually into the avs file, but did I miss something in the program that does it for us?You could probably speed it up a bit more, but a Pentium 4 isn't very fast, and it only has one core.

[tyee]

Yeah, I read a thread on videohelp yesterday about a Q6600 processor taking a pretty short time --

"Average 2-pass encode takes about an hour, maybe a little more, for a 90-minute movie."

So I started looking for a new Motherboard too, so many choices. A lot of guys have DOA from all the companies. Thinking about Gigabyte or Asus. 2 fps is just too slow nowadays!

Is the quad core Q6600 a good choice?

[Dark Shikari]

Yeah, I read a thread on videohelp yesterday about a Q6600 processor taking a pretty short time --

"Average 2-pass encode takes about an hour, maybe a little more, for a 90-minute movie."

So I started looking for a new Motherboard too, so many choices. A lot of guys have DOA from all the companies. Thinking about Gigabyte or Asus. 2 fps is just too slow nowadays!

Is the quad core Q6600 a good choice?The quad-core will likely be around 1.5-2x faster per core than your Pentium 4--and 4x faster due to the 4 cores. Its a great choice.

[mitsubishi]

Remember also that decoding a 1080 source isn't easy. When I'm doing 1080->720 2-pass encodes I first encode to huffy. Decoding the avs once, a huffy encode and two huffy decodes takes less cpu time than 2 avs decodes for this so overall time is a little lower.

Edit, you need plenty of space for the lossless file though.

[akupenguin]

Remember also that decoding a 1080 source isn't easy.
Filtering 1080p is hard. Decoding it is easy, or at least not helped by transcoding. Decoding 1080p 20mbit h264 takes about the same amount of cpu-time as decoding 1080p 150mbit huffyuv, let alone encoding once plus decoding twice.
btw, the 2nd decode is unnecessary. Just encode the huffyuv and the 1st pass at the same time, and then decode the huffyuv on the 2nd pass.

[mitsubishi]

Yeah, but I said when resizing, I meant the avs source, not just the plain video. Obviously if the source is a low bitrate 1080p mpeg then it's likely to be slower. But if the source is an interlaced high-bitrate h264 with all the slow options with added avisynth goodies, then there are gains to be had when going to 720p. I also add delogoing to my HDTV captures, so can save a couple of hours over a long encode since my source scripts play about 12 fps.


btw, the 2nd decode is unnecessary. Just encode the huffyuv and the 1st pass at the same time, and then decode the huffyuv on the 2nd pass.Yeah I know, you and squid_80 told me how to do that before, but I was keeping it simple.