x264 Revision 1000 Party!

[chainring]

Wow! Congrats on the 1000th revision of x264. It has come such a long way, and following the progress has been truly exciting to see the improvements made. DS, you're a huge credit to the team and huge props to all other contributors. Of course, huge props to, what I consider to be, the father of x264.

[jeffy]

Just all the best to all the people involved in this little gem :)

[Lele-brz]

Thank everyone for this great piece of software and the help given in this forum all the time.

[DeathTheSheep]

This is awesome and well-deserved. I wish I could have been at the party though... :(

Congratulations all, and may we all reach even more milestones! :)

[audyovydeo]

Now all we need is an awesome open source decoder :D

Granted, CoreAVC isn't open source, but with sinking value of the U$Dollar, it's de facto freeware ... ;-)


re: x264 :
0.65.1016 ............ 1.0.016 ????

I'm not the only one here apparently who was somehow expecting a more radical version change on this occasion.


cheers
a/v

[Shinigami-Sama]

Can't compete against Sharktooth though :D

http://www.webalice.it/f.corriga/temp/P07-23-05_20.15.jpg

no...
thats exactly how I pictured him, only with more stubble

also lol at the insane view count
its always nice to see that :D

[LoRd_MuldeR]

Final some cake for me too. Haha :D

http://img253.imageshack.us/img253/4016/cakeue6.png

[Gabriel_Bouvigne]

Gej seems to find the x264 cake idea quite funny on the pic.

[CruNcher]

Congratulation for the 1000th release to all the Devs and Users involved over the years on x264 :)

[RaW]

Congratulations and biggest thanks for all what you done!!! Good Luck!!!

[parsifal]

Congrats for 1K revisions, guys! The reception you got by the DivX colleagues was also something quite refreshing to read about! My respects to them, too!

[UsedUser]

Congrats, and thanks for all the hard work, guys. Serious kickassed-ness

Full sub8x8 RD mode decision
Small speed penalty with p4x4 enabled, but significant quality gain at subme >= 6
...
I'm guessing this means it should be recommended now to leave all the partitions enabled?
Not if you want hardware support. I forget if its DXVA, PS3, PSP, or where the requirement originated, but p4x4 is disabled for compatibility.

[Dark Shikari]

Congrats, and thanks for all the hard work, guys. Serious kickassed-ness


Not if you want hardware support. I forget if its DXVA, PS3, PSP, or where the requirement originated, but p4x4 is disabled for compatibility.I have yet to find a single device that has any issues with p4x4.

[Atak_Snajpera]

http://i36.tinypic.com/5zjgnb.jpg

Good to see that somebody used one of my re-made logos :) BTW When we will see new website?

I have yet to find a single device that has any issues with p4x4.
p4x4 can be enabled. I haven't had any problems on PS3 or other blu-ray player. DXVA works as well.

[LoRd_MuldeR]

Hope that cake didn't taste like fish, as the logo indicates :D

[Atak_Snajpera]

Hope that cake didn't taste like fish, as the logo indicates
I see no fish :) Maybe after few beers my imagination will improve :)

[Adub]

Maybe this will help.

http://i34.photobucket.com/albums/d125/Merlin7777/5zjgnb.gif

[gizzin]

Dark, that picture of you makes me wanna punch you :). Also you shoulda came in with a divx sucks, x264 rules cake. And threw water ballons at them or pieces of pie at them. Cut it up in front of them, and then start throwing it at them.

[TL0]

Not if you want hardware support. I forget if its DXVA, PS3, PSP, or where the requirement originated, but p4x4 is disabled for compatibility.

Is this topic why p4x4 is disabled by default?

In a previous post in a thread somewhere, it was mentioned by akupenguin that x264 doesn't produce level compliant streams for level >3 if the p4x4 macroblock analysis is set.

http://forum.doom9.org/showthread.php?t=125734

[juGGaKNot]

Congratulations on r1000 and GL in the future.

[~bT~]

Congrats guys!

Thanks for the huge improvements and looking forward to more in the near future!

PS. Hope you guys haven't been offered contracts with DivX :p

[Sagekilla]

