x264 Development Progress Thread

[DeathTheSheep]

...omgholybullfrog. All that time and it was alignment.

Mkay, it's encoding. Slow and steady. Now with 100% more asm. ;)

[edit]I sure hope that 256 multiplier is in the right place. Is it?

[Dark Shikari]

...omgholybullfrog. All that time and it was alignment.

Mkay, it's encoding. Slow and steady. Now with 100% more asm. ;)

[edit]I sure hope that 256 multiplier is in the right place. Is it?Yes it is.

[DeathTheSheep]

Sweet!! 1.51fps, exactly 50% slower than without! I couldn't have done it without you. Obviously. A nice birthday present indeed. :)

Now I should just make it optional, and then release it as part of my diff package (0.46, me-pre2, etc)...?

Hm, reminiscent of RCRD, the slowdown of 50% applies to an insane encoding, but it produces a much more significant relative speed impact when non-insane options are used. 2.5fps with fast options (>95% slowdown) vs 1.51fps (50% slowdown). Intriguing.

You said there was more hope for speedup? I hope you meant *before* it's limited to trellis/CABAC-only. :)

[Dark Shikari]

Sweet!! 1.51fps, exactly 50% slower than without!You better not try QNS 2 (--trellis 2) then ;)

[Blue_MiSfit]

I just want to say thank you to everyone for their hard work developing x264. The open source video encoding world has been _literally_ transformed in the last few years because of your efforts.

We've got a codec that dominates the (very expensive) competition, and doesn't cost a thing.

It never ceases to amaze me, especially when "big" things happen, like dark_shikari's AQ.

Thank you all!!

~MiSfit

[bob0r]

Except for your signature, i agree! :D

And who knows what Google's summer of code will bring us.
But to be completely honest, i love x264 the way it is now, just perfect for my setup :)

[Rodger]

I want a 64bit Version!!! :p
Still no chance to see a 64bit compiled build in the near future?:confused:

Saw in another thread there would be problems with 64bit?!

[burfadel]

I've got an enquiry about --merange, something which I've noticed which I'm not so sure about!

I did some tests with merange set to 16 and 32, with some strange results. Its probably coincidence but every encode with merange set to 32 was faster, although the difference was mostly less the 0.1 fps so thats within a tolerable error level.

The main point is the output was quite literally bit identical for several clips I tried. I'm not talking about just filesize, I'm referring to using the fc command from the command prompt (that is, no differences encountered). This was using the standard rev 826 build from www.x264.nl

Is this normal for everything to be bit identical like that? How come merange of 32 seems fractionally faster? (as I said this could be just coincidence since its slight).

[DeathTheSheep]

If you're using something like dia or hex, which are range-independent, it doesn't matter what you set merange to, there will be no difference. If you use umh or esa you will find that upping it does indeed slow you down.

[Dark Shikari]

If you're using something like dia or hex, which are range-independent, it doesn't matter what you set merange to, there will be no difference. If you use umh or esa you will find that upping it does indeed slow you down.merange is used for DIA/HEX; its just clipped to [4,16].

[DeathTheSheep]

Yup, so raising it to, say, 32+ wouldn't be at all different from just leaving it alone, as in burfadel's case (if I read correctly). Though why you'd want to lower it to 4 in the first place...is another story (unless you really want the speed?). :)

Oh, isn't the merange adaptive? So if UMH thinks something's just out of reach it will nab at it anyway, correct?

[akupenguin]

Oh, isn't the merange adaptive? So if UMH thinks something's just out of reach it will nab at it anyway, correct?
UMH's range is adaptive, but it adapts proportionally, i.e. multiplies merange by some heuristic. "just out of reach" is ascribing way too much intelligence. It just takes a wild guess at the typical mv size before searching.
I want a 64bit Version!!!
Still no chance to see a 64bit compiled build in the near future?
Whenever you implement it. Unless you fancy Linux or OSX; those can use the 64bit version right now.

[burfadel]

ah ok! that makes sense then :)

[Rodger]

Whenever you implement it. Unless you fancy Linux or OSX; those can use the 64bit version right now.

I don´t get that...I thought x264 is free from plattform-restrictions.
Available for any plattform. That was the main intention to get rid of vfw ect.
What I understood now off your posting, that this thinking is somehow wrong.

There is a 64bit version available, but for any system, but Windows?
Any acknowledgements from this 64bit version? is it faster?

If I knew how to help you guys I would have years from now ;)

By the way "DeathTheSheep" does a rockin´ job! Last time I checked the vfw-version was competitive to the cli-version.

