Description of problem: As described here http://forums.fedoraforum.org/showthread.php?t=163733, when trying to open a dvd-video .iso image file both totem-xine and the xine media player report an error saying that no demuxer was found. Thinking that it may be a xine-lib issue, I reported this bug here - if it's not the right place, please let me know where I should report this. Version-Release number of selected component (if applicable): 1.1.7 How reproducible: Open DVD-Video .iso file image with totem-xine or xine. Steps to Reproduce: 1. 2. 3. Actual results: Player does not open the file. Expected results: The player should play the file. Additional info: Thanks.
Neither xine or totem-xine are Fedora packages, and the Fedora xine-lib does not contain software MPEG playback features so even if the .iso would open, the video wouldn't play with the Fedora xine-lib alone. http://fedoraproject.org/wiki/ForbiddenItems Chances are that wherever you got xine and totem-xine from may also have a xine-lib addon package available that provides actual DVD/MPEG playback functionality for xine-lib. Also, you didn't mention how you tried to open the .iso - I think at least from the command line for xine the command should be like "xine dvd:///path/to/foo.iso"
Interestingly enough, using "xine dvd:///path/to/foo.iso" or "totem dvd:///path/to/foo.iso" works, but the File - Open method or "xine foo.iso" doesn't work... I thought that unencrypted DVD playback was provided by the xine-lib package shipped with Fedora, but looking over the link you posted above makes it clear that it's not. Thanks very much for the prompt answer. Adrian
To clarify, unencrypted DVDs are not the problem per se, there are several applications dealing with those already in Fedora (libdvdread, k3b, dvdauthor etc). The problem is decoding the MPEG audio/video streams on the DVD in software. Nevertheless, there's an open bug for adding the "raw" DVD support to xine-lib as there is at least one hardware solution supported in Fedora that can be used for the playback without the software decoding encumbrance, see bug 213597