x264 development

[squid_80]

I think I found the problem, some inline asm in ptw32_InterlockedCompareExchange.c was ignored when compiling pthread for amd64. Should be gone now : x264_x64_r648 (http://cef.neuf.fr/x264/x264_x64_r648.7z)
Looks perfect. Congrats on fixing it and thanks for doing x64 builds so I don't feel guilty about not keeping mine up-to-date.

[burfadel]

He also include the AQ patch which is great! :)

[Dannyboy007]

What's the differense if you rip a DVD with x264 in a MKV container or in a MP4 container? Is the quality better in MP4?

[bob0r]

What's the differense if you rip a DVD with x264 in a MKV container or in a MP4 container? Is the quality better in MP4?
http://x264.nl/jab.gif

[Bigmango]

What's the differense if you rip a DVD with x264 in a MKV container or in a MP4 container? Is the quality better in MP4?

The container has nothing to do with quality. It's only what it is... a "container".

The advantage with mkv, is that you can keep all the DVD sound tracks and subtitles. The disadvantage is that there is almost no hardware player support for mkv.

MP4 has more hardware player support, but compared to mkv, it has a lot of restrictions. You can't put DTS or AC3 tracks in MP4, and if I remember well, it is also limited to max 2 subtitles.

MKV is the better container.

[Dannyboy007]

I see. Thanks a lot Bigmango!

[bond]

in MP4, and if I remember well, it is also limited to max 2 subtitles.not true, you can place as much subs as you want in mp4

[Selur]

little feature request: option to stop x264 from exporting all the x264 encoding settings into the userdata.

[Terranigma]

little feature request: option to stop x264 from exporting all the x264 encoding settings into the userdata.

x264 Author's Response (http://forum.doom9.org/showthread.php?p=989015#post989015)

[Bigmango]

not true, you can place as much subs as you want in mp4

Ok, I was not sure on that one. Thx for correcting this.

[Sagittaire]

Possible to implement pulldown flags in x264 elementary stream ... ?

[Terranigma]

cef, any chance for a rev 651 build?
r651 | pengvado | 2007-04-21 13:32:34 +0200 (Sat, 21 Apr 2007) | 3 lines

cabac: use bytestream instead of bitstream.
35% faster cabac, 20% faster overall lossless, ~1% faster overall at normal bitrates.

[burfadel]

cef, any chance for a rev 651 build?

Make that 652 build :)

The aq patch is great! I wonder why it hasn't been included in the final build yet!

The thread patch sounds interesting, I wonder when that will be ready for inclusion!

Oh, and Cef you should let Sharktooth etc know what settings you use for your x264 compilation, because it seems to be way faster (same quality of course). Its not just a few percent either, it flies in comparison on my Core 2 Duo :)

[burfadel]

Cef's builds can be found on his x264 page here:

http://cef.neuf.fr/x264/

Hopefully he keeps up the good work and updates it soon with the latest build! He's currently got 650 up.

[e-Pawel]

The aq patch is great! I wonder why it hasn't been included in the final build yet!


What is that aq patch? What is its advantage???

[Terranigma]

What is that aq patch? What is its advantage???
Quote:
One part of the settings for Adaptive Quantisation. Adaptive Quantisation allows different parts of a frame to use different quantisers, as opposed to the whole frame using the same quantizer. The common use for this in XviD was that it would compress light and dark areas more, thus freeing bits for parts that were more noticable. Adaptive Quantisation works differently in x264 because it was added by Haali to address a problem that large blue areas could sometimes look blocky. Adaptive Quantisation in x264 assigns more bits to dark and blue areas to help stop them blocking up. This particular setting instructs the amount to adjust QP per Macroblock. Setting 0.0 is no Adaptive Quantisation, and 1.1 is considered strong. It is recommended that you only use this setting if your source is particularly blocky in blue areas only wheras the rest of the image looks fine.

[Selur]

little question about all the patches:

What has to happen for a patch to become part of the main branch?

Cu Selur

[Cef]

Cef's builds can be found on his x264 page here:

http://cef.neuf.fr/x264/

Hopefully he keeps up the good work and updates it soon with the latest build! He's currently got 650 up.

Thanks for noticing :) I updated to 654 today, sorry about the delay.

[LoRd_MuldeR]

little question about all the patches:

What has to happen for a patch to become part of the main branch?

Cu Selur

