Age | Commit message (Collapse) | Author |
|
if the checksums match
Originally committed as revision 22061 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
|
|
Originally committed as revision 22056 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
seems 20cpu cycles faster
Originally committed as revision 22055 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22054 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
3-7 cpu cycles faster
Originally committed as revision 22053 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
|
|
Originally committed as revision 22051 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
|
|
Originally committed as revision 22047 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
|
|
Originally committed as revision 22041 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22040 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22039 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
for high resolution videos.
about 20cycles faster per MB for cathederal.
Originally committed as revision 22038 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22036 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
same speed (ask gcc why, i dont know)
Originally committed as revision 22035 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22032 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
10-15 cpu cycles faster.
Originally committed as revision 22029 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
same speed as far as i can meassure but it might have fewer branches on some
archs.
Idea from x264 / jason
Originally committed as revision 22027 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22025 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
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.
Originally committed as revision 22024 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
prints the context
Originally committed as revision 22023 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22013 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22012 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
ff_combine_frame() is called, which allocates ParseContext->buffer if needed,
so ff_parse_close() must be called to free it.
Patch by jai.
Originally committed as revision 22005 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22000 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21993 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21992 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21991 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21990 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21989 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21988 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21986 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21985 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21984 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
block decoding at exit, so prevent that memory leak now.
Originally committed as revision 21983 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21982 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21981 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21980 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21979 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21977 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
This fixes some issues with the first few timestamps.
Originally committed as revision 21976 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
in read frame.
Originally committed as revision 21975 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21963 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Indeo 5, so make them global and move their initialization to the common place
as well. And fix static VLC initialization, as ff_ivi_create_huff_from_desc()
used old way to do so.
Originally committed as revision 21962 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
This prevents crashes during decoding grayscale Bink files like
samples from Impossible Creatures game demo.
Originally committed as revision 21961 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
This fixes issue 1764.
Originally committed as revision 21959 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Patch by Kostya, minor fixes by me.
Originally committed as revision 21958 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 21956 to svn://svn.ffmpeg.org/ffmpeg/trunk
|