Change ao_pcm to use the new audio output driver API and clean up some
of the code. Rewrite the logic controlling how playback timing works
when using -ao pcm. Deprecate the "fast" suboption; its only effect
now is to print a warning, but it's still accepted so that specifying
it is not an error.
Before, timing with -ao pcm and video enabled had two possible
modes. In the default mode playback speed was rather arbitrary - not
realtime, but not particularly fast. -ao pcm:fast tried to play back
at maximum video playback speed - mostly succeeding, but not quite
guaranteed to work in all cases. Now the default is to play at
realtime speed. The -benchmark option can now be used to get faster
playback (same as the video-only case). In the audio-only case
playback is always maximum speed.
-novideo is the right way to disable video, and should also work in
more cases now that lavf is used as the default demuxer for more formats
(like AVI; internal AVI demuxer fails with -novideo).
Also change the man page description of -novideo a bit to make it
sound less negative about the chances of the option working.
Where 8 channel support is non-trivial (e.g. ao_dsound), at least ensure we
fail gracefully.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29868 b3059339-0415-0410-9bf9-f77b7e298cf2
incorrectly does not fail like it should.
This ensures we will not incorrectly append the file header at the end.
Based on patch by Zhou Zongyi [zhouzongyi at pset.suntec.net]
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29311 b3059339-0415-0410-9bf9-f77b7e298cf2
WAV header (ca. 2GB currently) or if it can not update the header at all.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29035 b3059339-0415-0410-9bf9-f77b7e298cf2
be, thus using it like a constant is incorrect.
Move wavhdr initialization to the code.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@21266 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
Base on idea by Olivier Rolland (billl at users dot sf dot net)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@14299 b3059339-0415-0410-9bf9-f77b7e298cf2
Uoti Urpala
Uoti Urpala
cboesch
reimar
tack
diego
Amar Takhar
ulion
rathann
faust3
alex