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
values), so the comparison with vs_total_ac_bits is messed up on the
first couple loop iterations, leading to AC underflows.
the b->prev[] pointers were not being maintained correctly. We
potentially have to update b->prev[] both before and after the area
whose VLC length is getting adjusted.
this also might fix the ppc regression failure?
patch by (Dan Maas <dmaas maasdigital com>)
Originally committed as revision 5064 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
additionally compare the mp2 case with some delay as this matches better (the delay issue obviously should be fixed)
Originally committed as revision 3922 to svn://svn.ffmpeg.org/ffmpeg/trunk
"huffyuv" is compatible with the official version
"ffvhuff" contains our improvements
Originally committed as revision 3720 to svn://svn.ffmpeg.org/ffmpeg/trunk
-corrected wrong value in mv data
-set correct mb_type after adjusting index
-don't use H263 loop filter when the loop filter flag is set but when
using the H261 encoder
-use the same unquantizer as H263 (which is optimized btw)
-removed unused members in H261Context
patch by (Maarten Daniels <maarten.daniels >at< luc >dot< ac >dot< be>)
regression test checksum update by me
Originally committed as revision 3669 to svn://svn.ffmpeg.org/ffmpeg/trunk
finetune bit/distortion weighting factor used in motion estimation, the old coeffs where finetuned relative to incorrect mv_penalty tables which where then fixed later but the coeffs where not
this _may_ fix the long standing blocking artifacts, but may also introduce mudding artefacts theoretically, so please tell us if u stumble across any so we can either fix them or export this variable so the user can change it
Originally committed as revision 3189 to svn://svn.ffmpeg.org/ffmpeg/trunk
fixes the random dts/pts during encoding
asf preroll fix
no more initial zero frames for b frame encoding
mpeg-es dts during demuxing fixed
.ffm timestamp scale fixed, ffm is still broken though
Originally committed as revision 3168 to svn://svn.ffmpeg.org/ffmpeg/trunk
note, dont take the PSNR/stddev values serious, they are caused by a bug in ffmpeg.c which drops one frame before the last frame during encoding with b frames
Originally committed as revision 3110 to svn://svn.ffmpeg.org/ffmpeg/trunk
multithreaded/SMP encoding for MPEG1/MPEG2/MPEG4/H263
all pthread specific code is in pthread.c
to try it, run configure --enable-pthreads and ffmpeg ... -threads <num>
the internal thread API is a simple AVCodecContext.execute() callback which executes a given function pointer with different arguments and returns after finishing all, that way no mutexes or other thread-mess is needed outside pthread.c
Originally committed as revision 2772 to svn://svn.ffmpeg.org/ffmpeg/trunk
function moved to dspcontext
mmx&mmx2 optimized
change SSE -> SAD as default (better quality)
vbv buffer size command line option in kbyte
Originally committed as revision 2669 to svn://svn.ffmpeg.org/ffmpeg/trunk
interlaced mpeg2 encoding
P & B frames
rate distored interlaced mb decission
alternate scantable support
4mv encoding fixes (thats also why the regression tests change)
passing height to most dsp functions
interlaced mpeg4 encoding (no direct mode MBs yet)
various related cleanups
disabled old motion estimaton algorithms (log, full, ...) they will either be fixed or removed
Originally committed as revision 2638 to svn://svn.ffmpeg.org/ffmpeg/trunk
