[webkit-changes] [WebKit/WebKit] 17789a: Merge 254142 at main - [GStreamer] MediaPlayerPrivate...

Tyler Wilcock noreply at github.com
Mon Sep 5 07:30:03 PDT 2022


  Branch: refs/heads/webkitglib/2.38
  Home:   https://github.com/WebKit/WebKit
  Commit: 17789a7947a7596c730f925b5f159380cc5defda
      https://github.com/WebKit/WebKit/commit/17789a7947a7596c730f925b5f159380cc5defda
  Author: Alicia Boya Garcia <aboya at igalia.com>
  Date:   2022-09-05 (Mon, 05 Sep 2022)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/GStreamerVideoSinkCommon.cpp
    M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
    M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h

  Log Message:
  -----------
  Merge 254142 at main - [GStreamer] MediaPlayerPrivateGStreamer: Abort stale tasks on flushes
https://bugs.webkit.org/show_bug.cgi?id=244534

Reviewed by Philippe Normand.

This patch is a combination of a follow-up of
https://github.com/WebKit/WebKit/pull/3746, and a fix for a race
condition I independently discovered before said PR was published.

Minor cleanups for pr/3746 are done, additional logging is added,
MediaPlayerPrivateGStreamer::m_abortableTaskQueue is renamed to
MediaPlayerPrivateGStreamer::m_sinkTaskQueue, comments are added, and
most importantly: the task queue is flushed when a GStreamer flush is
received. This fixes a race condition on MSE flushes.

To compensate the additional logic added to the WebKit video sink probe,
this patch refactors the function, getting rid of the early return
spaghetti it had slowly become over the years.

In the process, I found the code for calling flushCurrentBuffer() on
FLUSH_START in the previous code was actually unreachable and had been
so for the most part of a year, as an accident of an early return in the
old code (FLUSH_START events have the
GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM flag. The old code did an early
return when that flag was found for an event other than a tag event).

Figuring out all bugs with flushCurrentBuffer() and what usages it
should have is very much outside of the scope of this patch. Instead,
this patch makes no change on behavior and adds a FIXME section
explaining the situation and how it needs further work.

* Source/WebCore/platform/graphics/gstreamer/GStreamerVideoSinkCommon.cpp:
(webKitVideoSinkSetMediaPlayerPrivate):
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::~MediaPlayerPrivateGStreamer):
(WebCore::MediaPlayerPrivateGStreamer::updateVideoOrientation):
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:
(WebCore::MediaPlayerPrivateGStreamer::sinkTaskQueue):

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

(cherry picked from commit e55d1903cf1086c65c6d1f1fdf87578d0d54596c)


  Commit: 735a9ad8c088df98a95988cfd2d3f8880d4ed0ee
      https://github.com/WebKit/WebKit/commit/735a9ad8c088df98a95988cfd2d3f8880d4ed0ee
  Author: Tyler Wilcock <tyler_w at apple.com>
  Date:   2022-09-05 (Mon, 05 Sep 2022)

  Changed paths:
    M Source/WebCore/accessibility/AccessibilityObject.cpp

  Log Message:
  -----------
  Merge 254152 at main - AX: AccessibilityObject::replacedNodeNeedsCharacter should not assume it can get an AXObjectCache from the replaced node
https://bugs.webkit.org/show_bug.cgi?id=244781
rdar://99369899

Reviewed by Chris Fleizach.

AccessibilityObject::replacedNodeNeedsCharacter erroneously assumes it
can get a non-null cache from Document::axObjectCache(), but in reality
there are several ways this method can return a nullptr -- for example,
if the document doesn't have a living render tree.

With this patch, we null check the cache returned from Document::axObjectCache()
before trying to use it.

* Source/WebCore/accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::replacedNodeNeedsCharacter):

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

(cherry picked from commit 11414e0bbcfbf8b525b937d4787515e470ad935d)


Compare: https://github.com/WebKit/WebKit/compare/f1736961e610...735a9ad8c088


More information about the webkit-changes mailing list