[Webkit-unassigned] [Bug 272095] New: Seeking troubles on large WebM files in Safari on mac and iOS

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 3 09:57:41 PDT 2024


https://bugs.webkit.org/show_bug.cgi?id=272095

            Bug ID: 272095
           Summary: Seeking troubles on large WebM files in Safari on mac
                    and iOS
           Product: WebKit
           Version: Safari 17
          Hardware: Unspecified
                OS: iOS 17
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: bvibber at wikimedia.org

Testing the new native WebM playback in Safari on iOS 17.4.x I found some seeking difficulties with large files from Wikimedia Commons, which I can also reproduce on macOS 14.4.1 with Safari stock and WebKit nightly.

Example:
https://upload.wikimedia.org/wikipedia/commons/b/bb/House_on_Haunted_Hill_%281959%29_by_William_Castle.webm
2.1 gigabytes, ~75 minutes 1080p WebM VP9/Opus

The file loads and plays back, but if you seek to an area beyond what has loaded so far, things go wonky: it'll seek somewhere in the middle and start playing back high-speed video either with no audio or bad synchronization. Sometimes it eventually catches up, other times it freezes after a while. Sometimes when it starts playing there's visible garbage, like it's decoding from in the middle of a GOP without starting at a keyframe.

As the download progresses, eventually you can seek around most of the file cleanly -- most of the time; sometimes it still gets stuck in fast-play.

It kind of seems like the seeking isn't using the cue data but is approximating a start point based on file size or something, then tries to decode forward -- once things have been buffered the actual timestamps are known and things seem cleaner.


Expected results:
* seeking anywhere in the stream should work as expected and go directly to that frame, with regular playback, even if it takes a short delay to load the cue data or sync up to the requested frame

Actual results:
* seeking to later parts of a file that have not yet been downloaded reliably result in unexpected behavior or image corruption visible on screen.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240403/1ce2e32b/attachment.htm>


More information about the webkit-unassigned mailing list