PSNR/bitrate is slightly better for my (short) test videos
more tests welcome ...
Originally committed as revision 6876 to svn://svn.ffmpeg.org/ffmpeg/trunk
Here's the description I'll add to the mplayer man page:
---
Causes frames with higher quantizers to be more likely to trigger a
scene change detection and make libavcodec use an I-frame (default: 1).
1-16 is a sane range.
Values between 2 and 6 may yield increasing PSNR (up to approximately
0.04 dB) and better placement of I-frames in high-motion scenes.
Higher values than 6 may give very slightly better PSNR (approximately
0.01 dB more than sc_factor=6), but noticably worse visual quality.
---
Original idea from Michael; patch by me.
Originally committed as revision 4883 to svn://svn.ffmpeg.org/ffmpeg/trunk
anyway, this change decreases bitrate and increase PSNR by ~1.00 on my test file, other files also benefit significantly
Originally committed as revision 4771 to svn://svn.ffmpeg.org/ffmpeg/trunk
different intra block coding (previous was just an ugly hack)
1.8% bitrate reduction -0.01PSNR (foreman@352x288 qscale=8)
1.5% bitrate reduction +0.05PSNR (foreman@352x288 qscale=1)
Originally committed as revision 3416 to svn://svn.ffmpeg.org/ffmpeg/trunk
wavelet based compare functions
make epzs_motion_search() more flexible so it can be used for a wider range of block sizes
make get_penalty_factor() independant of MpegEncContext
Originally committed as revision 3410 to svn://svn.ffmpeg.org/ffmpeg/trunk
be somewhat more tollerant on invalid input
return INT_MAX instead of -1 for unuseable mv/mb types as that ensures nicely that they arent used
initalize limits earlier for b frames
a few more asserts to check for out of picture vectors
Originally committed as revision 3213 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
currently works only with mpeg1/2 source or some luck
may need -sync 0 as otherwise framedrops could lead to extreemly long b frame sequences
Originally committed as revision 3042 to svn://svn.ffmpeg.org/ffmpeg/trunk
replace ugly macros by always_inline functions, that way its much more readable and flexible as always_inline can simply be removed while the macros couldnt be
about 0.5 % speedup with default parameters
Originally committed as revision 3037 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
bug was introduced in version 1.75 (2003-12-30)
this may have lead to a small drop in quality of the 4mv mode, but should have only affected the mbd=0 case
Originally committed as revision 2698 to svn://svn.ffmpeg.org/ffmpeg/trunk
