Age | Commit message (Collapse) | Author |
|
--HG--
branch : v4l
|
|
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.
|
|
|
|
--HG--
branch : v4l
|
|
--HG--
branch : v4l
|
|
|
|
|
|
|
|
|
|
|
|
There's a rendering bug when using the opengl fragment program if the width
of the video is not a multiple of 16.
U and V channels will have padding on each row because they always have
pitches which are a multiple of 8, glTexSubImage2D will copy the padding
data to the texture and the U & V channels will be skewed. The same also
applies to the Y channel when width is not a multiple of 8. Fixed by
passing pitch to glTexSubImage2D instead of width.
The U & V channels also have to be outlined in grey on the texture and if
there's padding then we need to add the line on the right to every frame
before calling glTexSubImage.
It also looks like the location of the V channel in the texture was off by
one pixel in the call to glProgramEnvParameter4fARB.
--HG--
extra : rebase_source : 1984e493f77e80081e55b7c3b816d3baea965e4e
|
|
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.
|
|
|
|
|
|
|
|
+ gapless).
|
|
|
|
BUF_FLAG_FRAME_END.
Fixes BluRay PCM audio when PES payload size is less than 2048 bytes.
|
|
|
|
--HG--
branch : v4l
|
|
--HG--
branch : v4l
|
|
Get rid of most compile-time warnings.
Clean up white space.
Mark xine_plugin_info as EXPORTED.
Fix xine-lib internal #includes.
Use #defines instead of many "#ifdef HAVE_LIBV4L2"/"#else"/"#endif".
--HG--
branch : v4l
|
|
--HG--
branch : v4l
|
|
It's ugly and works half the time, but it's there.
--HG--
branch : v4l
|
|
|
|
(data is lost if PCM frames are splitted in the middle)
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
TRACE and ERROR are now prefixed with XINE_HDMV_.
|
|
undefined.
|
|
|
|
|