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

@patchby Tomas Härdin |tomas dot hardin at codemill dot se|


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

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

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

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

for high resolution videos.
about 20cycles faster per MB for cathederal.


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

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

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

same speed (ask gcc why, i dont know)


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

metadata system.

Patch by Anton Khirnov <wyskas gmail com>.



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

Patch by Anton Khirnov <wyskas gmail com>.



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

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

Patch by Anton Khirnov <wyskas gmail com>.



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

Patch by Anton Khirnov <wyskas gmail com>.



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

10-15 cpu cycles faster.


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

Patch by Anton Khirnov <wyskas gmail com>.



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

same speed as far as i can meassure but it might have fewer branches on some
archs.
Idea from x264 / jason


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

Fixes a crash when audio stream is cycled twice.

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

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

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.



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

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

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

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

Patch by Yann Coupin, yann.coupin+ffmpeg gmail


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

Patch from Anton Khirnov wyskas gmail


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