Patch by Cyril Comparon: standard_gmail_full_name_address
Original thread: Suggestion for a centralized language-tag facility in libavformat
Date: 04/10/2009 07:33 PM
Originally committed as revision 18698 to svn://svn.ffmpeg.org/ffmpeg/trunk
While using large static table is not good (especially for embedded devices and
CPUs with small cache), other alternatives are not very good either.
Originally committed as revision 18696 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
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
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
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
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
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