On Mon, 18 Dec 2017 21:38:24 +0100
Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Mon, Dec 18, 2017 at 04:56:08PM -0300, James Almer wrote:
> > On 12/18/2017 4:52 PM, wm4 wrote:
> > > On Fri, 15 Dec 2017 14:24:17 -0800
> > > Jacob Trimble <modmaker-at-google....@ffmpeg.org> wrote:
> > >
> > >> 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;
> > >
> > > I don't think this is sane. So far, side data could simply be copied
> > > with memcpy, and having pointers to non-static data in side data would
> > > break this completely.
> >
> > Even more reasons to ditch the current side data API and come up with a
> > better designed one that can also be reused for packet, frame and
> > container needs.
>
> yes,
> also if its redesigned, it should become possible to pass it over the
> network. Currently all side data depends on the platform ABI, so its
> only valid on the platform its created on. That also makes it different
> from all other data, AVPacket.data and extradata are all
> platform independant. And there is no API to
> convert it into a platform ABI independant form.
Why should it be transferable over network? That makes no sense. We
don't have the ability to transfer AVFrame, AVPacket, or AVCodecContext
over network either.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
