| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
--HG--
extra : rebase_source : cfee1d5353fa3cacf4df8712fde15cd94e2ee3d4
|
|
The xine libmad adaptor seemed not to forward the pts to the metronome: It
buffers the MPEG audio packets until a threshold is reached (MAD_MIN_SIZE:
2889 bytes) and then has libmad decode the packets which is send to audio
out. The pts of the last audio packet is forwarded on to metronome which can
then sync video with audio.
For the channel4 channels MPEG audio packets have a size of 576 bytes which
means it takes five packets to fill the buffer enough for processing. In the
stream every fifth audio packet contains a pts.
The result of this is: If after a seek, the last audio packet is the one
with the pts, video and audio are in sync. If the pts is in any of the four
previous ones no pts will reach metronome and video and audio will never be
synced before a new seek and even then there's a one in five chance that
video and audio are not synced.
Other channels did not show this behaviour because e.g. BBC One has an audio
packet size of about 750 bytes and send a pts every fifth packet as well.
This means that not every pts from the stream gets through to metronome but
some do. This also means that syncing after a seek is probably not as quick
as it could be but it will sync.
My workaround to this problem is to start decoding not only when a the
buffer has reached a threshold but also when a pts != 0 arrives. This does
mean however that the buffer isn't always filled to the theshold and
decoding might not perform as well as it could.
--HG--
extra : transplant_source : %EC%90%EB%AA%8A%C7%BD%A4%B7%EE%F5%E9%E8SY%89S%9D0s
|
|
This is optional, and some systems don't support it. POSIX defines the
_POSIX_THREAD_PRIORITY_SCHEDULING to tell that support is present.
|
|
In dvd_input.c:file_read(), if the read is not done in a single access, the
buffer pointer doesn't get advanced so that the second read overwrites the
data of the first.
I actually don't remember under which circumstances this could happen, but
the flaw in the code is obvious.
The patch is from NetBSD's pkgsrc, and this patch is attributed to an
"unnamed contributor" in the CVS log.
|
|
In demux_loop(), a time value is calculated by adding to the fractional
part. In case a second barrier is crossed, the value is not in its
canonical form anymore - the fractional part is larger than 10^9-1.
It should be normalized for portability. While I haven't found a formal
requirement for this in POSIX, NetBSD's libpthread checks for it and
complains.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Currently, just treat it exactly as if it were Matroska.
|
|
|
|
|
|
Mplayer now only supports single location for all binary codecs, and therefore
on Mandriva packaging /usr/lib(64)/codecs was selected as the directory where
mplayer will try to load them from.
The 64-bit variant is missing from xine-lib (/usr/lib/codecs is there).
Attached patch adds it.
|
|
|
|
|
|
|
|
This event reports the buffer status for network streams (NBC) back to the
application, providing a way to measure if the stream delivers data fast
enough. This enables the application to slow down the stream playback to
get the buffers filling more quickly. (This is only a sample application of
the event.)
The event reports all vital data like fill percentage, remaining buffer in
seconds and discontinuity, separately for audio and video, whether the nbc
layer is actually buffering, the operation type (put or get) and also if the
buffering is enabled at all.
In essence, it's the output you get from nbc if you run xine-lib in
verbose mode on the console, but in raw data.
|
|
To reduce code duplication.
|
|
I noticed some alsa dropouts (losing audio) while hunting a bug which has
been related to a broken streaming server. This resulted in buffers running
empty and therefore showed some issues in the ALSA driver not correctly
applying some recovery procedures provided by ALSA itself (snd_pcm_recover()
and friends).
|
|
|
|
|
|
|
|
I don't know why I multiplied by integers _outside_ the parentheses. I blame
late nights.
Regardless, this fixes the skip every 24 seconds due to the truncation of
FRAME_TIME. The input_time is also more accurate for e.g. stopping cue tracks.
|
|
|
|
(Sample: http://samples.mplayerhq.hu/Matroska/H264%2bEAC3.mkv )
|
|
|
|
|
|
This makes seeking more accurate, I believe.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When opening empty files with xine, it reports:
> This is xine (X11 gui) - a free video player v0.99.6cvs.
> (c) 2000-2007 The xine Team.
> system call fstat: Bad file descriptor
> system call fstat: Bad file descriptor
> call failed
> object not accessible
> object not accessible
> call failed
The problem was that when detecting an empty file, it is closed, but the file
descriptor in struct file_input_plugin_t is still left at the previous value,
causing the errors when it is used later.
|
|
|
|
|
|
Based on patches from Roger Scott <ras351@hotmail.com>.
|
|
Rename "wmav3" to "wmapro" in xine-lib's internals to line up xine-lib's
nomenclature with what everyone else calls it and knows it as.
[Tweaked by ds to avoid API change.]
Tell xine-lib that when it finds wmapro, look to ffmpeg.
ffmpeg's wmapro decoder is unique in that it puts out samples that
are floats, not 16-bit ints. These need to be converted.
This requires external ffmpeg.
|
|
This will reduce logspam with little-endian streams, which Can't Happen anyway.
|
|
I have LCPM 24bit DVD.
When I played it on xine, sound was noisy noise. I found that LCPM 24bit
byte stream is _not_ the same as WAVE 24bit byte stream.
|
