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

Ben Rush ben at ben-rush.net
Fri May 3 17:29:56 UTC 2019


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.

BTW: I've also opened another issue that some GStreamer users might
encounter when using the Intel Media SDK (on Windows) here:
https://github.com/intel/gstreamer-media-SDK/issues/169. I might try fixing
this (it might be done so by a simple preprocessor statement preventing
that code from compiling on Windows).

Anyway. Keeping you up to date.

On Tue, Apr 30, 2019 at 5:39 AM Sebastian Dröge <sebastian at centricular.com>

> On Mon, 2019-04-29 at 10:46 -0500, Ben Rush wrote:
> > Sebastian,
> >
> > So, I'm not sure precisely what's going on, but I think it might -
> > maybe - have something to do with the fact that I'm using the MFX
> > (Intel Media SDK) GStreamer modules, and that perhaps things aren't
> > playing well together. Let me explain. I've got an example
> > application that, all it does, is encode a static image of the
> > scientist Richard Feynman to disk as an MP4 file (500 frames). I use
> > it to kind of tinker and explore the various parts of the GStreamer
> > pipeline.
> >
> > I have found that if I set the output caps to NV12, the
> > gst_buffer_map() call fails:
> >
> > static GstStaticPadTemplate gst_feynman_template =
> >       GST_PAD_SRC,
> >       GST_PAD_ALWAYS,
> > );
> >
> > If, on the other hand, I change this to AYUV, it works:
> >
> > static GstStaticPadTemplate gst_feynman_template =
> >       GST_PAD_SRC,
> >       GST_PAD_ALWAYS,
> > );
> >
> > It doesn't matter what I actually send as this failure happens before
> > I send anything at all. During the first invocation to fill the
> > buffer, the gst_buffer_map call fails as I've indicated in previous
> > emails if I specify NV12. As I'm writing this email out certain
> > things are starting to becoming clearer, and I presume what's
> > happening is that per the handshake between my source DLL and the
> > downstream gstmfx.dll (and the x264 encoder therein) something is
> > failing to initialize properly, thereby causing the GStreamer
> > pipeline to fail to also initialize the GstBuffer for me properly.
> > Specifically, the gstmfxenc_h264.c encoder is failing to handle NV12
> > properly (or me asking it to handle this format is failing on its
> > side and therefore falling back to some standard GStreamer
> > allocator/handler (I don't know the terminology well as I'm still
> > learning)).
> >
> > I know that the gstmfx encoder suite advertises that it supports
> > these formats:
> >
> >     "{ NV12, YV12, I420, YUY2, P010_10LE, BGRA, BGRx }"
> >
> > What tipped me off was inspecting the GstBuffer object in-memory, and
> > seeing when I specified NV12, the GstBuffer->Pool->Object->name was
> > "mfxvideobufferpool0", whereas if I specify AYUV, the name is
> > "videobufferpool0".
> >
> > So, does this appear to be a bug in the intel media encoder side of
> > things? Or am I still not using something correctly? If it is a bug
> > in the Intel side of things, do you have any advise on how to track
> > it down? They've been pretty unhelpful so far regarding various other
> > issues I've encountered using their stuff.
> Does it work correctly if you us AYUV?
> I don't see anything specifically wrong in your code, especially not in
> the fill() function. What you say sounds like the MFX plugin is
> providing you with a buffer pool that provides buffers that can't be
> write-mapped. That would be a bug in the MFX plugin.
> Which MFX plugin are you using? Does it work better if you use
> something else instead?
> In any case, instead of just providing the code in-line in a mail it
> would be good if you could provide a git repository with everything
> needed to compile and run it so that it's easier to check what exactly
> is happening.
> That said, from what you describe it sounds like a bug in the MFX
> plugin.
> --
> 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/20190503/3040a535/attachment-0001.html>

More information about the gstreamer-devel mailing list