On 11/6/2017 9:19 AM, Timo Rothenpieler wrote: > Am 05.11.2017 um 14:35 schrieb James Almer: >> On 11/5/2017 9:34 AM, Michael Niedermayer wrote: >>> This gives libavcodec a field that it can freely and safely use. >>> Avoiding the need of wraping of a users opaque_ref field and its issues. >> >> Could this perhaps be in an opaque internal struct instead, much like >> AVCodecInternal and whatnot? As wm4 said in the relevant discussion, >> this approach is nonoptimal and *will* snowball into a mess of fields if >> other libav* libraries start requiring their own buffers in a frame. >> An internal field of an opaque struct being in a public header is much >> cleaner and easier to maintain than adding such specific fields that may >> at some point in the future need to be removed. > > The problem here is that avcodec, due to nested decoders and the like, > might potentially wrap this field multiple times internally, so it > basically has to be something avcodec specific.
And an opaque internal struct would require avpriv_ symbols to be accessed from outside libavutil, so it's an ugly solution nonetheless. I already told Michael to discard the suggestion. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
