| Age | Commit message (Collapse) | Author |
|---|
|
It can be the case that the header is larger than buf->max_size (8 kilobytes),
especially for slightly larger files. This sends them in parts so we don't
overfill the buffer.
|
|
Supposed to be in milliseconds; totalframes is only approx. total seconds.
|
|
I don't think whoever wrote this played a TTA file all the way to the end.
|
|
* Return the correct stream length
* Return the current time
* Implement seeking
---
src/demuxers/demux_tta.c | 47 ++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 41 insertions(+), 6 deletions(-)
--HG--
extra : transplant_source : D%27%B7%5C%C4%95Ra%90E%DD%99IG%CF%5D%21%27zN
|
|
---
src/demuxers/demux_flac.c | 1 +
src/demuxers/demux_tta.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
--HG--
extra : transplant_source : C%21X%B8%E1p%D2%8E%E0%26%CA%3E%09%8B%09%16%19%C1CQ
|
|
I've noticed that a lot of the demuxers don't have mimetypes -- Nokia and
KDE's Phonon (when using the Xine backend, and consequently this bothers all
Amarok users) depend on the mimetypes to see what types of files it can
process.
This adds support for the True Audio data type, which scratches my itch; I'm
sure there are several other demuxers that need a similar change.
|
|
|
|
|
|
|
|
TRACE and ERROR are now prefixed with XINE_HDMV_.
|
|
undefined.
|
|
|
|
|
|
|
|
the middle of PMT packets.
Parsing PAT resets PMT buffer. If PMT does not fit to single TS packet and
PAT packet is scheduled in middle of PMT packets, PMT is never parsed and TS
demuxer falls to PID auto detection mode.
This moves PMT buffer reset to the case where PMT PID changes and all PIDs
are reset. [As far as I can see, worst regression can be invalid PMT
sections when stream changes, new PMT pid equals to old one and demuxer is
not reset(?), but this should be OK as PMT checksums are always checked.]
|
|
|
|
|
|
|
|
|
|
There are two tricks to make VC1 decoding work:
1) VC1 sequence and entry point headers must be present in context->extradata.
2) video width and height must be known when opening decoder.
Some container formats store required extra data, but mpeg-ts does not.
1) is fixed by scanning the stream for headers and discarding all data until
proper headers are found.
2) is fixed by re-opening decoder with width and height information from
first open.
|
|
|
|
|
|
Splitted decode_presentation_segment()
- Store presentation segments in decoder instance data.
- Try to update overlays after every decoded object.
|
|
|
|
|
|
|
|
show_overlay().
|
|
|
|
|
|
|
|
|
|
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.
|
