[Bug 781537] NVDEC - Nvidia Decoder plugin

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=781537

--- Comment #48 from Per-Erik Brodin <per-erik.brodin at ericsson.com> ---
(In reply to Sebastian Dröge (slomo) from comment #46)
> (In reply to Per-Erik Brodin from comment #43)
> > (In reply to Sebastian Dröge (slomo) from comment #41)
> > 
> > Thank you for the quick review!
> > 
> > > Review of attachment 352853 [details] [review] [review] [review]:
> > > 
> > > Just some initial comments below
> > > 
> > > ::: configure.ac
> > > @@ +1920,3 @@
> > > +  save_CPPFLAGS="$CPPFLAGS"
> > > +  CPPFLAGS="$NVCUVID_CFLAGS $save_CPPFLAGS"
> > > +  AC_CHECK_HEADER([nvcuvid.h], [HAVE_NVCUVID_H=yes],
> > > 
> > > Why don't you use pkg-config?
> > 
> > At least on Debian/Ubuntu there is no .pc file provided by nvidia-cuda-dev.
> > nvcuvid.h is located directly under /usr/include so typically you don’t have
> > to set the NVCUVID_CFLAGS.
> 
> There are checks for cuda/etc for nvenc already, which use the .pc files if
> available or $CUDA_PREFIX otherwise. Can you reuse those instead of adding
> your own, and just keep the nvenc/nvdec specific parts for those plugins?

Done

> 
> > > ::: sys/nvdec/gstnvdec.c
> > > @@ +120,3 @@
> > > +  CUgraphicsResource *resources;
> > > +  guint num_resources;
> > > +} GstNvDecCudaGraphicsResourcesMeta;
> > > 
> > > Why is this a GstMeta instead of a custom GstMemory (e.g. based on
> > > GstGLBaseMemory)?
> > 
> > I considered that but then we would also need a custom allocator and maybe a
> > custom buffer pool and then the downstream element won’t be able to do the
> > allocation. I think using a GstMeta is the best temporary solution until we
> > have a GstCUDA library.
> 
> What do you mean here? Couldn't downstream allocate any kind of GL buffer
> (e.g. glimagesink) and nvdec could make use of that? The meta limits how
> useful this is in the end, as the meta could disappear and also requires
> elements to know about the meta (while GL memory is generally supported by
> various elements already, including nvenc).
> 

The meta is only there so that we can call cuGraphicsGLRegisterImage once per
image, since it’s a costly operation, and associate the returned handle with
the buffer so that we can retrieve it when needed, and also so that
cuGraphicsUnregisterResource can be called when the buffer is freed. There’s no
need for other elements to know about it. I think a downstream element would
have to know about a custom GLMemory in order to allocate it, or are you
suggesting that nvdec adds additional memory to an already allocated buffer
similarly to how the meta is added now? Another option if you want to get rid
of the meta is to keep a table in nvdec with weak references to the GLMemory
that has been registered with CUDA, but that can be a bit problematic since the
buffers could potentially outlive the element.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.