[MPlayer-dev-eng] aes & bluray

[Jonathan Nell]

2009/9/10 Uoti Urpala <uoti.urpala at pp1.inet.fi>:
> On Thu, 2009-09-10 at 21:29 +0000, Jonathan Nell wrote:
>> 1) I've tried using the aes fcns included in libavutil but it doesn't
>> work (i've had to user the openssl ones for now). I mean i have
>> implemented the functions exacly as per the test example in aes.c but
>> neither cbc nor ecb is working at all (all the values are wrong). Any
>> ideas what's going on here? Is this traight forward aes (with the
>> correct sboxes)?
>
> Yes AFAIK it is supposed to be standard AES. However even if you do get
> it working what about speed? Doesn't the format require decryption of
> the whole stream at fairly high bitrates? The libavutil functions likely
> won't be as fast as openssl ones; how significant is the CPU use for
> decryption in practice?

Speed of aes is not an issue really. The unit decryption routines
happen on every 6144 byte chunk and are fairly 'light' for today's
processors (well certainly MUCH lighter than the actual decoding of
the stream). Obvisouly the faster the better anyway. Is there really
any problim of linking openssl?

>> 2) the 'fill_buffer' fcn in the stream code always have a len of 2048
>> passed to it. Is this standard/configurable? Does this change at all?
>> It's not a problem but i've hard-coded the splitting of the m2ts units
>> into 2048byte sub-units and if this value changes every, my code won't
>> work (I've done it stupidly anyway and will improve it, but i would
>> still like to know where this len value comes from).
>
> It's a property of the shared stream functions which call those of a
> specific stream. It's set in the STREAM_BUFFER_SIZE #define. It's not
> easily configurable at the moment, but a stream implementation shouldn't
> rely on it (you shouldn't make it any harder to change, as it can be
> inefficient).

Yeah, I'll fix my code to make it more generic.