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 way, we avoid overwriting stream_index in the user's AVPacket
with a nonsense value.
Originally committed as revision 22081 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
Most of the make builtin rules, which we do not need, are suffix rules,
and we use only new-style pattern rules. Disabling suffix rules saves
some time when building on slow systems.
Originally committed as revision 22064 to svn://svn.ffmpeg.org/ffmpeg/trunk
Also link avfiltergraph.o and graphparser.o against libavfilter, as it
uses them.
Originally committed as revision 22063 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
This is consistent with the metadata displaying in show_format() and
with the documentation.
Originally committed as revision 22046 to svn://svn.ffmpeg.org/ffmpeg/trunk
opt_input_file(). More consistent and more clear, as "filename" can be
easily confused with the global "input_filename".
Originally committed as revision 22045 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