I know x264 encoding is slower than XviD, but...

[buffyangel108]

On my overclocked E4300 dual-core system:

- an XviD encode (HQ settings, MSP 6, VHQ 4) averages around 120fps on 1st pass, 75 fps on 2nd pass

- an x264 encode (DXVA-SD-HQ profile in MeGUI) averages around 60fps on 1st pass, 7.5 fps on 2nd pass (!)

using the same source .avs script (DGDecode_MPEG2Source, cropped to 704 x 384).

I'm new to this x264 encoding... but does a tenfold increase in encoding time from XviD sound plausible?!

:(

[Inspector.Gadget]

Depending on complexity, certainly. "XviD is faster than x264" is NOT a complete, valid observation or generally true.

[dstln]

x264 can encode incredibly fast to incredibly slow, depending on settings chosen...

[thewebchat]

I frequently encode at 1-2 fps, so this sounds pretty fast to me. What are your settings? For 704x384, you should certainly be able to get at least 11-15 fps without noticeable quality drop from your current settings.

On the reverse side, if you use one of the really fast presets, you should be able to outperform Xvid and still look marginally better.

[roozhou]

Generally, x264 is faster than xvid because x264 can encode at high speed that xvid can never reach.
IMO Xvid's HQ setting is worse than x264's --preset veryfast.

[Blue_MiSfit]

x264 performs much better with a non-broken GUI :) MeGUI is currently out of date, and does not correctly support x264's new presets and tuning system.

From the looks of it, you're encoding an NTSC DVD, to a DXVA compatible profile. Do you really need DXVA compatibility? Not likely, as any system should be able to play back SD H.264.

Do you target filesize or quality? I usually suggest using CRF encoding mode, as it allows you to encode in a single pass, and get excellent uniform quality. The only downside is that filesize is a bit unpredictable. Thankfully, with hard drives as cheap as they are these days - that's not so much an issue.

If you absolutely must encode to hit a specific file size (like 1 CD or 1/2 a DVD5 etc...) then 2 pass is the way to go. Otherwise, I'd say do some test encodes using CRF 18-22, and pick one that gives you acceptable quality - then use that for your encodes in the future. The "new" x264 defaults (assuming you use an up-to date binary, like the ones posted on x264.nl), are chosen to be an excellent balance of speed:quality.

Ripbot264 would be my suggestion for x264 encoding - as it's quite simple and is fully compatible with the new presets / tuning system. I personally do all my encoding with Lord_Mulder's GUI, as it automates using avs2yuv and pipe buffers to feed 32 bit Avisynth to 64 bit x264 for a slight speed boost (since I'm running an Intel Q6600 on Windows 7 x64).

Good old fashioned CLI encoding works quite well, also!

Take a peek here for more detail about the new presets and tuning system.
http://mewiki.project357.com/wiki/X264_Settings

You should be able to blow away Xvid, both in terms of quality and speed.

~MiSfit

[Audionut]

Search the forums. There is a post somewhere showing that for the same PSNR or SSIM results, x264 is always faster than xvid.
And that post would be about 2 years old iirc. So the results from a current build would favour x264 even more.

edit: here is the thread. http://forum.doom9.org/showthread.php?t=105763
And it was over 3 years ago and unfortunally the pic is gone.

[buffyangel108]

Thank you for all of your replies and suggestions. It looks like I have some test encoding to do!

:thanks:

[dvy]

x264 should completely instead of XviD ,except of special xvid decoding requirement . x264 setting is very flexible from fastest to slowest ,x264 absolutly exceed xvid at quality/encoding-time ratio.

[BLKMGK]

x264 performs much better with a non-broken GUI :) MeGUI is currently out of date, and does not correctly support x264's new presets and tuning system.

From the looks of it, you're encoding an NTSC DVD, to a DXVA compatible profile. Do you really need DXVA compatibility? Not likely, as any system should be able to play back SD H.264.

Do you target filesize or quality? I usually suggest using CRF encoding mode, as it allows you to encode in a single pass, and get excellent uniform quality. The only downside is that filesize is a bit unpredictable. Thankfully, with hard drives as cheap as they are these days - that's not so much an issue.

If you absolutely must encode to hit a specific file size (like 1 CD or 1/2 a DVD5 etc...) then 2 pass is the way to go. Otherwise, I'd say do some test encodes using CRF 18-22, and pick one that gives you acceptable quality - then use that for your encodes in the future. The "new" x264 defaults (assuming you use an up-to date binary, like the ones posted on x264.nl), are chosen to be an excellent balance of speed:quality.

