This has the side-effect of using fftheora by default instead of
theora, which possibly should be changed.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31225 b3059339-0415-0410-9bf9-f77b7e298cf2
The loop initializing handles in the output surface table to
VDP_INVALID_HANDLE ran over indices from 0 to vc->num_output_surfaces.
However it is first called before that variable is initialized. As a
result later code could try to destroy the handles which still had the
"non-invalid" value 0. Most likely this caused no visible effects; at
least on my machine no valid surface gets handle 0, and libvdpau just
returns an error for the resulting invalid calls. Change the code to
loop over the whole table. Also add code to print visible warnings if
libvdpau rejects a surface destroy call (some other places already had
checks but not all).
The code handling larger-than-minimum realvideo extradata sizes was
complete nonsense. It tried to add the additional data to the exported
track extradata by reading data from the input stream, which was
completely bogus as this code is called long after the original
Matroska track extradata information has been read. As a result the
data read had nothing to do with correct values, and the read call
messed up the stream position which likely broke further parsing of
the file and caused complete playback failure. Change the code to
instead copy any additional part at the end of input extradata to the
end of output extradata. I believe this is the intended semantics,
though I haven't verified it from any specs.
reintroduce the logic that was removed with the previous commit. In case
the naive approach to link fails, try again with pkg-config.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31210 b3059339-0415-0410-9bf9-f77b7e298cf2
Commit fc39d48465 ("demux_mkv: store streams sequentially in
demuxer->[avs]_streams") had a simple bug in automatic stream
selection causing a crash if no video or audio track was marked as
'default'. Fix.
tehre is an infinite number of delayed frames, thus never finishing (happens
with -demuxer lavf -vc theora).
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31206 b3059339-0415-0410-9bf9-f77b7e298cf2
insanely large value.
Avoids hang if a decoder handles the data/size == 0 condition incorrectly.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31205 b3059339-0415-0410-9bf9-f77b7e298cf2
The previous version could possibly be misread in a way that forbids
reindenting if-blocks. The intended meaning, that whitespace changes
should be separated from other changes, is already implied from what
is written above that paragraph.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31200 b3059339-0415-0410-9bf9-f77b7e298cf2
Dramatically reduces seeking times with lavf ogg demuxer.
Needs a spearate implementation for the thread-based cache implementation.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31198 b3059339-0415-0410-9bf9-f77b7e298cf2
DirectShow codec).
Required changes:
- codecs.conf entry (of course).
- Allow opening files with “.col” in the file name, just like “vp3” and “.fpf”
already was allowed. (CineForm expects to be able to do this, presumably
for some color management code.)
- In registry.c, fake a few registry keys that the codec expects the installer
to have written. Also, change a few magic numbers (0, 2) to the appropriate
constants (ERROR_SUCCESS, ERROR_FILE_NOT_FOUND) where appropriate, so the code
is easier to follow.
SMP works fine, but seemingly performs suboptimally (e.g., on my dual-core
laptop, CineForm performs better if I lie to it and tell it I have four cores).
I don't know if this is inherent in the codec, or some inefficiency in the
emulated synchronization primitives.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31196 b3059339-0415-0410-9bf9-f77b7e298cf2
loader/module.c:618: warning: 'MODULE_DecRefCount' defined but not used
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@31195 b3059339-0415-0410-9bf9-f77b7e298cf2
diego
reimar
cehoyos
Uoti Urpala
hyc
siretart
sesse
stefano