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

Jacob Trimble modmaker at google.com
Wed Dec 20 22:07:09 EET 2017


On Tue, Dec 19, 2017 at 3:05 PM, wm4 <nfxjfg at googlemail.com> wrote:
> On Tue, 19 Dec 2017 14:20:38 -0800
> Jacob Trimble <modmaker-at-google.com at ffmpeg.org> wrote:
>
>> > 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
>>
>> Then how about storing the data like it is now (the encryption info
>> followed by the subsample array), but not have a pointer?  Then there
>> will be several helper methods to get the subsample array from the
>> side-data.  For example,
>> av_encryption_info_get_subsamples(AVPacketEncryptionInfo*) or
>> av_encryption_info_get_subsamples(AVPacket*) (since there will only be
>> one instance of it).
>
> I guess that would work? Not particularly fond of the idea anyway. I
> think the functions would probably work on the side data byte array,
> maybe.

I'm not fond of this either, but I can't think of a way to allow a
dynamic number of elements while supporting memcpy and not requiring
the app to "parse" the side-data.

So here is may latest attempt.  This has a binary format inside the
side-data that allows memcpy to work, but there is a public struct
that apps will interact with.  There are two methods used to convert
between the two so the app doesn't have to.  Even though this is a
binary format, it is not actually a wire format since the subsamples
are stored as-is, so they are host byte ordered.  Also, as Michael
requested, this uses dynamic sized key ID and IV.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: encryption-info-v4.patch
Type: text/x-patch
Size: 9667 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171220/790001fc/attachment.bin>


More information about the ffmpeg-devel mailing list