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

[Nicolas Dufresne]

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: s.stelmasik at it-websolutions.com to discuss the details.
> Thanks a lot in advance!
> Sebastian Stelmasik
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190311/5402e453/attachment.sig>