<div dir="ltr">The whole point of this email is to verify I've encountered a bug, and not that I'm doing some stupid. <br><br>I've been successfully using the Intel Media SDK GStreamer element from their repo here: <a href="https://github.com/intel/gstreamer-media-SDK/tree/topic_linux_and_window">https://github.com/intel/gstreamer-media-SDK/tree/topic_linux_and_window</a> for a while now. My successful setup is I've got a camera connected to a machine (a Windows machine), and then I'm using the GStreamer's RTSP server to take the camera feed, encode it on the GPU (with the help of the Intel GStreamer h265/h264 plugins), and then broadcast it. There were a few bumps along the way (mostly bugs and issues in their code), but I've since got it resolved and have things working. GStreamer is awesome. My point thus far is I've been able to get these Intel plugins to work with the rest of GStreamer. <br><br>I've been given another use case, and I'm encountering what appears to be another issue in Intel's code. I would normally think I'm doing something dumb, but given the # of issues I ran into when getting their elements to work in the aforementioned setup, I'm considering I've run into another bump. <br><br>Essentially I'm NOW writing a video player, and need to decode traffic. So I'm on the player side of the equation now. Again, I'm using the Intel Media SDK to decode. Now, according to gst-inspect, the output pins for either the h264 or h265 intel decoders should produce BGRA. This is important because the user interface control I'm using doesn't support NV12, and requires a BGRA buffer. I don't want to do the conversion from NV12 to RGB* on the CPU 'cause that defeats the whole reason I'm using the Intel Media SDK in the first place. Example output from gst-inspect on their h265 element: <br><br><p style="margin:0px 0px 1.5em;padding:0px;font-family:Arial,宋体,Tahoma,Helvetica,sans-serif;font-size:12px;color:rgb(83,87,94);font-style:italic">Pad Templates:<br>  SINK template: 'sink'<br>    Availability: Always<br>    Capabilities:<br>      video/x-h265<br>              alignment: au<br>                profile: { (string)main, (string)main-10 }<br>          stream-format: byte-stream</p><p style="margin:0px 0px 1.5em;padding:0px;font-family:Arial,宋体,Tahoma,Helvetica,sans-serif;font-size:12px;color:rgb(83,87,94);font-style:italic">  SRC template: 'src'<br>    Availability: Always<br>    Capabilities:<br>      video/x-raw(memory:MFXSurface)<br>                 format: { (string)NV12, (string)<span style="font-weight:700">BGRA</span>, (string)P010_10LE, (string)YUY2, (string)ENCODED }<br>                  width: [ 1, 2147483647 ]<br>                 height: [ 1, 2147483647 ]<br>              framerate: [ 0/1, 2147483647/1 ]<br>      video/x-raw<br>                 format: { (string)NV12, (string)<span style="font-weight:700">BGRA</span>, (string)P010_10LE, (string)YUY2 }<br>                  width: [ 1, 2147483647 ]<br>                 height: [ 1, 2147483647 ]<br>              framerate: [ 0/1, 2147483647/1</p>However, NOTHING I do successfully decodes into BGRA. I can write the following gst-launch script and see the video stream just fine when specifying NV12: <br><br><em style="margin:0px;padding:0px;color:rgb(83,87,94);font-family:Arial,宋体,Tahoma,Helvetica,sans-serif;font-size:12px">gst-launch-1.0.exe rtspsrc location=<a style="margin:0px;padding:0px;color:rgb(8,109,182)">rtsp://address/live</a> ! decodebin ! 'video/x-raw(memory:MFXSurface),format=<span style="font-weight:700">NV12</span>' ! autovideosink</em> <div><br></div><div>If I change the format to BGRA, however, the player doesn't pop up:<br><br> <em style="margin:0px;padding:0px;color:rgb(83,87,94);font-family:Arial,宋体,Tahoma,Helvetica,sans-serif;font-size:12px">gst-launch-1.0.exe rtspsrc location=<a style="margin:0px;padding:0px;color:rgb(8,109,182)">rtsp://address/live</a> ! decodebin ! 'video/x-raw(memory:MFXSurface),format=<span style="font-weight:700">NV12</span>' ! autovideosink</em>   </div><div><br></div><div>What's weird is I see both the CPU and GPU chewing away doing the above script, but nothing displays. By dumping out the dot files, I see the pipeline fails to successfully enter the PLAY state. Digging further...<br><br>If I attach and debug the Intel MFX element and run the above script that fails, I see the following line fails: <a href="https://github.com/intel/gstreamer-media-SDK/blob/94ab6055b60e9d67a3ccb6b13fddb6c3076e204d/gst/mfx/gstmfxdec.c#L424">https://github.com/intel/gstreamer-media-SDK/blob/94ab6055b60e9d67a3ccb6b13fddb6c3076e204d/gst/mfx/gstmfxdec.c#L424</a>. It looks like this: <br><br><span style="color:rgb(3,47,98);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:12px;white-space:pre;background-color:rgb(255,251,221)">return gst_video_decoder_finish_frame (vdec, frame);</span> </div><div><br></div><div>The function returns <span style="color:rgb(83,87,94);font-family:Arial,宋体,Tahoma,Helvetica,sans-serif;font-size:12px">GST_FLOW_NOT_NEGOTIATED. </span> Setting GST_DEBUG=4, I see the following warning which further indicates that some kind of negotiation failed: <br><br><span style="color:rgb(83,87,94);font-family:Arial,宋体,Tahoma,Helvetica,sans-serif;font-size:12px">WARN                GST_PADS gstpad.c:4230:gst_pad_peer_query:<mfxdec_h264-0:src> could not send sticky events</span> <br><br class="gmail-Apple-interchange-newline">What I need is confirmation that the above gst-launch commands OUGHT to give me BGRA at the autovideosink if things were working correctly in the Intel decoders. Everything thus far seems to indicate I'm running into some bug. To be doubly sure, I see the same behavior when I replace autovideosink with appsink and write some C++ around it. <br><br>Thanks for your expertise and extra pair of eyes. </div></div>