possible bugs in xine-lib-1.1.11.1

[Robert Daniels]

Current is xine-lib-1.1.12

"This release contains a security fix (unchecked array index, CVE-2008-1686). There are also a few bug fixes (including the 1.1.11.1 regressions), a new version of the pulseaudio output plugin, and open-source support for RealAudio “cook”."

[Randy McMurchy]

Because it is so late in the game and a BLFS release is right around the corner, could you ensure that all packages that link against xine-lib will build *and* work properly before updating the book.

My experience is that the Multimedia packages are the worst ones for introducing regressions with one another. If we can't get all the testing done, perhaps we can patch the security problems and defer the update until after the BLFS release.

[Robert Daniels]

Replying to randy@linuxfromscratch.org: Aside from the security fixes, the biggest reason to upgrade is KDE4, which wants a version >= 1.1.9. As KDE4 is not going to be in 6.3, patching may be the way to go, but I will try to get to the upgrade over the next few days.

Packages I see to test are kdemultimedia (is fine), amarok (also fine), xine-ui, and totem. Anything I missed?

[Randy McMurchy]

Looks like you got 'em all. XFCE (removed) and the old gst-plugins (deprecated) are the only things I can see that reference xine-lib. Probably a good test is playing a DVD movie in Totem. Seems also that the Xine-UI package also has an update, but not sure if we need it.

Thanks, Robert

[Randy McMurchy]

Thinking about it more, it might be easier for me to drop in the new xine-lib as I've already got the full GNOME stack and totem installed. I could test.

If you also have GNOME and totem installed, disregard this as it would just be a simple test after you get the new xine-lib installed.

[Robert Daniels]

I have never installed gnome before. If you can easily test totem out, that would be great. I can test out xine-ui no problem.

[Robert Daniels]

Is the note about --with-xv-path still needed? XFree86 is no longer in the book, and a by-the-book installation of Xorg has the compatibility symlink.

I would like to remove the note. At the least it should no longer mention XFree86.

[dnicholson@…]

I just looked, and --with-xv-path does nothing. Xine uses pkg-config to find libXv now.

[Robert Daniels]

xine-lib-1.1.10.1 breaks xine-ui-0.99.4, but works fine with xine-ui-0.99.5. Both will have to be upgraded if xine-lib is.

That just leaves Totem.

[Randy McMurchy]

Replying to rdaniels:

xine-lib-1.1.10.1 breaks xine-ui-0.99.4, but works fine with xine-ui-0.99.5. Both will have to be upgraded if xine-lib is.

That just leaves Totem.

Not sure how/why there is so much difference in what I have installed and what is in the book.

rml@rmlinux: ~/build > xine-config --version 1.1.7

But the book has 1.1.1

Not sure why I didn't update the book. It's been so long that I've actually used something that uses xine-lib that perhaps something isn't working right, so I didn't update the book. I've slept many times since installing 1.1.7.

I just popped a DVD in the drive and it works just fine playing though Totem. Maybe not too much of a test, maybe it is, not sure.

Anyway, I'll uninstall 1.1.7 and install 1.1.10.1 and test again.

[alexander@…]

There were some issues with some old version in the LiveCD repository, that's why there are additional ./configure arguments. With the new version, the problems may be still present or may no longer exist, thus this has to be retested.

--disable-opengl: this output plugin only produced X errors with xfmedia on unnaccelerated indirect rendering (e.g., in VMware or QEMU), and was picked up by default.

