[Webkit-unassigned] [Bug 168505] New: [GStreamer] Fast replay on video hide/unhide on platforms with limited video buffer pools

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Feb 17 04:35:31 PST 2017


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

            Bug ID: 168505
           Summary: [GStreamer] Fast replay on video hide/unhide on
                    platforms with limited video buffer pools
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media Elements
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: eocanha at igalia.com

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170217/6c5400fc/attachment.html>


More information about the webkit-unassigned mailing list