[MPlayer-dev-eng] [Patch] Re: what happened to the blu-ray support

[compn]

On Wed, 30 Jun 2010 00:15:58 +0200, Alexander Roalter wrote:
>On 06/29/2010 10:52 PM, Benjamin Zores wrote:
>> 2010/6/28 Alexander Roalter <alex at roalter.it>:
>>> On 06/28/2010 10:42 PM, Alexander Roalter wrote:
>>>> On 06/28/2010 08:46 PM, Alexander Roalter wrote:
>>>>> On 28.06.2010 20:05, Reimar Döffinger wrote:
>>>>>> On Mon, Jun 28, 2010 at 07:46:41PM +0200, Alexander Roalter wrote:
>>>>>>> Ok, here at work with a bit artificial code I get the correct results on
>>>>>>> both 32bit and 64 bit systems... Will have to see what's different on my
>>>>>>> home machine...
>>>>>>
>>>>>> Different compiler? I think the aes code is at least not strict-aliasing safe
>>>>>> currently...
>>>>>
>>>>> Gcc 4.4 at home (IIRC) gcc 4.3.2 on the on-site 64bit, 4.2.4 on the
>>>>> 32bit machine.
>>>>>
>>>>> at home I have an OpenSuse 11.1 (or .2), here debian and ubuntu, resp.
>>>>>
>>>>> should I try with different -O settings?
>>>>>
>>>> I have compiled libavutil/aes.c withouth -O4 (from config.mak), and now
>>>> the results match.
>>>>
>>>> The video doesn't play, though... :(
>>>>
>>> Ok, now the video plays (stupid change from my part when fixing the
>>> patch according to the suggestions without further thinking).
>>>
>>>
>>> Ok, here comes the patch (with a very ugly routine to read from
>>> ~/.dvdcss/KEYDB.cfg the VUK for a known Blu-ray. if the key is not
>>> found, the routine bails out, if the KEYDB.cfg file is not found, too.
>>> Reading is very ugly with fgets and sscanf and strstr; I'm simply not
>>> used to working with these functions nowadays... perhaps it will come back.
>>>
>>> The syntax is still the same: mplayer bd://title@vuk/path, but VUK can
>>> now be any string, the disc still has to be mounted at /path.
>>>
>>> The integration in the Makefile is as it was before, don't know what
>>> should be done there.
>> 
>> Please forget about this patch.
>> Bluray support has to use libbluray and having this temporary code
>> really makes no sense as it clearly has no future.
>> 
>> Attached is a very rough patch that plays a BD through libbluray.
>> It's ugly and BD disc path is hardcoded but I really had no more time
>> on tonight.
>> 
>> Please test it and if it's working for you, then I'll work on it to
>> have a clean inclusion within MPlayer, with all cmdline options
>> parsing, slave mode control and such.
>> 
>> To test it out:
>> - fetch libbluray: git clone git://git.videolan.org/libbluray.git
>> - bootstrap/configure/make/install it
>> - patch mplayer SVN tree with attached patch.
>> - edit stream/stream_bd.c:102 to use your disc path instead.
>> - configure/build mplayer
>> - ./mplayer bd://
>> 
>> *** It'll only work on descrambled BD right now. ***
>> 
>> libbluray avantages:
>> - LGPL
>> - full MPLS and CLPI parsing: i.e. playlist support, titles / chapters
>> / angles retrieval and switch
>> - no descrambling code in it: no licensing/redistribution issue
>> - if by any luck libaacs.so and libbdplus.so would be present in your
>> LD path, then it would however be possible to read scrambled BDs (but
>> that's not the point).
>
>And what's keeping me from adding the current approach, i.e. if the disc

well, this patch would require some work, both now and in the future.
since there is a lack of developers working on all of this, it
would be best to pool the resources onto the best looking one. and
libblurray obviously has the most people working on it atm.

that said, i'd still like to see both in mplayer, like dvd:// and
dvdnav:// . its useful to debug libbluray against another
implementation. e.g. avatar bd works in bluray:// but not br://

but hey, its not me doing the maintaining. maybe its a waste of time to
have both.

-compn