ibva error: va_getDriverName() failed with operation failed,driver_name=i965, on a .wmv file

Gwenole Beauchesne gb.devel at gmail.com
Thu Sep 18 07:06:11 PDT 2014 

Hi,

2014-09-18 12:13 GMT+02:00 Sergei Vorobyov <sergei.vorobyov at facilitylabs.com>:
> Thanks!
>
> Indeed the problem was caused by the fact I tried to gst-discover via an ssh
> connection, my fault. When I do it directly on the NUC, the .wmv file in
> question is discovered and played OK... Almost.
>
> Although the file started to play *reasonably well*, gst-launch continued to
> complain about i965_drv_video.so, which indeed was missing:
>
> fl at nuc3:~/ads$ gst-launch-1.0 filesrc location=621.wmv ! decodebin !
> videoconvert ! ximagesink
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> libva info: VA-API version 0.35.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
> libva info: va_openDriver() returns -1
> libva info: VA-API version 0.35.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
> libva info: va_openDriver() returns -1
> libva info: VA-API version 0.35.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
> libva info: va_openDriver() returns -1
> Redistribute latency...
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> Got EOS from element "pipeline0".
> Execution ended after 0:00:05.000180624
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...
>
> Worse things started to happen when I run apt-get install libva-*, which
> installed dri/i965_drv_video.so
>
> The playback became *real slow* (because of acceleration?) and gst-launch
> reported:

It became slow because...

> fl at nuc3:~/ads$ gst-launch-1.0 filesrc location=621.wmv ! decodebin !
> videoconvert ! ximagesink

... you are downloading the VA surface pixels to system memory, then
use SW color conversion to RGB format for ximagesink.

> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> libva info: VA-API version 0.35.0
> 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
> Got context from element 'vaapidecode0': gst.vaapi.Display=context,
> display=(GstVaapiDisplay)NULL;
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> WARNING: from element /GstPipeline:pipeline0/GstXImageSink:ximagesink0: A
> lot of buffers are being dropped.
> Additional debug info:
> gstbasesink.c(2791): gst_base_sink_is_too_late ():
> /GstPipeline:pipeline0/GstXImageSink:ximagesink0:
> There may be a timestamping problem, or this computer is too slow.
> WARNING: from element /GstPipeline:pipeline0/GstXImageSink:ximagesink0: A
> lot of buffers are being dropped.
> Additional debug info:
> gstbasesink.c(2791): gst_base_sink_is_too_late ():
> /GstPipeline:pipeline0/GstXImageSink:ximagesink0:
> There may be a timestamping problem, or this computer is too slow.
> WARNING: from element /GstPipeline:pipeline0/GstXImageSink:ximagesink0: A
> lot of buffers are being dropped.
> Additional debug info:
> gstbasesink.c(2791): gst_base_sink_is_too_late ():
> /GstPipeline:pipeline0/GstXImageSink:ximagesink0:
> There may be a timestamping problem, or this computer is too slow.
> WARNING: from element /GstPipeline:pipeline0/GstXImageSink:ximagesink0: A
> lot of buffers are being dropped.
> Additional debug info:
> gstbasesink.c(2791): gst_base_sink_is_too_late ():
> /GstPipeline:pipeline0/GstXImageSink:ximagesink0:
> There may be a timestamping problem, or this computer is too slow.
> Got EOS from element "pipeline0".
> Execution ended after 0:00:05.221524402
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...
>
> Luckily, when I replaced ximagesink with autovideosink, the playback became
> fast and smooth as before reporting:
>
> fl at nuc3:~/ads$ gst-launch-1.0 filesrc location=621.wmv ! decodebin !
> videoconvert ! autovideosink
> Setting pipeline to PAUSED ...
> libva info: VA-API version 0.35.0
> 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
> Pipeline is PREROLLING ...
> Got context from element 'vaapidecode0': gst.vaapi.Display=context,
> display=(GstVaapiDisplay)NULL;
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> Got EOS from element "pipeline0".
> Execution ended after 0:00:05.060843602
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...

And this is fine since, by using autovideosink, you allow for the
"vaapisink" element to get autoplugged.

> Does it mean that Video Acceleration and ximagesink are incompatible? How to
> choose an optimal video sink, rather than autovideosink? I tried others like
> clutter, v4l2sink. Nothing works except autovideosink.