Ripbot264 would be my suggestion for x264 encoding - as it's quite simple and is fully compatible with the new presets / tuning system. I personally do all my encoding with Lord_Mulder's GUI, as it automates using avs2yuv and pipe buffers to feed 32 bit Avisynth to 64 bit x264 for a slight speed boost (since I'm running an Intel Q6600 on Windows 7 x64).

Good old fashioned CLI encoding works quite well, also!

Take a peek here for more detail about the new presets and tuning system.
http://mewiki.project357.com/wiki/X264_Settings

You should be able to blow away Xvid, both in terms of quality and speed.

~MiSfit

Some questions... I currently use meGUI to great effect on an I7. I see that it hasn't seen any updates of late - at least not through it's automated update. I'll research further as to the project status but honestly I've found it helpful but am always looking for better. I'd like to encode HD MPEG vids from my TIVO down to a reasonable size, not for archive storage. kmttg is my tool of choice to automate this and I suspect I'll have to roll my own encoding profile - right now it's strange in that it doesn't seem to fully utilize the CPU but IS multithreaded.

I've tried searching for the GUI you've mentioned but am not finding it, could you please be more specific? I currently am using the one-step encoding with meGUI for TV shows when I'm unhappy with kmttg's profiles. I've got RipBot however I've not yet tried it on the files I'm interested in. My goal is to get HD files as good as some of the scene releases of TV shows condensed down from HD recordings - 720P is fine. They are noticeably better resolution than SD captures and about the same file size but danged if I can figure out what they're using. I figure encoding my own captures is a bit more legit than torrenting <shrug> so guidance would be nice. I've got power to burn so I don't mind something CPU intensive.

I also rip and encode BD media. I am again using meGUI, I have also tried RipBot some on these but the file sizes looked suspiciously small and I've not had a chance to test watch many encodes yet. I have plenty of storage, the BD stuff is for archival. With meGUI I see a 30-50% reduction in file size using x.264 which is fine but of course always looking for better ways to do things.

If anyone is serious about encoding get an I7. The 920 I have is clocked to 4.2ghz. I see 1stpass rates as high as 65FPS and second pass as high as 40+. About a 10X speedup from my 3.8ghz C2D using the same profile :eek:

P.S. Testing RipBot on a TIVO HD MPEG now. 1st pass clocking 65FPS with plenty of CPU left! It's the High profile. Feeding it is a pair of striped 1TB drives so I shouldn't be bottlenecked..

[Rumbah]

If you resize the source then probably the Avisynth resize filter is the bottleneck. You could try slower x264 settings and see if the fps stay the same.

[JohannesL]

On a Phenom II:

[~/Downloads]% x264 --crf 20 --preset fast -o /dev/null akiyo_cif.y4m
yuv4mpeg: 352x288@30000/1001fps, 128:117
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 1.3
x264 [info]: frame I:2 Avg QP:15.07 size: 19596
x264 [info]: frame P:76 Avg QP:19.76 size: 1864
x264 [info]: frame B:222 Avg QP:25.49 size: 128
x264 [info]: consecutive B-frames: 0.7% 0.0% 0.0% 99.3%
x264 [info]: mb I I16..4: 5.1% 65.9% 29.0%
x264 [info]: mb P I16..4: 0.0% 0.1% 0.0% P16..4: 16.7% 12.1% 10.4% 0.0% 0.0% skip:60.6%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 4.3% 0.7% 0.4% direct: 1.2% skip:93.4% L0:22.8% L1:32.6% BI:44.7%
x264 [info]: 8x8 transform intra:66.1% inter:40.6%
x264 [info]: coded y,uvDC,uvAC intra: 96.4% 95.9% 89.4% inter: 5.2% 3.7% 0.9%
x264 [info]: i16 v,h,dc,p: 48% 15% 0% 38%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 27% 19% 4% 4% 6% 4% 5% 6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 10% 11% 6% 7% 13% 7% 14% 7%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: ref P L0: 66.6% 20.8% 12.6%
x264 [info]: kb/s:167.28

encoded 300 frames, 409.43 fps, 167.28 kb/s

What did you say again?
I even run a stock 2.6.31 kernel without the new BFS that significantly boosts threading performance. (http://saintdevelopment.com/codecs/bfs-vs-cfs.txt)

[juGGaKNot]

Weighted P-Frames: Y:0.0%

no fades or borked ?

[nurbs]

It's only 300 frames. Or he has one of the miscompiled builds.

[JohannesL]

Yes, only 300 frames, no fades. Maybe I should find a longer test clip..

[JohannesL]

Ok, I grabbed [ASR]Suzumiya_Haruhi_Full_DANCE_Ending[DVD][848x480_H264_OGG][C34E9431].mkv referred to at Dark Shikari's blog, dumped to y4m with mplayer and encoded:

[~/Downloads]% x264 --crf 20 --preset fast -o /dev/null test.y4m
yuv4mpeg: 848x480@2997/125fps, 1:1
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 3.0
x264 [info]: frame I:19 Avg QP:16.32 size: 30403
x264 [info]: frame P:939 Avg QP:21.53 size: 12215
x264 [info]: frame B:610 Avg QP:25.54 size: 4761
x264 [info]: consecutive B-frames: 25.7% 65.2% 0.6% 8.5%
x264 [info]: mb I I16..4: 34.7% 33.4% 31.9%
x264 [info]: mb P I16..4: 3.2% 5.0% 6.4% P16..4: 15.1% 11.5% 7.3% 0.0% 0.0% skip:51.6%
x264 [info]: mb B I16..4: 1.3% 0.7% 1.8% B16..8: 16.5% 3.5% 4.1% direct: 3.3% skip:68.9% L0:42.3% L1:46.3% BI:11.4%
x264 [info]: 8x8 transform intra:32.0% inter:30.2%
x264 [info]: coded y,uvDC,uvAC intra: 55.7% 70.4% 45.8% inter: 12.8% 10.0% 1.4%
x264 [info]: i16 v,h,dc,p: 55% 25% 15% 5%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 16% 27% 5% 4% 7% 4% 7% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 27% 13% 19% 6% 8% 11% 5% 8% 4%
x264 [info]: Weighted P-Frames: Y:1.0%
x264 [info]: ref P L0: 75.2% 13.8% 11.0%
x264 [info]: kb/s:1828.97

encoded 1568 frames, 62.43 fps, 1828.97 kb/s

2.6x realtime. I'd hardly call x264 slow.
For optimal performance, run 64-bit and compile x264 yourself with -march=native. The x264.nl builds are fine though. Just don't use MeGUI.

[Atak_Snajpera]

1st pass clocking 65FPS with plenty of CPU left!
Fast first pass does not require all cores. If you are obsessed with cpu utilization at 100% then disable fast first pass in ripbot264.ini
FastFirstPassin2passMode=0

I personally do all my encoding with Lord_Mulder's GUI, as it automates using avs2yuv and pipe buffers to feed 32 bit Avisynth to 64 bit x264 for a slight speed boost (since I'm running an Intel Q6600 on Windows 7 x64).
Ripbot264 uses above method as well. (default)

[LoRd_MuldeR]

Fast first pass does not require all cores.

Uhm? I'd say "Fast" first-pass, as the name implies, uses extremely fast settings. Therefore the Non-parallelized (single-threaded) part in x264 becomes the bottleneck and thus not all CPU cores can be fully utilized. Usually (with "medium" to "slow" settings) this problem won't show up, simply because other multi-threaded parts in x264 are much slower (use more CPU cycles) and thus "hide" the bottleneck in single-threaded part with calculations. Still this doesn't mean the other cores aren't "required" in fast first-pass. They simply cannot be used, at the moment. But they could be used with threaded lookahead...

[mavinashbabu]

x264 performs much better with a non-broken GUI :) MeGUI is currently out of date, and does not correctly support x264's new presets and tuning system.

