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

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

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

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

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

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

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

Patch by kostya

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

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

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

tests/tiny_psnr.c:55: warning: ‘exp16’ defined but not used

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

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

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

Needed because avparser changes the size of the packets

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

per frame (this is untested as the encoder does not use it yet)

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

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

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

pts to set the start_time.
patch by Neil Brown: [neilb suse de]
original thread: [FFmpeg-devel] [patch 3/3] Make timing calculations less
dependant on start_time being defined.
date: 08/16/2007 08:27 AM

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

negligible increase in quality

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

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

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

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

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

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

(correct initial timestamps which have AV_NOPTS_VALUE)

sorry, i will rm tests/seek_test ; make ; make seektest from now on

Before r9917 lavf replaced the initial dts which were unknown (AV_NOPTS_VALUE)
by values starting from -frame_duration or another guessed value.
After r9917 lavf buffers packets until it finds a known timestamp or it buffered
too much, it will then correct the previous unknown timestamps in the buffer exactly.
For the seek tests that meant that a few initial timestamps would get changed.
If no packet in the whole stream contains a timestamp then all timestamps
will be changed by first_frame_duration or so as 0 is used instead of
-frame_duration as startpoint ...

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

closes issue5

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

patch by Andreas Öman: [andreas olebyn nu]

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

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

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

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

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

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

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