Bug 302541 – [GStreamer] Using the `loop` property in a media element breaks the seeking and looping.

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Loïc Le Page]

Created attachment 477398 [details]
Web page and audio/video samples to reproduce the bug

When using `loop` in an `<audio>` or `<video>` element, not only the looping is not working but the seeking is also broken.
Once reaching the end of the media, the media player loops back to 0 but stops playing and subsequent clicks on the play button fail.
Seeking using the media player bar is also failing.

The bug is systematic and can be reproduced with different audio (flac, aac, mp3, ogg, opus, wav) and video (mp4/h264) formats (see the attached test).
When using bigger compressed files (like a 3 MB mp3 file) it can even freeze the whole web page or stop playing in the middle of the media.

When quitting the `loop` property from the media element, playing and seeking work perfectly.

It seems to be a regression of this commit: https://github.com/WebKit/WebKit/commit/bc8bd3bac663f00e61c47c23bded08056ca348b0 that was introducing the segment looping instead of the flushed looping.

[Loïc Le Page]

The fix is available here: https://github.com/WebKit/WebKit/pull/53945
It has been tested with the stable versions of GStreamer: 1.22.12, 1.24.12 and 1.26.8 and fix the issue in all cases.

[Philippe Normand]

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

[Loïc Le Page]

(In reply to Philippe Normand from comment #2)
> Pull request: https://github.com/WebKit/WebKit/pull/54411

I've tested it and it works perfectly with all the media in the test. I'm closing my PR that was reverting the initial commit.

[EWS]

Committed 303539@main (d0dfb8e19931): <https://commits.webkit.org/303539@main>

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