Problem about VAAPI gstreamer plugins

[EFIRA1]

We have been trying to play a video streaming through a RTSP server by using vaapidecode and vaapisink gstreamer elements. But the problem is pipeline constructed seems problematic and it does not work. Here is the pipeline:

gst-launch-1.0 rtspsrc location=rtsp://192.168.1.15/media/video1?g726=rfc3551 ! rtph264depay ! vaapidecode ! vaapisink

The error message is as follows:

gstbasesrc.c(2865): gst_base_src_loop (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc2:

streaming task paused, reason not-linked (-1)

We are sure, vaapidecode and vaapisink elements are working properly. For example, following pipeline decodes a 1080p movie on GPU without any problems.

We think we should place a capsfilter before decode element but it did not work too. In addition we have placed demuxer elements for an rtsp stream such as: rtpptdemux but these did not even work.

Could you please help to decode an rtsp stream on GPU by using gstreamer vaapi plugins?

Regards.

[Casey_H_Intel]

Hello enienws,

Please provide additional information on this request. What is the chipset on which you are working. Also, what driver are you using, and driver version?

Best Regards,

Casey H.

[EFIRA1]

Hello Casey,

We are working on an Intel E3845 processor. We are on Ubuntu 14.04 LTS OS and driver version is as follows:

libva-intel-vaapi-driver and version: 1.3.0-1ubuntu1. Gstreamer vaapi element's name and version is as follows: libgstreamer-vaapi1.0-0 and version: 0.5.7-0ubuntu4

Moreover as a remark, we were able to play an H264 stream on this driver and OS configuration.

Best Regards.

[EFIRA1]

And moreover this is the output of the gst-launch:

libva info: VA-API version 0.35.1

libva info: va_getDriverName() returns 0

libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so

libva info: Found init function __vaDriverInit_0_35

libva info: va_openDriver() returns 0

Setting pipeline to PAUSED ...

Pipeline is live and does not need PREROLL ...

Got context from element 'vaapidecode0': gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL;

Progress: (open) Opening Stream

Progress: (connect) Connecting to rtsp://192.168.1.15/media/video1?g726=rfc3551

Progress: (open) Retrieving server options

Progress: (open) Retrieving media info

Progress: (request) SETUP stream 0

Progress: (request) SETUP stream 1

Progress: (open) Opened Stream

Setting pipeline to PLAYING ...

New clock: GstSystemClock

Progress: (request) Sending PLAY request

Progress: (request) Sending PLAY request

Progress: (request) Sent PLAY request

ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:camera/GstUDPSrc:udpsrc3: Internal data flow error.

Additional debug info:

gstbasesrc.c(2865): gst_base_src_loop (): /GstPipeline:pipeline0/GstRTSPSrc:camera/GstUDPSrc:udpsrc3:

streaming task paused, reason not-linked (-1)

Execution ended after 0:00:00.704377971

Setting pipeline to PAUSED ...

Setting pipeline to READY ...

Regards 

[Adolfo_S_Intel]

Hello enienws

Based on previous cases there are some possibilities as to what could be happening in this particular case:

1. You have mis-containered content. Outside it looks like a supported file type, but the contents are in some unsupported format and the decoder errors out.
2. The content is supported but was encoded with a bad codec that generated errors in the decoder
3. It is supported, and it is good content, but you have the video memory allocation set too low for the video memory to decode the content. Some players try to pre-allocate too many frame buffers ahead so software decode can also get ahead. That is not needed with hardware decode.

Since you are using Ubuntu and the Open Source drivers you should attempt to use the Open Source Community:

https://01.org/linuxgraphics/community https://01.org/linuxgraphics/community or Bugzilla to post your issue. They should be able to assist you further.

Best Regards,

Adolfo.

[EFIRA1]

Hello,

So what do you think about the following situation: We were able to decode same streaming by using a pipeline similar to this by using CPU of specified processor:

gst-launch-1.0 rtspsrc location=rtsp://192.168.1.15/media/video1?g726=rfc3551 ! rtph264depay ! avdec_h264 ! xvimagesink sync=false

This pipeline gives no error and decodes streaming video successfully. Don't you think this points out neither suggestion 1 nor 2 does not fit to our situation, do you?

I am going to report this problem on Open Source Community. Thank you for redirecting us to this community.

Best regards.

[Casey_H_Intel]

Hello enienws,

We are continuing to investigate this question. Please also let us know in this community if you have received information for this inquiry from the Open Source Community.

Best Regards,

Casey H.

[Casey_H_Intel]

Hello enienws,

I apologize that it is taking longer than expected to get feedback on your question. We are continuing to look into your inquiry.

Best Regards,

Casey H.

[Kirk_B_Intel]

CPU decode is generally more flexible than hardware decode. The decode engine designed in the chipset is fixed in hardware and only handles what it was designed to handle and no more. When you try to use the hardware decode and it reports problems, you are supposed to resort to s/w decode in the CPU and then if THAT fails, you need to look at what you are trying to decode to see what is wrong with your content.

I might suggest you analyze the data in your decode target to see what might be the issue with using our H/W decoder. I think you will find that an "iffy" encoder was used, or the content is NOT what was advertised by the container name. I would bet that the content really is NOT anything the h/w decoder was designed to support.

Hope this helps.

[EFIRA1]

Hello chaas,

Sorry for the delay. I wasn't able to check my mails and other things for a while. I haven't yet received any response from OpenSource community. I am going to resend that question to open source community again.

The problem still exists for us and any help on this problem will be appreciated.

Regards.