So it will take some more time to implement the 64bit code, huh?
hmmpf :(

[Dark Shikari]

I don´t get that...I thought x264 is free from plattform-restrictions.
Available for any plattform. That was the main intention to get rid of vfw ect.
What I understood now off your posting, that this thinking is somehow wrong.

There is a 64bit version available, but for any system, but Windows?
Any acknowledgements from this 64bit version? is it faster?Pengvado routinely breaks Windows 64-bit builds when hacking the assembly, since Windows has a slightly different calling convention from Linux on 64-bit, IIRC.

64-bit is about 10-15% faster, I believe.

[akupenguin]

I don´t get that...I thought x264 is free from plattform-restrictions.
Assembly is inherently platform specific. Windows chose to do everything differently, so it gets to be not supported. I don't code for OSX either, but it's much less different, and thus doesn't require constant maintenance.

btw, does anyone know what exactly would happen if we omitted the official stack frame and unwind metadata, and just treated it like linux except with different register allocation? Stack unwinding only pertains to exceptions, so that stuff shouldn't even be used unless the program has already crashed.

[Rodger]

Thanks for the information! Didn´t know the code-handling was that different.


64-bit is about 10-15% faster, I believe.

GOOD GOD!:eek:
I was hoping for a bit more than 5% and now it´s more like 10-15%.
Now THAT IS good news.

Makes me wanna habe a 64bit-version eben more ;)

So if you guys need a beta-tester for a 64bit build...just drop me a line.

[Avenger007]

Any word on when another patching spree will be unleashed? :)
Also, any rough estimates on speed and quality improvements we can expect to see in the near future, like weeks from now and then a few months from now?
Final question, should I encode with the stable 839 version or wait until after the patching spree?

:thanks: to all x264 developers!

[Dark Shikari]

Any word on when another patching spree will be unleashed? :)
Also, any rough estimates on speed and quality improvements we can expect to see in the near future, like weeks from now and then a few months from now?
Final question, should I encode with the stable 839 version or wait until after the patching spree?

:thanks: to all x264 developers!Encode with the stable 839 version; there's some speed improvements in the pipe, but all major stuff is saved for the summer.

I've been busy the past 2-3 days writing Photon, my own custom codec (mostly for the purpose of learning how to do so).

[plonk420]

horrible horrible question to ask a developer, i know, but any ideas as to ETA for an x264-like binary (or binary-building-ready code)? this sounds really really exciting for whatever reason... i wish i knew enough to code and/or build myself, but i only know enough to fix PHP scripts that won't load on my site... :(

[Adub]

What are you talking about? Just compile the binary yourself from the source code. Or am I misunderstanding your definition of binary.

[plonk420]

i pretty much don't know how to compile. my several attempts have ended in massive failure :/

(i'm an encoder enthusist and wannabe graphic designer, not a coder!)

[jeffy]

i pretty much don't know how to compile. my several attempts have ended in massive failure :/

(i'm an encoder enthusist and wannabe graphic designer, not a coder!)

What platform are you trying to compile the binary on and why, if you just need the x264 binary, don't you download it?

[plonk420]

i haven't tried compiling this and don't really have a desire to. i've tried compiling a program or two of DVD Jon's and something else i can't remember on x86, none of which succeeded. and i'm not asking for x264, i'm selfishly asking for Photon. i guess i'll shut up now and try my best to be patient :S

[Dark Shikari]

i'm not asking for x264, i'm selfishly asking for Photon.Wait, what? You want to use a totally custom intra-only highly inefficient codec with no asm whatsoever, whose latest version exists only on my computer? :p

[plonk420]

it's the idea of new technology that fascinates me, good sir! hell.. the only thing i encode in anymore is MPEG-2 and AVC :P so a happy medium between the two sounds like an interesting prospect :O

[Dark Shikari]

it's the idea of new technology that fascinates me, good sir! hell.. the only thing i encode in anymore is MPEG-2 and AVC :P so a happy medium between the two sounds like an interesting prospect :OMPEG-2 is still more efficient than Photon, given that Photon is intra-only and doesn't use custom VLCs ;)

[Inventive Software]

Wait, what? You want to use a totally custom intra-only highly inefficient codec with no asm whatsoever, whose latest version exists only on my computer? :p

Consider yourself popular! :D

[squid_80]

btw, does anyone know what exactly would happen if we omitted the official stack frame and unwind metadata, and just treated it like linux except with different register allocation? Stack unwinding only pertains to exceptions, so that stuff shouldn't even be used unless the program has already crashed.

If there's no unwind metadata and an exception is thrown (i.e. a crash, unless you're crazy enough to code throwing exceptions in asm) the app simply *poof* vanishes. No crash dialog, no offer to report it to MS. Not really a big deal with x264.exe, but when libx264 is used inside something else (ffdshow for example) it's not very polite to bring down the host app (which may be able to catch properly thrown exceptions) when you make a mistake.

(One other difference I remember between the linux/windows 64-bit code; on windows it is NEVER safe to write beyond the stack pointer.)

