| Age | Commit message (Collapse) | Author |
|---|
|
The problem
When watching live DVB, data is delivered strictly at the broadcasters
speed. We cannot change it through server commands. Our local systems clock
usually runs slightly faster or slower than that, causing a/v fifos to run
empty or full after a few minutes.
Standard network buffering control only handles the first case by pausing
the engine (not nice). The latter case ends up in severe stuttering and an
a/v lag of several seconds (annoying).
I tried quite a few differnt algorithms, and this one made it:
a 3 point controller.
There is a target buffer fill window with a center and some tolerated width:
Minimum:
definition: 1 second
safety: clamped to 38% of fio size
action: switch playback speed to 99.5%
Center:
definition: 2 seconds
safety: clamped to 73% fifo size
action: switch to normal playback speed
Maximum:
definition: 3 seconds
safety: clamped to 98% fifo fill
action: switch playback speed to 100.5%
If the usual dvb audio to video muxing delay is more than 1 second, center
time is increased. On low bitrate radio, window width is increased.
Real TVs do adjust playback audio sampling rate to follow delivery speed.
Some PC sound cards can do that, too. It could be implemented transparently
(although I don't know yet how). This comes quite close, resampling audio to
stretch.
That half percent is large enough to cover clock deviation, and it is small
enough not to cause audible pitch bending. Speed control consists of
adjusting SCR and telling audio out. Doing just the first will cause
metronom to drop and/or insert whole audio frames, not nice with music.
BTW. this one needs demux_ts to send BUF_FLAG_FRAME_START.
|
|
|
|
- mkdir/_mkdir function
- prefer prepared POSIX version in CDDA plugin
|
|
- use -no-undefined flag only for building shared libraries (libxine, plugins)
- plugins LDFLAGS unification
- move -no-undefined into LDFLAGS_NOUNDEFINED
- attributes.m4 fix
|
|
|
|
--HG--
extra : rebase_source : cfee1d5353fa3cacf4df8712fde15cd94e2ee3d4
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--HG--
branch : v4l
|
|
--HG--
branch : v4l
|
|
--HG--
branch : v4l
|
|
--HG--
branch : v4l
|
|
Get rid of most compile-time warnings.
Clean up white space.
Mark xine_plugin_info as EXPORTED.
Fix xine-lib internal #includes.
Use #defines instead of many "#ifdef HAVE_LIBV4L2"/"#else"/"#endif".
--HG--
branch : v4l
|
|
--HG--
branch : v4l
|
|
It's ugly and works half the time, but it's there.
--HG--
branch : v4l
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes the reading of CDDB information by not setting INPUT_CAP_BLOCK
for the CDDA plugin (and therefore also setting CD_RAW_FRAME_SIZE to 0), and
allow reading in non-block sized chunks as per
http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=a470c338149c;style=gitweb
Explanation: At some point a number of releases ago, a codepath in Xine
related to the reading of block devices which had been bypassed was fixed,
which meant that when certain frontends asked Xine to provide CDDB
information for a disc, querying the name, length, etc. of each track, Xine
would actually cause a seek to the starting block of each track, which meant
that before starting to play, the player would pause for 5-10 seconds,
seeking through each track. This is unnecessary, since Xine should have
simply used the CD TOC information from the CD audio header at the start of
the disc. Other frontends handle CDDB differently and don't query Xine for
information track by track, and so never triggered this problem. But for
those with the problem, it made loading a disc rather slow.
It turns out that the root of the problem is that the CDDA plugin shouldn't
be setting INPUT_CAP_BLOCK, since Audio CDs are not block devices _in the
sense that Xine intends_. Simply turning this off fixes the problem, with
no other side effects (tested locally, for some time now, on xine-ui, kscd,
kaffeine, amarok, etc.).
This change pairs nicely with a patch originally committed years ago (cset
a470c338149c) but which was reverted as it inadvertently triggered the same
problem as is now (properly) fixed by the simple above-mentioned change.
Now that a better fix is in, it can be re-committed.
|
|
This code is returned when there is more than one CDDB entry for the disc in
question. Before, when receiving a 211 response from a CDDB server, Xine
would simply not display any CDDB information. Now one of the responses is
displayed, on the theory that something is better than nothing.
|
|
|
|
|
|
Use strchr instead of strrchr to allow text to contain "=".
--HG--
extra : transplant_source : l%29%15%0F%DFVV%08%B7%CF%FEb%E0v%22%18%FA%9Ap%8B
|
|
(Tweaked to fit current hg and to fix a bug.)
--HG--
extra : transplant_source : %FC%0C%D1n%D1%26%90%88%E0%EC%7D/%27%A1i%00%B0m%E5%AF
|
|
--HG--
extra : transplant_source : w%85%203%2C%D1%04%CCgoRexh%03%88%9E%86Z%5B
|
|
|
|
|
|
|
|
--HG--
extra : transplant_source : %8D9%B3J%8E%DE%A1%81t%7E%A0%08%13%A4%AE%9C%EA.%C3%10
|
|
|
