| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
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.]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
--HG--
extra : transplant_source : %F5K%AE%D3f%EFQ%F5U%E5%FE%BB%1E.%2Beh%C5%20%7F
|
|
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.
|
