Why is GstBuffer not writable in the _fill method of GstPushSrc?

[Ben Rush]

Sebastian,

Thanks for the link! I'll check it out. Part of what I'm doing is just
digging into the code base in an attempt to understand what's happening.
So, even though it's a bit of a pain, the struggle I'm dealing with is
educational and will likely pay off heavily as I start to build more
advanced stuff atop Gstreamer. That being said, I've got a question that
maybe you could answer. A while ago I had mentioned I discovered the
"pack_func" function and using it within the context
of gst_video_frame_map. I started tinkering with
the gst_video_frame_map function as a way to solve this and found that when
I pin down the Intel video memory and map it with that function, I'm able
to access it directly in write mode. Everything works. I discovered this by
walking my way back up through the code base and see this is done in
the gst_video_frame_map function (well, down the stack a way):
https://github.com/jojva/gst-plugins-base/blob/a8353866857b05b3f447d2702194bb7bf1ec9e23/gst-libs/gst/video/gstvideometa.c#L268.
This call to meta->unmap actually calls into the function I was trying to
get to in the Intel Media SDK which maps the buffer for write access:
https://github.com/intel/gstreamer-media-SDK/blob/d4edf72ee2975186f11befbb24ea19d404b394fb/gst/mfx/gstmfxvideomemory.c#L118.
My question is what's the difference between the gst_video_frame_map and
the gst_buffer_map in that one is calling into these "meta" functions
whereas the other is not. They appear to be two separate ways of mapping
the memory, and indeed have dramatically different effects when used in my
context, but it's my understanding they should both be doing about the same
thing.

Ultimately I wound up basically doing something like this:

if (!gst_video_frame_map(&frame, &src->info, buffer, GST_MAP_WRITE))
goto invalid_frame;
...
int numberOfPlanes = GST_VIDEO_FRAME_N_PLANES(&frame);
guint8* pixels = (guint8*)GST_VIDEO_FRAME_PLANE_DATA(&frame, 0);
...
memcpy(pixels, buff, length);
...
gst_video_frame_unmap(&frame);

And was able to write onto the video memory just fine.


On Sat, May 4, 2019 at 5:47 AM Sebastian Dröge <sebastian at centricular.com>
wrote:

> Hi Ben,
>
> On Fri, 2019-05-03 at 12:29 -0500, Ben Rush wrote:
> >
> > I apologize for not getting back to you sooner. I will try putting up
> > some sample code for you in the near future. However, I have opened
> > up the following issue on the Intel Media SDK gstreamer github repo
> > that my be of interest to you:
> > https://github.com/intel/gstreamer-media-SDK/issues/173.
> >
> > Essentially I'm using their x264 encoder. I don't know how it's
> > working exactly, but when I request AYUV, I'm able to get a writable
> > buffer (and yes, everything works). It looks as though the GstBuffer
> > is writable, but allocated by the gstreamer pipeline itself. When I
> > request NV12, which is supported by the x264 plugin as a media type
> > from upstream elements, the Intel Media pipeline allocations memory
> > for me. This is video memory. Now, it's possible that one could make
> > the argument the memory isn't writeable from CPU code because it's on
> > the video device, but I know in Intel's OpenCL drivers I'm able to
> > get writable memory buffers since the GPU has a shared memory space
> > with the CPU (the whole point of the Intel on-chip GPU). So, it
> > should be possible. Why the code above appears to not work with it,
> > I'm unsure.
>
> That's nonetheless a bug in the MediaSDK plugin. It should not
> unconditionally give you a useless buffer pool that requires special
> mechanisms to do something with the buffers.
>
> As an alternative you might want to try the MediaSDK plugin that is
> part of the GStreamer plugin sets:
>
> https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/tree/master/sys/msdk
>
> It shouldn't have the bug with the buffer pool and also is known to
> work fine on Windows and Linux.
>
> --
> Sebastian Dröge, Centricular Ltd · https://www.centricular.com
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190506/34586305/attachment.html>