memory is allocated in that function (ugly!!).
Fixes bug #450, patch by Mikulas Patocka (mikulas at artax karlin mff cuni cz)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17599 b3059339-0415-0410-9bf9-f77b7e298cf2
libpostproc is no longer built from within the libavcodec directory.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17596 b3059339-0415-0410-9bf9-f77b7e298cf2
once when the scaler is initialized, instead of building them and freeing
them over and over. This gives massive performance improvements.
patch by Alan Curry, pacman*at*TheWorld*dot*com
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17589 b3059339-0415-0410-9bf9-f77b7e298cf2
variables, and remove the unused dir parameter from set_xxx_near()
calls.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17576 b3059339-0415-0410-9bf9-f77b7e298cf2
automatically, and remove a call to snd_pcm_drop() because
snd_pcm_close() does it automatically.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17575 b3059339-0415-0410-9bf9-f77b7e298cf2
can call snd_pcm_delay() directly.
To avoid the audio device appearing to be running too fast after an
underrun, ignore any samples that were lost in an underrun.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17574 b3059339-0415-0410-9bf9-f77b7e298cf2
device states, and there is no need to avoid returning a positive value
less than 1024.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17573 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
do the opposite of what they say.
The vec_mstrgb24 and vec_mstbgr24 macros should be opposites and not perform
the same things.
patch by Alan Curry, pacman_at_world_dot_std_dot_com
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17564 b3059339-0415-0410-9bf9-f77b7e298cf2
The CSeq was mispelled as Cseq, so MPlayer alwys answered with CSeq=1
Fixed with help from xiojason on #mplayer
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17563 b3059339-0415-0410-9bf9-f77b7e298cf2
outputs RGBA. This patch supports 6 output formats and prints an error message
if it is asked to provide an output format it is not capable of.
patch by Alan Curry, pacman_at_world_dot_std_dot_com
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17561 b3059339-0415-0410-9bf9-f77b7e298cf2
based on a patch by Helio Polis, simplesmoke_at_hotmail_dot_com
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@17560 b3059339-0415-0410-9bf9-f77b7e298cf2
gpoirier
alex
rtognimp
nicodvb
henry
reimar
diego
ods15
rathann
cladisch
corey
faust3
iive
aurel