x264 v 1.0.0 ??

audyovydeo · 25th June 2010, 12:57

Hello

I've just noticed the latest changelog.

x264 now does BluRay, zero latency, error resilience, and a lot more, at a unique quality/speed ratio.

Does it not deserve a 1.0.0 as opposed to a 0.100.1659 ?

(incidentally, for r1658, lookaheadless == lookbehind)

cheers,
(tongue-in-cheek) audyovydeo

Atak_Snajpera · 25th June 2010, 14:09

As the matter of fact only last numbers are important for me

Warpman · 25th June 2010, 16:10

I'd like to quote Loren on that

Quote:

<pengvado> making an alpha product into final is easy
<pengvado> the hard part is adding features so that it stays alpha

Dark Shikari · 25th June 2010, 18:35

0.100 looks close enough to 1.00 for me!

burfadel · 26th June 2010, 00:25

Due to the nature of hte update cycle the current version numbering is ideal. Problem with releasing it as v1.00 is that people will thing that v1.00 is better over any later mintor revision, unless you call those v1.01, v1.10 etc. That would only create needless confusion.

Soichiro · 26th June 2010, 00:49

The devs could go with some complicated naming scheme like naming the current version 1.0.00, then a minor revision would lead to 1.0.01, then a big new feature or something would be 1.1.00, then if they just randomly decide, they can make x264 version 2.0... or they could stick with the current, simple revision-based scheme. x264 will most likely never stop being revised until H.264 itself becomes obsolete, so making a version 1.0 at an arbitrary point in time doesn't really make sense.

Midzuki · 26th June 2010, 01:19

IF POSSIBLE, I'd like to see a "definitive" and "perfect" version of x264

but I already know that...

not only AVC is an extremely-complicated subject,
but also, and worse, the H264 (and the Blu-Ray) specs were NOT written during a "minimally-sane" state-of-mind.

So I'd rather keep assuming the x264 team will always be much-more qualified than wannabe pseudo-nerds like myself.

kypec · 26th June 2010, 06:03

I hope they won't change revision numbering anytime soon.
It's simple yet perfect as it is now:
Developer asks "what revision of x264 are you using?"
User replies "rXXXX"
Developer suggests "please use newer/most recent revision i.e. the one having HIGHEST rYYYY number"
and the last reply applies forever

Maccara · 26th June 2010, 08:05

Quote:

Originally Posted by burfadel

Problem with releasing it as v1.00 is that people will thing that v1.00 is better over any later mintor revision, unless you call those v1.01, v1.10 etc.

Oo! Can we get v1.1 and later v1.10 so we can have the endless confusion of v1.1 < v1.10 when people don't realize version numbers != decimal numbers (i.e. they mean whatever the devs choose them to mean).

(it's even funnier when people start to argue with the devs about that

)

burfadel · 26th June 2010, 11:33

Yeah exactly! Whats the difference between using the current system and calling it rev 1659, or calling it 16.59 or 1.659? Absolutely none! If x264 was only updated every few months like normal software, then a more common versioning system may be possible (but not necessary).

LoRd_MuldeR · 26th June 2010, 11:56

If the x264 developers did maintain various branches and/or had planned milestones, it would make sense to have different version numbers. Like 1.x is the "previous" release series, 2.x is the current "stable" release series and 3.x is the upcoming "development" series. However that obviously isn't how x264 is developed. Instead they constantly improve and fix the "HEAD" branch like hell without looking back. And so far this has turned out to work perfectly fine for the project. So counting "only" revision numbers and API changes seems like the most reasonable approach here...

bob0r · 27th June 2010, 23:58

0.0000001659 pre-alpha.

Bi11 · 28th June 2010, 02:05

The only way I can see x264 v1.0.0 being realistically practical without "revision confusion" and the viral spread of old broken versions, is for x264 to somehow know it's old.

Either x264 itself can check for updates, or the "official x264 GUI" hosted on the "official x264 website" would check for updates.
If there is ever an "official x264 GUI" then x264 v1.0.0 would be fitting.

