Originally committed as revision 9468 to svn://svn.ffmpeg.org/ffmpeg/trunk

This gets rid of some recursion and simplifies the code.

Originally committed as revision 9255 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

Originally committed as revision 8486 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 8485 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

prevent audio packets from being fragmented, wmp mac doesnt seem to like that and microshitty also doesnt seem to ever fragment them

Originally committed as revision 8265 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

Originally committed as revision 7960 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7955 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7954 to svn://svn.ffmpeg.org/ffmpeg/trunk

disabling vorbis regression test for now, both encoder and decoder behave strange and have to be fixed

Originally committed as revision 7953 to svn://svn.ffmpeg.org/ffmpeg/trunk

dont set the keyframe flag for audio as microshitty doesnt do it and some things have problems with our asfs, maybe that has a positive effect?

Originally committed as revision 7952 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7951 to svn://svn.ffmpeg.org/ffmpeg/trunk

add a few asserts

Originally committed as revision 7903 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7879 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

Originally committed as revision 7865 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7519 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

in the onMetaData header. Patch by Allan Hsu <allan at counterpop dot net>.

Originally committed as revision 7382 to svn://svn.ffmpeg.org/ffmpeg/trunk

slight PSNR/bitrate increase

Originally committed as revision 7361 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7349 to svn://svn.ffmpeg.org/ffmpeg/trunk

 some PSNR/bitrate improvement for adaptive quant

Originally committed as revision 7346 to svn://svn.ffmpeg.org/ffmpeg/trunk

skip motion estimation and encoding of non direct-0,0 MBs if the next MB is skiped (mpeg4 doesnt allow such MBs and in the past we did ME and encoding until at the end we droped them, so this should be faster though i didnt benchmark it, benchmark welcome)

Originally committed as revision 7343 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

  some PSNR/bitrate gain for b frames with adaptive quant or QPRD

Originally committed as revision 7341 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7340 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7334 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 7284 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

+0.01 PSNR
idea from x264

Originally committed as revision 7189 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

Originally committed as revision 7157 to svn://svn.ffmpeg.org/ffmpeg/trunk

fix b frames + -mbd rd without -psnr (yes that was seriously buggy and probably hasnt been noticed as everyone who tested stuff used -psnr)

Originally committed as revision 7151 to svn://svn.ffmpeg.org/ffmpeg/trunk

    [ Based on a patch by Brian Brice (bbrice at newtek dot com) ]

Originally committed as revision 6161 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 6072 to svn://svn.ffmpeg.org/ffmpeg/trunk

replace MULL by MULH + shift in dct32() (code is very slightly faster, and the compiler should be able to optimize the shift away on 64bit archs)

Originally committed as revision 6045 to svn://svn.ffmpeg.org/ffmpeg/trunk

umovimus at gmail dot com

Originally committed as revision 6022 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 5982 to svn://svn.ffmpeg.org/ffmpeg/trunk