[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