x264 x86 builds older than rev1416

[kenpachi]

Hi, I've been redirected here from the official http://x264.nl (http://x264.nl/x264/?dir=./32bit/8bit_depth). I'm searching for x264 x86 builds older than rev1416 not available on any mirror anymore. I bet someone might still have a collection of old revisions. If possible, share it with me, please. Would be much obliged.

[LoRd_MuldeR]

Hi, I've been redirected here from the official http://x264.nl (http://x264.nl/x264/?dir=./32bit/8bit_depth). I'm searching for x264 x86 builds older than rev1416 not available on any mirror anymore. I bet someone might still have a collection of old revisions. If possible, share it with me, please. Would be much obliged.

https://i.imgur.com/M6vz9nf.jpg?1

FWIW, here is x264 r614, 32-Bit only, built on Dec 23 2006:
https://www.sendspace.com/file/e2wgpe

And here is x264 r1074, 32-Bit + 64-Bit, built on Jan 8 2009:
https://www.sendspace.com/file/dp8l3n

[kenpachi]

"Sense of nostalgia"

:) Right? The reason I'm looking for those ancient builds is to have a possibility in the future to encode partially and merge without the need of re-encoding when dealing with old releases and different cuts. I've done it a few times. Demands much work, though.

[sneaker_ger]

That shouldn't require old versions.

[LoRd_MuldeR]

That shouldn't require old versions.

But it requires the "--stitchable" option for segmented encoding, which has not been available before r2342 (Fri May 31 17:01:29 2013).

[Andouille]

Here are some.
https://www.sendspace.com/file/a6xla3

[kenpachi]

Here are some.

Thanks :)

But it requires the "--stitchable" option for segmented encoding, which has not been available before r2342 (Fri May 31 17:01:29 2013).

Had managed it using e.g. r786. Cutting must be done at key-frames (I don't remember but I may have used DGAVCIndex), all parameters must be equal, merging was done with mkvmerge. If parameters are not equal or x264 revisions differ much, many problems may occur e.g. a new version of the decoder stops decoding properly.

[sneaker_ger]

But it requires the "--stitchable" option for segmented encoding
Not necessarily but speaking of --stitchable: it is actually quite complicated. Starting with r2229 (Sep 26, 2012) x264 tries to optimize headers (PPS pic_init_qp) in 2pass mode which makes it difficult to append encodes even when they were created with the very same revision. With --stitchable this is turned off. But there is no cli setting to match 2pass encodes that have been done with >=r2229 but without --stitchable. --stitchable is meant to be used on ALL parts, not a magic setting that can encode for arbitrary, already existing parts.
For high bitdepth pic_init_qp was changed in r1742 (Sep 30 2010) as well. It also changes with crf which is a problem when x264's custom debugging SEI is not present.

I don't know if there have been more changes than this but those should be the biggest hurdles when trying to match settings. So actually my "That shouldn't require old versions" isn't fully true. It should rather say "revisions older than r1742 can't help you". What would actually be required is a cli parameter to set pic_init_qp (and the user running a stream analyzer on the existing stream) or you do some trial and error to get it right.

[kenpachi]

Just bumping in case there's anyone else possessing old x264 builds. I'm searching for x264 x86 builds older than rev1416 not available on any mirror anymore. If possible, share it with me, please. Much appreciated.

[mariush]

Try Internet Archive, if you're lucky they copied executables as well as pages: https://web.archive.org/web/20070101000000*/http://mirror01.x264.nl

^ they have pages from as early as 2015 there.

Not sure if it helps, but maybe you could download old versions of x264vfw package from sourceforge : https://sourceforge.net/projects/x264vfw/files/x264vfw/

The oldest downloadable version seems to be based on revision 715

[Groucho2004]

Just bumping in case there's anyone else possessing old x264 builds. I'm searching for x264 x86 builds older than rev1416 not available on any mirror anymore. If possible, share it with me, please. Much appreciated.If you don't need MP4 output and/or ffms/lavf input I can build one for you.

[kenpachi]

Try Internet Archive

thanks, some executables are downloadable!

If you don't need MP4 output and/or ffms/lavf input I can build one for you.

It's not a matter of life and death, thanks Groucho2004

[mandarinka]

But it requires the "--stitchable" option for segmented encoding, which has not been available before r2342 (Fri May 31 17:01:29 2013).

I have been able to cut and append encodes without --stitchable fine. Maybe it's because I use .264 output, which repeats headers every keyframe, unlike mkv/mp4 output.

At one point around r1600-r1700 though, using just binary concacenation would start resulting in buggy mkv muxes (timecodes would go crazy, playback would be disrupted), so after that you had to do the appending via mkvmerge itself.

P.S.
If you are desperate and want to make cut/replace work with some old encode that wasn't encoded nicely like this, I think there was one trick that could force incompatible encodes to play together. Try giving --sps-id 1 parameter when encoding the new segments (or was it --sps-id 0? I forgot but I think you need non-zero number). This hack IIRC forced decoders to reset and that would make "incompatible" appended streams to decode properly. Or at least in ffmpeg.

[sneaker_ger]

Default sps/pps-id is 0. So it would seem like a good idea to increment that number for additional parts. But: this can confuse ffmpeg/LAV if you don't prepend the SPS/PPS to every GOP. Even if the SPS/PPS are otherwise 100% identical except the id! So by incrementing the ids you might end up shooting yourself in the foot. For mkv it is still safer to 100% match SPS/PPS including the ids.

[nevcairiel]

In MKV or MP4 you can just put multiple SPS/PPS into the file header and all should be fine - assuming the IDs are different of course.
In an AnnexB format (ie. raw h264 or in a header-less container like mpegts), you should repeat the SPS/PPS in every GOP anyway.

Otherwise sneaker_ger is correct. Sequential decoding from start to finish would likely work, but if you try to perform random access (ie. seeking) and the SPS/PPS isnt in the file header and not present in the GOP you seeked to, then it just won't be available, and decoding fails.