25th June 2010, 12:57	#1 \| Link
audyovydeo Registered User Join Date: Apr 2007 Posts: 464	x264 v 1.0.0 ?? Hello I've just noticed the latest changelog. x264 now does BluRay, zero latency, error resilience, and a lot more, at a unique quality/speed ratio. Does it not deserve a 1.0.0 as opposed to a 0.100.1659 ? (incidentally, for r1658, lookaheadless == lookbehind) cheers, (tongue-in-cheek) audyovydeo

25th June 2010, 14:09	#2 \| Link
Atak_Snajpera RipBot264 author Join Date: May 2006 Location: Poland Posts: 7,866	As the matter of fact only last numbers are important for me __________________ Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper

25th June 2010, 18:35	#4 \| Link
Dark Shikari x264 developer Join Date: Sep 2005 Posts: 8,666	0.100 looks close enough to 1.00 for me! __________________ Follow x264 development progress \| akupenguin quotes \| x264 git status ffmpeg and x264-related consulting/coding contracts \| Doom10

26th June 2010, 11:56	#11 \| Link
LoRd_MuldeR Software Developer Join Date: Jun 2005 Location: Last House on Slunk Street Posts: 13,249	If the x264 developers did maintain various branches and/or had planned milestones, it would make sense to have different version numbers. Like 1.x is the "previous" release series, 2.x is the current "stable" release series and 3.x is the upcoming "development" series. However that obviously isn't how x264 is developed. Instead they constantly improve and fix the "HEAD" branch like hell without looking back. And so far this has turned out to work perfectly fine for the project. So counting "only" revision numbers and API changes seems like the most reasonable approach here... __________________ Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 28th June 2010 at 21:56.

26th June 2010, 00:25	#5 \| Link
burfadel Registered User Join Date: Aug 2006 Posts: 2,229	Due to the nature of hte update cycle the current version numbering is ideal. Problem with releasing it as v1.00 is that people will thing that v1.00 is better over any later mintor revision, unless you call those v1.01, v1.10 etc. That would only create needless confusion.

26th June 2010, 00:49	#6 \| Link
Soichiro Registered User Join Date: May 2007 Posts: 75	The devs could go with some complicated naming scheme like naming the current version 1.0.00, then a minor revision would lead to 1.0.01, then a big new feature or something would be 1.1.00, then if they just randomly decide, they can make x264 version 2.0... or they could stick with the current, simple revision-based scheme. x264 will most likely never stop being revised until H.264 itself becomes obsolete, so making a version 1.0 at an arbitrary point in time doesn't really make sense.

26th June 2010, 01:19	#7 \| Link
Midzuki Unavailable Join Date: Mar 2009 Location: offline Posts: 1,480	IF POSSIBLE, I'd like to see a "definitive" and "perfect" version of x264 but I already know that... not only AVC is an extremely-complicated subject, but also, and worse, the H264 (and the Blu-Ray) specs were NOT written during a "minimally-sane" state-of-mind. So I'd rather keep assuming the x264 team will always be much-more qualified than wannabe pseudo-nerds like myself.

26th June 2010, 06:03	#8 \| Link
kypec User of free A/V tools Join Date: Jul 2006 Location: SK Posts: 826	I hope they won't change revision numbering anytime soon. It's simple yet perfect as it is now: Developer asks "what revision of x264 are you using?" User replies "rXXXX" Developer suggests "please use newer/most recent revision i.e. the one having HIGHEST rYYYY number" and the last reply applies forever

26th June 2010, 11:33	#10 \| Link
burfadel Registered User Join Date: Aug 2006 Posts: 2,229	Yeah exactly! Whats the difference between using the current system and calling it rev 1659, or calling it 16.59 or 1.659? Absolutely none! If x264 was only updated every few months like normal software, then a more common versioning system may be possible (but not necessary).

27th June 2010, 23:58	#12 \| Link
bob0r Pain and suffering Join Date: Jul 2002 Posts: 1,337	0.0000001659 pre-alpha.

28th June 2010, 02:05	#13 \| Link
Bi11 Architect Join Date: May 2010 Posts: 57	The only way I can see x264 v1.0.0 being realistically practical without "revision confusion" and the viral spread of old broken versions, is for x264 to somehow know it's old. Either x264 itself can check for updates, or the "official x264 GUI" hosted on the "official x264 website" would check for updates. If there is ever an "official x264 GUI" then x264 v1.0.0 would be fitting.