Description of problem: After update to xine-lib-1.1.11.1-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): xine-lib-1.1.11.1-1.fc8 How reproducible: always Steps to Reproduce: 1.update to xine-lib-1.1.11.1-1.fc8 2.install xine or totem-xine or Miro from livna 3.try to play some MP4 videos Actual results: 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." Expected results: can piew MP4 videos. Additional info:
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-1.1.11.1-1.fc8 and xine-lib-extras-1.1.11.1-1.fc8 and xine-lib-extras-nonfree-1.1.11.1-1.lvn8, It won't. Anyway, I opened a new bug report for xine-lib-extras-nonfree to bugzilla.livna.org. Thanks.
The bug actually is in the Fedora xine-lib package; specifically it's an upstream regression in the Quicktime demuxer, introduced in 1.1.11.1. There's a similar but worse (crasher) Matroska regression in it, too.
xine-lib-1.1.11.1-1.fc8.1 has been submitted as an update for Fedora 8
xine-lib-1.1.11.1-1.fc7.1 has been submitted as an update for Fedora 7
The F7 update I pushed is also affected (it's also an 1.1.11.1), 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-1.1.11.1-1.fc8.1 and xine-lib-extras-1.1.11.1-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 and livna. 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? - 1.1.11.1. - Require xine-lib(plugin-abi) instead of xine-lib.
The synchronization issue is a separate issue, this bug has nothing to do with xine-lib-extras-nonfree.
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?.
https://admin.fedoraproject.org/updates/F8/pending/xine-lib-1.1.11.1-1.fc8.1
xine-lib-1.1.11.1-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-1.1.11.1-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.