| Age | Commit message (Collapse) | Author |
|---|
|
Attached is a little patch that allows using ffmpegvideo w/o direct rendering
to play mpeg2 ts.
It works for both mpeg2 and h264.
|
|
|
|
|
|
|
|
of the file.
|
|
|
|
|
|
Solaris definitions.
|
|
A null pointer dereference happens if reading a xv port attribute
(which has been reported as readable) fails. This issue exists for
example with proprietary (and a bit buggy ...) ati drivers;
nevertheless it shouldn't cause a segmentation fault (the non-xcb
version simply stores an unitialised value).
This patches solves the issue in a clean way for both branches.
Fixes debian bug #428612 :-)
|
|
xine-lib-specific patch.
|
|
Applied to FFmpeg tree already.
|
|
Applied to FFmpeg tree already.
|
|
|
|
Inspired by a patch by Albert Lee.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some plugins may have been missed due to them not being built here.
|
|
Some plugins may have been missed due to them not being built here.
|
|
|
|
|
|
|
|
config.h is now include/configure.h and no longer #includes os_internals.h.
A new file, include/config.h, #includes both; this breaks a #include loop.
Other files are updated accordingly.
|
|
|
|
I discovered some problems with the framebuffer output driver. The first
problem I had was a segfault when trying to play a 480x360 clip on a 640x480
display. I traced it to the yuv420_rgb16() color conversion function, which
was overrunning the input buffer (the "y" part of the image). The reason
was that it was being called downstack from fb_frame_proc_slice(), multiple
times for each 16-pixel high horizontal slice of the image. When it got to
the last slice, only 8 pixels were left to the bottom but it still tried to
process a 16-pixel high slice.
Nosing around a bit, I compared the configuration of the color converter as
used by the fb driver to the xshm driver and found some oddities:
1) The color converter was configured with a "source height" of 16 pixels no
matter what the size of the image, and a "dest height" based on what was
referred to within video_out_fb.c as a "stripe" -- essentially an input
slice scaled up or down as required by the output size.
2) Apparently to prevent the above from causing problems, the position in
the output buffer was managed by special code -- see the "stripe_incr"
variable.
3) The xshm driver calls yuv2rgb_next_slice() with a NULL argument at the
beginning of each frame to allow the color converter to reset its tracking
of the slice-by-slice progress through the image; the fb driver does not.
I'm not sure exactly why it was done that way, but my best guess would be
that whoever coded it didn't know about the need to call
yuv2rgb_next_slice() with a NULL argument, and the rest was built up to get
it to mostly work without that.
The attached patch changes the behaviour to match that of the xshm driver,
and also removes the reset_dest_pointers() function, replacing its single
invocation with one to fb_frame_field(), which is identical after removing
the "stripe" management.
It fixed my crash. Can anyone see if I've misunderstood what was going on?
If not, it should probably be applied to the official version.
|
|
|
|
close the driver on a return value <0
|
|
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).
|
|
|
|
misfire and report a good file as unplayable.
|
|
|
|
external libmad.
|
|
The attached patch fixes a problem with embedded references in recent
versions of quicktime's movie formats.
Apparently there is an additional atom (RMRA) before the RMDA atom: it
works like a container for all subsequent atoms, so it can be safely
skipped.
You can test yourself what I'm saying by watching some trailers at
apple.com (http://www.apple.com/trailers).
--
Regards,
Claudio Ciccani
klan@users.sf.net
http://directfb.org
http://sf.net/projects/php-directfb
|
|
makes little sense, move BE_*_synchsafe functions from id3.c to id3.h and declare them inline, then BE_32_synchsafe can be replaced to id3v2_tagsize as drop in.
|
|
iteration over the decoded frames to transform them to integer, and also avoids an improper saturation.
|
|
|
|
|
|
(was used by demux_flac only).
|
