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

[Sebastian Dröge]

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_STATIC_PAD_TEMPLATE("src",
> 	GST_PAD_SRC,
> 	GST_PAD_ALWAYS,
> 	GST_STATIC_CAPS(GST_VIDEO_CAPS_MAKE("{NV12}"))
> );
> 
> If, on the other hand, I change this to AYUV, it works: 
> 
> static GstStaticPadTemplate gst_feynman_template =
> GST_STATIC_PAD_TEMPLATE("src",
> 	GST_PAD_SRC,
> 	GST_PAD_ALWAYS,
> 	GST_STATIC_CAPS(GST_VIDEO_CAPS_MAKE("{AYUV}"))
> );
> 
> 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: 
> 
> # define GST_MFX_SUPPORTED_INPUT_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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190430/fcc45631/attachment.sig>