Currently only used on CPUs that _only_ support SSE (otherwise try 3DNow* before)
Patch by The Mighty Zuxy Meng %zuxy * meng $ gmail * com%
Original thread:
Date: Jun 21, 2006 10:20 AM
Subject: [MPlayer-dev-eng] [PATCH] SSE version of DCT64 for mp3lib
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18937 b3059339-0415-0410-9bf9-f77b7e298cf2
be used on a K6-2/3+.
Patch by Zuxy Meng < zuxy PP meng AH gmail PP com >
Original thread:
Date: Jun 21, 2006 2:50 PM
Subject: [MPlayer-dev-eng] [PATCH] Saturation & PSWAPD bugfix in mp3lib/dct64_3dnow.c & mp3lib/dct64_k7.c
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18838 b3059339-0415-0410-9bf9-f77b7e298cf2
when it uses the optimized IMDCT.
patch by Alexander Strange, astrange __ at __ ithinksw __ dot __ com
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18102 b3059339-0415-0410-9bf9-f77b7e298cf2
patch replaces '()' for the correct '(void)' in function
declarations/prototypes which have no parameters. The '()' syntax tell
thats there is a variable list of arguments, so that the compiler cannot
check this. The extra CFLAG '-Wstrict-declarations' shows those cases.
Comments about a similar patch applied to ffmpeg:
That in C++ these mean the same, but in ANSI C the semantics are
different; function() is an (obsolete) K&R C style forward declaration,
it basically means that the function can have any number and any types
of parameters, effectively completely preventing the compiler from doing
any sort of type checking. -- Erik Slagter
Defining functions with unspecified arguments is allowed but bad.
With arguments unspecified the compiler can't report an error/warning
if the function is called with incorrect arguments. -- Måns Rullgård
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17567 b3059339-0415-0410-9bf9-f77b7e298cf2
This was an incorrect fix made at the codec when it should be done at the demuxer level.
static variables in codecs are ALWAYS wrong: the demuxer is supposed to have already removed all the junk
Does anyone have an idea of a fix for the demuxer?
(discussed on IRC)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17301 b3059339-0415-0410-9bf9-f77b7e298cf2
patch makes it to look for two consecutive valid MP3 frame headers,
reducing the probability of false positives, which causes Bug 380.
Funny that the fix is so simple. Seems that someone has forgotten to
initialize MP3_resync correctly.
Also this is the recommended way to sync MP3 frames. See
http://www.dv.co.yu/mpgscript/mpeghdr.htm. "
Original thread:
Date: Dec 31, 2005 10:15 AM
Subject: [MPlayer-dev-eng] [PATCH] Try twice when searching for MP3 frame header, fixes Bug 380
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17280 b3059339-0415-0410-9bf9-f77b7e298cf2
Based on a patch by Sebastian Hegler <s_hegler at gmx dot de>.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@13788 b3059339-0415-0410-9bf9-f77b7e298cf2
if(fr->sampling_frequency>8) return FALSE; // valid: 0..8
which allows fr->sampling_frequency to go up to 8.
Obviously, the code does not bother about what would happen if
fr->sampling_frequency lies in the range [3,8].
patch from Nilmoni Deb, Nick?, Rich
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@9131 b3059339-0415-0410-9bf9-f77b7e298cf2
compilation of the AltiVec stuff on both Darwin
and non-Darwin system. They've only been tested
for compilation on Debian using Debian's gcc-3.2.
Romain Dolbeau <dolbeau@irisa.fr>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@9123 b3059339-0415-0410-9bf9-f77b7e298cf2
mplayer: stack overflow in function dct64_MMX_3dnowex
patch by Björn Sandell <biorn@dce.chalmers.se>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@9040 b3059339-0415-0410-9bf9-f77b7e298cf2
