git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22086 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22085 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

patch by Zhou Zongyi @ zhouzy () os punkt pku dot edu speck cn


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22084 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

 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.



git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22083 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

result depending on uninitialized data.

FATE result may change for this test.


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22082 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

This way, we avoid overwriting stream_index in the user's AVPacket
with a nonsense value.


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22081 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

8 cpu cycles faster.


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22079 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

maybe 0.5 cpu cycles faster


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22078 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Patch by Francesco Cosoleto gmail($name)


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22077 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22075 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

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.


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22073 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22072 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22071 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

This seems unneeded as nothing seems to ever set it to non zero values.


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22070 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22069 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22068 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22067 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Not benchmarked as this is petty much just code removial.


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22066 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

ones based on mb_stride in h264.
about 20 cpu cycles faster overall per MB


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22065 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

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.

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22064 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Also link avfiltergraph.o and graphparser.o against libavfilter, as it
uses them.


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22063 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22062 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

if the checksums match


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22061 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

svq3 decoder does not work yet though but i didnt want to keep compilation
broken longer


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22060 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Patch by Anton Khirnov wyskas gmail com


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22059 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Patch by Anton Khirnov wyskas gmail com


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22058 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Patch by Anton Khirnov wyskas gmail com


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22057 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22056 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

seems 20cpu cycles faster


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22055 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22054 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22053 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

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)


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22052 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22051 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Patch from Anton Khirnov wyskas gmail com


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22050 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Patch from Anton Khirnov wyskas gmail com


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22049 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

The code read/write code itself was 1 cycle faster, overall its
likely more due to cache effects


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22048 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22047 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

This is consistent with the metadata displaying in show_format() and
with the documentation.


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22046 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

opt_input_file(). More consistent and more clear, as "filename" can be
easily confused with the global "input_filename".


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22045 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

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.


git-svn-id: file:///var/local/repositories/ffmpeg/trunk@22044 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b