| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
MSVC complained about a memset to a const object and all "long long"
variables that are GNU only. I fixed it by grouping the fields into a
structure and now even GCC is more happy.
|
|
|
|
|
|
--HG--
rename : src/libspudvb/Makefile.am => src/libspuhdmv/Makefile.am
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This adds the following functionality:
* Read segment title and uses that for display in a UI
There is an issue when the file does not specify a segment title. It will
then fall back to a generic "(No title)", since I could not find a way to
retrieve the file name the player shows.
* More implementation files
Added:
- demux_matroska.h
- demux_matroska_chapters.h
This breaks the OO-ish C visibility a bit, since there need to be public
(i.e. non-static) interfaces between the units.
* Chapter Handling
I did a rough initial implementation of Matroska's "editions" system. The
demuxer will parse all editions from the header, and for each edition the
top level of chapters. This is not quite the full spec as Matroska
intends, but it should work fine as long as there is only a single edition
and all editions/chapters only reference only one (the first and only)
segment in the stream, and are supposed to apply to all tracks therein.
When the stream has chapters, the demuxer will now handle skip events from
the player to jump between chapters.
|
|
xine-lib jack audio output plugin still uses deprecated jack_client_new()
function. This function has been superseded by jack_client_open(). New API
has an advantage that jackd is allowed to alter name of the client in case
of ambiguity.
|
|
|
|
|
|
|
|
|
|
|
|
Using bitmeter, I found that xine's jack output suffers from the problem
mentioned at the bottom of bitmeter's home page.
"Although JACK itself works entirely with IEEE floating point values the
conversion to and from analog audio uses integers, as do popular audio
storage technologies like DAT and Red Book CDs. For correct operation JACK
software which uses such integers should use the same conversion ratios as
JACK itself. e.g. 16-bit samples should be divided by exactly 32768.
A common mistake is to choose the value 32767 instead. You can't hear this,
or see it with ordinary meters, but the bitmeter shows a clear signature for
audio processed in this way. The 8th bit of the mantissa (counting the
rightmost as the 0th) is orange, indicating that an unusually high
percentage of samples have this bit set."
(from http://users.ecs.soton.ac.uk/njl98r/code/audio/bitmeter/
via Google cache)
|
|
|
|
At the moment playing multichannel audio via the sndio backend results in
garbled sound. This disables the multichannel audio support until I have
more time to look into a better and more appropriate fix.
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
Similar to the fix in cset 86b9162cfcfe.
|
|
|
