[Libva] VPP Deinterlacing problem
Holger Kaelberer
hk at elberer.de
Fri May 16 10:30:42 PDT 2014
Hi
On 05/16/2014 06:36 PM, Steven Toth wrote:
> On Thu, May 15, 2014 at 10:01 PM, Zhao, Halley <halley.zhao at intel.com> wrote:
>>> Question: Does Motion Adaption implementation (unlike Bob) require two distinct source surfaces plus an ADDITIONAL surface for the result?
>> Yes. A new surface is required for the result surface.
>
> Thanks. Just to be clear, the resulting deinterlaced content is
> written to the forward_reference surface, correct?
No, the target/output/destination surface for vpp goes to the render_target param of vaBeginPicture().
Forward references are references to already available surfaces needed for advanced deinterlacing
(forward temporal direction) as are backward references (backward temporal direction) and go to the
VAProcPipelineParameterBuffer:
pipeline_param->forward_references = forward_references;
pipeline_param->num_forward_references = num_forward_references_used;
pipeline_param->backward_references = backward_references;
pipeline_param->num_backward_references = num_bacward_references_used;
... as does the source/interlaced surface:
pipeline_param->surface = src_surface; // current to-be-deinterlaced surface
Have a look at how it is done in gst-vaapi:
https://gitorious.org/vaapi/gstreamer-vaapi/source/c12d80eb88359a4a5babe8ca3a7fd82397c7838a:gst-libs/gst/vaapi/gstvaapifilter.c#L1298
and the "Detailed Description" on http://people.freedesktop.org/~gb/vaapi/vpp/group__api__vpp.html
Holger
More information about the Libva
mailing list