through lrintf(), that is gcc put the 32bit int flags in a 32bit float
which caused some to be lost ...).
I wonder why FATE did not pick this up?
Originally committed as revision 12329 to svn://svn.ffmpeg.org/ffmpeg/trunk
and the information needed to guess the duration only becomes known at a later packet.
Originally committed as revision 11963 to svn://svn.ffmpeg.org/ffmpeg/trunk
This only removes 2 bytes from MP3 and MP2 currently.
Up to 4 could be removed from MP3/MP2 though this might need a 2pass muxer.
Primitive code to remove headers from MPEG-1/2/4 is there too but for the
single file I tried it on (the one in the regression tests), it was a loss
because all video frames were >4096 byte, so that it is disabled ATM.
Originally committed as revision 11936 to svn://svn.ffmpeg.org/ffmpeg/trunk
Correctly interleave ogg packets per granule
and set eos correctly, 2 packets buffering is needed.
It duplicates interleave_per_dts a bit,
if someone has a good solution, I'll implement it.
Originally committed as revision 11867 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
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
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
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
