Bug 309377 – [GStreamer][ARM64] GStreamerVideoFrameConverter.cpp:130:run:<video-frame-converter-gl> Video frame conversion 200ms timeout expired

• Status: REOPENED
• Component: WPE WebKit

[Carlos Alberto Lopez Perez]

The layout test imported/w3c/web-platform-tests/html/canvas/element/manual/imagebitmap/canvas-createImageBitmap-video-resize.html is failing on WPE ARM64

Regressions: Unexpected text-only failures (1)
  imported/w3c/web-platform-tests/html/canvas/element/manual/imagebitmap/canvas-createImageBitmap-video-resize.html [ Failure ]


The diff is the following:

--- /sdk/webkit/layout-test-results/imported/w3c/web-platform-tests/html/canvas/element/manual/imagebitmap/canvas-createImageBitmap-video-resize-expected.txt
+++ /sdk/webkit/layout-test-results/imported/w3c/web-platform-tests/html/canvas/element/manual/imagebitmap/canvas-createImageBitmap-video-resize-actual.txt
@@ -1,3 +1,3 @@
 
-PASS createImageBitmap(HTMLVideoElement) with resize option
+FAIL createImageBitmap(HTMLVideoElement) with resize option assert_true: expected true got false
 
https://build.webkit.org/results/WPE-Linux-ARM64-bit-Release-Tests/308816@main%20(171)/imported/w3c/web-platform-tests/html/canvas/element/manual/imagebitmap/canvas-createImageBitmap-video-resize-pretty-diff.html

And the tests prints the following in stderr:

0:05:51.962573807  4875 0xaaaae3c4c350 ERROR   webkitvideoframeconverter GStreamerVideoFrameConverter.cpp:130:run:<video-frame-converter-gl> Video frame conversion 200ms timeout expired.

This test passes fine on WPE x86_64
It is unknown when this test started to fail. It has been failing since we deployed the new WPE ARM64 bot at https://build.webkit.org/#/builders/1882

[Carlos Alberto Lopez Perez]

After checking in more detail I see this test not always fails on ARM64, but fails a lot.

The bot wpe-arm64-release completed 152 runs on the interval [308164@main-308819@main]
Frequency of results for test: imported/w3c/web-platform-tests/html/canvas/element/manual/imagebitmap/canvas-createImageBitmap-video-resize.html
  117 times [77.0%]      ->  TEXT
  11 times [7.2%]        ->  TEXT PASS
  24 times [15.8%]       ->  NOERROR

Of those 152 runs it didn't match the expectation 128 times [84.2%]
Details of the type and frequency of unmatched expectations:
  117 times [77.0%]      ->  TEXT (Expected: PASS)
  11 times [7.2%]        ->  TEXT PASS (Expected: PASS)

Flakiness factor: 36.8%
    - This test was flaky on 36.8% of the 152 runs analyzed, either giving different
      results within a single run, or a different result than in the previous run.


Perhaps is related to some timing issue? 200ms being too low? The single-thread performance of the CPU from this ARM64 bot is less than on the x86_64 bots

On the x86_64 bots it also fails sometimes but much less.

WPE x86_64 fails 1.6% of the times and on GTK x86_64 1.3% of the times.

[Carlos Alberto Lopez Perez]

Test expectations updated at 308825@main

[Philippe Normand]

> Perhaps is related to some timing issue? 200ms being too low? The single-thread performance of the CPU from this ARM64 bot is less than on the x86_64 bots

Does the bot have only one CPU core?

[Philippe Normand]

*** Bug 310410 has been marked as a duplicate of this bug. ***

[Philippe Normand]

Pull request: https://github.com/WebKit/WebKit/pull/61623

[Carlos Alberto Lopez Perez]

(In reply to Philippe Normand from comment #3)
> > Perhaps is related to some timing issue? 200ms being too low? The single-thread performance of the CPU from this ARM64 bot is less than on the x86_64 bots
> 
> Does the bot have only one CPU core?

no, it has a lot of cores: 80.

[EWS]

Committed 310635@main (366a2fb8ac53): <https://commits.webkit.org/310635@main>

Reviewed commits have been landed. Closing PR #61623 and removing active labels.

[Philippe Normand]

We have this on the bots (from glib.py)

        # Disable SIMD optimization in GStreamer's ORC. Some bots (WPE release) crash in ORC's optimizations.
        environment['ORC_CODE'] = 'backup'


Which means CPU-specific optimizations are disabled for audio and video conversions, among other things... Maybe we can try to remove that hack eventually, but for now let's see if those 2 tests are more stable...

[Philippe Normand]

Seems OK so far, I'll keep an eye on this: https://results.webkit.org/?suite=layout-tests&suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fhtml%2Fcanvas%2Felement%2Fmanual%2Fimagebitmap%2Fcanvas-createImageBitmap-video-resize.html&test=http%2Fwpt%2Fwebcodecs%2FvideoFrame-video-element-compressed.html&platform=WPE&architecture=arm64

[Philippe Normand]

Still falky