>> +
>> +    /** 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.
From a1b2cbcb7da4da69685f8f1299b70b672ce448e3 Mon Sep 17 00:00:00 2001
From: Jacob Trimble <modma...@google.com>
Date: Tue, 5 Dec 2017 14:52:22 -0800
Subject: [PATCH] avcodec/avcodec.h: Add encryption info side data.

This new side-data will contain info on how a packet is encrypted.
This allows the app to handle packet decryption.  To allow for a
variable number of subsamples, the buffer for the side-data will be
allocated to hold both the structure and the array of subsamples.  So
the |subsamples| member will point to right after the struct.

Signed-off-by: Jacob Trimble <modma...@google.com>
---
 libavcodec/avcodec.h | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 70 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5db6a81320..ccc89345e8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1112,6 +1112,63 @@ typedef struct AVCPBProperties {
     uint64_t vbv_delay;
 } AVCPBProperties;
 
+typedef struct AVPacketSubsampleEncryptionInfo {
+    /** 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;
+} AVPacketSubsampleEncryptionInfo;
+
+/**
+ * This describes encryption info for a packet.  This contains frame-specific
+ * info for how to decrypt the packet before passing it to the decoder.  If this
+ * side-data is present, then the packet is encrypted.
+ */
+typedef struct AVPacketEncryptionInfo {
+    /** The fourcc encryption scheme. */
+    uint32_t scheme;
+
+    /** The ID of the key used to encrypt the packet. */
+    uint8_t key_id[16];
+
+    /** The initialization vector. */
+    uint8_t iv[16];
+
+    /**
+     * 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;
+
+    /**
+     * The number of sub-samples in this packet.  If 0, then the whole sample
+     * is encrypted.
+     */
+    unsigned int subsample_count;
+
+    /** The subsample encryption info. */
+    AVPacketSubsampleEncryptionInfo *subsamples;
+} AVPacketEncryptionInfo;
+/**
+ * The size of the side-data for the AV_PKT_DATA_PACKET_ENCRYPTION_INFO type.
+ * The side-data will contain the AVPacketEncryptionInfo struct followed by
+ * the subsample array.  The subsamples member should point to after the struct
+ * so the app can easily access it.
+ */
+#define FF_PACKET_ENCRYPTION_INFO_SIZE(subsample_count) \
+    (sizeof(AVPacketEncryptionInfo) + sizeof(AVPacketSubsampleEncryptionInfo) * subsample_count)
+
 /**
  * The decoder will keep a reference to the frame and may reuse it later.
  */
@@ -1327,6 +1384,19 @@ enum AVPacketSideDataType {
      */
     AV_PKT_DATA_A53_CC,
 
+    /**
+     * This side data is encryption "initialization data".
+     * For MP4 this is the entire 'pssh' box.
+     * For WebM this is the key ID.
+     */
+    AV_PKT_DATA_ENCRYPTION_INIT_DATA,
+
+    /**
+     * This side data is an AVPacketEncryptionInfo structure and contains info
+     * about how the packet is encrypted.
+     */
+    AV_PKT_DATA_PACKET_ENCRYPTION_INFO,
+
     /**
      * The number of side data types.
      * This is not part of the public API/ABI in the sense that it may
-- 
2.15.1.504.g5279b80103-goog

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to