HLS - ADAPTIVEDEMUX CPU Consumption Issue

[Edward Hervey]

Hi,

On Wed, 2017-05-10 at 13:28 +0200, Josu Gorostegui wrote:
> Esteemed gurus,
> 
> I find some strange behavior playing HLS 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.

  The commit you point to below is in adaptivedemux, so it should only
happen on those kind of elements (hlsdemux, dashdemux, ...).

> 
> 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.

  What kind of error messages do you get ?

> 
> The tests is simple:
> 
> $ gst-launch-1.0 -e souphttpsrc location=http://a3live-lh.akamaihd.ne
> t/i/antena3_1 at 35248/index_4_av-b.m3u8 name=source ! hlsdemux
> name=hlsm ! queue ! tsdemux name=demux use-buffering=true demux. !
> fakesink sync=true
> 
> Running this pipeline, even at the start the behaviour is right.
> 
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+
> COMMAND             
> 24202 udooer    20   0  133396  27780   5224 S   2.0  2.7   0:02.89
> lt-gst-launch-1 
> 
> After some couple of hours, 
> 
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+
> COMMAND             
> 23816 udooer    20   0  137304  33516   5284 S  55.6  3.3  38:03.58
> lt-gst-launch-1     
> 
> This simple test is run in an i.MX6 platform but the behaviour is
> exactly the same in other platforms (x86).
> 
> 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.
> 
> In my point of view there is some kind of instability here.
> Analyzing the problem, I founded that the problem arises from the
> next patch:
> 
> https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=585
> e60c4abd0ea4e0a12700b84580e5b8a7cdc53
> 
> So, deleting the callback:
> 
> 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_lock);
>   stream->src_at_ready = TRUE;
>   g_cond_signal (&stream->fragment_download_cond);
>   g_mutex_unlock (&stream->fragment_download_lock);
> 
>   return GST_PAD_PROBE_OK;
> }
> 
> and the obviously the related stuff 
> 
>   stream->src_at_ready = FALSE;
> 
>   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_lock);
>   while (!stream->src_at_ready) {
>     g_cond_wait (&stream->fragment_download_cond,
>         &stream->fragment_download_lock);
>   }
>   g_mutex_unlock (&stream->fragment_download_lock);
> 
> This behavior doesn't happen, so I think that is some kind of
> regression in this patch.
> However, I don't think that removing the stuff is the perfect way to
> go so I would like to consult you first.
> 
> What do you think? Should I file a bug?

  The first step would be to try to reproduce it with a more recent
version (1.12 for example).
  If it still happens, please do open a bug report with as much detail
as possible (logs, error messages, etc..).

  Thanks !

     Edward
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170526/d1419256/attachment.sig>