--disable-optimizations: without this, xine is compiled with various -falign-* CFLAGS, and on some occasions (e.g., external ffmpeg) this led to the "Compiler did not align stack variables. Libavcodec has been miscompiled" message (I don't remember whether I could reproduce this with internal ffmpeg, but see below).

Also, there is a bug in the internal ffmpeg that leads to green goo appearing from the left in H.264 videos. This is very easy to hit, just encode some scene with motion of something like snow from the left (oops, I forgot, x264 is not in the book), and in fact affects many videos found in P2P networks. Debian worked around this by using external ffmpeg: ​http://bugs.debian.org/395869

As I said, these are old bugs that certainly happen in the old version of xine-lib, and should not be the reason to postpone upgrading.

[alexander@…]

testcase for green artifacts, originally from ​http://www.shocknife.com/video/activated_blade_lo.mov

[Randy McMurchy]

Wow! Some pretty high-tech stuff there Alexander. Nice summary of perhaps still-existing bugs. Not sure if we can check all that, but it's nice to know that someone at least has the details down as well as you do.

Anyway, I built new xine-lib and totem worked fine. I then built Totem again using the xine-lib backend (without issues) and it worked fine.

As far as I can tell, it's safe to update xine-lib.

[Robert Daniels]

Fixed in rev.7267 and rev.7268.

[alexander@…]

New version is not retested for bugs (with at least xine-ui and gxine), reopening.

[Randy McMurchy]

I also meant to note on this ticket before Dan updated that it would be nice to get the docs from the xine-lib package into a versioned directory. I had already run configure and make before I remembered I wanted to fix this so I used:

make docdir=/usr/share/doc/${PACKAGE_NAME}-${PACKAGE_VERSION} install

Not sure if we can pass it to configure via --docdir. I didn't try.

[Robert Daniels]

Since xine-lib has been updated again by ken in rev 7335, I believe we can reclose this bug now. Comments?

[alexander@…]

No, this ticket can't be closed until (g)xine built against xine-lib, compiled according to the recommended instructions in the book, plays the attached file without green artifacts and doesn't crash with the default video output plugin in VMware. Or, until the reader is warned that xine-lib is buggy, with detailed description of all valid bugs mentioned in this ticket.

[bdubbs@…]

Replying to alexander@linuxfromscratch.org:

No, this ticket can't be closed until (g)xine built against xine-lib, compiled according to the recommended instructions in the book, plays the attached file

I can't play it at all. What plug in does it need? It plays fine in mplayer.

Actually, it sounds like the problem may be an external plug in, not something built into xine-libs.

Also, version 1.1.12 is out.

[alexander@…]

The video file uses H.264 video codec (part of ffmpeg, and the green artifacts are the bug in the included ffmpeg). gxine on the LiveCD can play the file, but produces artifacts.

[bdubbs@…]

The problem may be in gxine or in the gnome-vfs dependent parts. I do not have GNOME_VFS installed and the log says those parts are disabled.

When I run xine, I get:

"There is no demuxer plugin available to handle 'activated_blade_lo.mov'. Usually this means that the file format was not recognized."

I have a lot of files in /usr/lib/xine/plugins/1.20/ like xineplug_dmx_*.so but nothing has a 264 in the filename. What should I be looking for?

I have not yet tried 1.1.12.

[alexander@…]

Maybe you attempted to save it by right-clicking the link and choosing "save as". This saves a small HTML page instead of the MOV file. The correct URL is ​http://wiki.linuxfromscratch.org/blfs/attachment/ticket/2476/activated_blade_lo.mov?format=raw

And here are the decoders used by gxine for this file:

xineplug_inp_file.so
xineplug_dmx_qt.so
xineplug_decode_ff.so  (from internal ffmpeg)

and the video output plugin that depends on the system. As I said, please try LFS LiveCD before claiming that the file is unplayable.

[alexander@…]

For testing H.264 decoding, you can also use ​http://kerrek.linuxfromscratch.org/~alexander/bug897.avi and ​http://kerrek.linuxfromscratch.org/~alexander/circlebug.avi (my bug reports against the PlaneShift game). These two AVI files also use H.264 codec and thus should be playable by anything based on ffmpeg (and I consider the ability to play H.264 files essential, as it is the preferred format for HDTV rips in P2P networks). However, they don't trigger the "green goo" artifact in gxine.

[bdubbs@…]

The unplayable problem was 1.1.11.1. Updating to 1.1.12 allows the file to be played, but it still has the green artifacts.

So, the issues are:

1. Do we upgrade to 1.1.12 for BLFS 6.3. (I'd say yes.)
2. Where do we go from here? I'll try to build --with-external-ffmpeg and see what happens.

[bdubbs@…]

Adding --with-external-ffmpeg fixed the artifact problem for me.

My approach would be to be to use this in the instructions and make ffmpeg a recommended dependency.

[bdubbs@…]

Updated to xine-lib-1.1.12 at revision 7397.

Fixes green artifact problem noted in the ticket comments by using the external ffmpeg library.

[alexander@…]

Bruce, there were other bugs mentioned: "Compiler did not align stack variables. Libavcodec has been miscompiled" (due to various -malign CFLAGS that are used by default), and crash with unaccelerated OpenGL output. Unless you have tested that those two bugs no longer exist, it is wrong to close this ticket.

[alexander@…]

Also, xine-lib requires libpostproc from ffmpeg, and libpostproc is not built by default on the ffmpeg page. I suggest either changing the default on the ffmpeg page, or changing the wording on the xine-lib page to state explicitly that --enable-pp --enable-gpl are required ffmpeg switches.

[bdubbs@…]

Do NOT reopen this ticket. Start a new one of necessary.