I guess the developers must be willing to accept and maintain the patch.
Just adding the patch to the SVN isn't enough, as future changes might break the patch.

[Terranigma]

Thanks for noticing :) I updated to 654 today, sorry about the delay.

Welcome back Cef, we missed you :D

[burfadel]

New build of x264 out, 656. Very small changes in regards to speed apparently, but still its the first update in a while!

[fight2win]

how to update x264 in megui to latest version???

[Terranigma]

how to update x264 in megui to latest version???

By copying the x264.exe file to megui\tools\x264

[burfadel]

Long wait, 658 is out :) very small changes but its an update! :D

[mroz]

I'm trying to find out what the current state of support is for interlaced encoding (in respect of future pal dv encodes).

I've spent a good three nights searching the web including this forum & can't find any mention more recent than last year, none of which were definitive but did make it clear interlaced support is still young.

DeathTheSheep's guide http://gabextreme.googlepages.com/DeathTheSheep_x264_VfW_guide.html states trellis & b frames have to be disabled. Is this still the case or is it maybe specific to the VfW version (seems unlikely)? Disabling b frames seems so extreme as to make me question whether I ought to consider x264 yet for this application. I think in such a case I'd have to restrict x264 to dv with only low motion & then deinterlace prior to encoding, which would be a shame.

Yet when I look at various third party front ends several seem to allow selection of interlaced functionality without any caveats either built into their code or docs - eg Megui iirc & certainly h264enc.

Is there any information available elsewhere?

I hope it was okay to pose this question in the dev thread. :thanks: for an excellent codec btw.

[akupenguin]

Trellis and B-frames work with interlacing.
B-pyramid might not, there's a bug I still have to track down.

[mroz]

:thanks: for the lightening quick response. I'll give interlaced encoding a go when I next have a batch of miniDV tapes to edit - quite curious so might have to do some testing soon.

[simonhowson]

I'm wondering if the motion estimation in next generation intel CPUs could help x264? Intel have sample code on their webpage here (http://softwarecommunity.intel.com/articles/eng/1246.htm) explaining how the new SIMD instruction is designed specifically to help speedup modern video encoders.

I was considering buying a Core 2 Quad CPU when the prices are cut on July 22nd. But if these new instructions are going to make their next gneration CPUs even better for video encoding, then I may wait for those.

Does x264 rely on these sort of motion estimation? Or is it unlikely that this feature will help with the way x264 works?

I mainly encode to the iPod 5.5 profile in MeGUI, does this even use motion estimation? Or is it only used in higher profiles?

[Terranigma]

I think someone, maybe even myself, should consider compiling patched builds from the sources in Cef's absence. Now if only there was a package that contained everything I need to compile......

[Manao]

simonhowson : http://forum.doom9.org/showthread.php?p=993986#post993986

So SSE4 isn't that usefull for the motion estimation. It will speed up the codec, but don't expect miracles.

[simonhowson]

simonhowson : http://forum.doom9.org/showthread.php?p=993986#post993986

So SSE4 isn't that usefull for the motion estimation. It will speed up the codec, but don't expect miracles.
Ahh, thanks for the reply, so it looks like the main improvement will be the bigger caches (6 MB rather than 4 MB).

[mroz]

How important is L2 cache to x264? I'm currently using a bunch of old Athlon XP machines & have always built AMD in the past as I like value for money. Probably be building a new machine in the next three months & will obviously be switching to Intel Core 2.

The cpu will either be the price slashed Quad 6600 or an overclocked budget E21xx. As x264 encoding will be a common task for the box I just wanted to check how big an impact the cache size will have.

Obviously I'd rather have the quad, but it'll depend on exact prices, how many pennies I have in the jar & expected relative performance.

[burfadel]

There is a massive difference metween the Q6600 and the ultra budget one you suggested. If you are thinking of an E6300 or E6400, you should pass those as they have been superceded by the E6320 and the E6420. The E6320 and E6420 have 4mb of L2 cache compared to the E6300 and E6400's 2mb, but run at the same speed. They are also the same price, so going for the older 6300's and 6400's would be silly (unless they cut the price in half or something).

[mroz]

There is a massive difference between the Q6600 and the ultra budget one you suggested.

I realise that. I just wanted to be able to make a judgement based on performance as one component only, but to do that I need to know how important cache size is to x264. How important is it?

Thanks for the other info.