@TL0: You don't need to even worry since 99% of the time you won't need p4x4. It's disabled in the CLI's partitions by default because the speed vs compression gain is so tiny, since it's rarely used. Even in sequences where I had an absurdly huge number of small scale movements going on, it was rarely used.

[G_M_C]

Full sub8x8 RD mode decision
Small speed penalty with p4x4 enabled, but significant quality gain at subme >= 6

Its unfortunate that the majority of people have disabled the p4x4 partitions, since they thought they weren't beneficial quality wise. I'm guessing this means it should be recommended now to leave all the partitions enabled?


[...]
Not if you want hardware support. I forget if its DXVA, PS3, PSP, or where the requirement originated, but p4x4 is disabled for compatibility.

I have yet to find a single device that has any issues with p4x4.

@ DS:
I want to come back onto this subject. I'm recently encoding a lot of blu-rays (or compatible BD9's), and so i got interested in this subject. Better quality is allways good.

But when you say that you haven't found a device that has issues with P4x4, what do you mean? Cause "not having found a device that has issues with P4x4", isn't the same as "P4x4 is usable according to Blu-ray standards".

So i want to ask this: Are you shure that P4x4 is compatible with hardware (in other words: Is it compatible with Blu-ray standards) ?
I've just started an BD9-encode with --partitions all switched on. So I'll find out if it works anyway, but the question remains if it is acceptable according to BD standards.

[Dark Shikari]

So i want to ask this: Are you shure that P4x4 is compatible with hardware (in other words: Is it compatible with Blu-ray standards) ?The Blu-ray spec is not public, so I can't say for sure, but its surely allowed by Level 4.1 as a whole.

[G_M_C]

The Blu-ray spec is not public, so I can't say for sure, but its surely allowed by Level 4.1 as a whole.

Hmmmm ... That should also mean that it's acceptable in BD-standard (since BD-standard describes using L4.1 video) ....

If my "test-encode" works in my BD30, and gives the desired results (i.e. better quality), than i'll keep using the option. Thx for your answer :)

[G_M_C]

Hmmmm ... That should also mean that it's acceptable in BD-standard (since BD-standard describes using L4.1 video) ....

If my "test-encode" works in my BD30, and gives the desired results (i.e. better quality), than i'll keep using the option. Thx for your answer :)

Seems you are right DS (not that i doubted that), it works fine, player doesn't have any issues with --partitions all set on a Blu-ray. It looks like it achieves better quality too !

Am i right when i say that the clip seems to be more fine-detailed when using P4x4, or are my eyes just deceiving me ?

[Dark Shikari]

Am i right when i say that the clip seems to be more fine-detailed when using P4x4, or are my eyes just deceiving me ?Your eyes are probably deceiving you. It's not that useful*

*I haven't actually done any testing at bitrates as high as Blu-ray uses, so I can't say for sure.

[Atak_Snajpera]

Seems you are right DS (not that i doubted that), it works fine, player doesn't have any issues with --partitions all set on a Blu-ray. It looks like it achieves better quality too !
Wow :rolleyes: I knew that long time ago :)

[EuropeanMan]

Congrats to all involved...and many thanks.

[iNT]

I'm kind of late! But that cake is really epic!!

[Mc Onyx]

Congrats on the 1k revision, although somewhat late. Can't believe how much time has passed, I've started encoding with x264 rev. 40 and if i remember correctly at the time it didn't even have a two pass mode and look at it now, best AVC encoder available, hats off to anyone that contributed to the great encoder that is x264!

[burfadel]

I've started encoding with x264 rev. 40 and if i remember correctly at the time it didn't even have a two pass mode and look at it now, best AVC encoder available, hats off to anyone that contributed to the great encoder that is x264!

How does rev 1029 compare to rev 40 speed and quality wise? :D

(I know obviously superior, just out of interest)

[Sagekilla]

Oldest revision I can find on x264.nl dates back to.. revision 598, so you could use that as a point of reference at least ;)

[Audionut]

Oldest revision I can find on x264.nl dates back to.. revision 598, so you could use that as a point of reference at least ;)

http://forum.doom9.org/showthread.php?t=141352

[Inventive Software]

I've got ones going back to 1xx or 2xx days. ;)

