[Webkit-unassigned] [Bug 185592] [MSE][GStreamer] Before deleting the stream from WebKitMediaSource we should unlink its elements and flush the appsrc.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=185592

--- Comment #11 from Yacine Bandou <bandou.yacine at gmail.com> ---
(In reply to Alicia Boya García from comment #9)
> (In reply to Yacine Bandou from comment #8)
> > 
> > When we properly unlink and flush the appsrc (basesrc), we don't stay block
> > when we go from the paused state to ready in appsrc.
> > 
> > Do you have an other way to avoid this blocking ? I attached the thread call
> > stack
> 
> A small blocking wait is expected, as the main thread needs to wait for the
> worker thread to finish before freeing the memory and resources it was
> using. The code performing the wait is in gst_base_src_stop().
> 
> This happens whenever the pad gets "deactivated" (gst_pad_set_active() is
> called with active=FALSE), which triggers the gstbasesrc pad (de)activation
> function, gst_base_src_activate_mode(). This happens whenever the source
> element state is downgraded to READY (you can see this in
> gst_element_change_state_func(), look for `case
> GST_STATE_CHANGE_PAUSED_TO_READY:`).
> 
> This is all expected behavior in GStreamer and for the most part, threaded
> code in general.
> 
> Unlinking the pads during playback or flushing does not alter this behavior.


The problem, it is not a small blocking but it is infinite waiting as a deadlock.

But in the callstack I don't see a deadlock.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180514/369733a1/attachment.html>