Any c2d is going to massively outperform my old machines. A quad would be nice but even slashed it will still cost significantly more than an E21xx & cost is a major concern, especially as over the next year I'd like to replace all three of our existing desktop machines.

Normally I go with value first (ie minimal price : performance) & keep to the budget end of the spectrum, but if the price cut to the Q6600 makes it /much/ better value I might aim for it. I'm not likely to go for anything mid range unless they look to be at least as good value as the Q6600. I don't want to go into further detail about my reasoning as that would take this off thread.

Can anyone answer the cache question?

[akupenguin]

I have only one data point on the cache question, so take this with a grain of salt:
An Athlon64 w/ 1MB L2 cache is 5% faster per clock cycle than an Athlon64 w/ 512KB L2 cache when running x264.

[mroz]

:thanks:

A small data set indeed, but if cache size was the only difference it still seems potentially significant. Ta for the info.

Reminds me, I seem to recall reading elsewhere about the idea to bundle some performance analysis & reporting code with standard x264 builds. As I like stats that'd be a cool thing to see. I hope that idea gets off the ground. Must search for that thread.

Thanks again.

[Manao]

That would be : http://forum.doom9.org/showthread.php?p=1011128#post1011128

[mroz]

Ooh, lovely data :) Now I do want a quad.

Wasn't the thread I stumbled over before though - that talked of x264 incorporating code to gather stats automatically.

[Terranigma]

Update: x264 revision 659 by Cef (http://cef.neuf.fr/x264/) :)

[JarrettH]

rev 662

Add vertical and horizontal luma deblocking accelerated with Altivec,
based on Graham Booker's code written for FFmpeg with slight modifications
to re-use x264's macros

can anyone explain more about this change?

[Manao]

It speeds up the deblocking on power PC

[burfadel]

Altivec is the PowerPC (older Macintosh) version of SSE (thankyou Wikipedia!). Therefore it will provide no benefit for a x86/x64 based comptuer.

Here's the next question... is deblocking fully SSE/SSE2/SSE3/SSSE3 optimised? ...

[Manao]

For x86, it's mmx/isse only.
For x64, it's mmx/isse & sse2 only.

Deblocking will gain some speed with SSE2 on p4/conroe in x86, and with SSSE3 in both x86/x64. However, on the whole encoding process, that speed gain is negligible, especially when subme is high.

[JarrettH]

thanks, i've been looking for a reason to update from 656, guess that isn't it :p

[burfadel]

thanks, i've been looking for a reason to update from 656, guess that isn't it :p

Update to 661 though...!

Oh, and use cef's build, they're noticeably faster (several percent) on Core 2's anyway.

Plus he has the thread pool patch, aq patch etc so with the extra settings to can maximise the cpu use, leading to a little extra speed.

If someone knew what they were doing, they could update the x86 code to maximise the use of sse/sse2/sse3/ssse3, as there's many parts that aren't using the fastest implementation if available.

[rbt01]

how to use the C version instead of asm version of the module in codec?

I want to use the dct.c instead of the dct-a.asm.

[burfadel]

Here's a good question:...
Media Player Classic has the options to use pixel shaders, and you can select the pixel shader version through the editor. These do things such as sharpening etc.

I was wondering whether its possible to port it into x264, and have certain functions completed with the pixel shaders (preferable 3 or 4 due to their speed, but with the ability to select shader 2 on older cards)? I'm sure Gabest would be ok with that, as long as you get prior permission.

Even if you also have to port the (preferably) EVR mode (as this is the preferred mode in Vista for the future, and is available on XP through Net framework 3).

Is this at all possible? I realise it would require a bit of work, but at least there's a base to start from. This could give a very significant boost to encoding performance (in theory)...

[Inventive Software]

how to use the C version instead of asm version of the module in codec?

I want to use the dct.c instead of the dct-a.asm.

If you mean when you compile, I can't remember cause I've not done it in years, but if you mean when encoding, then add:
--no-asm
to the command line.

[Terranigma]

akupenguin, could you comment on what the change is for revision 665? I just seen a new version posted at x264.nl, but nothing of a changelog. Thanks in advance :)

[Bigmango]

akupenguin, could you comment on what the change is for revision 665? I just seen a new version posted at x264.nl, but nothing of a changelog. Thanks in advance :)

r665 | pengvado | 2007-07-13 01:48:23 +0200 (Fri, 13 Jul 2007) | 2 lines

extend zones to support (some) encoding parameters in addition to ratecontrol.