Log in

View Full Version : Is it safe to use x264 r2692?


pepelugil
15th May 2016, 09:57
Hi,

I use Komisar x264 builds and his last build is r2692, but in videolan I see that last version is r2694.

Can I use r2692 without facing any problem or does r2694 solve any problem I couls get if I encode using r2692?

Thanks

Sparktank
15th May 2016, 10:39
on VideoHelp.com (mirror site for binaries), it lists a short changelog between 2692 and 2694.

http://www.videohelp.com/software/x264-Encoder
16 hours agoClean up header includes master
commit | commitdiff | tree
Anton Mitrofanov [Wed, 13 Apr 2016 18:54:25 +0000 (21:54 +0300)]
Clean up header includes

16 hours agoEliminate some compiler warnings on BSD
commit | commitdiff | tree
Henrik Gramner [Wed, 13 Apr 2016 15:53:49 +0000 (17:53 +0200)]
Eliminate some compiler warnings on BSD

Include <strings.h> in addition to <string.h>. According to the POSIX
specification the prototypes for strcasecmp() and strncasecmp() are
declared in <strings.h>. On some systems they are also declared in
<string.h> for compatibility reasons but we shouldn't rely on that.

Define _POSIX_C_SOURCE only when it's required to do so. Some BSD
variants doesn't declare certain function prototypes otherwise.

Probably not big deal, only if you plan on compiling yourself (on BSD).

Other than that, it won't hurt anything to still use 2692 over 2694.
The difference is mostly negligible for the typical end user. Any serious users would just compile themselves using the git and Komisar's patches.

Those updates should be included in the next major update for x264.

Stereodude
15th May 2016, 18:41
No, it's not safe to use r2692!!! I was using it and small black hole formed inside my PC and it consumed my encode and two DIMMs of memory and my CPU fan! I suppose it's better than r2525 which opened a portal to hell though. Thankfully I noticed that one before too many cacodemon's could come through, but the resulting mess was rather hard to explain to the wife.

Use at your own risk!!!

:D

pepelugil
16th May 2016, 08:39
Thanks, I didn't understand what these "Clean up header includes" could mean.

LoRd_MuldeR
16th May 2016, 13:06
Thanks, I didn't understand what these "Clean up header includes" could mean.

About including C/C++ header files:
https://en.wikipedia.org/wiki/Include_directive#C.2FC.2B.2B

So that commit is only about code clean-up, it shouldn't effect the resulting binary at all. And that's probably why Komisar didn't bother creating a new build.

(VideoLAN probably uses an automated build bot, so you'll get a "fresh" binary after each push, regardless of whether there are any relevant changes or not)

pepelugil
18th May 2016, 22:18
Perfect, lots of thanks, now everything is clear now. I've also done some tests and everything has been bug free.