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

Michael Niedermayer michael at niedermayer.cc
Sat Dec 16 19:49:08 EET 2017


On Fri, Dec 15, 2017 at 02:24:17PM -0800, Jacob Trimble wrote:
> >> +
> >> +    /** 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.

It is difficult to change side data in the future as it is part of the ABI
Including a value representing the block size even if you only support 16 would
make it less painfull if it needs to be extended in the future.


[...]

> >
> >
> >> +
> >> +    /**
> >> +     * 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.

ok


[...]

> @@ -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,

So its basically like extradata is for a codec ?
If so it should be defined similarly as opaque encryption scheme specific data.
It should not be container specific.
Data taken from one container should be storable in another if both support
the features used

thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171216/ea2ca2b4/attachment.sig>


More information about the ffmpeg-devel mailing list