[Libva] Decoding and displaying multiple streams using gstreamer-vaapi

[Erik Andersson]

Me and Andreas work together and to test the threading on a lower level we
used the putsurface test in the libva package.
Turns out that the EMGD driver was not able to run this test with 2
threads. ( putsurface -t ).

So this is probably not a problem in the gst-vaapi glue or in libva itself.
We think its more likely that there is a starvation problem in the EMGD
libva backend.
The tests we have performed works fine on Ivy and Sandy with the open
driver.

Since the EMGD driver is closed we are kind of stuck. Does anyone know why
this driver is closed? We can understand that the 3D stuff for the US15W is
closed but is there really that much IP in the libva backend?

@Krzysztof: This test might be a good one for you as well. To rule out the
gst-vaapi glue.

Best regards.
Erik

2012/9/14 Krzysztof Kotlenga <pocek at users.sf.net>

> andreas.larssona wrote:
>
> > Btw, what I forgot to mention is that multiple streams works fine if
> > we have separate processes, instead of threads. So the kernel layer
> > and the HW obviously is correct and capable.
>
> Same problem exists with libva and vdpau-driver. A simple test case
> can be this one:
>
> gst-launch-0.10 -e filesrc location=some.mkv ! matroskademux ! tee
> name=tee \
> tee. ! queue ! vaapidecode ! fakesink \
> tee. ! queue ! vaapidecode ! fakesink
>
> Errors with vdpau-driver range from SIGSEGV to one from:
>
> gst-launch-0.10: object_heap.c:109: object_heap_allocate: Assertion
> `heap->next_free >= 0' failed.
>  or
> vdpau_video: vaTerminate(): buffer ID 0x0400001e is still allocated,
> destroying
>  or
> gst-launch-0.10: vdpau_buffer.c:47: destroy_dead_va_buffers: Assertion
> `obj_buffer' failed.
>
> etc.
>
> This is with all the VA stuff from master branches and gst from the
> 0.10 branch. No problem with separate processes.
>
> libva/intel-driver/gstreamer-vaapi from ubuntu 12.04 also sometimes
> crash with SIGSEGV in this case (i965). Master branches as of today
> seem to work fine though.
>
> Adding some long delay between each vaapidecode creation and startup
> doesn't help.
>
> Backtrace: http://paste.debian.net/189800/
>
> Any ideas?
>
>
>
> _______________________________________________
> Libva mailing list
> Libva at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libva
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20120918/01a1ed5b/attachment-0001.html>