add UYNV,UYNY,uyv1,2Vu1 to rawuyvy
add P422 to raw422P
works on samples/V-codecs/.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29789 b3059339-0415-0410-9bf9-f77b7e298cf2
Fixes r29770, which probably should not have been committed.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29786 b3059339-0415-0410-9bf9-f77b7e298cf2
Just the dependencies are different, so specify them separately.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29779 b3059339-0415-0410-9bf9-f77b7e298cf2
They are only used in one place so the indirection is pointless.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29778 b3059339-0415-0410-9bf9-f77b7e298cf2
The Matroska demuxer didn't place FLAC codec extradata in the normal
extradata field but instead constructed a fake data packet and inserted
that at the start of the demuxer stream. Current FFmpeg FLAC decoder
can read the data from the proper extradata field too, so use that
mechanism instead.
This fixes a problem with files that use ordered chapters to load
external segments from other files that have FLAC audio. In that case
there can be a seek before the audio decoder is first initialized, and
the seek will flush all stream packets so the decoder would never see
the inserted extra packet. That particular issue could be fixed by
initializing the decoder before any seeks instead (and there could
still be other similar problem cases where doing that would be more
robust), but this change is still generally right. I think the
previous code would also cause problems in case there are multiple
audio streams; there's only a single demuxer stream used for data
packets, meaning that a packet inserted for the sake of a secondary
audio stream could be read by the codec of the default stream
(possibly not FLAC at all) and the packet would not be available when
switching to the secondary audio stream later.
This also makes the demuxing function set the keyframe flag for
vorbis packets that aren't header packets and have a time stamp,
even if we do not have vorbis_info struct yet.
The reason for this is that header packets always have 0 as time stamp.
Fixes bug #1585
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29776 b3059339-0415-0410-9bf9-f77b7e298cf2
Allows to use ITU-R BT.709 instead of the default ITU-R BT.601.
Patch by Lauri Mylläri, lauri D myllari gmail
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29769 b3059339-0415-0410-9bf9-f77b7e298cf2
Fixes the use of options on the command line which should not override each other (like -vf-add).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29768 b3059339-0415-0410-9bf9-f77b7e298cf2
Checking that installed header and library match is not really our task,
also if desired it would be more correct to do it at runtime (e.g. because
of distributed binaries, or system updates gone wrong, ...).
tmp_run also slows down configure on systems with slow fork like MinGW.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29753 b3059339-0415-0410-9bf9-f77b7e298cf2
There's apparently a new OpenAL version which contains some constructor
code that runs at startup if the binary links with OpenAL at all (even
if no OpenAL function is called). This startup code does some
nontrivial interaction with ALSA libraries and as a side effect this
idiocy also breaks test binaries run by configure, causing features to
not be detected. Avoid the problems by disabling OpenAL by default.
It's not a particularly good audio output method anyway and there are
almost certainly fewer users who would benefit from it automatically
being available than users who'd suffer from some kind of breakage
caused by it.
As part of merging subtitle-in-terminal changes make
update_subtitles() only clear existing subtitles if called with the
reset argument, and not try to set new ones. Later calls should set
the needed new subtitles, and this change avoids some problems with
trying to set subtitles when mp_property_sub() in command.c gets
called from initialization code before full initialization.
all other filters that should apply to it
(fix PEBCAK as seen on #mplayer)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29752 b3059339-0415-0410-9bf9-f77b7e298cf2
except for the last chunk.
Should fix high CPU usage reported e.g. here: http://bugs.gentoo.org/show_bug.cgi?id=286020
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29748 b3059339-0415-0410-9bf9-f77b7e298cf2
compn
lorenm
Uoti Urpala
cehoyos
diego
reimar
ptt
adrian
attila
cladisch
jrash