Background: Safari’s <video> element has native support for HLS streams. These HLS streams can contain timed metadata through the #EXT-X-DATERANGE tag. (https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-11#section-4.4.5.1) Issue: Safari extracts the incorrect startTime and endTime of #EXT-X-DATERANGE cues. Expected behavior: Safari should extract the correct attributes related to #EXT-X-DATERANGE tags, for any type of stream (e.g. VOD, Live) and content protection mechanism (unencrypted, AES-128, FairPlay, …). Impact: Video streaming services are not capable of using #EXT-X-DATERANGE through the native Safari player. By not supporting this, video streaming services cannot use this tag to mark their ad breaks, their ad beacons, …, and makes them resort to solutions outside of the HLS specification. Furthermore, for streaming services that are unaware of this bug, they might be doing (unintentional) ad fraud by firing ad beacons at inappropriate times informed by an incorrect Safari API. Reproduction steps A: 1. Go to https://safaridaterange.thijsl.repl.co/index.html. 2. Wait for the video to autoplay, or hit the play button. 3. Confirm that you see something like “0: [startTime: 0] - [endTime: 15] - [value: {"key":"X-DATA","data":"lala”}]” being printed. This line represents the startTime and endTime detected through the API. 4. Confirm that this startTime and endTime should be 363 and 378 instead. Reproduction steps B: 1. Create a HLS VOD with #EXT-X-DATERANGE tags. Ensure that they are correctly formatted across media playlists, and that you use more than one media playlist. 2. Ensure that your #EXT-X-DATERANGE cues start at a different position than 0. 3. When the video is playing, ensure that your metadata textTrack isn’t disabled. 4. Query the cues, and confirm that the startTime and endTime is incorrect. Remarks: * https://safaridaterange.thijsl.repl.co/goodbutinvalid.html is a demo page that has the correct startTime and endTime but has illegal syntax. Why is it illegal? This HLS stream has two video qualities (i.e. media playlists). The first media playlist has the following: #EXT-X-PROGRAM-DATE-TIME:2022-07-27T12:36:10.000Z ... #EXT-X-DATERANGE:ID="b",START-DATE="2022-07-27T12:42:13.000Z",DURATION=15.000,X-DATA="lala" The second media playlist has illegal/weird syntax. It doesn’t have a PLANNED-DURATION, DURATION or END-DATE attribute, but it does have two identical START-DATE attributes: #EXT-X-PROGRAM-DATE-TIME:2022-07-27T12:36:10.000Z ... #EXT-X-DATERANGE:ID="b",START-DATE="2022-07-27T12:42:13.000Z",START-DATE="2022-07-27T12:42:13.000Z",X-DATA="lala" And, even though it’s incorrect, the startTime and endTime will be correct. You can also click the providing one video quality button on this page to observe that the timings are also correct when you only provide one video quality in your HLS stream. (I also raised this through https://feedbackassistant.apple.com/feedback/11008280. I wasn't sure what was best.)
(In reply to Thijs from comment #0) > (I also raised this through > https://feedbackassistant.apple.com/feedback/11008280. I wasn't sure what > was best.) rdar://97978527 (I have a suspicion this isn't in WebKit, but let's at least link them together for now.)
This issue is still reproducible on Version 16.2 (17614.3.2.11.4, 17614) and Release 156 of the Technology Preview (Safari 16.4, WebKit 17615.1.8.5).
Sam's suspicion was correct, this is a bug in one of the frameworks used by WebKit. The team responsible for the framework is investigating the issue.
(In reply to Eric Carlson from comment #3) > Sam's suspicion was correct, this is a bug in one of the frameworks used by > WebKit. The team responsible for the framework is investigating the issue. Hi Eric, what's the latest news on the investigation? To expand on the described impact: This bug prohibits us from monetizing advertisements on Safari, although advertisements are still shown to customers. I'd expect that other streaming services also suffer from this. Some of the alternatives are to 1/ not use (features of the) HLS (specification) for this use case, and/or 2/ push our customers to other browsers. We prefer not having to resort to these alternatives.