through lrintf(), that is gcc put the 32bit int flags in a 32bit float
which caused some to be lost ...).
I wonder why FATE did not pick this up?
Originally committed as revision 12329 to svn://svn.ffmpeg.org/ffmpeg/trunk
in block in adpcm-ima decoder
Patch by Timofei V. Bondarenko: tim £ ipi, ac, ru
Original thread: [FFmpeg-devel] [PATCH] adpcm-ima-wav header and codec
Date: 10/15/2007 05:55 PM
Originally committed as revision 10933 to svn://svn.ffmpeg.org/ffmpeg/trunk
these were wrong (in pts vs dts sense) when b frames were in use
they were also wrong if the average framerate was smaller than 1/timebase
resulting in totally wrong final bitrate
Originally committed as revision 10477 to svn://svn.ffmpeg.org/ffmpeg/trunk
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
Kostya Shishkov
Michael Niedermayer
Måns Rullgård
Benjamin Larsson
Timofei V. Bondarenko
Benoit Fouet
Diego Biurrun
Bill O'Shaughnessy
Michel Bardiaux
Allan Hsu
Baptiste Coudurier
Reimar Döffinger