Red Hat Bugzilla – Bug 441705
xine-lib-184.108.40.206-1.fc8 can't play MP4 videos
Last modified: 2008-04-16 23:55:13 EDT
Description of problem:
After update to xine-lib-220.127.116.11-1.fc8, any media players require xine-lib
can't play MP4 (QuickTime) videos. For example, kmplayer, kaffeine, xine,
totem-xine and Miro.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.update to xine-lib-18.104.22.168-1.fc8
2.install xine or totem-xine or Miro from livna
3.try to play some MP4 videos
got a message "-xine engine error- There is no demuxer plugin available to
handle 'foobar.mp4'. Usually this means that the file format was not recognized."
can piew MP4 videos.
mp4 support (afaik) requires nonfree plugin support, WONTFIX (here).
Hint: install xine-lib-extras-nonfree from some other repo. :)
The xine-lib-extras-nonfree is already installed.
With xine-lib-1.1.11-1.fc8 and xine-lib-extras-1.1.11-1.fc8 and
xine-lib-extras-nonfree-1.1.11-1.lvn8, I can play MP4 videos.
With xine-lib-22.214.171.124-1.fc8 and xine-lib-extras-126.96.36.199-1.fc8 and
xine-lib-extras-nonfree-188.8.131.52-1.lvn8, It won't.
Anyway, I opened a new bug report for xine-lib-extras-nonfree to bugzilla.livna.org.
The bug actually is in the Fedora xine-lib package; specifically it's an
upstream regression in the Quicktime demuxer, introduced in 184.108.40.206. There's a
similar but worse (crasher) Matroska regression in it, too.
xine-lib-220.127.116.11-1.fc8.1 has been submitted as an update for Fedora 8
xine-lib-18.104.22.168-1.fc7.1 has been submitted as an update for Fedora 7
The F7 update I pushed is also affected (it's also an 22.214.171.124), so I submitted
a matching update for F7.
Maybe next time we should be backporting security fixes rather than upgrading
for near-EOL releases? (There'll not be an issue of fixes accumulating if we
only do it for near-EOL.) On the other hand this means even less testing,
because pushing a rebuilt F8 package means at least it got tested on F8. I'm
open to suggestions there.
I downloaded xine-lib-126.96.36.199-1.fc8.1 and xine-lib-extras-188.8.131.52-1.fc8.1,
and they work as a charm. Thank you very much.
While the xine-lib is one of "still in development" software, backporting is not
a good idea, I think.
I consider that the problem was synchronization issue between updates-testing
Most xine users like me also depends on xine-lib-extras-nonfree.
Although new xine-lib had been submitted to updates-testing, testers couldn't
install it until matching xine-lib-extras-nonfree was submitted to livna.
But this synchronization issue was gone by change of xine-lib-extras-nonfree
package below, wasn't it?
- Require xine-lib(plugin-abi) instead of xine-lib.
The synchronization issue is a separate issue, this bug has nothing to do with
As for testing, as a security update, this update shouldn't have gone through
updates-testing at all, the reason it did was a synchronization issue (yet
another one) between the security team approval and the updates push.
I think in this case the regressions were very closely related to the security
fixes, so backporting the fixes without additional code review probably wouldn't
have prevented the regressions.
*** Bug 441715 has been marked as a duplicate of this bug. ***
I too have this problem. I don't seem to see any updates for the xine-lib
package in the repos (updates or updates-testing). How do I get it?.
xine-lib-184.108.40.206-1.fc8.1 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
xine-lib-220.127.116.11-1.fc7.1 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.