[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