| 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.
|
|
|
|
|
|
Note that the Matroska and Bluray changes have only been compile-tested.
--HG--
rename : src/xine-engine/buffer.h => include/xine/buffer.h
rename : src/libspuhdmv/xine_hdmv_decoder.c => src/spu_dec/spuhdmv_decoder.c
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
|
--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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--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.
|
|
|
|
|
|
|
|
|
|
|
