multiple vaapi pipelines
Víctor Jáquez
vjaquez at igalia.com
Tue Jul 18 14:44:48 UTC 2017
On Sun, 16 Jul 2017 at 14:18, Julien Isorce wrote:
> You probably want to install libglib2.0-0-dbg to resolve the "??"
> Can you open a bug attaching full GST_DEBUG log, dmesg output (to get some
> info on the driver and kernel) and mesa version (or glxinfo output) ?
> And output of "thread apply all bt" when it crashes.
>
> On 16 July 2017 at 12:41, rataj28 <rataj28 at gmail.com> wrote:
>
> > Hello,
> >
> > I am writing and application which creates up to 12 encoding pipelines
> > using vaapih264enc. It is working fine on Intel with i965 driver but it is
> > very unstable on AMD using mesa gallium radeonsi driver. On radeonsi I can
> > run up to 16 following pipelines as a separate gst-launch:
> >
> > gst-launch-1.0 videotestsrc ! video/x-raw,width=1280,height=1024 !
> > vaapih264enc ! testsink
> >
> > I am not sure if it is relevant and gst-launch can be even used like this,
> > but when I run it as a single gst-launch:
> >
> > gst-launch-1.0 videotestsrc ! video/x-raw,width=1280,height=1024 !
> > vaapih264enc ! testsink \
> > videotestsrc ! video/x-raw,width=1280,height=1024 !
> > vaapih264enc ! testsink \
> > videotestsrc ! video/x-raw,width=1280,height=1024 !
> > vaapih264enc ! testsink \
> > videotestsrc ! video/x-raw,width=1280,height=1024 !
> > vaapih264enc ! testsink
> >
> > I am able to run up to 6 pipelines with very unstable operation which is
> > pretty much the same as I am getting from the real app. I am using latest
> > mesa from git.
> >
> > Setting pipeline to PAUSED ...
> > Pipeline is PREROLLING ...
> > Got context from element 'vaapiencodeh264-7': gst.vaapi.Display=context,
> > gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayDRM\)\
> > vaapidisplaydrm1";
> > 0:00:01.726719568 5523 0x55b8d1a88b70 ERROR vaapivideomemory
> > gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot
> > create a VA derived image from surface 0x7fa638002800
> > 0:00:01.728399262 5523 0x55b8d1a88ad0 ERROR vaapivideomemory
> > gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot
> > create a VA derived image from surface 0x7fa634002940
> > 0:00:01.728645791 5523 0x55b8d1a88a30 ERROR vaapivideomemory
> > gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot
> > create a VA derived image from surface 0x7fa640001c00
> > 0:00:01.730375640 5523 0x55b8d1a8b8f0 ERROR vaapivideomemory
> > gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot
> > create a VA derived image from surface 0x7fa63c002680
> > 0:00:01.731129406 5523 0x55b8d1a8b8a0 ERROR vaapivideomemory
> > gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot
> > create a VA derived image from surface 0x7fa624001d40
> > 0:00:01.733516403 5523 0x55b8d1a88b20 ERROR vaapivideomemory
> > gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot
> > create a VA derived image from surface 0x7fa61c001e80
> > 0:00:01.740319994 5523 0x55b8d1a8b800 ERROR vaapivideomemory
> > gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot
> > create a VA derived image from surface 0x7fa62c002a80
> > 0:00:01.743724613 5523 0x55b8d1a8b850 ERROR vaapivideomemory
> > gstvaapivideomemory.c:736:gst_video_info_update_from_surface: Cannot
> > create a VA derived image from surface 0x7fa628001400
> > Pipeline is PREROLLED ...
> > Setting pipeline to PLAYING ...
> > New clock: GstSystemClock
> > Caught SIGSEGV
> > #0 0x00007fa66296a63d in poll () at ../sysdeps/unix/syscall-template.S:84
> > #1 0x00007fa6632a5c16 in ?? () from /lib/x86_64-linux-gnu/libglib-
> > 2.0.so.0
> > #2 0x00007fa6632a5fa2 in g_main_loop_run ()
> > #3 0x00007fa663a179c1 in gst_bus_poll (bus=0x55b8d18c9a30,
> > #4 0x000055b8cfb76bb0 in event_loop (pipeline=0x55b8d1ab21e0, blocking=1,
> > #5 0x000055b8cfb75b7e in main (argc=<optimized out>,
> > argv=<optimized out>)
It seems to be a mix of two or more bugs.
It looks like the radeonsi cannot allocate enough surfaces, perhaps it
is a bug in the driver.
On the other hand gstreamer-vaapi is not handling nicely this surface
exhaustion. In this case it would be nice to have the backtrace with
symbols, as Julien said.
vmjl
> >
> > Vainfo output:
> >
> > libva info: VA-API version 0.40.0
> > libva info: va_getDriverName() returns 0
> > libva info: User requested driver 'radeonsi'
> > libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/
> > radeonsi_drv_video.so
> > libva info: Found init function __vaDriverInit_0_40
> > libva info: va_openDriver() returns 0
> > vainfo: VA-API version: 0.40 (libva )
> > vainfo: Driver version: mesa gallium vaapi
> > vainfo: Supported profile and entrypoints
> > VAProfileMPEG2Simple : VAEntrypointVLD
> > VAProfileMPEG2Main : VAEntrypointVLD
> > VAProfileVC1Simple : VAEntrypointVLD
> > VAProfileVC1Main : VAEntrypointVLD
> > VAProfileVC1Advanced : VAEntrypointVLD
> > VAProfileH264ConstrainedBaseline: VAEntrypointVLD
> > VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
> > VAProfileH264Main : VAEntrypointVLD
> > VAProfileH264Main : VAEntrypointEncSlice
> > VAProfileH264High : VAEntrypointVLD
> > VAProfileH264High : VAEntrypointEncSlice
> > VAProfileNone : VAEntrypointVideoProc
> >
> > What is the difference between running it as a single or separate
> > processes in relation to vaapi? Do anyone have any experience with vaapi on
> > radeonsi?
> >
> > Thanks
> > Tomas
> >
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> >
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
More information about the gstreamer-devel
mailing list