| Age | Commit message (Collapse) | Author |
|---|
|
|
|
(Sample: http://samples.mplayerhq.hu/Matroska/H264%2bEAC3.mkv )
|
|
|
|
|
|
This makes seeking more accurate, I believe.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When opening empty files with xine, it reports:
> This is xine (X11 gui) - a free video player v0.99.6cvs.
> (c) 2000-2007 The xine Team.
> system call fstat: Bad file descriptor
> system call fstat: Bad file descriptor
> call failed
> object not accessible
> object not accessible
> call failed
The problem was that when detecting an empty file, it is closed, but the file
descriptor in struct file_input_plugin_t is still left at the previous value,
causing the errors when it is used later.
|
|
|
|
|
|
Based on patches from Roger Scott <ras351@hotmail.com>.
|
|
Rename "wmav3" to "wmapro" in xine-lib's internals to line up xine-lib's
nomenclature with what everyone else calls it and knows it as.
[Tweaked by ds to avoid API change.]
Tell xine-lib that when it finds wmapro, look to ffmpeg.
ffmpeg's wmapro decoder is unique in that it puts out samples that
are floats, not 16-bit ints. These need to be converted.
This requires external ffmpeg.
|
|
This will reduce logspam with little-endian streams, which Can't Happen anyway.
|
|
I have LCPM 24bit DVD.
When I played it on xine, sound was noisy noise. I found that LCPM 24bit
byte stream is _not_ the same as WAVE 24bit byte stream.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
