with SSE and add a avcodec_align_dimensions2 taht returns the stride alignment
requirements independently from doing the width/height padding.
Originally committed as revision 22095 to svn://svn.ffmpeg.org/ffmpeg/trunk
this way it works on 64-bit archs too.
Patch by Jindřich Makovička ($lastname without last letter and háček, gmail)
Originally committed as revision 22093 to svn://svn.ffmpeg.org/ffmpeg/trunk
Indeo 5 into single structure IVIHuffTab and factorize code using it.
Based on patch by Maxim (max_pole at German GMX)
Originally committed as revision 22092 to svn://svn.ffmpeg.org/ffmpeg/trunk
It happens when the number of channels defined by DCAContext:acmod is lower
than DCAContext:prim_channels. In this case, dca_subsubframe() will call
qmf_32_subbands() using s->channel_order_tab[] entries equal to -1.
Originally committed as revision 22083 to svn://svn.ffmpeg.org/ffmpeg/trunk
result depending on uninitialized data.
FATE result may change for this test.
Originally committed as revision 22082 to svn://svn.ffmpeg.org/ffmpeg/trunk
this seems 1 cpu cycle slower even though we practically just remove code.
Speed loss seems caused by the merge of if(left_type), iam commiting this
anyway as i cant imagine this to be anything but compiler messup.
Originally committed as revision 22073 to svn://svn.ffmpeg.org/ffmpeg/trunk
svq3 decoder does not work yet though but i didnt want to keep compilation
broken longer
Originally committed as revision 22060 to svn://svn.ffmpeg.org/ffmpeg/trunk
about 5 cpu cycles slower in the local code but should be overall faster
due to reduced cache use. (my sample though has too few intra4x4 blocks
for this to be meassureable easily either way)
Originally committed as revision 22052 to svn://svn.ffmpeg.org/ffmpeg/trunk
The code read/write code itself was 1 cycle faster, overall its
likely more due to cache effects
Originally committed as revision 22048 to svn://svn.ffmpeg.org/ffmpeg/trunk
Due to a shortcoming in the AAC specification, if an all zero buffer is
fed to section data decoding it will never terminate. That means without
a buffer exhaustion check decode_band_types() will consume all input
buffer padding. Worse if a get_bits() implementation that returns zeros
when padding is exhausted is used, the function will never terminate.
The fixes that by added a buffer exhaustion check in the sectioning
decoding loop.
Originally committed as revision 22044 to svn://svn.ffmpeg.org/ffmpeg/trunk
same speed as far as i can meassure but it might have fewer branches on some
archs.
Idea from x264 / jason
Originally committed as revision 22027 to svn://svn.ffmpeg.org/ffmpeg/trunk
MPV_common_init(), so calling both is redundant and leads to memory
leaks in WMV3/VC-1 decoder. Thus use only the first function in
WMV3/VC-1 decoder initialization.
Originally committed as revision 22024 to svn://svn.ffmpeg.org/ffmpeg/trunk
ff_combine_frame() is called, which allocates ParseContext->buffer if needed,
so ff_parse_close() must be called to free it.
Patch by jai.
Originally committed as revision 22005 to svn://svn.ffmpeg.org/ffmpeg/trunk
Reimar Döffinger
Jindřich Makovička
Kostya Shishkov
Michael Niedermayer
Zhou Zongyi
Laurent Aimar
Vitor Sessak
Benoit Fouet
Alex Converse
Peter Ross
Jai Menon
Daniel Verkamp