[MPlayer-dev-eng] Bluray playback

Jonathan Nell crtrn13 at gmail.com
Tue Sep 8 06:57:40 CEST 2009


Well there certainly seem to be a LOT of different opinions on the
best way to go about doing this (which is definitely a good thing).
Here are my further thoughts:

1) The AACS spec is open, meaning that there is certainly no problem
with implementing the algorithms. If implemented from the VUK step,
the code could be fairly small and neat. But that would require a user
to find a key somewhere and provide it as a command line option to
mplayer. I don't think that this is a terrible first step. The point
here is that I think I need to integrate bluray support step by step
instead of all to once. As a second stage I can implement the code
from the PK step but assumes that the bluray drive is patched to get
the volume key but doesn't require them to provide a VUk for their
disc (only a single K for all their discs). The third step would be to
implement the host certificate code so that the user doesn't need a
patched drive, but then they would also need to provide this
certificate (or patch their drive). Obviously if someone wants to go
over to doom9 and patch the keys into the binary they can go ahead and
do that. That would mean that no keys are needed (at least until AACS
revokes the key). An alternative would be to actually buy a key legit
(get one donated or cash donated somehow) - i'll look into the cost.

2) I think PGS support is a little way down the line - certainly it's
better to get the movies playing first. I think that the crypto is
important too. Obviously it would be easier to support decrypted files
and bluray dir structure (which will be supported anyway), but anyone
who knows how to dump their discs and decrypt the content knows how to
pipe it to mplayer. The idea here I think is to make it easy and get
it to a stage where it just 'works' - no need for dumping tools,
pipes, etc.

3) A library would be a good idea but it's actually a pain. The main
codebase would need to support the directory structure, data streaming
etc. anyway. Only the crypto would be flogged off to the library and
I'm not actually sure it's worth doing that when we can just add one
or two extra c files to the codebase that deal with the crypto. It's
actually easier to maintain than a library. As for code re-use in
other projects - they can just grab the file - it's open source after
all! I don't want to maintain a library with 1,000 projects that use
it and report bugs cause they are using it stupidly - and those
projects need to implement dealing with directory structure etc
anyway. Unless I flog the whole reading of the disc etc into a library
as well and there's really no point in that as it'll duplicate code
that most projects have already (not to mention that everyone has a
different way of doing this).

4) Bluraynav would be great to - but that's later on - for now,
playback of the main title would be great (it's easy to identify this
on the disc).

5) BD+ is a different story entirely but lets get the AACS stuff
sorted first (it's only Fox discs affected atm afaik). The spec is
closed but it's not really key-reliant, meaning that the algos
probably could be implemented without a problem. It requires a VM etc.
etc. and a library would probably be best here. I'm waiting to see how
libblueray comes along (it deals with BD+) and when it's more mature
maybe I'll recode it in C. But this is a LATER job.

6) Where I am right now: I basically have the AACS code done from the
PK all the way down to the decryption of the mpeg stream. This source
is completely separate to mplayer and is not coded with mplayer in
mind - just to test the algos.

7) What i'm going to do next: clean up me code and refactor with
mplayer codebase in mind. Cut out the pk code and just work on the
code from the vuk onwards. I'm then going to have a go implementing
this in the mplayer stream code and will let you see. Then the
feedback can begin! :)

2009/9/7 Carl Eugen Hoyos <cehoyos at ag.or.at>:
> I have a related question:
> If you try to copy an (encrypted) stream from the Blu-ray disc to your
> hard-disc (using OS), is the encrypted file actually copied and can then be
> decrypted (using the known keys)?
> If yes, imo, you should start there.

Yes, you can copy the file but it needs unit/title keys to decrypt.
These keys are easily generated from the VUK (volume unique key) and
the encrypted unit keys found on the disc (this needs to be copied too
of course). I intend to start here, but it makes no diff if I read
from the bluray disc or from a harddrive copy - the algos are the same
and the keys are the same. The directory structure is also the same.
Obviously on a copy I will not have the volume ID - this would be
needed if I was decrypting from the PK (processing key) stage.



More information about the MPlayer-dev-eng mailing list