Red Hat Bugzilla – Bug 205798
Review Request: xine-lib - The Xine library
Last modified: 2007-11-30 17:11:42 EST
Spec URL: http://gauret.free.fr/fichiers/rpms/fedora/xine-lib.spec
SRPM URL: http://gauret.free.fr/fichiers/rpms/fedora/xine-lib-1.1.2-12.src.rpm
This package contains the Xine library. Xine is a free multimedia player.
It can play back various media. It also decodes multimedia files from local
disk drives, and displays multimedia streamed over the Internet. It
interprets many of the most common multimedia formats available - and some
of the most uncommon formats, too. Non-default rpmbuild options:
--without imagemagick: Disable ImageMagick support
--with directfb: Enable DirectFB support
This probably needs an ack from legal before it makes much sense to spend time
on a review -> adding blocker on FE-Legal.
(Removing explicit Cc to me, I already receive the traffic through the
as with other media packages you will need to use a modified tarball with all
of the patented codec support removed.
That is already done, see comments in the specfile. I think a legal ack is
doesn't look like it
I see the comment in %prep it should be up with the sources.
# The tarball is generated from the upstream tarball using
# the script in SOURCE1. It prunes potentially patented code
comment should be moved and id have a guess that the ffmpeg patch dropped
Ah yes, sorry. This version actually builds...
* Tue Sep 12 2006 Aurelien Bompard <email@example.com> 1.1.2-13
- drop patches 2 and 4
Do you know how long the legal audit is likely to take ? Could we expect
xine-lib in FC6, or is it much too close ?
The SuSE specfile contains a mini-audit, if it can be of any help:
No idea. Some packages have been waiting a long time, eg. mkvtoolnix 9+ months
in bug 177134.
See also http://www.redhat.com/archives/fedora-extras-list/2006-August/msg00199.html
There was a word from someone that getting the legal queue moving would be put
on the Board's agenda, but I haven't heard more about that, and summaries for
the two last Board meetings seem to be missing from Wiki. Rex, any news?
> Rex, any news?
Other than the last 2 FPB meetings weren't held (for various reasons). I'll
make sure it's discussed by FPB at next opportunity.
How is this package going to coexist with the various xine-libs available from
"other repos" and legally used by people in countries with no software patents ?
Since xine-lib has to be crippled to make it into Extras, won't it create an
unnecessary annoyance ? Does it add real value to FE ?
xine-lib is the only viable engine on some arches for amarok. other repos
should be able to have a xine-lib-extras package that has non free bits for
those that can use them.
Re: comment #10
> other repos
If this makes it in, there are plans to also make a xine-libs-extras-nonfree for
> Does it add real value to FE ?
IMO, a *definite* yes. We'll be able to include apps that depend on
xine-lib-devel to build (otherwise they wouldn't be included in Extras *at all*).
Excellent! thanks for the clarification.
The liba52 code needs to go, it is patent encumbered and still present in the
tarball. Otherwise, it looks ok. Lifting FE-Legal, on the grounds that the
liba52 directory will be removed from the source.
Great news ! Thanks !
I've updated the pruning script to remove liba52 too :
- src/libdts: most likely needs to be removed. The code contains links to
http://www.videolan.org/dtsdec.html - check it out for more info.
- The option summary after ./configure contains lots of things containing the
word "mpeg" - is it just the message or does the source tarball require
- The cleanup script removes src/libspudec twice, maybe the other one was
supposed to remove something else?
- xine-lib-dxropts.patch is not needed because src/dxr3 is pruned.
- Build fails on x86_64:
(In reply to comment #16)
> - src/libdts: most likely needs to be removed. The code contains links to
> http://www.videolan.org/dtsdec.html - check it out for more info.
Probably need to be removed.
From libdts website: "Provisional Warning: DTS Inc. claims that use of libdca
software, to decode DTS compressed sound data on a DVD could violate DTS's
patent rights. If you are unsure about the legality of using and distributing
this code in your country, in particular in the USA, please consult your lawyer
before downloading it".
- removed libdts
- fixed the cleanup script to remove libspudec only once
- dropped dxr patch
- listed xineplug_decode_gdk_pixbuf.so and xineplug_vo_out_vidix.so only on x86
The mpeg-related configure switches are there to skip the mpeg tests (saves me
from hacking even more the configure script)
(In reply to comment #18)
> - listed xineplug_decode_gdk_pixbuf.so and xineplug_vo_out_vidix.so only
> on x86
This doesn't look like the correct fix to me. vidix is x86 only IIRC so that
part is maybe ok, but gdk-pixbuf appears to be just a matter of missing BR:
> The mpeg-related configure switches are there to skip the mpeg tests
Note that I was talking about the printed configuration summary
after ./configure is run, not switches passed to it. Eg.
* demultiplexer plugins:
- avi - mpeg
- mpeg_block - mpeg_audio
- mpeg_elem - mpeg_pes
- mpeg_ts - qt/mpeg-4
dts removal looks incomplete:
RPM build errors:
More later tomorrow - others' feel free to chime in on the review.
You're right about gdk_pixbuf, I thought you meant you tried on both x86 and
x86_64 and it failed only on the latter.
- add BR gtk2-devel
- remove xineplug_decode_gdk_pixbuf.so from x86-only
find -name "*mpeg*" in the sources dir yields some results, but I don't think
it's mpeg decoding code. It looks more like interfacing with ffmpeg or code for
the mpg container. In any case, I trust Legal in this.
I tried to build the package in mock, and it fails because of an improper
selinux label on /usr/lib/libSDL-1.2.so.0.7.2. Is it fixable ? Will it fail in
the Fedora Buildsystem ?
Ok, getting closer. It now builds and a q'n'd-modified and rebuilt FE5 amarok
works nicely with flacs on x86_64.
Just an observation: xine-lib appears to ship and use its private slightly
customized copies of libmatroska and libmpcdec (and possibly other things),
and doesn't provide an option to use the system ones. Not nice, but not a
blocker IMO either.
The installed docs should be reviewed for usefulness, at least README.dxr3 and
README.MINGWCROSS look like clear candidates for removal.
About some input plugins: are MMS, RTP, and RTSP ok to be included? AFAIK MMS
is proprietary (libmms was not submitted to FE, I think Hans asked about it
sometime ago), and a quick Googling session revealed these for the two latter.
spot, your thoughts on the above?
About the SDL issue, no idea. No problems building it for FC5 here, using
RTP looks ok because Microsoft is stating in that document that they are
granting a "Royalty-Free, Reasonable, and Non-Discriminatory License to All
Implementers" in that RFC. Likewise, the Real Networks document seems to cover
The MMS protocol implementation on the other hand is definitely not
royalty-free, and needs to go.
- cleanup docs
- remove mms
- delete more source files in the cleanup script
- drop patch3 (affecting mms)
About the 3rd line, I realized I did not remove all the source code files in the
input plugins dir, so I changed the script to do that.
The failure in mock may be beacause my FC5 is a yum-upgraded FC4, I don't know.
Ok, looks even better. One more question about pruned stuff:
What's the problem with including the DVD reading functionality in this
package? The capability to read data from encrypted DVDs is not implemented
directly in xine-lib as far as I can tell. Based on some recent discussions
in private mail with spot, that would be the only real problem with including
DVD reading libraries in Fedora.
The ability to read unencrypted DVDs would be useful to have. And even though
the actual MPEG data on them couldn't be decoded in software with packages in
Fedora, there are hardware solutions to that, such as the em8300/dxr3 cards
supported by the em8300* packages in FE, and probably full-featured DVB cards
(ie. ones that have a MPEG decoder chip). Enabling libdvdnav in xine-lib
would also allow enabling the dxr3 hardware MPEG decoding functionality in it.
The dxr3 functionality here is associated with libavcodec, rte, and fame, all
of which can't be included in Fedora, but they're only used to re-encoded
non-MPEG content to MPEG for feeding to the em8300 devices. MPEG playback
with em8300 requires none of those.
At the moment, libdvdnav is not in Extras, so we need to review and accept it
before enabling dvd support in xine-lib. Since the libdvdnav sumbission will
have to go through Legal review, it may take some time.
So I'd rather have xine-lib without dvdnav support imported in the close future,
and add the support when libdvdnav is in Extras.
Are you guys OK with that ?
Ville, would you like to co-maintain xine-lib with me in Extras ?
Yeah, feel free to add me as a co-maintainer when this goes in.
Note that xine-lib uses a bundled/modified libdvdnav by default, dunno how
feasible would it be to try to convert it to use an external one. But yeah,
that can be looked into later.
I have nothing to add here at the moment, so as far as I'm concerned, this is
approved. I'll set this to FE-ACCEPT tomorrow in order to provide a bit of
time in case someone (spot?) wishes to take one more look at the package
contents. Please delay importing until this is in FE-ACCEPT state.
Oh, one little thing, I think xineplug_decode_gdk_pixbuf.so and
xineplug_vo_out_caca.so are good candidates for moving into the list of
plugins potentially to be moved to a xine-lib-extras subpackage later.
Moving to FE-ACCEPT.
Imported and built, thanks a lot !
Package Change Request
Package Name: xine-lib
Updated Fedora Owners: abompard,scop
Updated Fedora CC: [none]
I've been already co-maintaining this package for a while, so I suppose it
wouldn't hurt to move me from initialcc to a real co-maintainer.
Package Change Request
Package Name: xine-lib
New Branches: EL-5
Updated EPEL Owners: scop,abompard