| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
The licenses probably disallow the distribution of xine binaries built against mediaLib.
And on non-VIS capable boxes is probably worse than our own code.
|
|
|
|
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.
|
|
|
|
in 1.2 series.
|
|
|
|
|
|
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).
|
|
|
|
|