[LoRd_MuldeR]

Oldest revision I can find on x264.nl dates back to.. revision 598, so you could use that as a point of reference at least ;)

Celtic Druid, whatever he may be doing now, has archived some pretty old versions too:
http://tirnanog.fate.jp/mirror/x264/

There is a CLI build of r544 and a VfW build of r459 ;)

[kemuri-_9]

the GIT repository seemingly has all the changes recorded from when x264 was still on SVN.
so if you really wanted, you could revert back to some really early revisions and play around with them.

just be sure to copy the latest version.sh
to the reverted directory so it has the revision number in the build.
(if version.sh exists when you go back that far)

i just tried and was able to make the following:
r300 w/ pthreads, avs, + gpac
r200 w/ avs
(no pthread support, incompatible with current gpac)
r196 w/ avs - ./configure has mingw32 support added
(w/ small configure fixes:
A. recognize mingw32 having avs support
B. remove debug symbols )

good luck getting any earlier ones to work for mingw (well r195 probably with more ./configure fixes)...
r196 available here (http://kemuri9.net/dev/x264/history/x264_r196.exe)

[LoRd_MuldeR]

x264 r196 -vs- x264 r1029
Uncompressed YUV source, 2-Pass @ 333 kbit/s, all settings available in x264 r196 maxed out.
x264_r196-vs-r1029.7z (http://www.mediafire.com/file/lumnwtye2bm/x264_r196-vs-r1029.7z)

Of course x264 r1029 clearly outperforms r196, but still r196 performs much better than I had expected...

[kemuri-_9]

*Edit*
major lie... got even revision 1 to compile (with just a small bit of work)
something I'll be working on for a bit is this 'history' (http://kemuri9.net/dev/x264/history/)
(i seem to have too much free time as of late... :rolleyes:)

[LoRd_MuldeR]

Interesting :D

I try to run r43, first revision with 2-pass support. It's hard to do any comparison before that feature was available. But I can't get it to work :(

My commandline is:
x264_r0043.exe --bframe 5 --cabac --ref 6 --bitrate 333 --pass 1 --stats "c:\wurst.stat" --analyse all --output "c:\test_r43.first.mp4" "c:\downloads\x264_git\sample.avs"

But it doesn't encode. It always prints the help screen. No error message. What am I missing? :confused:

[kemuri-_9]

none of the builds have GPAC (.mp4) support until r299 where the GPAC API was updated
(to what's used now, thus only why it starts working then, didn't want to have to play with reverting it to get support).
and none have AVS support until r161 either.
that's probably what's doing it.

YUV input and .h264 output only for r43 ;)
and that works for me

avs2yuv -raw -o some.yuv some.avs to get a .yuv of your .avs
and then mp4box for .h264 -> .mp4 needs (as usual)

[LoRd_MuldeR]

none of the builds have GPAC (.mp4) support until r299 where the GPAC API was updated (to what's used now, thus only why it starts working then).
and none have AVS support until r161 either.

I see ;)

[Sagekilla]

What was used pre r43 for input then?

[LoRd_MuldeR]

What was used pre r43 for input then?

Uncompressed YUV data, it seems.

[crypto]

@kemuri-_9
Thanks for the history compiles. Its great to see the improvements over the time.

[kemuri-_9]

What was used pre r43 for input then?

up until avis input in r161, it was strictly limited to raw YUV input.
then came y4m input (similar to yuv format, except with a header for fps, resolution, and SAR) with r484.
.yuv and .y4m are raw data formats, like raw RGB24, so they take up a good bit of space.

yuv input can be created easily with akupenguin's avs2yuv tool
which converts a .avs to a .yuv/.y4m (.yuv with -raw, .y4m without)
(i'm inferring it was made specifically for x264 use back then)
so if you want to try some of the really old builds, going to need that.

*edit*
i'll go ahead and supply avs2yuv on the page as well, for convenience.

[burfadel]

I think we're all grateful that development of x264 has continued, it must have seemed an overwhelming task to some extent at the beginning - but rewarding that it has been so successful.

[akupenguin]

it must have seemed an overwhelming task to some extent at the beginning
Not at all. The marginal improvement of quality per development effort was much greater.