| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hi, the next bug that has been annoying me is as follows.
I have some streams recorded from BBC4 on UK DVB-T. BBC4 only actually
starts transmitting at about 7pm; prior to that there is a static
picture saying it is not playing just now. With these streams and
xine, I would get audio, but no picture.
Looking at the PMT table during the static picture, all the streams
have type 0x0b. However there IS a video stream in there, but there
are also several streams of binary data.
Xine's current video PID auto-detection code was locking on to one of
these streams of binary data because it contained the magic sequence
00 00 01 e0 at one of the PUS. *HOWEVER* it is NOT a PES stream; this
sequence is just an accident. The other problem is that xine can only
handle one video stream; so once it was misdetected once, it was stuck
at that PID.
The attached patch changes the corrupted_pes flag into a counter. If a
video stream has more than CORRUPT_PES_THRESHOLD corrupt PES packets
in a row, then it is deselected as the video stream, and
auto-detection is kicked off again. Auto-detection will now also
ignore any streams seen previously which have a nonzero corrupted_pes
count. This works very well; I can now see the video fine.
One possible issue might be that if you get a lot of corrupt PES in a
stream which really IS the video stream, it will be deselected.
However, this is not actually a problem: once the corruption goes
away, the corrupted_pes counter will be reset to 0, and the stream
will once again be autodetected as the video stream (and playback will
continue from there).
|
|
|
|
|
|
Hi, I've been tracking down a very odd bug this afternoon. As it turns
out it is caused by enabling xine's mmap() support for the input_file.c.
I'm running 32 bit linux 2.6.21. The file in question is 0x10e4da000
bytes long (you can probably guess what kind of bug this is by now :)
Anyway, the issue stems from the definition of mmap():
void *mmap(void *start, size_t length, int prot, int flags, int fd,
off_t offset);
compare this to the definition of st_size in struct stat:
off_t st_size; /* total size, in bytes */
On my machine (in input_file.c) sizeof(size_t) ==4, whilst
sizeof(off_t) == 8. However the compiler doesn't generate a warning
when the following is done in xine's code:
if ( (this->mmap_base = mmap(NULL, sbuf.st_size, PROT_READ,
MAP_SHARED, this->fh, 0)) != (void*)-1
So it silently truncates the upper part of the length. Obviously you
cannot mmap() a file that large into (32 bit) memory anyway, but as it turns
out, mmapping() 0xe4da000 succeeds, which causes... problems.
The patch (against xine-lib 1.1.6) does two things:
* Check that the length will not be truncated, while still allowing
for mmap()s of large files under 64 bit OSes.
* A correctness fix: if mmap() fails, this->mmap_base will be set to
0xffffffff. Later on when the file is closed, this means it was
attempting to do munmap(0xffffffff).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--HG--
rename : doc/faq/faq.sgml => doc/faq/faq.docbook
|
|
|
|
|
|
|
|
|
|
|
|
from Hg.
|
|
|
|
|
|
|
|
|
|
variable.
|
|
|
|
|
|
|
|
|
|
|
|
--HG--
rename : doc/hackersguide/hackersguide.sgml => doc/hackersguide/hackersguide.docbook
rename : doc/hackersguide/internals.sgml => doc/hackersguide/internals.docbook
rename : doc/hackersguide/intro.sgml => doc/hackersguide/intro.docbook
rename : doc/hackersguide/library.sgml => doc/hackersguide/library.docbook
rename : doc/hackersguide/output.sgml => doc/hackersguide/output.docbook
rename : doc/hackersguide/overview.sgml => doc/hackersguide/overview.docbook
rename : doc/hackersguide/stream.sgml => doc/hackersguide/stream.docbook
|
|
This requires renaming po/libxine1.pot -> po/libxine2.pot.
--HG--
rename : po/libxine1.pot => po/libxine2.pot
|
|
|
|
--HG--
rename : debian/libxine-dev.install => debian/libxine2-dev.install
|
|
|
|
--HG--
rename : debian/libxine1-doc.docs => debian/libxine2-doc.docs
rename : debian/libxine1-doc.manpages => debian/libxine2-doc.manpages
|
|
|
|
|
|
suffix rules works.
|
|
|
|
|
|
|
