<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Sebastian, <br><br>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): <a href="https://github.com/jojva/gst-plugins-base/blob/a8353866857b05b3f447d2702194bb7bf1ec9e23/gst-libs/gst/video/gstvideometa.c#L268">https://github.com/jojva/gst-plugins-base/blob/a8353866857b05b3f447d2702194bb7bf1ec9e23/gst-libs/gst/video/gstvideometa.c#L268</a>. 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:
<a href="https://github.com/intel/gstreamer-media-SDK/blob/d4edf72ee2975186f11befbb24ea19d404b394fb/gst/mfx/gstmfxvideomemory.c#L118">https://github.com/intel/gstreamer-media-SDK/blob/d4edf72ee2975186f11befbb24ea19d404b394fb/gst/mfx/gstmfxvideomemory.c#L118</a>. 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. <br><br>Ultimately I wound up basically doing something like this: <br><br><div dir="ltr"><span style="white-space:pre"> </span>if (!gst_video_frame_map(&frame, &src->info, buffer, GST_MAP_WRITE))</div><div dir="ltr"><span style="white-space:pre"> </span>goto invalid_frame;</div><div dir="ltr"><span style="white-space:pre"> </span>...</div><div dir="ltr"><span style="white-space:pre"> </span>int numberOfPlanes = GST_VIDEO_FRAME_N_PLANES(&frame); </div><div dir="ltr"><span style="white-space:pre"> </span>guint8* pixels = (guint8*)GST_VIDEO_FRAME_PLANE_DATA(&frame, 0);</div><div dir="ltr"><span style="white-space:pre"> </span>...</div><div dir="ltr"><span style="white-space:pre"> </span>memcpy(pixels, buff, length); </div><div dir="ltr"><span style="white-space:pre"> </span>...</div><div dir="ltr"><span style="white-space:pre"> </span>gst_video_frame_unmap(&frame);</div><br>And was able to write onto the video memory just fine. <br><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 4, 2019 at 5:47 AM Sebastian Dröge <<a href="mailto:sebastian@centricular.com">sebastian@centricular.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Ben,<br>
<br>
On Fri, 2019-05-03 at 12:29 -0500, Ben Rush wrote:<br>
> <br>
> I apologize for not getting back to you sooner. I will try putting up<br>
> some sample code for you in the near future. However, I have opened<br>
> up the following issue on the Intel Media SDK gstreamer github repo<br>
> that my be of interest to you: <br>
> <a href="https://github.com/intel/gstreamer-media-SDK/issues/173" rel="noreferrer" target="_blank">https://github.com/intel/gstreamer-media-SDK/issues/173</a>. <br>
> <br>
> Essentially I'm using their x264 encoder. I don't know how it's<br>
> working exactly, but when I request AYUV, I'm able to get a writable<br>
> buffer (and yes, everything works). It looks as though the GstBuffer<br>
> is writable, but allocated by the gstreamer pipeline itself. When I<br>
> request NV12, which is supported by the x264 plugin as a media type<br>
> from upstream elements, the Intel Media pipeline allocations memory<br>
> for me. This is video memory. Now, it's possible that one could make<br>
> the argument the memory isn't writeable from CPU code because it's on<br>
> the video device, but I know in Intel's OpenCL drivers I'm able to<br>
> get writable memory buffers since the GPU has a shared memory space<br>
> with the CPU (the whole point of the Intel on-chip GPU). So, it<br>
> should be possible. Why the code above appears to not work with it,<br>
> I'm unsure. <br>
<br>
That's nonetheless a bug in the MediaSDK plugin. It should not<br>
unconditionally give you a useless buffer pool that requires special<br>
mechanisms to do something with the buffers.<br>
<br>
As an alternative you might want to try the MediaSDK plugin that is<br>
part of the GStreamer plugin sets:<br>
<a href="https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/tree/master/sys/msdk" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/tree/master/sys/msdk</a><br>
<br>
It shouldn't have the bug with the buffer pool and also is known to<br>
work fine on Windows and Linux.<br>
<br>
-- <br>
Sebastian Dröge, Centricular Ltd · <a href="https://www.centricular.com" rel="noreferrer" target="_blank">https://www.centricular.com</a><br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div>