Some platforms have limited video buffer pools. For instance, OMX on Raspberry Pi 2 when using EGL buffers and zero copy. On those platforms, the fact of returning all the video buffers to the pool is critical to avoid stalling the video pipeline waiting for available buffers. When a video is hidden by setting "display: none", a special early return codepath triggering an early return[1] is activated on MediaPlayerGStreamerBase::pushTextureToCompositor(). This causes that the texture in the video sample is never consumed and therefore never released. This causes a stall of the video stream in the aforementioned platforms, as the video pool runs out of buffers. At the same time, the audio stream doesn't suffer from that problem and the audio keeps being decoded and "rendered" at a normal rate. When the video is shown again, the buffers are returned and the decoder tries to catch up, quickly producing all the pending samples and sending them for display to the video sink. As a result, the user sees the video "on fast forward" until the catching up is complete. IMHO, the proper solution would be to consume the video buffer in some way even when the layer is hidden, so it's returned to the pool and the video stream keeps flowing. I haven't been able to reproduce the issue on desktop Linux because the software decoder used on this platform uses the regular allocator, which can provide a virtually unlimited amount of new buffers. There's no buffer pool to exhaust. [1] https://github.com/WebKit/webkit/blob/9fced9a00615b3ee7a5ff82485e92440a1f4d030/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp#L677
Created attachment 301915 [details] Patch
Comment on attachment 301915 [details] Patch Clearing flags on attachment: 301915 Committed r212549: <http://trac.webkit.org/changeset/212549>
All reviewed patches have been landed. Closing bug.