This allows some simplifications and optimizations and should
not have any effect on quality.
Originally committed as revision 10172 to svn://svn.ffmpeg.org/ffmpeg/trunk
how did i succeed doing such a ridiculously silly thing? well i think it happened like:
1. verifying that the regression tests pass with old resample2.c
2. updating the regressions to the new resample2.c ... failed svn complained
3. svn up
4. updating the regressions to the new resample2.c success (r8485)
at that point everything was still ok
5. some more resample2.c work update regressions, read diff, commit (r8486)
my misstake was that the svn up at point 3 was run in tests/ -> iam an idiot
Originally committed as revision 8489 to svn://svn.ffmpeg.org/ffmpeg/trunk
bring AC3 encoder output up to input volume level
patch by Bill O'Shaughnessy % bill P oshaughnessy A gmail.com %
+ reg tests update gruntwork by me
Original thread:
date: Nov 21, 2006 11:36PM
subject: [Ffmpeg-devel] Simpler Patch to bring AC3 encoder output up to input level
Originally committed as revision 8444 to svn://svn.ffmpeg.org/ffmpeg/trunk
====
Author: michael
Date: Mon Mar 5 03:41:49 2007
New Revision: 8240
Modified:
trunk/libavformat/asf-enc.c
Log:
create codec_comment_header which looks more like what M$ creates, sane or not ...
Originally committed as revision 8260 to svn://svn.ffmpeg.org/ffmpeg/trunk
(using .asf as our .ogg muxer depends on libogg, nut muxer depends on libnut and vorbis in avi/mpeg is not really a good idea)
Originally committed as revision 7874 to svn://svn.ffmpeg.org/ffmpeg/trunk
this makes frames a few bytes smaller (0.1% for high bitrate but >1% for low bitrates)
Originally committed as revision 7401 to svn://svn.ffmpeg.org/ffmpeg/trunk
some PSNR/bitrate gain if adaptive quant is used
initalize qscale_table correctly (it was pretty much random since the qp->lambda change)
this probably has not much effect as the table isnt used currently IIRC
Originally committed as revision 7342 to svn://svn.ffmpeg.org/ffmpeg/trunk
this has pretty much no quality or speed effect except very small random changes
Originally committed as revision 7202 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Bill O'Shaughnessy % bill P oshaughnessy A gmail.com %
+ reg tests update gruntwork by me
Original thread:
date: Nov 21, 2006 11:36 PM
subject: [Ffmpeg-devel] Simpler Patch to bring AC3 encoder output up to input level
Originally committed as revision 7160 to svn://svn.ffmpeg.org/ffmpeg/trunk
1) search for optimal rice parameters and partition order. i also
modified the stereo method estimation to use this to calculate estimated
bit count instead of using just the pure sums.
2) search for the best fixed prediction order
3) constant subframe mode (good for encoding silence)
Note that the regression test for the decoded wav file also changed.
This is due to FFmpeg's FLAC decoder truncating the file, which it did
before anyway...just at a different cutoff point. The generated FLAC
files are still 100% lossless.
With this update, FFmpeg's FLAC encoder has speed and compression
somewhere between "flac -1" and "flac -2". On my machine, it's about
15% faster than "flac -2", and about 10% slower than "flac -1". The
encoding parameters are identical to "flac -2" (fixed predictors, 1152
blocksize, partition order 0 to 3).
Originally committed as revision 5536 to svn://svn.ffmpeg.org/ffmpeg/trunk
Michael Niedermayer
Benoit Fouet
Diego Biurrun
Bill O'Shaughnessy
Michel Bardiaux
Måns Rullgård
Allan Hsu
Baptiste Coudurier
Reimar Döffinger
Roman Shaposhnik
David Conrad
Justin Ruggles
Loren Merritt