HLS - ADAPTIVEDEMUX CPU Consumption Issue

[Josu Gorostegui]

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

The tests is simple:

$ gst-launch-1.0 -e souphttpsrc location=http://a3live-lh.
akamaihd.net/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/commi
t/?id=585e60c4abd0ea4e0a12700b84580e5b8a7cdc53

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?


Many thanks for your help. It's much appreciated.


Josu Gorostegui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170510/e7e55264/attachment-0001.html>