flag for diagonal interpolation
the primary reason for this change is that previously MC up to 1/4 pel
matched H.264 exactly and that increases the risk of stumbling over
patents
secondly this allows 0.10 db or more quality gain by choosing a longer
filter and the filter could also be chosen optimally for each frame
though that of course would cause speed loss at the decoder and encoder
side ...
Originally committed as revision 10436 to svn://svn.ffmpeg.org/ffmpeg/trunk
perform interpolation steps in such an order that halfpel interpolation
could be done per picture
this also makes mc_block() match h.264 for the 1/4 pel cases so that the
use of the h264 functions for some cases does not introduce a fantastic mess
Originally committed as revision 10433 to svn://svn.ffmpeg.org/ffmpeg/trunk
the old 32bit code)
disable mmx/sse2 optimizations as they need a rewrite now
Originally committed as revision 10218 to svn://svn.ffmpeg.org/ffmpeg/trunk
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