<div dir="auto">It seems my problem comes from the caps negotiation (gst_nv_decoder_negotiate) which is called several times.<div>The first time, after requesting gst.cuda.context :</div><div>as I can't implement allocation query (my application is in Java) , a default pool is created with CUDAMemory and some buffers start using this pool. </div><div>The next time, after requesting gst.gl.app_context : a new pool is created with GLMemory.<div><br></div><div><div><div>Is it a voluntary behaviour or a bug ?</div><div><br></div><div>Christophe </div></div></div></div></div><div style="line-height:1.5"><br><br>-------- Message original --------<br>De : Christophe Lafolet via gstreamer-devel <gstreamer-devel@lists.freedesktop.org><br>Date : ven. 2 juin 2023 à 20:24<br>À : gstreamer-devel@lists.freedesktop.org<br>Cc : Christophe Lafolet <christophe.lafolet@laposte.net><br>Objet : nvh264sldec + CUDA<br><blockquote>hello<br><br>I try to decode a H264 video with nvh264sldec<br><br>my appsink accept only video/x-raw and video/x-raw(memory:GLMemory) caps <br>: no CUDAMemory in my caps<br><br>on the need_context msg, I set only my GL wrapped context : no CUDA <br>context set<br><br>I receive several buffers with CUDAMemory (that I can't use) and after <br>others buffers with GLMemory<br><br>Christophe<br><br><br>Environment : CentOS7, Gstreamer 1.22.3, NVIDIA RTX A4000<br><br><br><br></blockquote></div>