[FFmpeg-devel] [PATCH] libavcodec/qsv.c: Re-design session control and internal allocation
h.leppkes at gmail.com
Wed Oct 14 11:47:02 CEST 2015
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.
More information about the ffmpeg-devel