[Libva] Problem with vaapipostproc element

Engin Firat engin.firat at adonissyazilim.com
Tue Dec 16 02:43:49 PST 2014


Hello,

I have tried to follow the way described here.
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-dynamic-pipelines.html

*If state in PLAYING, a unlink happened there, gst_pad_push_buffer may
return GST_FLOW_NOT_LINKED, this depends on how the plugin handle
NOT_LINKED message.*

>From this I understand that, we actually do not know how vaapipostproc
handles the NOT_LINKED message, do not we? However, the unlinked element is
not the vaapipostproc element, it is the queue3 (just before the bin that
contains matroskamux and filesink) in first pipeline below.

I have tried two pipelines:
videotestsrc -> queue1 -> vaapipostproc -> queue2 -> vaapiencode_h264 ->
queue3 -> (bin)(matroskamux -> filesink) : Successfully running for first
time period but it fails whenever placing a new bin
videotestsrc -> queue1 -> x264enc -> queue2 -> (bin)(matroskamux ->
filesink) : Successfully running and changing the file location


1. I do not want to pause the whole pipeline since I do not want to lose
any data.
2. I assume queueBeforeBin (gst element queue) make the appropriate
buffering while the pads are unlinked.

I am suspicious on vaapipostproc element. According to debug messages below
(attached in very first post),  it seems there is a problem with internal
memory management on this element when trying to adding a new bin to
pipeline. However I cannot understand how do we trigger this problem on
this element.

*vaapipostproc
gstvaapipluginbase.c:532:gst_vaapi_plugin_base_decide_allocation:<GPUPostProcessing>
no pool or doesn't support GstVaapiVideoMeta, making new pool*
*vaapivideomemory
gstvaapivideomemory.c:627:gst_vaapi_video_allocator_new: has
direct-rendering for NV12 surfaces: no*
*vaapipostproc gstvaapipostproc.c:412:create_output_buffer: failed to
create output video buffer*

Regards.



On 16 December 2014 at 12:13, Yuan, Feng <feng.yuan at intel.com> wrote:
>
>  Hi,
>
>      I’m not sure this is the right way to unlink the pad in a playing
> state. If state in PLAYING, a unlink happened there, gst_pad_push_buffer
> may return GST_FLOW_NOT_LINKED, this depends on how the plugin handle
> NOT_LINKED message. Normally may cause enter unstable state.
>
> Maybe
>
> 1.      you can try pause the whole pipeline then destroy the mux bin.
> This may depend on all plugins can handle pause correctly.
>
> 2.      Add a appsink before muxbin.  If unlink happened, , make appsink
> to queue them for a while, then push_data after relink done.
>
>
>
> Thanks
>
> Wind
>
>
>
> *From:* Libva [mailto:libva-bounces at lists.freedesktop.org] *On Behalf Of *Engin
> Firat
> *Sent:* Tuesday, December 16, 2014 5:12 PM
> *To:* libva at lists.freedesktop.org
> *Subject:* Re: [Libva] Problem with vaapipostproc element
>
>
>
> Hello,
>
>
>
> It is a typo. Sorry for mistake.
>
> An updated implementation.c is attached to this mail. Also I have been
> setting the *format *attribute to vaapipostproc element.
>
> There is no problem getting and encoding a video by using vaapi elements.
> The problem is occurred whenever I remove the bin and create a new one to
> update filesink's location. ie. I have been encoding the video and writing
> to disk successfully for specified time period (10 seconds in
> implementation.c line 217). After this period I need to remove the bin
> (consists of muxer and filesink, creating by using CreateNewBin function in
> implementation.c) create the new one and then try to continue play. At that
> time, vaapipostproc element halts the whole pipeline.
>
> The problem still continues and I cannot find a way to handle this
> problem.
>
>
>
> Thank you so much for your consideration.
>
> Regards.
>
>
>
> On 16 December 2014 at 09:36, Yuan, Feng <feng.yuan at intel.com> wrote:
>
>
>
> 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
>
>
>
>
> --
>
> *Engin FIRAT*
>
> Adoniss Yazılım Bilişim
>
> Elektronik Araştırma Geliştirme
>
> Limited Şirketi
>
> +90 506 884 82 07 (Mobile)
>
> ODTÜ Teknokent, ODTÜ-Halıcı Yazılımevi
>
> İnönü Bulvarı / ANKARA (Address)
>
>

-- 
*Engin FIRAT*
Adoniss Yazılım Bilişim
Elektronik Araştırma Geliştirme
Limited Şirketi

+90 506 884 82 07 (Mobile)
ODTÜ Teknokent, ODTÜ-Halıcı Yazılımevi
İnönü Bulvarı / ANKARA (Address)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20141216/51cb65ce/attachment-0001.html>


More information about the Libva mailing list