Bug 213597

On the other hand, if this is accepted, it needs to be checked how players
behave with DVDs if there's no software or hardware available for decoding data
for viewing.  Users who have MPEG decoding hardware represent a very small part
of Fedora userbase, and the experience shouldn't be too confusing for those who
don't have it.

We have libdvdread now in Extras.

Alas, xine-lib uses libdvdnav.  I wonder if someone would be interested in
checking if it's ok for inclusion and if it is, submitting it?

I seem to remember that compiling the DVD bits in xine-lib is dependent on one
or more of libspu, libspucc and/or libspucmml which are currently pruned from
the xine-lib tarball, but the cleanup script doesn't mention why.  Aurelien?

It was disabled in the SuSE rpm I based mine on, with this notice :
  # I am not sure about these plugins, they need to be checked
  xineplug_decode_spucmml
  # Closed Captioning Decoder (EIA-608). Patented ???
  xineplug_decode_spucc
  xineplug_decode_spu
  xineplug_decode_sputext

You can check the current srpm here:
http://download.opensuse.org/distribution/10.2/repo/src-oss/suse/src/xine-lib-1.1.2-39.src.rpm
To stay on the safe side, I did not include those plugins, but it would be
better if someone from Legal reviewed them.

libdvdnav has been submitted: bug 375871.

libdvdnav is in.

(In reply to comment #4)
> It was disabled in the SuSE rpm I based mine on, with this notice :
>   # I am not sure about these plugins, they need to be checked
>   xineplug_decode_spucmml
>   # Closed Captioning Decoder (EIA-608). Patented ???
>   xineplug_decode_spucc
>   xineplug_decode_spu
>   xineplug_decode_sputext

I can't find any patents on DVB, CMML or CC decoders. Software encoders, yes,
but not software decoders. CMML is already being used by OGG.

You should be able to bring these bits back in, assuming they don't drag in any
of the other untouchable bits.

Thanks for the info, spot.  To clarify:

> I can't find any patents on DVB, CMML or CC decoders. Software encoders, yes,
> but not software decoders. CMML is already being used by OGG.

The DVB SPU decoder has been included already for a while.  Did you mean the
DVD/VOB SPU decoder (src/libspudec in upstream vanilla tarball,
xineplug_decode_spu plugin) and that it would be ok to include it as well?


Also, I'm wondering whether the MPEG and friends demuxers need to be excluded. 
We already have things that demux MPEG or MPEG-like things in the distro, see
eg. bug 191036 comment 14.  But anyway the demuxer code should be reviewed by
someone competent enough to tell whether it stays within demuxing and is not a
decoder.

Yes, sorry. I meant libspudec.

I'd have to look at the MPEG stuff more specifically, lets leave that aside for now.

Ok, I've experimented with this.  It is possible to get these built without
bringing in any of the things not welcome in Fedora.  The only apparent drawback
I could find is that the xineplug_decode_spu plugin requires use of the bundled
libdvd{nav,read}, it is not compatible with the libdvd{nav,read} packages in Fedora.

However, I also noticed that my original motivation for doing this doesn't
actually get fulfilled by this; em8300 cards don't do MPEG audio decoding in
hardware so building dxr3 support in xine-lib despite of these changes being in
is not that good an idea because then 3rd party packages that have MPEG support
couldn't easily replace the crippled PCM/AC3 (both in hardware) only dxr3
plugin.  There might be other Fedora supported hardware that would benefit from
this though.

So, I'm inclined to proceed with getting these new spu plugins built in, but
leaving the dxr3 plugin out, even though it'd use the bundled libdvd{nav,read}
for now.  Opinions?

(In reply to comment #10)
> Ok, I've experimented with this.  It is possible to get these built without
> bringing in any of the things not welcome in Fedora.  The only apparent 
> drawback I could find is that the xineplug_decode_spu plugin requires use of
> the bundled libdvd{nav,read}, it is not compatible with the libdvd{nav,read}
> packages in Fedora.

Why is it not possible to use external libdvd{nav,read}?

(In reply to comment #11)

> Why is it not possible to use external libdvd{nav,read}?

From the part you quoted:

> > it is not compatible with the libdvd{nav,read} packages in Fedora.

More specifically, libdvdnav detection tests in configure fail miserably
(partially because of bug 428910, but fixing that is not enough), header names
have changed and/or some of the headers xine-lib expects to find are not
included in the Fedora libdvdnav/read-devel packages.  At that point I lost
interest.  If you decide to beat it into shape, patches welcome.

libdvdnav should be fixed now. Hopefully it makes the next rawhide push. I also
fixed libdvdnav and libdvdread in F-7/8. Should hit -testing soon.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Just a ping to make sure no one is waiting on me for anything here.

(In reply to comment #15)
> Just a ping to make sure no one is waiting on me for anything here.

Comment #9?

Also, I'm bumping this to rawhide, because I don't know when I'll have some time
to look at it.

Created attachment 314848 [details]
patch to fix detection of and building with external libdvdnav

Here's a patch for F-8 and F-9. Please hold off with rawhide for now, I have some changes to libdvdnav pending upstream decision.

(In reply to comment #16)
> (In reply to comment #15)
> > Just a ping to make sure no one is waiting on me for anything here.
> 
> Comment #9?

It's been so long that I don't remember what I was checking into here. Can you refresh my memory on what you want me to be looking into?

(In reply to comment #18)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > Just a ping to make sure no one is waiting on me for anything here.
> > 
> > Comment #9?
> 
> It's been so long that I don't remember what I was checking into here. Can you
> refresh my memory on what you want me to be looking into?

I'm not sure, really, but see Comment #8.

I'm going to err on the side of caution here and say that we should leave the MPEG demuxer bits out... several comments seem to imply the same code could be used for decoding, and I'd rather not risk it.

And which comments in what files would that be? I've just skimmed demux_mpeg*.c and demux_ts.c and there is no decoding code in them.

demux_mpeg_pes.c: *   This code might also decode normal MPG files.

One comment (not several!), at the top of the file, before any code. And I couldn't find any code that does decoding of video data, so I think they meant "demux normal MPG files". We could ask upstream.

Hmm, okay. Ask upstream on this one.

Did upstream ever respond?

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

(In reply to comment #25)
> Did upstream ever respond?

Sorry, I didn't get to asking them before. Done now, awaiting reply:

http://sourceforge.net/mailarchive/forum.php?thread_name=20081202003136.GA8154%40mokona.greysector.net&forum_name=xine-devel

And there's one:

http://sourceforge.net/mailarchive/forum.php?thread_name=200812020302.30985.hftom%40free.fr&forum_name=xine-devel

Is that enough to lift FE-Legal?

Yeah, the MPEG demuxer bits are fine to go in.

whew, quite a novel here, OK, I can take a crack at making this happen finally... sorry for the delay.

xine-lib-1.1.16-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/xine-lib-1.1.16-1.fc10

xine-lib-1.1.16-1.fc9.1 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/xine-lib-1.1.16-1.fc9.1

xine-lib-1.1.16-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

xine-lib-1.1.16-1.fc9.1 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.