[FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation

[wm4]

On Wed, 7 Oct 2015 19:20:56 +0300
Ivan Uskov <ivan.uskov at 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.uskov at 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.