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

wm4 nfxjfg at googlemail.com
Wed Dec 20 01:05:04 EET 2017


On Tue, 19 Dec 2017 14:20:38 -0800
Jacob Trimble <modmaker-at-google.com at ffmpeg.org> wrote:

> > You pretty much did. Side data is an ffmpeg internal concept, and if
> > your hypothetical streaming protocol needs special support for side
> > data, it's automatically relying on ffmpeg internals.  
> 
> I thought side data was public data?  Doesn't it contain public info
> like display info and required decoder info?  So if someone wants to
> decode frames without using the demuxers, they'll need to reconstruct
> the side data so the decoder can still work.

Side data is ffmpeg API, but it's a ffmpeg specific concept, and
tightly bound to its internal workings. Using it for a streaming
protocol would essentially mean both client and server have to be
ffmpeg. That doesn't make for a good (standardizable) protocol.

> > On that note, I wonder if we should add an AVPacket reserved field for
> > this, just so we don't have to wait for the next ABI bump.  
> 
> I would much prefer to have this in AVPacket since it is in no way
> "optional".  Having the info in the packet ensures a custom app can
> see the info and is less likely to get confused on why their packets
> aren't decoding.  I did this as side-data since it would have less ABI
> impact and I thought it would cause less conflict.  But having it as
> another field on AVPacket would allow more control over memory so the
> dynamic fields don't cause problems anymore.

I was talking about making a new side data API, which could handle
cases like this much better, instead of just being byte arrays. I don't
think we should add anything specific to encryption directly to
AVPacket, it's an too obscure use case. (The whole point of side data
was to avoid adding new fields for obscure use cases to top level
structs. Just look how many weird fields AVCodecContext has.)

> > 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.


More information about the ffmpeg-devel mailing list