Update libraries?

General questions or discussion about HandBrake, Video and/or audio transcoding, trends etc.
Locked
erenodlogin
Posts: 3
Joined: Wed Mar 11, 2009 7:02 am

Update libraries?

Post by erenodlogin »

How Update libraries in handbrake?

lame-398-2.tar.gz -> lame-398-2.tar.gz
faac-1.26.tar.gz -> faac-1.28.tar.gz
faad2-2.6.1.tar.gz -> faad2-2.7.tar.gz
libvorbis-aotuv_b5.tar.gz -> libvorbis-aotuv_b5.7.tar.bz2
libsamplerate-0.1.4.tar.gz -> libsamplerate-0.1.7.tar.gz
xvidcore-1.1.3.tar.gz -> xvidcore-1.2.1.tar.gz
x264-r1125-10d6ef0.tar.gz -> x264 r1127
dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Re: Update libraries?

Post by dynaflash »

speaking for x264, not sure what your trying to say, but I updated it here:
http://trac.handbrake.fr/changeset/2241
which was three days ago. so I guess we are guilty of being three whole days out of date.
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Re: Update libraries?

Post by s55 »

Libraries are updated when a developer takes interest / requires it.
erenodlogin
Posts: 3
Joined: Wed Mar 11, 2009 7:02 am

Re: Update libraries?

Post by erenodlogin »

the others libraries have a forecast to be updated?

8)
thank you.
nightstrm
Veteran User
Posts: 1887
Joined: Fri Mar 23, 2007 5:43 am

Re: Update libraries?

Post by nightstrm »

erenodlogin wrote:the others libraries have a forecast to be updated?

8)
thank you.
What specifically are you looking to gain from the updated libraries, other than "it's newer"?
erenodlogin
Posts: 3
Joined: Wed Mar 11, 2009 7:02 am

Re: Update libraries?

Post by erenodlogin »

CHANGES

lame Changelog 3.98 -> 3.98.2
  • Fix for Bugtracker item [ 2123206 ] lame 3.98.1 segfaults with -h
More fixes for the abx tool for Unix systems:
  • Plugged a memory leak.
  • Fixed an endianness problem: users of big-endian machines can now do abx tests.
  • Fixed history's HTML doctype
  • Fixed history so that it finally validates at W3's validator
  • Fixed compilation of frontend mp3rtp.c. Thanks to Kris Karas. Bugtracker item [ 2015432 ] mp3rtp missing uint16_t in lame 3.98
  • Fix for Bugtracker item [ 2031704 ] --id3v1-only didnt work in 3.98-final
  • Fix for Bugtracker item [ 2022035 ] encoder_padding value and resampling
  • Fix for Bugtracker item [ 2029282 ] Frequency filtering API broken in 3.98
  • Fix for Bugtracker item [ 2039648 ] potential memory leak in parse_args() function in parse.c
Fix for some tagging issues:
  • Made search for ID3v1 genres more sloppy, abbrevations may match more often as some simple typos. Examples:
  • --tg "Alt. Rock" matches genre "Alternate Rock"
  • --tg "acapela" matches genre "A Cappella"
  • New switch --pad-id3v2-size "n": adds ID3v2 tag with n padding bytes.

libvorbis-aotuv changelog b5 -> b5.7
  • The noise control of the Impulse block was expanded. This is effective with the outstanding sample of the pre-echo.
  • The pre-echo reduction code came to work at a lower bit rate.
  • Noise Normalization was reviewed. As a result, the bug is revised.
  • The detailed tuning was done again.
  • (Important!) The security hole of old libvorbis origin was fixed like latest libvorbis. The software using the decode function of the former library should be updated to the latest library. This problem does not influence the encode function.
  • Reduced distortion by clipping at low sampling frequency and/or low bitrate.
  • Fixed noise control part of impulse block added in the beta5.5.
  • Tuning of each part was redone according to above-mentioned changed part.
  • Fixed the error to occur by specific software.
  • Improvement of the encoding speed of low bitrate mode. (Around 11% at the max)
  • Fixed some bugs.

libsamplerate changelog 0.1.4 -> 0.1.7
  • Optimisation resulting in dramatic throughput improvements.
  • Minor bug fix in test suite (account for rounding error on x86_64).
  • Fix a segfault bug. Fix compilation under MSVC.

xvidcore changelog 1.1.3 -> 1.2.1
  • Fix for 'nested function' potential compilation error.
  • WIN64 fix: Properly treat xmm6/xmm7 registers as non-volatile on WIN64.
  • Added test for WIN64 xmm6/xmm7 preservation to xvid_bench.
  • This release is Xvid 1.2.1 bugfix release. It is API compatible with the previous 1.2.0 stable release.
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Re: Update libraries?

Post by s55 »

Ok, was there a point to that post?

As I said above:
Libraries are updated when a developer takes interest / requires it.
User avatar
JohnAStebbins
HandBrake Team
Posts: 5712
Joined: Sat Feb 09, 2008 7:21 pm

Re: Update libraries?

Post by JohnAStebbins »

More to the point, have you experienced any of the bugs (while using handbrake) that have been fixed in these updates? If not, we would just be trading a set of known problems that seem to not affect anyone for a new set of completely unknown problems.
Dukers
Posts: 43
Joined: Sat Jun 27, 2009 1:39 am

Re: Update libraries?

Post by Dukers »

Up

At least at libsamplerate you devs could take a look. According to src's history (link), libsamplerate version 0.1.5 and newer (current Handbrake trunk code uses 0.1.4) has "dramatic throughput improvements" (sic) (info here). I have no tech skills to do that kind of work with source code, but I think an update will help to increase Handbrake speed when resampling.
rhester
Veteran User
Posts: 2888
Joined: Tue Apr 18, 2006 10:24 pm

Re: Update libraries?

Post by rhester »

Given that is about 0.1% of the total CPU used by HandBrake during H.264/AAC encoding...anyone would care why?

Rodney
TedJ
Veteran User
Posts: 5388
Joined: Wed Feb 20, 2008 11:25 pm

Re: Update libraries?

Post by TedJ »

rhester wrote:Given that is about 0.1% of the total CPU used by HandBrake during H.264/AAC encoding...anyone would care why?
You're forgetting those idiots who try encoding on their Atom based netbooks. :P
Dukers
Posts: 43
Joined: Sat Jun 27, 2009 1:39 am

Re: Update libraries?

Post by Dukers »

rhester wrote:Given that is about 0.1% of the total CPU used by HandBrake during H.264/AAC encoding...anyone would care why?

Rodney
I really don't know what is the amount of total CPU use. But even with 0.1%, "dramatic throughput improvements" can give us improvments, like a total CPU use of 0.05%. The number itself maybe not be shocking, but the percentage is significative.
Deleted User 11865

Re: Update libraries?

Post by Deleted User 11865 »

TedJ wrote:
rhester wrote:Given that is about 0.1% of the total CPU used by HandBrake during H.264/AAC encoding...anyone would care why?
You're forgetting those idiots who try encoding on their Atom based netbooks. :P
And HandBrake for iPhone :-)
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Re: Update libraries?

Post by s55 »

aw geez, I guess I'll say it again. :roll:

One more time now everyone, "Libraries are updated when a developer takes interest / requires it."

"dramatic throughput improvements" can give us improvments,
Not necessarily. We are not currently throughput limited on it, so it really isn't a problem. It won't even make a minor difference to encoding.
It'll get updated when it needs to be updated, or we are doing a batch of updates anyway and it's easy to throw it in there.

This is getting locked now. Continual prodding is not helpful. We monitor 3rd party libraries. We are in direct communication with some of them. Libraries will get updated, when it suits us to do so. The story ends.
Locked