Update libraries?
-
- Posts: 3
- Joined: Wed Mar 11, 2009 7:02 am
Update libraries?
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
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
Re: Update libraries?
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.
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.
Re: Update libraries?
Libraries are updated when a developer takes interest / requires it.
-
- Posts: 3
- Joined: Wed Mar 11, 2009 7:02 am
Re: Update libraries?
the others libraries have a forecast to be updated?
thank you.
thank you.
Re: Update libraries?
What specifically are you looking to gain from the updated libraries, other than "it's newer"?erenodlogin wrote:the others libraries have a forecast to be updated?
thank you.
-
- Posts: 3
- Joined: Wed Mar 11, 2009 7:02 am
Re: Update libraries?
CHANGES
lame Changelog 3.98 -> 3.98.2
libvorbis-aotuv changelog b5 -> b5.7
libsamplerate changelog 0.1.4 -> 0.1.7
xvidcore changelog 1.1.3 -> 1.2.1
lame Changelog 3.98 -> 3.98.2
- Fix for Bugtracker item [ 2123206 ] lame 3.98.1 segfaults with -h
- 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
- 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.
Re: Update libraries?
Ok, was there a point to that post?
As I said above:
As I said above:
Libraries are updated when a developer takes interest / requires it.
- JohnAStebbins
- HandBrake Team
- Posts: 5723
- Joined: Sat Feb 09, 2008 7:21 pm
Re: Update libraries?
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.
Re: Update libraries?
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.
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.
Re: Update libraries?
Given that is about 0.1% of the total CPU used by HandBrake during H.264/AAC encoding...anyone would care why?
Rodney
Rodney
Re: Update libraries?
You're forgetting those idiots who try encoding on their Atom based netbooks.rhester wrote:Given that is about 0.1% of the total CPU used by HandBrake during H.264/AAC encoding...anyone would care why?
Re: Update libraries?
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.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
Re: Update libraries?
And HandBrake for iPhoneTedJ wrote:You're forgetting those idiots who try encoding on their Atom based netbooks.rhester wrote:Given that is about 0.1% of the total CPU used by HandBrake during H.264/AAC encoding...anyone would care why?
Re: Update libraries?
aw geez, I guess I'll say it again.
One more time now everyone, "Libraries are updated when a developer takes interest / requires it."
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.
One more time now everyone, "Libraries are updated when a developer takes interest / requires it."
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."dramatic throughput improvements" can give us improvments,
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.