After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 763239 - vaapipostproc : rejected caps on NVIDIA hardware, nice on Intel hardware
vaapipostproc : rejected caps on NVIDIA hardware, nice on Intel hardware
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
1.6.3
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-03-07 14:59 UTC by Cyril Baletaud
Modified: 2016-03-07 17:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
output with log-level=6 (385.79 KB, application/zip)
2016-03-07 14:59 UTC, Cyril Baletaud
Details

Description Cyril Baletaud 2016-03-07 14:59:38 UTC
Created attachment 323289 [details]
output with log-level=6

Hi,
To test if hardware acceleration is available, i run this :

gst-launch-1.0 videotestsrc ! "video/x-raw,format=I420,width=640,height=640,framerate=(fraction)60/1" ! queue ! vaapipostproc ! vaapiencode_h264 ! vaapiparse_h264 ! vaapidecode ! vaapisink

with Intel hardware this works nicely.

On NVidia hardware:

libva info: VA-API version 0.38.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
Définition du pipeline à PAUSED...
0:00:00.159024508 29132      0x1bd72f0 WARN                GST_PADS gstpad.c:1098:gst_pad_set_active:<vaapipostproc0:sink> Failed to activate pad
ERREUR : le pipeline refuse de se mettre en pause.
Got context from element 'vaapipostproc0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)NULL;
Définition du pipeline à NULL…
Libération du pipeline…
Comment 1 Víctor Manuel Jáquez Leal 2016-03-07 15:11:57 UTC
That vaapi-nvidia bridge backend doesn't support the vaapipostproc. You can verify it running the vainfo command. That's why the element fails to link.

One possible solution is to force the element to do passthrough ( bug 751876 ), but then, again, the encoders are not supported by the vaapi-nvidia bridge backend, and you'll find again that the pipeline won't link. Perhaps you can use nvenc instead.
Comment 2 Cyril Baletaud 2016-03-07 16:34:39 UTC
(In reply to Víctor Manuel Jáquez Leal from comment #1)
> That vaapi-nvidia bridge backend doesn't support the vaapipostproc. You can
> verify it running the vainfo command. That's why the element fails to link.
> 
> One possible solution is to force the element to do passthrough ( bug 751876
> ), but then, again, the encoders are not supported by the vaapi-nvidia
> bridge backend, and you'll find again that the pipeline won't link. Perhaps
> you can use nvenc instead.

Oki, i understand.
Is this is definitely not supported or an update will fix this problem ?
Thanks
Comment 3 Víctor Manuel Jáquez Leal 2016-03-07 17:07:04 UTC
(In reply to Cyril Baletaud from comment #2)
>
> Is this is definitely not supported or an update will fix this problem ?
> Thanks

The thing is that this is not fixable in gstreamer-vaapi, but in the backend, and the backend that you are using is currently not maintained. There's another backend in development by Mesa (only for nouveau driver), but it doesn't support postproc neither, afaik.

So no, no fix is foreseeable right now.
Comment 4 Cyril Baletaud 2016-03-07 17:17:57 UTC
OK, only the development machine has an nvidia card production machines use an Intel chipset.
So pass me now to buy nvidia hardware.

Thanks you very much.