Skip to content

Tracking for a Major version of VHS #1057

@brandonocasey

Description

@brandonocasey

See the story for Video.js here

Each of these breaking changes and major refactors should come with a corresponding entry in a migration guide.

Breaking

  • Remove hls- events and hls properties fix: remove deprecation hls options, properties, and events #1229
  • Remove smoothQualityChange
  • get rid of handleManifestRedirects option feat: remove handleManifestRedirects and always use XHR.responseURL if available #1226
  • set gap jumping to jump all gaps
  • Refactor our exclusion logic and rename from "blacklist" where it's used. Currently we can exclude a playlist:
    • Via an error object with various properties passed to blacklistCurrentPlaylist
    • Via an error trigger on segmentLoader, playlistLoader, and that gets sent to blacklistCurrentPlaylist
    • Via a regular object with various properties as seen everywhere in masterPlaylistController
    • Any time we want by adding excludeUntil so every place that we exclude we have to add a lot of the same logic.
    • blacklistCurrentPlaylist can be used to exclude any playlist... but we still select a new current playlist
    • We can run into circular loops where playlists are excluded over and over again for the same reason
    • We even have a duplicate way to exclude renditions via disabled... omg
    • I'm sure there is more...
  • Remove experimental options and make them the default or remove them.
  • Remove IE11 support: Change browsers in babel-preset-env and drop any special code for ie 11. Maybe even try out rollup-plugin-esbuild

  • Stop with the playlist id/uri/index object none-sense. Currently we store references to the index on an array and it's weird. We should instead add some helper functions to playlist-loader getPlaylistById, getPlaylistByUri, and getPlaylistByIndex stop doing this. Some of the code is here: https://github.com/videojs/http-streaming/pull/1124/files#diff-78a204a1a5c631f08cbea3fee1b2eecb32158191db5e6db9c5c4c1595bd4366cR273
  • Switch from xhr to fetch to support streaming segment downloads. Use events rather than global overrides and options to modify requests? Tie-in with player-level hooks
  • es6 mux.js code and vhs-utils update
  • setLiveSeekableRange Use setLiveSeekableRange when available #855
  • use promises!
  • Dash Playlist loader should handle the actual MPD xml. This means that we need to separate the logic for choosing a segment into playlist loader and have segment loader call that when it needs a new segment or something. We should push logic from the segment loader to the playlist loader because we HLS and DASH can have different contraints for knowing what the next segment is. This will simplify the segment loader.

Non Breaking

  • We should download a segment and seek to that and then set seekable. Right now we estimate seekable and download a segment based off of that. If the segment starts before or after where current time is it causes us to stall until playback-watcher kicks in. If we download a segment and then seek to it instead, playback can start much quicker.
  • remove TIME_FUDGE_FACTOR from Playlist#getMediaInfoForTime if possible. See feat: Add experimentalExactManifestTimings which forgoes TIME_FUDGE_FACTOR during segment choice #1165 1165
  • Offload ts/mp4 probing to the web worker: refactor: offload mp4/ts probe to web worker #1117
  • default to 3 target durations behind live, as specified in the specification, instead of this: https://github.com/videojs/http-streaming/pull/1078/files#r596088823
  • Drop the partial muxer and handle partial if it isn't needed refactor: drop support for the partial muxer #1119
  • enable handleManifestRedirects by default feat: default handleManfiestRedirect to true #927
  • Use BigInt and a polyfill for 64 bit numbers in mux.js
  • add a flag to allow jumping all gaps regardless of size (will then flip to default in a major version)
  • media group updates: dedupe most of this code and add in video groups, as our mainSegmentLoader just duplicates a lot of media group handling in masterPlaylistController
    • this requires more research
    • we probably want to figure out some first steps that are not breaking
    • but the final piece may require a final breaking change
  • use navigator.connection if bandwidth is set to default and it is available. This includes listening for navigator.connction change events for abr switching.
  • rename everything that includes blacklist or other similar terms. These will then be removed as part of a breaking change.
  • Unify our segmentIndex/segmentNumber naming We currently use:
    • variables: segmentIndex, mediaIndex, mediaSequence
    • functions: safeLiveIndex i'm sure there are more.
  • Unify the logic we use to select the next segment to download. The logic is spread through playlist.js, sync-controller, and segment-loader. (some of this is done in refactor: checkBuffer_/fillBuffer_/generateSegmentInfo #1097)
  • Async manifest parsing in a web worker
  • More spec compliant parsing of mpeg-ts packets. Right now we hope that the stream doesn't contain any weird ts features, and for the most part they usually don't, but when they do we will break. See https://github.com/brandonocasey/media-stream-transmuxer/blob/4250fd6964c35480adb6f09f8cc363f66cd0fd81/src/formats/m2ts/demuxer.js#L97
  • player-level beforeRequest and request hooks
  • playlist selection hooks
  • Base class for playlist loaders?
  • reset the media source and re-create on media source error.
  • See fix: Use segmentInfo.trackInfo to get segment information. #1162 . Should we even have currentMediaInfo_? Originally this was added to support codec type switching so anything we do will need to be tested to ensure that codec switching still works. Should we still have startingMediaInfo_ this was added so that we always have a trackInfo to look back at, should future segments fail to contain trackinfo, but we should be triggering directly in the muxer at all times. I think this could all use a rework.
  • Migrate addSidxSegmentsToPlaylist from mpd-parser into vhs.
  • Can we switch to listening to update instead of updateend on sourceBuffers? Saves use 5-10ms per append/remove. The only caveat is that updateend always fires, even on error. As long as we handle errors (which I think we do) Then we should be able to switch.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions