feat: support temporal media fragment URIs

[christriants]

This PR will...

Add support for W3C Media Fragments URI (temporal dimension) to allow loading and playing specific time ranges of HLS streams using URL fragments like video.m3u8#t=100,110.

New functionality:

• Parse #t=start,end fragments from source URLs (supports NPT formats: seconds, MM:SS, HH:MM:SS)
• Set playback start position from fragment start time
• Automatically pause playback when fragment end time is reached (one-time pause)
• New MediaFragmentController handles fragment parsing and playback monitoring
• New MEDIA_FRAGMENT_PARSED and MEDIA_FRAGMENT_END events for application integration

More about MediaFragmentController:

This has been implemented as a separate, optional controller module (can be disabled via config). It listens to MANIFEST_LOADING events to intercept and parse fragments, and attaches media element listeners only when fragment end time is specified. It should automatically detach listeners after pausing.

Why is this Pull Request needed?

Media Fragment URIs are part of the W3C specification and are natively supported by browsers for direct video playback. However, we do not currently support this feature, meaning applications using hls.js cannot use fragment URIs to link to specific time ranges in videos.

Are there any points in the code the reviewer needs to double check?

• Should temporal media fragments take precedence over startPosition config?
• Are there any other additional considerations we need to make for live?
• Should we consider a "reload" button to replay the URI fragment recommended by the spec?

Resolves issues:

Closes #5445

Testing:

Manual testing and demo available at: https://hlsjs-temporal-media-fragments.pages.dev/

Tested scenarios include:

• VOD streams with valid #t=start,end
• Start-only fragments (#t=start)
• End-only fragments (#t=,end)
• Invalid or out-of-range fragments
• URLs without fragments (no behavior change)

Checklist

• changes have been done against master branch, and PR does not conflict
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[robwalch]

If this were all encapsulated in an optional media fragment controller, then a config class would make it extendable, replaceable, and optional, so that apps configuring HLS.js could ignore media fragments or customize their handling.

[christriants]

Thanks, @robwalch. I've addressed feedback by creating the media-fragment-controller. This should encapsulate the related logic, and it should be configurable by the application. Appreciate the suggestion.

[christriants]

Thanks for the feedback @robwalch! I've addressed your feedback.

While investigating the seeking behavior question, I re-read the W3C Media Fragments URI spec and realized I missed some features including:

• percent-decoding support - URLs like #t=%31%30,%32%30 (encoded t=10,20) should now work correctly
• multiple occurrence handling - #t=5&t=10,20 now properly uses the last occurrence (t=10,20) per spec
• NPT prefix support -#t=npt:10,20 format now supported
• last valid occurrence -#t=10&t=20 would ignore the previous occurrence and use t=20

I tested these features out in hls.js, and also within browsers.

So the PR has grown a bit because I've added support for these spec-compliant features, but all existing functionality remains unchanged.