HLS - ADAPTIVEDEMUX CPU Consumption Issue
Locked
HLS - ADAPTIVEDEMUX CPU Consumption Issue
 
|
Re: HLS - ADAPTIVEDEMUX CPU Consumption Issue
|
|
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@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? 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 _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
signature.asc (836 bytes) | Free forum by Nabble | Edit this page |