> 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. > 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 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). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
