| Age | Commit message (Collapse) | Author |
|---|
|
--HG--
rename : src/libmusepack/xine_musepack_decoder.c => src/audio_dec/xine_musepack_decoder.c
|
|
|
|
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.
|
|
In trickspeed mode, input_vdr's metronom generates a discontinuity for
each video frame. These generated discontinuities could interfere with
discontinuities generated by the demuxer. As a result the metronom
deadlocked while waiting for a matching discontinuity indication.
So care must be taken to not mix internal and external discontinuities.
|
|
|
|
|
|
The supplied functions and constants allow to define a video output area
(called video window) within the OSD area to show for example a small
preview of the current channel in the top right corner while zapping
through the channel list displayed as OSD.
A VDPAU enabled xine-lib implements VO_CAP_VIDEO_WINDOW_OVERLAY already.
|
|
|
|
|
|
|
|
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
|
|
Was breaking on systems which, for some strange reason, use /usr/lib64.
|
|
|
|
This is an incomplete patch porting xine-lib to the new libmpcdec API.
Incomplete, because 1) no SV8 support and 2) still no seeking.
|
|
I noticed recently that xine's DVB plugin had disappeared. After a bit of investigation (and a few handfuls of hair) I have created this patch:
|
|
|
|
--HG--
extra : transplant_source : %F5K%AE%D3f%EFQ%F5U%E5%FE%BB%1E.%2Beh%C5%20%7F
|
|
The new _x_compute_interval functions uses clock_gettime() which is
not provided on OS X. If _POSIX_TIMERS is not defined, use the older
gettimeofday().
|
|
start_pos is of type off_t, and since we compile with D_FILE_OFFSET_BITS=64,
-off_t is a 64-bit long long int, so you'd think we'd be fine here -- but we
aren't, because start_time, this->duration and this->frame_size are all
32-bit ints, which means that the computed seek position gets truncated to
32 bits before it's assigned to start_pos. The simple solution is to cast
start_time to off_t, expanding the computation to 64 bits in time to avoid
truncation.
|
|
|
|
|
|
|
|
|
|
Similar to the fix in cset 86b9162cfcfe.
|
|
--HG--
rename : src/xine-engine/buffer.h => include/xine/buffer.h
rename : src/libmad/xine_mad_decoder.c => src/audio_dec/xine_mad_decoder.c
|
|
|
|
|
|
m4/pthreads.m4
* Mingw GCC says that '-pthread' option is unknown.
* Correct library name under Mingw is -lpthreadGC2.
src/xine-engine/demux.c
* function _x_compute_interval cannot be compiled
|
|
|
|
|
|
VDR 1.7.5 requires that STC should be near to a previously transmitted PTS
value. We cannot hold this requirement immediately after a discontinuity
as the currently displayed image's vpts time (which originated before the
discontinuity) will be transformed to STC by applying the new vpts offset
established at discontinuity.
Therefore, a queue of vpts offset pairs is created and at discontinuity
the current offset is stored there in combination with the vpts value
up to which it has to be used. When retrieving a STC value, we lookup
the offset to use from current vpts and therefore get a STC near to an
originating PTS value.
As VDR requires this quality of STC values also for its trickspeed modes,
it is nolonger possible to simply set PTS of incoming frames to 0 to
schedule them just after the previous frame. Therefore a discontinuity is
generated for each frame in trickspeed mode, which allows us to schedule
each frame immediately after the previous one while there may be gaps in
PTS values. As a result the above mentioned code will take care to provide
proper STC values even in VDR's trickspeed modes.
|
|
|
|
|
|
|
|
|
|
This avoids use of strlen(), which doesn't cope well with UTF-16, and
also has the ID3 parser double-NUL-terminate the buffered string.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--HG--
extra : transplant_source : %AE%D3%DCw%0F%073h%5D%C0%B5%A7%BA%2B%95%81%95bT%D6
|
|
|
|
|
|
This patch adds mimetypes to src/demuxers/demux_mod.c for the file types it
can handle. After this patch is applied, then xine_get_mime_types() reports
them correctly, which allows Amarok 2.x to play them and probably prevents
other interoperability problems.
Previously Amarok 2.x rejected MOD/S3M/IT/XM/etc. files that were enqueued
there when using the xine phonon backend because their mime types were not
included in those announced by xine-lib.
|
