AOMediaCodec / av1-isobmff

Official specification of the AOM group for the carriage of AV1 in ISOBMFF
https://AOMediaCodec.github.io/av1-isobmff
64 stars 16 forks source link

Encryption alignment in the AV1 ISOBMFF specification #115

Closed alexismt73 closed 4 years ago

alexismt73 commented 5 years ago

In the current AV1 ISOBMFF specification, in section 4.1 (General Subsample Encryption constraints) it is stated that "BytesOfProtectedData SHALL end on the last byte of the decode_tile structure (including any trailing bits)." Since only complete 16-byte blocks are encrypted, this can result in the beginning of a decode_tile structure not being encrypted (i.e. encryption is aligned with the end of a decode_tile structure, not the beginning).

Was there any particular reason why the encryption alignment selected in this way? The current method seems to have certain drawbacks, e.g. from the encoder perspective it requires that the decode_tile structure to be complete before initiating the encryption process, while (and more importantly) for partial encryption the start of the decode tile is in the clear, potentially impacting encryption performance. It should be noted that when ISOBMFF is used with other codecs, e.g. AVC or HEVC, then encryption is aligned with the start of a slice and not the end for similar reasons.

We are wondering, and if there is no strong reason of why the alignment was set in this way, if it is still possible to change this specification and have the encryption alignment specified to consider the start of the decode_tile structure.

The required change for such support would involve changing the following line:

BytesOfProtectedData SHALL end on the last byte of the decode_tile structure (including any trailing bits).

To

BytesOfProtectedData SHALL start on the first byte of the decode_tile structure.

And removing the following Note:

NOTE: As a result of the above, partial blocks are not used and it is possible that BytesOfProtectedData does not start at the first byte of the decode_tile structure, but some number of bytes following that.

kqyang commented 5 years ago

@alexismt73 I don't see it necessary to start the encryption before the decode_tile is completed as time taken for encryption is almost negligible compared to the time taken for encoding.

for partial encryption the start of the decode tile is in the clear, potentially impacting encryption performance

Can you clarify what you mean by this? Are you talking about the possibility of having critical data in clear?

It should be noted that when ISOBMFF is used with other codecs, e.g. AVC or HEVC, then encryption is aligned with the start of a slice and not the end for similar reasons.

This is true for 'cbcs' encryption scheme, but not for other encryption schemes. For 'cenc' encryption scheme, BytesOfProtectedData is recommended to be multiple of 16 bytes and aligned with the end of structure.

cconcolato commented 4 years ago

closed by merging of #116