From the looks of it, you're encoding an NTSC DVD, to a DXVA compatible profile. Do you really need DXVA compatibility? Not likely, as any system should be able to play back SD H.264.

Do you target filesize or quality? I usually suggest using CRF encoding mode, as it allows you to encode in a single pass, and get excellent uniform quality. The only downside is that filesize is a bit unpredictable. Thankfully, with hard drives as cheap as they are these days - that's not so much an issue.

If you absolutely must encode to hit a specific file size (like 1 CD or 1/2 a DVD5 etc...) then 2 pass is the way to go. Otherwise, I'd say do some test encodes using CRF 18-22, and pick one that gives you acceptable quality - then use that for your encodes in the future. The "new" x264 defaults (assuming you use an up-to date binary, like the ones posted on x264.nl), are chosen to be an excellent balance of speed:quality.

Ripbot264 would be my suggestion for x264 encoding - as it's quite simple and is fully compatible with the new presets / tuning system. I personally do all my encoding with Lord_Mulder's GUI, as it automates using avs2yuv and pipe buffers to feed 32 bit Avisynth to 64 bit x264 for a slight speed boost (since I'm running an Intel Q6600 on Windows 7 x64).

Good old fashioned CLI encoding works quite well, also!

Take a peek here for more detail about the new presets and tuning system.
http://mewiki.project357.com/wiki/X264_Settings

You should be able to blow away Xvid, both in terms of quality and speed.

~MiSfit

Hi Blue_MiSfit,

In that wiki update, i see b-pyramid as one of switches available, but with MeGUI [rev. 1056] and 264 [build 1320] i get error --b-pyramid is an invalid option or something similar error.... so i started doing my encodes in CLI

Also it would be very kind and great help if i can know and learn some terms like .... 'scenecut','no-mbtree','weightp' .... i tried to read on but i few things i could not understand.

Thanks,
Avinash

[J_Darnley]

--b-pyramid now requires an argument, as stated in "that wiki", of none, strict or normal. You, or megui, are probably missing the argument so x264 reads the next option which is not valid. In future paste the exact error instead of a "something"