[Libva] Problem with vaapipostproc element

[Yuan, Feng]

Hi,
From your attachment implementation.c, found
vaapiencoder = gst_element_factory_make ("x264enc", NULL);
Maybe typo. Suppose you want “vaapiencode_h264”. Anyway,  I just tried
$ gst-launch-1.0 videotestsrc ! video/x-raw,format=NV12,width=320,height=240,framerate=30/1 ! vaapipostproc ! queue ! vaapiencode_h264 !  fakesink
Failed in latest master branch. This issue caused by gstvaapiencoder need strict format check but vaapipostproc with format ‘Encoded’(VASurface). After adding a specific ‘format’ for vaapipostproc, encoder works. You can take a try .
$ gst-launch-1.0 videotestsrc ! video/x-raw,format=NV12,width=320,height=240,framerate=30/1 ! vaapipostproc format=nv12 ! queue ! vaapiencode_h264 !  fakesink


Thanks,
Wind
From: Libva [mailto:libva-bounces at lists.freedesktop.org] On Behalf Of Engin Firat
Sent: Friday, December 12, 2014 11:48 PM
To: libva at lists.freedesktop.org
Subject: [Libva] Problem with vaapipostproc element

Hello,

I have a problem related to element called vaapipostproc. The problem is as follows:

I have a pipeline and for specified time intervals I attempt to change pipeline dynamically in order to change write location of the filesink. I have implemented this functionality and everything works well in case I do not use vaapipostproc element. If I use vaapipostproc element, the pipeline crashes unexpectedly. An error message is thrown from the element vaapipostproc: "failed to create output video buffer" at the immediate point the pipeline is changed dynamically.

My pipeline change strategy is as follows:
0. Create a bin and place mux and filesink elements inside it. Moreover create a queue element before this bin.
1. For specified intervals, fire a clock event and catch it in a handler
2. In clock handler place a blocking probe to queue's source pad and register a blocking data handler
3. In blocking data handler unlink queue and bin and send an EOS event to bin's sink pad.
4. Handle EOS event on bin element. In this handler, destroy bin, create a new bin with an updated filesink location connect bin with queue. And remove the blocking probe.

This strategy for dynamic pipeline changing works well when I do not use vaapipostproc element. But I want to do encoding process on GPU and using vaapipostproc is a mandatory.

I have inspected the source code  gstvaapipostproc.c for element vaapipostproc and It seem the problem is related to function named as GstBuffer * create_output_buffer(GstVaapiPostproc*).

You can find output messages when GST_DEBUG environment variable is set to 4. In addition to this, you can also find my implementation to change the pipeline dynamically. The implementation won't compile, I just want to share a pseudo-code for your well understanding of the implementation.

I want to share the most interesting part of the out.log file:
0:00:11.075920072 [334m11325 [00m      0x1dcc720 [36mINFO   [00m [00m       vaapipostproc gstvaapipluginbase.c:532:gst_vaapi_plugin_base_decide_allocation:<GPUPostProcessing> [00m no pool or doesn't support GstVaapiVideoMeta, making new pool
0:00:11.076231088 [334m11325 [00m      0x1dcc720 [36mINFO   [00m [00m    vaapivideomemory gstvaapivideomemory.c:627:gst_vaapi_video_allocator_new: [00m has direct-rendering for NV12 surfaces: no
0:00:11.076568949 [334m11325 [00m      0x1dcc720 [31;01mERROR   [00m [00m       vaapipostproc gstvaapipostproc.c:412:create_output_buffer: [00m failed to create output video buffer
0:00:11.076723161 [334m11325 [00m      0x1dcc720 [33;01mWARN   [00m [00m       basetransform gstbasetransform.c:2130:gst_base_transform_handle_buffer:<GPUPostProcessing> [00m could not get buffer from pool: error
0:00:11.076773273 [334m11325 [00m      0x1dcc720 [36mINFO   [00m [00m                task gsttask.c:300:gst_task_func:<queue0:src> [00m Task going to paused

How can I solve this problem? Any help will be appreciated.

Regards.

Engin FIRAT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20141216/1e4616c4/attachment.html>