[Webkit-unassigned] [Bug 185242] [MSE][GStreamer] Delete properly the stream from the WebKitMediaSource

[bugzilla-daemon at webkit.org]

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

--- Comment #12 from Yacine Bandou <bandou.yacine at gmail.com> ---
(In reply to Alicia Boya García from comment #11)
> Comment on attachment 339534 [details]
> Patch
> 
> 
> Summarizing: in order to tear down the source element you need to tear down
> its streaming thread. In order to tear down the streaming thread you need to
> wait for the current flowing buffer to complete its journey in this
> streaming thread, but that won't happen until the queue at the end of this
> stream has available space and therefore stops blocking the thread. The
> queue won't have available space until the sink is set to PLAYING or the
> pipeline is flushed. That won't ever happen (moreso when the main thread is
> waiting), therefore you've got a deadlock.

I agree with you, when I studied in detail what happen with encrypted-media WPT tests, I saw what you said.
For that, I tried to fix it with the patch 185592, but it is a bad solution.

After a detailed investigation, I found that, this patch doesn't fix the crash, it just replaces the crash by a blocking.

Here is the real root cause of the crash. (-> : calls)

1.When an error occurs in playback pipeline (no decipher key), we receive an error message in MediaPlayerPrivateGStreamer::handleMessage -> MediaPlayerPrivateGStreamer::loadingFailed (MediaPlayer::FormatError).

2.The function loadingFailed -> HTMLMediaElement::mediaPlayerNetworkStateChanged (MediaPlayer::FormatError) -> setNetworkState -> mediaLoadingFailed -> noneSupported go to the point 3
                              |
                               -> HTMLMediaElement::mediaPlayerReadyStateChanged(MediaPlayer::HaveNothing) -> setReadyState -> updatePlayState() go to the point 5

3.nonSupported -> detachMediaSource -> MediaSource::detachFromElement -> removeSourceBuffer -> MediaSourceGStreamer::removeSourceBuffer -> .. ->PlaybackPipeline::removeSourceBuffer

4.PlaybackPipeline::removeSourceBuffer -> webKitMediaSrcFreeStream . 

5.HTMLMediaElement::updatePlayState -> potentiallyPlaying -> stoppedDueToErrors ( This function returns false because (m_readyState >= HAVE_METADATA && m_error) is false, m_readyState equal to HaveNothing )

6.HTMLMediaElement::updatePlayState -> MediaPlayer::play -> MediaPlayerPrivateGStreamer::play -> changePipelineState (set the pipeline to playing state)

7.WebkitMediaSourceGStreamer sends "source-setup" signal when its state change from Ready to Paused, the signal catched in MediaPlayerPrivateGStreamer::sourceSetupCallback

8.MediaPlayerPrivateGStreamer::sourceSetupCallback -> MediaPlayerPrivateGStreamerMSE::sourceSetup -> MediaSourceGStreamer::open -> MediaSource::setPrivateAndOpen (crash in this function because the mediaSource is detached from mediaElement in the point 3, thus the variable  m_mediaElement is null).


In the point 5 the function "HTMLMediaElement::stoppedDueToErrors" returns false, because m_readyState equal to HaveNothing and it is not upper than HAVE_METADATA.
I think we don't have to set the ReadyState to HaveNothing when an error occurs in pipeline, we should just set NetworkState to error.


Here is the my roadmap:
1. I'll push a new patch to remove a part of this patch (185242) which caused the blocking.
2. I'll push an other new patch to fix the crash, this patch just set NetworkState without ReadyState when an error occurs in pipeline.
3. I'll close the bug 185592 as invalid bug.
4. I'll update the patch 185593 to depend on the two new patches.

-- 
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/20180517/dcbb638a/attachment.html>