<div dir="ltr"><div class="gmail_extra">
<br><div class="gmail_quote">On Wed, Jan 4, 2017 at 6:07 PM, Tim Müller <span dir="ltr"><<a href="mailto:tim@centricular.com" target="_blank">tim@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, 2017-01-04 at 11:25 +0800, Yi-Lung Tsai wrote:<br>
<br>
> Our team currently develop an HEVC decode library and want to<br>
> integrate it into GStreamer pipeline.<br>
> Unfortunately we encounter a performance issue.<br>
><br>
> We test a video with frame rate 29.97.<br>
> In our test-bed, the HEVC library could process video stream under<br>
> FPS 33~34 on average.<br>
> This performance seems enough on the target machine.<br>
><br>
> Then we develop a video decoder plugin to leverage our HEVC library.<br>
> The performance is measured in "playbin" with "fpsdisplaysink".<br>
> FPS message is shown every 500ms.<br>
> From the beginning, FPS value is around 29.8~30.1.<br>
> After two seconds, the FPS starts declining and never goes back to<br>
> 20.<br>
><br>
> There is a drop mechanism in "gst_video_decoder_clip_and_pu<wbr>sh_buf".<br>
> I guess this issue is related to QoS.<br>
<br>
</span>You could first check if that's actually the case.<br>
<br>
There might be other reasons for poor performance (e.g. additional<br>
frame copies/allocations or such).<br>
<br>
Or fpsdisplaysink's text rendering being slow (use text-overlay=false).<br>
<br>
Most sinks (not fpsdisplaysink though) have a "qos" property, which<br>
will be true by default for most video sinks and false for most other<br>
sinks.<br>
<br>
You could try e.g.<br>
<br>
 ... ! fpsdisplaysink text-overlay=fa<wbr>lse video-sink="fakesink"<br>
<br></blockquote><div>In this case, average fps could exceed 30 to the end. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(^^^ measures pure decoder throughput)<br>
<br>
<br>
 ... ! fpsdisplaysink text-overlay=fa<wbr>lse video-sink="fakesink sync=true<br>
max-lateness=20000000"<br>
<br></blockquote><div>In this case, average fps could also exceed 30 to the end. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(^^^ like above but syncing to the clock and configure more like a<br>
videosink, but without QoS enabled)<br>
<br>
<br>
 ... ! fpsdisplaysink text-overlay=fa<wbr>lse video-sink="fakesink sync=true<br>
max-lateness=20000000 qos=true"<br>
<br></blockquote><div>In this case, the measure result is unstable.<br></div><div>Sometimes average fps ranges from 27 to 30.<br></div><div>But sometimes average fps is down to around 20. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(^^^ like above but syncing to the clock and configure more like a<br>
videosink, with QoS enabled)<br>
<br>
Cheers<br>
<span class="m_1272771279819844479HOEnZb"><font color="#888888"> -Tim<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Here is also an interesting found.<br></div><div class="gmail_extra">In case 3 above, there is no help if the "max-size-buffers" of queue between decoder and video sink is set to 60.<br></div><div class="gmail_extra">But in my real playback pipeline, average fps would be 29.8~30.1 if "max-size-buffers" is set to 60 as well.<br><br></div><div class="gmail_extra">According to testing results with "fakesink" above, the key point would be QoS.<br></div><div class="gmail_extra">However, in my real playback, enlarging max size of queue seems an option to get better performance.<br></div><div class="gmail_extra">Is turning QoS a good option?<br></div></div>