[plonk420]

MPEG-2 is still more efficient than Photon, given that Photon is intra-only and doesn't use custom VLCs ;)

at least it's something NEW to try out..! >_>

[akupenguin]

If there's no unwind metadata and an exception is thrown (i.e. a crash, unless you're crazy enough to code throwing exceptions in asm) the app simply *poof* vanishes
Sounds fine to me. Now all we need is a way to mix win64 and linux64 abis in the same lib, and we can get away with no new asm.

[Kurtnoise]

DS, can we have an update to your table in your 1st post with the last infos/news ?

I'm particularly interested by the GPGPU challenge...;)

[professor_desty_nova]

Can we have an update of the table with the latest info?;)
And how is progress going in the "Google Summer of Code Projects"?

[Ranguvar]

I've recently switched to XP x64, 'twould be awesome if x264 worked in 64-bit for the Windows platform as well :)

[cyberbeing]

Since that other thread got locked, I guess I should post this here since it never got answered.

On that note, something that may be interesting would be fully tweakable presets for rate-control to better suit the types of frames where you want quality to be and have the ability to give things different weights of importance (dark areas, light areas, medium areas, detailed areas, flat areas, gradients, fades, fast moving scenes, slow moving scenes etc). I think AQ and PsyRD does some of this in a generalized fashion, but a streamlined and specialized weight based rate control, based on different frame characteristics would be interesting. It would give a level of control beyond what we have today.

How feasible would it be to implement something like this? Anybody interested in trying to make a patch?

It would definitely have its uses if it doesn't slow down encoding too much, but ease of use would be another factor. For that reason the current rate control should still always be kept as the default if this gets added.

[Sagekilla]

Hey Dark Shikari, is there any hope of any progress on the RCRD patch, or even an improvement on the existing RC through usage of RCRD concepts?

[Dark Shikari]

Hey Dark Shikari, is there any hope of any progress on the RCRD patch, or even an improvement on the existing RC through usage of RCRD concepts?Well, I've managed to port it up to the most recent revisions ;)

The main problem with using RCRD concepts to improve regular ratecontrol is that its rather difficult to calculate the optimal lamba to use--there's really no obvious way of knowing.

MBtree would achieve a good portion of what RCRD does, and on a macroblock level, without the lambda issues or the speed penalty.

[Sagekilla]

Ah, you mean this: Macroblock Trees GSOC (http://wiki.videolan.org/SoC_2008/x264/Macroblock_tree). Nifty, this always sounded like something that could make -big- difference in video output, since temporally important frames/MBs could be given a quality boost compared to frames/MBs that show up maybe only once.

[Sagekilla]

Hrm, I read your dev blog and you say you have nehalem specific optimizations: Is it too much to give away to say that x264 would run vastly better on a quad core nehalem vs quad core penryn at the same clock speeds?

Edit: Sorry about the double post, I'm rather excited about these recent changes ;)

[nurbs]

Nehalem would be faster even without further optimizations: http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3326&p=6

[Dark Shikari]

Original post updated on request.

[video_magic]

My archiving of VHS -> x264 has been very pleasing so far, at bitrates of around 1200 for 720x576 25fps captures.

As I am capturing using a BT878a based card I have many captures in YUY2, I was wondering about YUY2 support in x264 as I read here:

http://wiki.videolan.org/SoC_x264#4:4:4_and_4:2:2_color_support

It would save any further (lossy?) conversion from my captures, and I don't know how much encoding-time it might save, because of the converttoyv12 in my avs?

Anyway, thanks, I appreciate everything about this amazingly good codec. I suppose version r1000 is being held off for numerous improvements...

[akupenguin]

Save? Converttoyv12 throws away information, and therefore makes the encoding process faster as it doesn't have to encode that information. You could ask for 4:2:2 if you think your VHS actually contain 360x576 pixels worth of real chroma (hah) and think keeping that is worth the cost of 33% more pixels.

[video_magic]

....Converttoyv12 throws away information, and therefore makes the encoding process faster as it doesn't have to encode that information.....

Ah ok, thanks for that information! :thanks:

So converting to YV12, from YUY2 is 'visually lossless' or effectively so (negligible loss) to any reasonable person?

[Sagekilla]

Well, YUY2 vs YV12 has some minor loss in color resolution, but unless you're doing chroma keying (even then there's tricks to mask artifacts) 99% of all people will not notice a difference.

The thing akupenguin was trying to get at is that a 720x576 cap from VHS has no where near that much chroma resolution. They have so little resolution that the difference between YUY2 and YV12 is negligible.

[professor_desty_nova]

I figure we should have a thread like this so that people can see the general status of x264 development.

http://i36.tinypic.com/11qqpsn.png
Updated October 19th, 2008.


I think this needs an update :D