[MSE][GStreamer] Missing support for aborts not followed by an initialization segment

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Alicia Boya García]

Two new tests are failing:

media/media-source/media-mp4-h264-partial-abort.html
media/media-source/media-webm-opus-partial-abort.html

The reason of these failures is that the current implementation of aborts in the AppendPipeline works by moving the state of the pipeline down to READY and back to PLAYING, which necessitates for an initialization segment afterwards to resume demuxing. Following an abort with an initialization segment is common, but not required by the spec. This makes those tests fail when they do exactly that.

Unfortunately, making abort() correct necessitates from changes not only in WebKit, but also in the GStreamer demuxer elements. A patch was proposed for qtdemux long ago, but that effort was later deprioritized and stalled. https://bugzilla.gnome.org/show_bug.cgi?id=795424 qtdemux: Add MSE-style flush

Since compatibility with older GStreamer versions is a problem, especially in slower moving distros, a solution to this problem would likely require patching GStreamer and WebKit in a way that the current suboptimal way to do aborts is preserved for GStreamer versions missing the patch.

[Enrique Ocaña]

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

[Enrique Ocaña]

Note that the patch from https://github.com/WebKit/WebKit/pull/11313 still does NOT pass the layout tests, so if it eventually lands, this bug should be reopened.

The reason is that the layout tests append partial data on purpose to check how the
demuxer recovers from that, and qtdemux can't yet recover from that situation.
However, if the tests are modified to use append full fragments, the test passes.
Still, this patch would be an improvement and would unblock the test case in
WebPlatformForEmbedded/WPEWebKit#1016

[Enrique Ocaña]

The media-webm-opus-partial-abort.html failure is unrelated to the partial abort support. That test is failing because non-glib/GStreamer ports aren't honoring the CodecDelay field in the webm file.

It's being addressed separately on https://bugs.webkit.org/show_bug.cgi?id=254222, where a patch that changes the webm file to have a zero CodecDelay is being submitted.

[Enrique Ocaña]

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

[EWS]

Committed 262144@main (9bc4d3cabf88): <https://commits.webkit.org/262144@main>

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