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