On Wed, 7 Oct 2015 19:20:56 +0300 Ivan Uskov <ivan.us...@nablet.com> wrote:
> Hello Hendrik, > > Wednesday, October 7, 2015, 5:58:25 PM, you wrote: > > HL> On Wed, Oct 7, 2015 at 4:41 PM, Ivan Uskov <ivan.us...@nablet.com> wrote: > > HL> Global static variables are not acceptable, sorry. > HL> You'll have to find another way to solve your problem, but global > HL> state is not the way to go. > Unfortunately I do not have ideas how to provide single and common > memory block for separate modules by another way. Memory mapping > files looks not too portable and much more bulky solution then one global > variable. > I do not see the way to use appropriate field of AVCodecContext to share > global data. > Has anybody any ideas? > Is me missed something? There is really the necessary to have a global > common > structure shared between decoder, vpp and decoder. > There's no automagic way to get this done. Hardware accelerators like vaapi and vdpau need the same thing. These have special APIs to set an API context on the decoder. Some APIs use hwaccel_context, vdpau uses av_vdpau_bind_context(). The hwaccel_context pointer is untyped (just a void*), and what it means is implicit to the hwaccel or the decoder that is used. It could point to some sort of qsv state, which will have to be explicitly allocated and set by the API user (which might be ffmpeg.c). For filters there is no such thing yet. New API would have to be created. For filters in particular, we will have to make sure that the API isn't overly qsv-specific, and that it is extendable to other APIs (like for example vaapi or vdpau). Unfortunately, you can be sure that we won't accept your current patch, though. Global mutable variables are a no in new code. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
