[webkit-changes] [WebKit/WebKit] 71e98e: [MSE][GStreamer] Dimension SourceBuffer size limit...

[Enrique Ocaña González]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 71e98e40411520b4980a0b1d9f7aeccb52b369f4
      https://github.com/WebKit/WebKit/commit/71e98e40411520b4980a0b1d9f7aeccb52b369f4
  Author: Enrique Ocaña González <eocanha at igalia.com>
  Date:   2024-01-15 (Mon, 15 Jan 2024)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/mse/SourceBufferPrivateGStreamer.cpp

  Log Message:
  -----------
  [MSE][GStreamer] Dimension SourceBuffer size limit for all possible track types before init segment received
https://bugs.webkit.org/show_bug.cgi?id=267417

Reviewed by Philippe Normand.

SourceBuffer has separate max size limits for video, audio and text, but it has to parse the
init segment first to know if there are any video, audio or text tracks. At the very first
appendBuffer() there are not tracks parsed yet, so platformMaximumBufferSize() returns 0 (as
no tracks are there), and the limit is taken from MediaElementSession as audio limit 15MB as
no video track is present.

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

Inspired by the work of Andrzej Surdej <Andrzej_Surdej at comcast.com>.

This patch adjusts the platform limits for WPE so that they account for the possibility of
any (or even all) of the possible track types appearing when processing the init segment.

* Source/WebCore/platform/graphics/gstreamer/mse/SourceBufferPrivateGStreamer.cpp:
(WebCore::SourceBufferPrivateGStreamer::platformMaximumBufferSize const): Accumulate all the audio, video, text maximum sizes when no tracks have been detected yet.

Canonical link: https://commits.webkit.org/273039@main