[MPlayer-dev-eng] [FYI] new versions of libdvdread 0.9.3 and libdvdcss 1.2

[D Richard Felker III]

On Mon, Jun 03, 2002 at 12:26:12AM +0200, Clemens Wächter wrote:
> Well, I think that cracking all the keys is not such a bad idea since
> you can use them all when you implement dvd navigation support. And as
> far as I know it is not included right now in mplayer but it will be
> in the distant future, so maybe this becomes usefull some day...

Useful maybe, but it should be optional, and the default should
definitely be off when not in dvdnav mode. Without dvdnav, it's
absolutely useless. Even if you do

  mplayer -dvd 1 -dvd 2

I'm pretty sure it will crack them all when preparing to play title 1,
then crack them all again before playing title 2 (if it doesn't cache
them in ~/.mplayer).

> > Finally, one more thing, MPlayer seems to cache cracked keys in
> > ~/.mplayer for later use, which I don't recall stock dvdread doing.
> > Maybe it can do that now with the latest version, though...
> 
> Lets hope so. Cracking all the keys can sometimes be really annoying
> if it has to be done every time you try to play a dvd.

Sometimes?

> a) The CSS stuff included in those libraries may have ( have definitely ) legal
> implications. 

Yes. Well I'm not the one facing that crap, so I can't speak for the
authors. But IMO, it's very important that CSS cracking *not* be an
underground type thing, and that it be included in mainstream programs
and used by your average Redhat newbie. This is what will make the
brain damaged lawmakers and judges wake up and see what it really is
-- a necessary part of playing DVDs on a non-propriatary computer
platform -- and not a w4r3zk1dd13 tool.

In summary, strength in numbers.

> b) A library shipped with mplayer has to be maintained which costs time. Or is
> anybody willing to do that? (Hmmm.... thinking about wheter I am... but lets first
> hear what the rest of the community says)

A separate library (especially dvdread/dvdcss it seems) periodically
breaks things and that costs time telling users to RTFM. An included
library only needs to have new versions checked into CVS when they're
confirmed working.

> c) If you ship it with mplayer and compile and link it statically it takes more 
> bandwith to download, more space to compile and to run it. I have tons of Ram and
> hdd but others have not. Or think about mplayer on a embedded system. I don't know
> if anybody does this or plans this in the future but I like the "small is beautiful"
> approach.

The rm -rf libmpdvdkit before compiling. Certainly you don't compile
on an embedded system...

You're right about download time, though -- that is an issue. Not sure
what the best way to handle that is.

Rich