[FFmpeg-devel] [RFC] avcodec/avcodec.h: Add encryption info side data

Jacob Trimble modmaker at google.com
Sat Dec 16 00:24:17 EET 2017


>> +
>> +    /** The ID of the key used to encrypt the packet. */
>> +    uint8_t key_id[16];
>> +
>> +    /** The initialization vector. */
>> +    uint8_t iv[16];
>
> what happens if the key or iv is longer ?

Both are specified by common encryption to be exactly that size.  To
be able to be
longer would require an updated spec.  Plus it avoids having to store a dynamic
string somewhere in the side data.

>
>> +
>> +    /**
>> +     * Only used for pattern encryption.  This is the number of 16-byte blocks
>> +     * that are encrypted.
>> +     */
>> +    unsigned int crypt_byte_block;
>> +
>> +    /**
>> +     * Only used for pattern encryption.  This is the number of 16-byte blocks
>> +     * that are clear.
>> +     */
>> +    unsigned int skip_byte_block;
>
> why is "16-byte blocks" hardcoded ?

Because that is how pattern encryption works in common encryption.  It
is specified
by number of AES blocks, not individual bytes.  I could change to
bytes, but it would
likely require the app to divide by 16 later and it runs the risk of
the value not being a
multiple of 16 like the spec requires.

>
>
>> +
>> +    /**
>> +     * The number of sub-samples in this packet.  If 0, then the whole sample
>> +     * is encrypted.
>> +     */
>> +    unsigned int subsample_count;
>> +
>> +    struct {
>> +      /** The number of bytes that are clear. */
>> +      unsigned int bytes_of_clear_data;
>> +
>> +      /**
>> +       * The number of bytes that are protected.  If using pattern encryption,
>> +       * the pattern applies to only the protected bytes; if not using pattern
>> +       * encryption, all these bytes are encrypted.
>> +       */
>> +      unsigned int bytes_of_protected_data;
>> +    } *subsamples;
>
> Are these patterns random in practice ?
> if not they possibly would be better not repeated per packet

They are unique per packet.

For example, in H.264, certain NAL unit types should be kept in the clear, while
others should be encrypted.  Plus even for encrypted NAL units, the header
should be kept in the clear even when the payload is encrypted.

>
>
>> +} AVPacketEncryptionInfo;
>
>> +#define FF_PACKET_ENCRYPTION_INFO_SIZE(a) (sizeof(AVPacketEncryptionInfo) + sizeof(unsigned int) * a * 2)
>
> This assumes things about the padding and alignment of fields that are not
> guranteed by C i think
>

I was trying to avoid having another top-level struct.  Too bad you
can get the size
of members without an instance in c.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: encryption-info-v3.patch
Type: text/x-patch
Size: 3651 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171215/eb9533f8/attachment.bin>


More information about the ffmpeg-devel mailing list