diff options
| author | ygorshenin@chromium.org <ygorshenin@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-03-27 08:39:18 +0000 |
|---|---|---|
| committer | ygorshenin@chromium.org <ygorshenin@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-03-27 08:39:18 +0000 |
| commit | d707fdef095589dda221af41f522bd1a423ed294 (patch) | |
| tree | 9d219b2aae6c98f0edae83c486f97c7a686dbc32 /media/test | |
| parent | 027935380c71208b1d16f0094f5a65470f50f676 (diff) | |
| download | chromium_src-d707fdef095589dda221af41f522bd1a423ed294.zip chromium_src-d707fdef095589dda221af41f522bd1a423ed294.tar.gz chromium_src-d707fdef095589dda221af41f522bd1a423ed294.tar.bz2 | |
Revert 190807 "Fix a Chrome renderer hang which occurs when a We..."
> Fix a Chrome renderer hang which occurs when a WebMediaPlayerImpl instance is shutting down and hangs due to
> a deadlock between the media pipeline thread and the Renderer main thread.
>
> The media pipeline thread waits on a task(RendererGpuVideoDecoderFactories::AsyncCreateSharedMemory) to be
> executed on the main thread while the main thread waits on the media pipeline thread to exit.
>
> The proposed fix is to introduce the following functions on the media::GpuVideoDecoder::Factories interface.
> 1. Abort:- Called during shutdown.
> 2. IsAborted:- Called to check if shutdown is in progress.
>
> The Abort function is called when the WebMediaPlayerImpl is shutting down. The video decoder factory sets an
> event in this context. All tasks which complete asynchronously check for this event along with the event
> which indicates that the async task completed. This ensures that they don't indefinitely wait during shutdown.
> The asynchronous tasks in the RendererGpuVideoDecoderFactories now use a common event to signal completion
> and return their results in member variables. This prevents a race between RendererGpuVideoDecoderFactories::Abort
> being called and these tasks attempting to copy data to the callers stack which may have unwound at this point.
>
> While debugging this problem, I also found that there are scenarios where the GVD::Reset never completes
> thus hanging the renderer. This problem occurs when the GVD is in the kDrainingDecoder state, i.e. waiting
> for a Flush to complete. The VRB is waiting for the GVD::Reset operation to complete. The VDA is waiting for
> output picture buffers which the VRB is holding on to. Proposed fix for that was to flush out the ready frames
> in the VRB::Flush call which unblocks the VDA.
>
> I changed the ReadPixelsCB to take in a const SkBitmap& instead of void* to address the refcount issues with the
> SkBitmap.
>
> While running my test case with tip two DCHECK's in VideoFrameStream::OnDecoderStopped fired. The first one
> is the case where the decoder is stopped while there is a pending read callback. The second one is for the same
> scenario with a pending reset. These fire when the media pipeline is destroyed on the main renderer thread while
> these operations are pending. I added code in the GpuVideoDecoder::Stop function to fire these callbacks which
> seems like the right thing to do.
>
> The other change in the GpuVideoDecoder::NotifyResetDone function was to remove the check for a NULL vda as there
> are scenarios where in the decoder could be destroyed before this callback runs. We need to fire the read and
> reset callbacks anyway.
>
> BUG=179551
> TEST=The rapid_video_change_test.html file added to media\test\data, when loaded in chrome should hang without
> this patch. Needs some more work to get something similar running in the Chrome OS autotest suite.
> Review URL: https://codereview.chromium.org/12634011
TBR=ananta@chromium.org
Review URL: https://codereview.chromium.org/12942011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@190863 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'media/test')
| -rw-r--r-- | media/test/data/rapid_video_change_test.html | 47 |
1 files changed, 0 insertions, 47 deletions
diff --git a/media/test/data/rapid_video_change_test.html b/media/test/data/rapid_video_change_test.html deleted file mode 100644 index 81a853b..0000000 --- a/media/test/data/rapid_video_change_test.html +++ /dev/null @@ -1,47 +0,0 @@ -<!DOCTYPE html> -<html> - <head> - <title>HTML 5 Change H.264 Video Test</title> - <script> - var changeVideoInterval; - var changeVideoCounter = 0; - - function changeVideo() { - try { - if (changeVideoCounter == 40) { - alert('40 video changes done. Test over'); - window.clearInterval(changeVideoInterval); - return; - } - var video = document.getElementById('video'); - video.pause(); - video.src = 'bear-1280x720.mp4?counter=' + - changeVideoCounter.toString(); - ++changeVideoCounter; - video.play(); - video.currentTime = 1; - } - - catch (e) { - } - } - - function onLoad() { - var video = document.getElementById('video'); - video.play(); - video.currentTime = 1; - changeVideoInterval = setInterval(changeVideo, 200); - } - </script> - </head> - - <body onload='onLoad();'> <b> This test tests the case where in H.264 H/W - decoded videos are added and removed a number of times from the page, - while they are playing. <br> This should not cause the browser to hang. - <div id='videoDiv'> - <video id='video' width=320 height=240 src='bear-1280x720.mp4' - controls='controls'> - </video> - </div> - </body> -</html> |