[Webkit-unassigned] [Bug 248217] New: [GStreamer] Fix readyState calculations

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Nov 22 04:38:34 PST 2022


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

            Bug ID: 248217
           Summary: [GStreamer] Fix readyState calculations
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: vwatermeier at igalia.com

On some platforms, the audio sink is acting as a fake sink while the decoder fetches data from the pipeline and transfers it to the SoC drivers, removing it from the gstreamer pipeline. This is done even in READY and PAUSED states.

Now, in webkit, if the progressive playback player is in a READY or PAUSED state, we're assuming the queue2 element (or multiqueue in AV pipelines) is very much the only place which accumulates the data and thus we treat it like a reliable source of information on whether we have enough data to play or not.

What happens is the following: for pipelines with very low download speed (like e.g. livestreams) we're slowly feeding the queue2 element with data (regardless the READY/PAUSED/PLAYING state) while the decoder is consuming the data very fast from the very same queue2 element at the same time. So, generally speaking, in that situation (on that platform) we cannot really relay on buffering messages anymore - regardless the state a player is in.

Additionally, since the buffering query is issued to the entire pipeline, on some platforms it may yield misleading results if some random element implements buffering query and receives that query first.

See: https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/975

-- 
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/20221122/9ae8977b/attachment.htm>


More information about the webkit-unassigned mailing list