[MPlayer-dev-eng] aes & bluray

[Jonathan Nell]

2009/9/11 Reimar Döffinger <Reimar.Doeffinger at gmx.de>:
> On Fri, Sep 11, 2009 at 11:55:13AM +0200, Reimar Döffinger wrote:
>> On Fri, Sep 11, 2009 at 11:42:40AM +0200, Nico Sabbi wrote:
>> > Il venerdì 11 settembre 2009 11:32:06 Reimar Döffinger ha scritto:
>> > > Either way I admit I would simply like to have libavformat _also_
>> > > support decrypting (because lavf already has some other decryption
>> > > stuff, so this could be some kind of common way to handle all kinds
>> > > of encryption, MXF, ASF, AACS etc.), and I would also like it if
>> > > the scrambling control checks would be re-added in the demuxers in
>> > > a well-tested way so that people trying to play encrypted files
>> > > (e.g. when people do a simple file copy from a DVD) at least get a
>> > > proper warning instead of just strangely broken playback.
>> > > Overall I just have the feeling that at the demuxer layer it would
>> > > solve a whole bunch of problems more.
>> >
>> > well, in this case we need a .decrypter member to inizialize at
>> > demux_open() according to the stream type.
>> > I don't particularly like the idea, but...
>>
>> Do you _know_ that this is needed or are you just guessing? As said, I
>> have not found much documentation, particularly about CSS at the demuxer
>> level so I don't know if the demuxer really needs to know the stream
>> type. I do know that DVB and HD-DVD can be distinguished with nothing
>> more than the value of PES_scrambling_control.
>
> And CSS and AACS can be distinguished by key size: CSS is 40 bits and
> AACS is one or more 128 bit keys.
> Now, I admit that this _might_ still be ugly, but I do believe that this
> is possible without breaking stream/demuxer layering.
> I also admit that there might be some issue with CSS due to title
> and associated key changes, as I understand it that is no issue with
> AACS since the stream contains the info which key out of a list of keys
> to use.
> Of course to some level this discussion is a bit pointless with probably
> nobody volunteering to implement this at the demuxer layer...

My thoughts on the above convo thread: it's a lot of work to move
everything out to the demuxer (and the first time I looked at the
mplayer codebase was a few days ago). I'm also of the opinion that it
being in the stream layer is a MUCH better option (if the code is kept
neat). I don't think there is much core reuse across disc protection
methods so I can't see the benefit of move it out of the stream layer
really. Truth be told, there is already a 'hack' in my code that
resets the PES scrambled bits. This is probably unnecessary and imho
should be removed (i think that'd make it easier for us to show
legally that we're interested in bluray playback and not ripping....)