An optimal sink, if you use gstreamer-vaapi, is vaapisink. Having said
that, cluttersink & glimagesink shall work equally well too, nowadays.
The latter with GStreamer >= 1.4 of course, and recent enough
gstreamer-vaapi (git master branch).

> Which sink is actually selected by autovideosink? I am hesitant of using
> autovideosink in the real C application with gst_element_factory_make
> ("autovideosink", "videosnk"), because it is more tricky to map this
> autovideosink into an X-window. Note this mapping is static with ximagesink
> (no callbacks needed)

If you know your system supports VA-API, then you could use vaapisink
that also supports the GstVideoOverlay interface.

> On Wed, Sep 17, 2014 at 2:02 PM, Gwenole Beauchesne <gb.devel at gmail.com>
> wrote:
>>
>> Hi,
>>
>> 2014-09-17 13:51 GMT+02:00 Sergei Vorobyov
>> <sergei.vorobyov at facilitylabs.com>:
>> > While GStreamer supports the .wmv on nVidia cards, it apparently does
>> > not on
>> > Intel's built-in graphics cards found in Intel's NUC2820FYKH (see below:
>> > the
>> > same .wmv file is gst-discovered on the NUC and on a workstation with
>> > the
>> > Quadro FX 580 card). What are the prospects of getting fully functional
>> > drivers/libraries  for Intel NUCs in the nearest future?
>> >
>> > Thanks!
>> >
>> > PS: Although Intel does not specify it, I found that the NUC2820 has the
>> > Ivy
>> > Bridge derived HD Graphics with a 756MHz burst core frequency
>> >
>> > ---------------------------------------------------------
>> > fl at nuc3:~/ads$ gst-discoverer-1.0 621.wmv
>> > Analyzing file:///home/fl/ads/621.wmv
>> > libva info: VA-API version 0.35.0
>> > libva info: va_getDriverName() returns 1
>> > libva error: va_getDriverName() failed with operation
>> > failed,driver_name=i965
>> > Done discovering file:///home/fl/ads/621.wmv
>>
>> This means that, a plain `vainfo' call on your nuc3 system will yield
>> the same output. If so, this would mostly report an additional error
>> like X11 display not available. This means that, if you have been
>> connecting to nuc3 with ssh, and that the remote host has X running,
>> the correct command would be DISPLAY=:0.0 vainfo, resp.
>> gst-discoverer-1.0. Otherwise, initialization of the VA driver, so
>> gst-discoverer-1.0 will fail finding out anything, unless you have a
>> SW decoder around (gst-libav).
>>
>> However, there normally is correct support for headless displays. So,
>> if you have built gstreamer-vaapi with the VA/DRM backend too, and
>> your user belongs to the "video" group, or whatever has access to
>> /dev/dri/card0, this should fallback to that headless mode.
>>
>> >
>> > Topology:
>> >   container: Advanced Streaming Format (ASF)
>> >     video: Windows Media Video 9 Screen
>> >     audio: Windows Media Audio 9
>> >
>> > Properties:
>> >   Duration: 0:00:05.460000000
>> >   Seekable: yes
>> >   Tags:
>> >       container format: ASF
>> >       audio codec: WMA Version 9
>> >       video codec: Microsoft Windows Media 9
>> >
>> > --------------------------------------------------------
>> > sergei at wsl:~$ gst-discoverer-1.0 621.wmv
>> > Analyzing file:///home/sergei/621.wmv
>> > Done discovering file:///home/sergei/621.wmv
>> >
>> > Topology:
>> >   container: Advanced Streaming Format (ASF)
>> >     video: Windows Media Video 9 Screen
>> >     audio: Windows Media Audio 9
>> >
>> > Properties:
>> >   Duration: 0:00:05.460000000
>> >   Seekable: yes
>> >   Tags:
>> >       container format: ASF
>> >       audio codec: WMA Version 9
>> >       video codec: Microsoft Windows Media 9
>> >
>> > _______________________________________________
>> > gstreamer-devel mailing list
>> > gstreamer-devel at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>> >
>>
>>
>> Regards,
>> --
>> Gwenole Beauchesne
>> Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
>> Registration Number (RCS): Nanterre B 302 456 199
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>


Regards,
-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199

More information about the gstreamer-devel mailing list