Originally committed as revision 18686 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18685 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18684 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18683 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18682 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18681 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18680 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18679 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Wolfram Gloger: wmglo (your at here) dent med uni (minus) muenchen de

Originally committed as revision 18678 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Reimar Döffinger <latinize($name) at (MN's favourite mail provider).de>

Originally committed as revision 18677 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18676 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18675 to svn://svn.ffmpeg.org/ffmpeg/trunk

decoding becomes slower, encoding becomes faster, with gcc on duron.
some inlining overrides like av_flatten are added to keep inlining similar
to before.

Originally committed as revision 18674 to svn://svn.ffmpeg.org/ffmpeg/trunk

We need to change decode_line to always_inline because gcc decided not to inline
it anymore once we force some calls to get/put_symbol() to be non inlined and
this decision of gcc would lead to a 10% overall speed loss.
100k smaller object file, no speed change

Originally committed as revision 18673 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18672 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18671 to svn://svn.ffmpeg.org/ffmpeg/trunk

threads support is not enabled. This should avoid the need for
thread_count explicit setting in applications.

Originally committed as revision 18670 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 29229 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale

(found by clang static analyzer)

Originally committed as revision 18669 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18668 to svn://svn.ffmpeg.org/ffmpeg/trunk

Based on patches by Laurent Aimar (fenrir >whirlpool< videolan >dit< org)

Originally committed as revision 18667 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Laurent Aimar <fenrir at VLCsite>
Thread: [PATCH] Fixed wavpack 9-15 bits support

Originally committed as revision 18666 to svn://svn.ffmpeg.org/ffmpeg/trunk

only avctx->{width,height} and don't touch coded_{width,height} when parsing
them. This fixes the case when coded and display dimensions differ by more
than one macroblock.

Originally committed as revision 18665 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18664 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18663 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18662 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18661 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18660 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18659 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18658 to svn://svn.ffmpeg.org/ffmpeg/trunk

fixes misdetection of mpegps_mp3_unrecognized_format.mpg (issue997)

Originally committed as revision 18657 to svn://svn.ffmpeg.org/ffmpeg/trunk

Should fix FATE, i forgot to commit this.

Originally committed as revision 18656 to svn://svn.ffmpeg.org/ffmpeg/trunk

New max size is 16bit * 4 samples (RGBA).

Originally committed as revision 18655 to svn://svn.ffmpeg.org/ffmpeg/trunk

which have AFAIK been created for the jvt:
ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_exports/SVT_YUV10_Exports_/NewMobCal_YUV10_720p5994_/
I have called the format v210x due to its similarity to v210, note though I have
not confirmed that v210x is different from actual v210 samples it just is
different from the description of v210 I am aware of.

Originally committed as revision 18654 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18653 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18652 to svn://svn.ffmpeg.org/ffmpeg/trunk

Now that max channels and primitive matrices are properly validated, there is
no need to be paranoid that random data will be overwritten.
As a bonus this makes matrix_coeff 16-byte aligned between matrices.

Originally committed as revision 18651 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18650 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18649 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 18648 to svn://svn.ffmpeg.org/ffmpeg/trunk