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
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
performance impact is less than 1%.
Patch by Dan Maas (dmaas at maasdigital dot com)
Originally committed as revision 5070 to svn://svn.ffmpeg.org/ffmpeg/trunk
roman, dont hesitate to reverse this and solve it differntly if you want ...
Originally committed as revision 5053 to svn://svn.ffmpeg.org/ffmpeg/trunk
Note, if you think thats too harsh, look at the cvs history he has broken the regression tests many times and has not once
updated the checksums ...
regression test checksum change due to: movenc.c 1.46->1.47
"finally found what those >138 codes were... crappy compressed 5bit ascii. this gets them correctly, and adds setting track"
Originally committed as revision 4826 to svn://svn.ffmpeg.org/ffmpeg/trunk
dc coeff rounding fix
class=3 num of bits fix
do interlaced check & idct only if CODEC_FLAG_INTERLACED_DCT
Originally committed as revision 4542 to svn://svn.ffmpeg.org/ffmpeg/trunk
be fixed even without adding the feature. The output correctly uses 4
dummy values for the rematrixing flags in block-0, but the bit
allocation routine does not take these bits into account. From what I
can tell, there was a patch in 2003 that corrected the output to make it
DVD and spec compatible, but it didn't correct the bit allocation. It's
only 4 bits over the entire 6 blocks, so overflow errors would happen
rarely or never, but it's still worth fixing. So here is a fix.
patch by (Justin Ruggles {jruggle earthlink net)
Originally committed as revision 4179 to svn://svn.ffmpeg.org/ffmpeg/trunk
about 10% lower bitrate for -qscale 32 (forman & some music video)
worst case bitrate increase <0.1% (lossless or low qscale)
and now the bad news, even though this just adds a single subtraction and an if() into the medium sized unpack_coeffs() loop and the if() will only be false once per unpac_coeff() call, gcc produces 50% slower code, i didnt look at the generated asm yet, not sure if i want to ...
Originally committed as revision 4131 to svn://svn.ffmpeg.org/ffmpeg/trunk
this is needed as the quantization stepsize for each subband is also in this precission and insignificant changes to the wavelet like scaling its coefficients slightly differently would lead to wildly variing PSNR and bitrate
note, a encoder could also simply choose to leave the least significant bits of the quantization parameters zero which would give the exact previous behaviour except a y very tiny number of bits in the header
Originally committed as revision 4115 to svn://svn.ffmpeg.org/ffmpeg/trunk
