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
(partially, it seems roughly three times as fast as
the C code according to quick-n-dirty gprof tests)
This one is bit-perfect.
patch by Romain Dolbeau <dolbeau@irisa.fr>
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@9003 b3059339-0415-0410-9bf9-f77b7e298cf2
- we need to compile this with -fomit-frame-pointer or we cannot access the
function parameters
- we need to save & restore %ebp, or we'll destroy the caller's stack ptr
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@8544 b3059339-0415-0410-9bf9-f77b7e298cf2
rathann
diego
gpoirier
rfelker
henry
reimar
rtognimp
faust3
atmos4
alex
michael
nexus
arpi