<div dir="ltr"><div style="font-size:12.8px">Esteemed gurus,</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I find some strange behavior playing <b>HLS</b> sources from internet with versions of GStreamer 1.8.3 and above. I don't think this occurs only to HLS sources, as will be explained ahead.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The source is played correctly but the CPU consumption increases without any reason and the pipeline until the pipeline eventually freezes or exits with an error.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The tests is simple:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">$ gst-launch-1.0 -e souphttpsrc location=<a href="http://a3live-lh.akamaihd.net/i/antena3_1@35248/index_4_av-b.m3u8" target="_blank">http://a3live-lh.<wbr>akamaihd.net/i/antena3_1@<wbr>35248/index_4_av-b.m3u8</a> name=source ! hlsdemux name=hlsm ! queue ! tsdemux name=demux use-buffering=true demux. ! fakesink sync=true</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Running this pipeline, even at the start the behaviour is right.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><div><b> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND </b></div><div><b>24202 udooer 20 0 133396 27780 5224 S 2.0 2.7 0:02.89 lt-gst-launch-1 </b></div><div><br></div><div>After some couple of hours, <br></div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><div><b> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND </b></div><div><b>23816 udooer 20 0 137304 33516 5284 S 55.6 3.3 38:03.58 lt-gst-launch-1 </b></div><div><br></div><div>This simple test is run in an i.MX6 platform but the behaviour is exactly the same in other platforms (x86).</div><div><br></div></div><div style="font-size:12.8px">The pattern repeats with playbin too, so it is not possible to play an Internet source without problems continuously without the pertinent CPU consumption increase issue.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">In my point of view there is some kind of instability here.</div><div style="font-size:12.8px">Analyzing the <i>problem, </i>I founded that the problem arises from the next patch:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><a href="https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=585e60c4abd0ea4e0a12700b84580e5b8a7cdc53" target="_blank">https://cgit.freedesktop.org/g<wbr>streamer/gst-plugins-bad/commi<wbr>t/?id=585e60c4abd0ea4e0a12700b<wbr>84580e5b8a7cdc53</a><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">So, deleting the callback:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><pre style="white-space:pre-wrap;padding:0px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0);font-size:13.3333px"><code><i>static GstPadProbeReturn gst_ad_stream_src_to_ready_cb (GstPad * pad, GstPadProbeInfo * info, gpointer user_data) { GstAdaptiveDemuxStream *stream = user_data; /* The source's src pad is IDLE so now set the state to READY */ g_mutex_lock (&stream->fragment_download_lo<wbr>ck); stream->src_at_ready = TRUE; g_cond_signal (&stream->fragment_download_co<wbr>nd); g_mutex_unlock (&stream->fragment_download_lo<wbr>ck); return GST_PAD_PROBE_OK; }</i></code></pre></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">and the obviously the related stuff </div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><i> <span style="color:rgb(0,0,0);font-size:13.3333px"> stream->src_at_ready = FALSE;</span></i></div><pre style="white-space:pre-wrap;padding:0px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0);font-size:13.3333px"><code><i> gst_element_set_locked_state (stream->src, TRUE); gst_pad_add_probe (stream->src_srcpad, GST_PAD_PROBE_TYPE_IDLE, gst_ad_stream_src_to_ready_cb, stream, NULL); g_mutex_lock (&stream->fragment_download_lo<wbr>ck); while (!stream->src_at_ready) { g_cond_wait (&stream->fragment_download_co<wbr>nd, &stream->fragment_download_loc<wbr>k); } g_mutex_unlock (&stream->fragment_download_lo<wbr>ck);</i></code></pre><pre style="white-space:pre-wrap;padding:0px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0);font-size:13.3333px"><code><i><br></i></code></pre><pre style="white-space:pre-wrap;padding:0px;margin-top:0px;margin-bottom:0px"><font face="arial, helvetica, sans-serif"><font color="#000000"><span style="font-size:13.3333px">This behavior doesn't happen, so I think that is some kind of regression in this patch.</span></font></font></pre><pre style="white-space:pre-wrap;padding:0px;margin-top:0px;margin-bottom:0px"><font face="arial, helvetica, sans-serif"><font color="#000000"><span style="font-size:13.3333px">However, I don't think that removing the stuff is the perfect way to go so I would like to consult you first.</span></font></font></pre><pre style="white-space:pre-wrap;padding:0px;margin-top:0px;margin-bottom:0px"><br></pre><pre style="white-space:pre-wrap;padding:0px;margin-top:0px;margin-bottom:0px"><font face="arial, helvetica, sans-serif"><font color="#000000"><span style="font-size:13.3333px">What do you think? </span></font>Should I file a bug?</font></pre><pre style="white-space:pre-wrap;padding:0px;margin-top:0px;margin-bottom:0px"><font face="arial, helvetica, sans-serif"><br></font></pre><pre style="white-space:pre-wrap;padding:0px;margin-top:0px;margin-bottom:0px"><font face="arial, helvetica, sans-serif">Many thanks for your help. It's much appreciated.</font><br></pre><pre style="white-space:pre-wrap;padding:0px;margin-top:0px;margin-bottom:0px"><font face="arial, helvetica, sans-serif"><br></font></pre><pre style="white-space:pre-wrap;padding:0px;margin-top:0px;margin-bottom:0px"><font face="arial, helvetica, sans-serif">Josu Gorostegui</font></pre></div>