| Age | Commit message (Collapse) | Author |
|---|
|
stream_id >= 0xbc)
|
|
|
|
|
|
|
|
|
|
First of all, it improves the qt demuxer, ensuring that 24-bit audio is
marked appropriately, and detecting little vs. big endian audio. It also
adjusts the buffer size when audio is 24-bit, ensuring that samples aren't
chopped in half (8192 does not divide evenly into 3 byte samples).
Secondly, in the lpcm decoder, the patch distinguishes between standard
24-bit lpcm (big and little endian) and special DVD-format 24-bit lpcm (see
http://wiki.multimedia.cx/index.php?title=PCM) and now handles both, instead
of only handling the DVD format.
The result is that xine now correctly plays all the 24-bit lpcm samples I
throw at it, whereas before only a few worked.
|
|
demux_aac.c looks for 2 signatures in the given stream to detect if it is an
AAC stream, however only the absence of the second signature is used to rule
out a positive match. This may lead to false positives.
|
|
|
|
Reserved space on the start of block_data for the headers during reading to
avoid temporary memory buffers and memcpy()'s.
|
|
|
|
- use -no-undefined flag only for building shared libraries (libxine, plugins)
- plugins LDFLAGS unification
- move -no-undefined into LDFLAGS_NOUNDEFINED
- attributes.m4 fix
|
|
|
|
|
|
Source: informational messages generated by lintian.
|
|
|
|
|
|
|
|
|
|
|
|
Currently, just treat it exactly as if it were Matroska.
|
|
|
|
|
|
To reduce code duplication.
|
|
|
|
|
|
I don't know why I multiplied by integers _outside_ the parentheses. I blame
late nights.
Regardless, this fixes the skip every 24 seconds due to the truncation of
FRAME_TIME. The input_time is also more accurate for e.g. stopping cue tracks.
|
|
|
|
(Sample: http://samples.mplayerhq.hu/Matroska/H264%2bEAC3.mkv )
|
|
This makes seeking more accurate, I believe.
|
|
|
|
|
|
|
|
This bug appears to be a variety of aliasing bug, caused by the compiler not
knowing that buffer is written to by ...->read(). On i386, the bug shows up
because buffer[0] has to be re-read when extracting the sample rate etc.; on
amd64, it works fine because the value was cached in a register.
The problem is avoided by not read()ing into any storage more than once
while it remains in scope.
|
|
|
|
The content of large PES packets must be split into several input buffers.
The current code attaches the PTS of the PES packet to all input buffers.
A decoder must attach PTS to the image for example which starts next in
the data. If the same PTS appears on several input buffers, a decoder
might buffer the PTS and attach it to the next image for which the
broadcaster didn't supply a PTS. Finally xine's metronom gets confused
about those incorrect PTS and tries to correct that issue which usually
makes things even more worse. By passing on PTS just once to the decoder
it is less likely that the decoder behaves incorrect.
I must admit that this is the second approach to fix this issue. The
first approach slipped through into a totally different changeset and
instead of passing the PTS just on the first buf, it passed it on the
last buf of a PES packet which was totally wrong. This incorrect approach
has been reverted recently.
|
|
We pretend that it's 16-bit to avoid "audio device unavailable" (ALSA).
Also, the clock is a bit fast.
|
|
|
|
|
|
|
|
BUF_FLAG_FRAME_END.
Fixes BluRay PCM audio when PES payload size is less than 2048 bytes.
|
|
|
|
|
|
Its resolution was in frames (+/- ~1 second), now it is calculated from the
number of samples, as it should be.
|
|
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.
|
|
undefined.
|
