[GStreamer] Fast replay on video hide/unhide on platforms with limited video buffer...
authoreocanha@igalia.com <eocanha@igalia.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 17 Feb 2017 14:50:37 +0000 (14:50 +0000)
committereocanha@igalia.com <eocanha@igalia.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 17 Feb 2017 14:50:37 +0000 (14:50 +0000)
commit77276f67ab8b5178b464123d6a2552a4895d0dcd
tree7f51998b5ebc818dfe3241f83e479a47655537aa
parentf91a06a5c7f3a2267cfd728a2e0a215d44ff9575
[GStreamer] Fast replay on video hide/unhide on platforms with limited video buffer pools
https://bugs.webkit.org/show_bug.cgi?id=168505

Reviewed by Žan Doberšek.

The WebKit code isn't consuming the video samples when the video layer is hidden,
so the buffers aren't being returned to the pool and starve the decoder when the
buffer pool runs out of buffers (on platforms using a buffer pool and a custom
allocator, such as OMX on the Raspberry Pi 2). When the video layer is restored,
the pipeline tries to catch up and the user sees the video "going fast forward".

The added code "consumes" (removes and unrefs) the buffer in that case. However,
the sample isn't completely removed because it still holds important info (eg:
caps) needed for the proper operation of the video element.

* platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:
(WebCore::MediaPlayerPrivateGStreamerBase::pushTextureToCompositor):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@212549 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore/ChangeLog
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp