Upstream bugs in xine-lib

[alexander@…]

This is a continuation of #2476. Three upstream xine-lib bugs were mentioned there:

1) green artifacts on H.264 videos with the internal ffmpeg (fixed in the book by switching to the external ffmpeg, but the fact that the external ffmpeg has to be compiled with --enable-pp --enable-gpl is mentioned nowhere).

2) Broken (and crashing xfmedia, which is not in the book) OpenGL output as a reason to --disable-opengl: xfmedia still crashes. Gxine doesn't crash, but produces incorrect output when using unaccelerated OpenGL (and defaults to this broken output configuration in qemu or other emulators--you can probably reproduce this on a real machine by moving /usr/lib/dri out of the way and restarting X). The distortion with the same testcase file looks like overall greenish background, a ghost image of the blade shifted to the right from the real one, and purple artifacts on the right. Also, scaling is incorrect. The xshm output plugin produces the correct image. So, the --disable-opengl swtich is still a good idea. Maybe it also makes sense to disable other uncommon outputs such as a framebuffer.

3) Incorrect stack alignment causing the external ffmpeg to think that it has been miscompiled: I cannot reproduce this, and assume that it has been fixed upstream, so there is no need to pass --disable-optimizations as of xine-lib 1.1.12.

[bdubbs@…]

Have these bugs been tested with the now current versions of xine-libs and ffmpeg?

Marking as minor until they are validated.

1. ffmpeg text has been updated.

2. I don't use /usr/lib/dri, and I don't get an error. I do use nvidia closed source drivers though which has built in dri.

3. This is totally inappropriate as it's obvious it has not been tested with the current version.

[alexander@…]

1. The new text mentions mpg123, not xine-lib. Typo?

2. Indeed, the incorrect scaling bug is not reproducible with nvidia library, but does exist with software-rendering Mesa. Try rebuilding xine-lib with external ffmpeg and OpenGL support on the r2160 LiveCD and see it.

3. The point of bringing this up in this ticket was exactly to show that this kludge was mentioned in the previous ticket, but is no longer needed.

[alexander@…]

as for (1): the new text in the note essentially duplicates the information just above it. Maybe it is better to say something like this, with no note:

Additionally, you may want to build the postprocessing library as other packages such as MPlayer and Transcode can utilize it, and xine-lib depends on it. See the Command Explanations section for additional information.

[bdubbs@…]

Made the text change in revision 7401. If you need to tweak it, why don't you do it yourself?

[alexander@…]

Currently I am at work, and all ports are blocked at the firewall. I can only connect to other sites via HTTP through the proxy. So I can't make any changes from here. I will fix the typo when I return home.

[bdubbs@…]

I'm going to close this ticket because the remaining issues revolve about inconsistencies between xine-lib and other packages not in the book. We really can't determine if the problems described are the fault of xine-lib or the other packages.

Further comments about non-BLFS packages should go into the User Notes.