AW: AW: [External] Re: ZeroCopy + AppSink + VAAPI + Qt

[Timtchenko, Michael]

Hi,

thx 4 response!

> >I'll summarize my situation:
>>
> >- Setup: udpsrc -> vaapi -> glupload -> appsink
> >- Pulling Frames with retrieving texture ids (ids are increased by every
>>   frame) via appsink

> They shouldn't increase forever. That would mean you're leaking textures.

>> - Mapped texture ids are propagated to rendering code, but they are not mapped
>>   properly

> What does that mean?

I'm receiving a textureId within my new_sample callback and passing this to my application. In my application I'm using this textureId for creating a Qt-ScreneGraph-Node. The problem I'm facing is, that I got obviously two opengl contexts (the context from gstreamer and those from my application). When I'm receiving a textureId from new_sample, this textureId has a different meaning in my application context. For example I'm receiving the textureId 2 in my new_sample callback, which should be a frame... in my application context, this can be an icon or sth else, what was previously uploaded. (at least this is what I see).

Is my assumption right, that I should be able to use/reference a texture by the textureId within my application context? Or is this approach invalid?

Kind regards,
Michael

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] Im Auftrag von Víctor Jáquez
Gesendet: Montag, 10. Februar 2020 17:18
An: Discussion of the development of and with GStreamer <gstreamer-devel at lists.freedesktop.org>
Betreff: Re: AW: [External] Re: ZeroCopy + AppSink + VAAPI + Qt

On Mon, 10 Feb 2020 at 12:30, Timtchenko, Michael wrote:
>
> I'll summarize my situation:
>
> - Setup: udpsrc -> vaapi -> glupload -> appsink
> - Pulling Frames with retrieving texture ids (ids are increased by every
>   frame) via appsink

They shouldn't increase forever. That would mean you're leaking textures.

> - Mapped texture ids are propagated to rendering code, but they are not mapped
>   properly

What does that mean?

>
> My guess is, that there is sth wrong with content sharing. But
> unfortunately i don't know what.
>
> Am i right, that gstreamer creates its own gl context, and the passed
> context by the bus-message "GST_MESSAGE_NEED_CONTEXT" is merely used
> for sharing textures between both? In the case that this is correct,
> should it be possible to bind an textureid in Thread/Context A, which
> has been created in Thread/Context B?

gl pipeline will create is own context, but you can pass, with that bus message, *your application's gl context*, thus gl pipeline's thread will create a shared GL context with your application's one (where both context can share objects),

>
> Furthermore i get three context requests over the bus with the following types:
>
> gst.gl.app_context
> gst.gl.GLDisplay
> gst.vaapi.Display
>
> Is it nescessary to provide all three contexts, or is the application
> context sufficient for appsink?

No. Only app_context will be enough.

>
> Does anybody has suggestions towards this issue? I really appreciate
> any help/advice or coding examples. Unfortunately i cannot find any
> complete example :-/

https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/blob/master/tests/examples/gl/sdl/sdlshare.c

vmjl


Bitte beachten / Please note!

*******************************************************************************

AGCO GmbH
Sitz der AGCO GmbH: Johann-Georg-Fendt-Str.4, 87616 Marktoberdorf, Germany
Registergericht Amtsgericht Kempten HRB 10327
Geschäftsführer: Christoph Groeblinghoff, Ingrid Bussjaeger-Martin, Dr. Heribert Reiter, Ekkehart Glaeser
Vorsitzender des Aufsichtsrates: Torsten Dehner

*******************************************************************************

Diese E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches
bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht
oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder
Meinung von AGCO dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich
erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher
Druck dieser E-Mail ist strengstens untersagt. Weder AGCO noch der Absender übernehmen die
Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren angehängte
Dateien (sofern vorhanden) auf Viren zu überprüfen.

*******************************************************************************

This email is intended solely for the use of the individual to whom it is addressed and may contain
confidential and/or privileged material. Any views or opinions presented are solely those of the
author and do not necessarily represent those of AGCO. If you are not the intended recipient, be
advised that you have received this email in error and that any use, dissemination, forwarding,
printing or copying of this email is strictly prohibited. Neither AGCO nor the sender accepts any
responsibility for viruses and it is your responsibility to scan and virus check the email and its
attachment(s) (if any).

*******************************************************************************