<div dir="ltr"><span class="gmail-m_1796972974947715454m_-6708618273139103220gmail-im" style="font-size:12.8px">>> I am using Gstreamer to render live video with Unity3D. Currently, I append<br>>> a fakesink to my pipeline, and at every frame of the Unity application the<br>>> fakesink's last-sample is queried and used to update a texture.<br>>><br>>> This works, but I feel that the performance of the plugin is a bit lacking.<br>>> I'm considering rewriting the plugin to instead use an appsink.<br>>><br>>> My question is: does querying appsink samples have any different performance<br>>> characteristics relative to querying a fakesink's last-sample?<br>>><br></span><span style="font-size:12.8px">>Are you connecting to the last-sample signal and running a callback?</span><br style="font-size:12.8px"><span style="font-size:12.8px">>If so, there is a noticeable difference between using a gobject signal</span><br style="font-size:12.8px"><span style="font-size:12.8px">>for running a callback vs using a function call in libgstapp. You can</span><br style="font-size:12.8px"><span style="font-size:12.8px">>try using gst_app_sink_pull_sample() and friends.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thanks for the reply!</span><span style="font-size:12.8px"><br></span><div><br></div><div>Every frame of the application, the plugin get's the fakesink's "last-sample" property. From the returned GstSample it gets the buffer and copies that to a target texture, so it's not using any callbacks.</div><div><br style="font-size:12.8px"><span style="font-size:12.8px">>However, I think you should do some performance measurements first. I</span><br style="font-size:12.8px"><span style="font-size:12.8px">>suspect that since you're doing GL rendering, most of your overhead is</span><br style="font-size:12.8px"><span style="font-size:12.8px">>in copying video buffers around and the function call vs. signal</span><br style="font-size:12.8px"><span style="font-size:12.8px">>callback overhead is minor in comparison. In that case, you should be</span><br style="font-size:12.8px"><span style="font-size:12.8px">>using glimagesink to write directly to a GL texture. Here's some</span><br style="font-size:12.8px"><span style="font-size:12.8px">>examples that do this with SDL2:</span><br style="font-size:12.8px">><a href="https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/gl/sdl" rel="noreferrer" style="font-size:12.8px" target="_blank">https://cgit.freedesktop.org/<wbr>gstreamer/gst-plugins-bad/tree<wbr>/tests/examples/gl/sdl</a><div><br></div><div>You're probably right that the major bottleneck is most likely copying the data from the CPU to the GPU. I looked into it, and I think I can have gstamcvideodec decode directly into GL memory.</div><div>Unfortunately when I try to do this gstamcvideodec logs:</div><div>"ERR amcvideodec gstamcvideodec.c:1977:gst_amc_video_dec_set_format:<amcvideodec-omxexynosavcdec0> Codec only supports GL output but downstream does not"</div><div><br></div><div>This is despite that fact that, before that error, gstamcvideodec logs:</div><div><br></div><div>"gstamcvideodec.c:1904:gst_amc_video_dec_set_format:<amcvideodec-omxexynosavcdec0> Available downstream caps: video/x-raw(memory:GLMemory), format=(string)RGBA, texture-target=(string)external-oes"</div><div><br></div><div>Which I <i>believe </i>should intersect properly with amcvideodec's required GL output sink caps.</div><div><br></div><div>Could this be a bug, or am I doing something wrong here?</div><div>This is with Gstreamer 1.10.4, and I'm setting playbin's videosink to "video/x-raw(memory:GLMemory),texture-target=2D,format=RGBA ! fakesink sync=1 qos=1 name=sink"</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 9:12 AM, Nirbheek Chauhan <span dir="ltr"><<a href="mailto:nirbheek.chauhan@gmail.com" target="_blank">nirbheek.chauhan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_1796972974947715454m_-6708618273139103220gmail-">On Thu, Mar 16, 2017 at 8:49 AM, Brendan Lockhart <<a href="mailto:somedude114@gmail.com" target="_blank">somedude114@gmail.com</a>> wrote:<br>
> I am using Gstreamer to render live video with Unity3D. Currently, I append<br>
> a fakesink to my pipeline, and at every frame of the Unity application the<br>
> fakesink's last-sample is queried and used to update a texture.<br>
><br>
> This works, but I feel that the performance of the plugin is a bit lacking.<br>
> I'm considering rewriting the plugin to instead use an appsink.<br>
><br>
> My question is: does querying appsink samples have any different performance<br>
> characteristics relative to querying a fakesink's last-sample?<br>
><br>
<br>
</span>Are you connecting to the last-sample signal and running a callback?<br>
If so, there is a noticeable difference between using a gobject signal<br>
for running a callback vs using a function call in libgstapp. You can<br>
try using gst_app_sink_pull_sample() and friends.<br>
<br>
However, I think you should do some performance measurements first. I<br>
suspect that since you're doing GL rendering, most of your overhead is<br>
in copying video buffers around and the function call vs. signal<br>
callback overhead is minor in comparison. In that case, you should be<br>
using glimagesink to write directly to a GL texture. Here's some<br>
examples that do this with SDL2:<br>
<a href="https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/tests/examples/gl/sdl" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/g<wbr>streamer/gst-plugins-bad/tree/<wbr>tests/examples/gl/sdl</a><br>
<br>
Cheers,<br>
Nirbheek<br>
______________________________<wbr>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesk<wbr>top.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/gstreamer-dev<wbr>el</a><br>
</blockquote></div><br></div></div></div></div></div></div>