Need help for finishing migration of a Digital Signage application on basis of gstreamer(-vaapi) GLX 1.6.x and info-beamer => gstreamer 1.14/15 EGL

[Sebastian Stelmasik]

Hello gstreamer Pros!

we are currently migrating a Digital Signage application on basis of gstreamer(-vaapi) 1.6.x (using the handoff signal in vaapisink) and info-beamer (https://info-beamer.com/opensource).

Until now we were using (cheap) AMD devices where we use glx-pixmaps for surface sharing between gstreamer and info-beamer which works quite perfect (no mem copy at all).

Now we have to switch to INTEL devices as there are no cheap (and compatible with the former open source driver) AMD devices and now we are experiencing frame-drop issues in surface sharing between gstreamer(-vaapi) and info-beamer on INTEL ATOM Z8300 devices (which should be a lot faster than the AMD E-350 we have been using before). As I said before we use glx-pixmaps for surface sharing which works perfect on AMD-GPUs. But now there seems to be a lot of in mem copy which causes a lot of frame-drops.

So regarding to an answer from  Víctor Jáquez our issues are now:

1) We are using a old version of gstreamer and gstreamer-vaapi
2) We are using a deprecated API for handling VA-API
3) We are using a soon-to-be deprecated buffer meta
4) We are relying on GLX, which has no future, as far as I understand

The tasks we have/had are:

1) upgrade to the latest gstreamer, gstreamer-vaapi release (nearly done: ~80%)
2) remove the old GstVaapi code (done: 75%)
3) use EGL (done: 66%)  => egl context sharing seems unfinished
4) change code to use a pipeline like this: playbin video-sink="glupload ! appsink" (done: ??)

=> the code should then use the appsink API to fetch the decoded video frames with GLMemory, which it will contain a texture that one can render. By using EGL vaapi it should export dmabuf-based buffers, those buffers should be imported as EGLImages, wrapped the texture, and thus no memcopy should be required.

Right now we have some compile issues (regarding migration of gstreamer 1.6 => 1.14) and code has to be migrated to use EGLImages instead of GLImages?
I believe that it will not be complicated as everything here is already done, all we need is make it compile (some symbols seem to have changed) and modify a couple of (sink?) functions. But unfortunately our developer cannot finish the project so I am looking for someone who can finish the migration he started for a reasonable amount of money.

You'll get full access to required project sources (via subversion) and should be able to compile/run the project.
Target platform is Ubuntu 18.04.x on INTEL Atom devices - but any other INTEL integrated GFX should be OK for developing.

Please contact me via E-Mail: [hidden email] to discuss the details.

Thanks a lot in advance!

Sebastian Stelmasik

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le lundi 11 mars 2019 à 19:47 +0100, Sebastian Stelmasik a écrit :

> Hello gstreamer Pros!
> we are currently migrating a Digital Signage application on basis of gstreamer(-vaapi) 1.6.x (using the handoff signal in vaapisink) and info-beamer (https://info-beamer.com/opensource).
> Until now we were using (cheap) AMD devices where we use glx-pixmaps for surface sharing between gstreamer and info-beamer which works quite perfect (no mem copy at all).
> Now we have to switch to INTEL devices as there are no cheap (and compatible with the former open source driver) AMD devices and now we are experiencing frame-drop issues in surface sharing between gstreamer(-vaapi) and info-beamer on INTEL ATOM Z8300 devices (which should be a lot faster than the AMD E-350 we have been using before). As I said before we use glx-pixmaps for surface sharing which works perfect on AMD-GPUs. But now there seems to be a lot of in mem copy which causes a lot of frame-drops.
> So regarding to an answer from  Víctor Jáquez our issues are now:
> 1) We are using a old version of gstreamer and gstreamer-vaapi
> 2) We are using a deprecated API for handling VA-API
> 3) We are using a soon-to-be deprecated buffer meta
> 4) We are relying on GLX, which has no future, as far as I understand
> The tasks we have/had are:
> 1) upgrade to the latest gstreamer, gstreamer-vaapi release (nearly done: ~80%)
> 2) remove the old GstVaapi code (done: 75%)
> 3) use EGL (done: 66%)  => egl context sharing seems unfinished
> 4) change code to use a pipeline like this: playbin video-sink="glupload ! appsink" (done: ??)

I'm not sure you really want/need glupload here. The VAAPI decoder can
now produce DMABuf, which you can share across process as long as you
have a mechanism to pass the rest of the metadata (format, size,
strides, offsets, etc). To request DMABuf, there is a new caps feature:

  vaapih264dec ! "video/x-raw(memory:DMABuf)" ! appsink

> => the code should then use the appsink API to fetch the decoded video frames with GLMemory, which it will contain a texture that one can render. By using EGL vaapi it should export dmabuf-based buffers, those buffers should be imported as EGLImages, wrapped the texture, and thus no memcopy should be required.
> Right now we have some compile issues (regarding migration of gstreamer 1.6 => 1.14) and code has to be migrated to use EGLImages instead of GLImages?
> I believe that it will not be complicated as everything here is already done, all we need is make it compile (some symbols seem to have changed) and modify a couple of (sink?) functions. But unfortunately our developer cannot finish the project so I am looking for someone who can finish the migration he started for a reasonable amount of money.
> You'll get full access to required project sources (via subversion) and should be able to compile/run the project.
> Target platform is Ubuntu 18.04.x on INTEL Atom devices - but any other INTEL integrated GFX should be OK for developing.
> Please contact me via E-Mail: [hidden email] to discuss the details.
> Thanks a lot in advance!
> Sebastian Stelmasik
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel