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

[Hendrik Leppkes]

On Wed, Oct 7, 2015 at 7:07 PM, Ivan Uskov <ivan.uskov at nablet.com> wrote:
> Hello wm4,
>
> Wednesday, October 7, 2015, 7:40:45 PM, you wrote:
>
> w> There's no automagic way to get this done.
>
> w> Hardware accelerators like vaapi and vdpau need the same thing. These
> w> have special APIs to set an API context on the decoder. Some APIs use
> w> hwaccel_context, vdpau uses av_vdpau_bind_context().
>
> w> The hwaccel_context pointer is untyped (just a void*), and what it means
> w> is implicit to the hwaccel or the decoder that is used. It could point
> w> to some sort of qsv state, which will have to be explicitly allocated
> w> and set by the API user (which might be ffmpeg.c).
> So  if  I will implement something like ffmpeg_qsv.c (using ffmpeg_vdpau.c as
> example)   and   extend  the  hwaccels[]  into  ffmpeg_opt.c  by corresponded
> qsv entries it  would  be the acceptable solution, correct?
>
> w> For filters there is no such thing yet. New API would have to be
> w> created. For filters in particular, we will have to make sure that the
> w> API isn't overly qsv-specific, and that it is extendable to other APIs
> w> (like for example vaapi or vdpau).
> Ok,   if   VPP  could be the  issue  I  would  like  to  get  working  direct
> link qsv_decoder-qsv_encoder first.
>

Libav has a patch that does exactly this, allow direct QSV->QSV
transcoding with help of some utility code in ffmpeg.c/avconv.c
You might want to look at that instead of re-inventing it. That'll
help make everyones live easier, as I'll just merge it when the time
comes, and the codebases don't diverge too drastically.

Adding VPP on top of that would be a future step then.

- Hendrik