From 70303bcd2c684615c15b841c4a9a6ac87377d03e Mon Sep 17 00:00:00 2001 From: ldayananda Date: Fri, 20 Apr 2018 17:18:36 -0400 Subject: [PATCH 01/11] remove old data --- README.md | 2 +- docs/intro.md | 9 ++++++ docs/live.md | 77 --------------------------------------------------- 3 files changed, 10 insertions(+), 78 deletions(-) create mode 100644 docs/intro.md delete mode 100644 docs/live.md diff --git a/README.md b/README.md index e43436956..8e0a33df3 100644 --- a/README.md +++ b/README.md @@ -165,7 +165,7 @@ You can deploy a single HLS stream, code against the regular HTML5 video APIs, and create a fast, high-quality video experience across all the big web device categories. -Check out the [full documentation](docs/) for details on how HLS works +Check out the [full documentation](docs/intro.md) for details on how HLS works and advanced configuration. A description of the [adaptive switching behavior](docs/bitrate-switching.md) is available, too. diff --git a/docs/intro.md b/docs/intro.md new file mode 100644 index 000000000..d526ac89b --- /dev/null +++ b/docs/intro.md @@ -0,0 +1,9 @@ +# Further Documentation + +- [Arch](arch.md) +- [Adaptive Bitrate Switching](bitrate-switching.md) +- [Multiple Alternative Audio Tracks](multiple-alternative-audio-tracks.md) + +# Helpful Tools +- [FFmpeg](http://trac.ffmpeg.org/wiki/CompilationGuide/macOS) +- [Thumbcoil](http://thumb.co.il/) \ No newline at end of file diff --git a/docs/live.md b/docs/live.md deleted file mode 100644 index b3c33593e..000000000 --- a/docs/live.md +++ /dev/null @@ -1,77 +0,0 @@ -# Video.JS HLS Live - -## Brightcove Service Differences: -- Brightcove uses the Zencoder HLS Live API. -- Once ingest begins, approximately 50 seconds later the original manifest is available. -- I have not seen any ability to enforce a sliding window, so I believe Brightcove Live HLS serves all available segments on a continuously growing manifest. -- One minute after last disconnect from the ingest stream, the event is considered complete and the final manifest delivered. -- The final manifest will be different in two distinct ways, it will include the `EXT-X-ENDLIST` tag notifying all connected clients that the live stream has concluded and is now VOD. It will also contain a custom `ZEN-TOTAL-DURATION`: tag with representing the total amount of recorded time in seconds. - -## Akamai Service Differences: -- Akamai only serves HLS Live off of Akamai HD2 endpoints. -- These vary from their HDS counterparts by url syntax. - - ``` /i/``` vs.``` /z/``` for HDS - - `master.m3u8` vs.`manifest.f4m` for HDS -- Their endpoints are difficult to arrange CORS configurations on. -- Akamai manifests span the gamut of known HLS tags, both supported and unsupported by our plugin. - -## Once Service Differences: -- Once manifests tend to include the use of `EXT-X-DISCONTINUITY` tags which are unsupported to date. -- Once streams so far tend to use a different encoding algorithm on their segments which sometime result in a range error during transmuxing. - - -# Live HLS Research -This document is a collection of notes on Live HLS implementations in the wild. - -There are two varieties of Live HLS. In the first, playlists are -persistent and strictly appended to. In the alternative form, the -maximum number of segments in a playlist is relatively stable and an -old segment is removed every time a new segment becomes available. - -On iOS devices, both stream types report a duration of `Infinity`. The -`currentTime` is equal to the amount of the stream that has been -played back on the device. - -## Akamai HD2 - -## OnceLIVE -"Sliding window" live streams. - -### Variant Playlists -Once variant playlists look like standard HLS variant playlists. - -### Media Playlists -OnceLIVE uses "sliding window" manifests for live playback. The media -playlists do not have an `EXT-X-ENDLIST` and don't declare a -`EXT-X-PLAYLIST-TYPE`. On first request, the stream media playlist -returned four segment URLs with a starting media sequence of one, -preceded by a `EXT-X-DISCONTINUITY` tag. As playback progressed, that -number grew to 13 segment URLs, at which point it stabilized. That -would equate to a steady-state 65 second window at 5 seconds per -segment. - -OnceLive documentation is [available on the Unicorn Media -website](http://www.unicornmedia.com/documents/2013/02/oncelive_implementationguide.pdf). - -Here's a script to quickly parse out segment URLs: - -```shell -curl $ONCE_MEDIA_PLAYLIST | grep '^http' -``` - -An example media playlist might look something like this: -```m3u8 -#EXTM3U -#EXT-X-TARGETDURATION:5 -#EXT-X-MEDIA-SEQUENCE:3 -#EXTINF:5,3 -http://example.com/0/1/content.ts?visitguid=uuid&asseturl=http://once.example.com/asset.lrm&failoverurl=http://example.com/blank.jpg -#EXTINF:5,4 -http://example.com/1/2/content.ts?visitguid=uuid&asseturl=http://once.example.com/asset.lrm&failoverurl=http://example.com/blank.jpg -#EXTINF:5,5 -http://example.com/2/3/content.ts?visitguid=uuid&asseturl=http://once.example.com/asset.lrm&failoverurl=http://example.com/blank.jpg -#EXTINF:5,6 -http://example.com/3/4/content.ts?visitguid=uuid&asseturl=http://once.example.com/asset.lrm&failoverurl=http://example.com/blank.jpg -``` - -## Zencoder Live From abff58e5917fecdba5eb69c7fc9ea82ff98eb405 Mon Sep 17 00:00:00 2001 From: ldayananda Date: Fri, 20 Apr 2018 17:56:42 -0400 Subject: [PATCH 02/11] wip glossary --- docs/glossary.md | 7 +++++++ docs/intro.md | 3 ++- 2 files changed, 9 insertions(+), 1 deletion(-) create mode 100644 docs/glossary.md diff --git a/docs/glossary.md b/docs/glossary.md new file mode 100644 index 000000000..35c4d64c4 --- /dev/null +++ b/docs/glossary.md @@ -0,0 +1,7 @@ +# Glossary + +**Master Playlist Controller**: This is the starting point of the project and acts as the controller for the playback engine. It interacts with the SegmentLoaders, PlaylistLoaders, PlaybackWatcher, etc. +**Playlist Loader**: This will request the source and load the master manifest. It also interacts with the ABR algorithm to pick a media playlist or wraps a media playlist if it is provided as the source. +**Media Playlist**: This is a manifest that represents a single rendition of the source. +**ABR(Adaptive Bitrate) Algorithm**: this is defined in [selectPlaylist]() and is described more [here](./bitrate-switching.md). +**Playback Watcher**: This handles seeking to live when playing a live source with a live window, or skipping over gaps in content. This is described in detail [here](). \ No newline at end of file diff --git a/docs/intro.md b/docs/intro.md index d526ac89b..c813749aa 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -1,9 +1,10 @@ # Further Documentation - [Arch](arch.md) +- [Glossary](glossary.md) - [Adaptive Bitrate Switching](bitrate-switching.md) - [Multiple Alternative Audio Tracks](multiple-alternative-audio-tracks.md) # Helpful Tools -- [FFmpeg](http://trac.ffmpeg.org/wiki/CompilationGuide/macOS) +- [FFmpeg](http://trac.ffmpeg.org/wiki/CompilationGuide) - [Thumbcoil](http://thumb.co.il/) \ No newline at end of file From 2ca752f9c85904ef7f196d98d095afeeb5606232 Mon Sep 17 00:00:00 2001 From: ldayananda Date: Thu, 3 May 2018 15:22:39 -0400 Subject: [PATCH 03/11] moving some introductory information from arch to intro. Updating glossary --- docs/arch.md | 19 ------------------- docs/glossary.md | 11 +++++++---- docs/intro.md | 19 +++++++++++++++++++ 3 files changed, 26 insertions(+), 23 deletions(-) diff --git a/docs/arch.md b/docs/arch.md index 804f76723..7fd0a23c8 100644 --- a/docs/arch.md +++ b/docs/arch.md @@ -1,22 +1,3 @@ -# HLS Overview -The HLS project polyfills support for [HTTP Live Streaming](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html) (HLS) video format. This document is intended as a primer for anyone interested in contributing or just better understanding how bits from a server get turned into video on their display. - -## HTTP Live Streaming -HLS has two primary characteristics that distinguish it from other video formats: - -- Delivered over HTTP(S): it uses the standard application protocol of the web to deliver all its data -- Segmented: longer videos are broken up into smaller chunks which can be downloaded independently and switched between at runtime - -A standard HLS stream consists of a *Master Playlist* which references one or more *Media Playlists*. Each Media Playlist contains references one or more sequential video segments. All these components form a logical hierarchy that informs the player of the different quality levels of the video available and how to address the individual segments of video at each of those levels: - -![HLS Format](hls-format.png) - -HLS streams can be delivered in two different modes: a "static" mode for videos that can be played back from any point, often referred to as video-on-demand (VOD); or a "live" mode where later portions of the video become available as time goes by. In the static mode, the Master and Media playlists are fixed. The player is guaranteed that the set of video segments referenced by those playlists will not change over time. - -Live mode can work in one of two ways. For truly live events, the most common configuration is for each individual Media Playlist to only include the latest video segment and a small number of consecutive previous segments. In this mode, the player may be able to seek backwards a short time in the video but probably not all the way back to the beginning. In the other live configuration, new video segments can be appended to the Media Playlists but older segments are never removed. This configuration allows the player to seek back to the beginning of the stream at any time during the broadcast and transitions seamlessly to the static stream type when the event finishes. - -If you're interested in a more in-depth treatment of the HLS format, check out [Apple's documentation](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html) and the IETF [Draft Specification](https://datatracker.ietf.org/doc/draft-pantos-http-live-streaming/). - ## HLS Project Overview This project has three primary duties: diff --git a/docs/glossary.md b/docs/glossary.md index 35c4d64c4..1cd5162d5 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -1,7 +1,10 @@ # Glossary -**Master Playlist Controller**: This is the starting point of the project and acts as the controller for the playback engine. It interacts with the SegmentLoaders, PlaylistLoaders, PlaybackWatcher, etc. -**Playlist Loader**: This will request the source and load the master manifest. It also interacts with the ABR algorithm to pick a media playlist or wraps a media playlist if it is provided as the source. +**Playlist**: This is a representation of an HLS or DASH manifest. +**Master Playlist Controller**: This acts as the gateway for the playback engine to interact with the player. It interacts with the SegmentLoaders, PlaylistLoaders, PlaybackWatcher, etc. +**Playlist Loader**: This will request the source and load the master manifest. It also interacts with the ABR algorithm to pick a media playlist or wraps a media playlist if it is provided as the source. There are more details about the playlist loader [here](./arch.md). **Media Playlist**: This is a manifest that represents a single rendition of the source. -**ABR(Adaptive Bitrate) Algorithm**: this is defined in [selectPlaylist]() and is described more [here](./bitrate-switching.md). -**Playback Watcher**: This handles seeking to live when playing a live source with a live window, or skipping over gaps in content. This is described in detail [here](). \ No newline at end of file +**Segment Loader**: This controlls the requesting and appending of segments on to the browser's [SourceBuffers](https://developer.mozilla.org/en-US/docs/Web/API/SourceBuffer). +**ABR(Adaptive Bitrate) Algorithm**: This is defined in selectPlaylist and is described more [here](./bitrate-switching.md). +**Playback Watcher**: This handles seeking to live when playing a live source with a live window, or skipping over gaps in content. This is described in detail [here](). +**Sync Controller**: This will attempt to create a mapping between the segment index and a display time on the player. \ No newline at end of file diff --git a/docs/intro.md b/docs/intro.md index c813749aa..504cfca19 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -1,3 +1,22 @@ +# HLS Overview +The HLS project polyfills support for [HTTP Live Streaming](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html) (HLS) video format. This document is intended as a primer for anyone interested in contributing or just better understanding how bits from a server get turned into video on their display. + +## HTTP Live Streaming +HLS has two primary characteristics that distinguish it from other video formats: + +- Delivered over HTTP(S): it uses the standard application protocol of the web to deliver all its data +- Segmented: longer videos are broken up into smaller chunks which can be downloaded independently and switched between at runtime + +A standard HLS stream consists of a *Master Playlist* which references one or more *Media Playlists*. Each Media Playlist contains references one or more sequential video segments. All these components form a logical hierarchy that informs the player of the different quality levels of the video available and how to address the individual segments of video at each of those levels: + +![HLS Format](hls-format.png) + +HLS streams can be delivered in two different modes: a "static" mode for videos that can be played back from any point, often referred to as video-on-demand (VOD); or a "live" mode where later portions of the video become available as time goes by. In the static mode, the Master and Media playlists are fixed. The player is guaranteed that the set of video segments referenced by those playlists will not change over time. + +Live mode can work in one of two ways. For truly live events, the most common configuration is for each individual Media Playlist to only include the latest video segment and a small number of consecutive previous segments. In this mode, the player may be able to seek backwards a short time in the video but probably not all the way back to the beginning. In the other live configuration, new video segments can be appended to the Media Playlists but older segments are never removed. This configuration allows the player to seek back to the beginning of the stream at any time during the broadcast and transitions seamlessly to the static stream type when the event finishes. + +If you're interested in a more in-depth treatment of the HLS format, check out [Apple's documentation](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html) and the IETF [Draft Specification](https://datatracker.ietf.org/doc/draft-pantos-http-live-streaming/). + # Further Documentation - [Arch](arch.md) From ad6132fdbe6fea7d1bb731667fba49789d8b50e7 Mon Sep 17 00:00:00 2001 From: ldayananda Date: Thu, 3 May 2018 15:24:02 -0400 Subject: [PATCH 04/11] glossary should have newlines --- docs/glossary.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/glossary.md b/docs/glossary.md index 1cd5162d5..2a42b3476 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -1,10 +1,17 @@ # Glossary **Playlist**: This is a representation of an HLS or DASH manifest. + **Master Playlist Controller**: This acts as the gateway for the playback engine to interact with the player. It interacts with the SegmentLoaders, PlaylistLoaders, PlaybackWatcher, etc. + **Playlist Loader**: This will request the source and load the master manifest. It also interacts with the ABR algorithm to pick a media playlist or wraps a media playlist if it is provided as the source. There are more details about the playlist loader [here](./arch.md). + **Media Playlist**: This is a manifest that represents a single rendition of the source. + **Segment Loader**: This controlls the requesting and appending of segments on to the browser's [SourceBuffers](https://developer.mozilla.org/en-US/docs/Web/API/SourceBuffer). + **ABR(Adaptive Bitrate) Algorithm**: This is defined in selectPlaylist and is described more [here](./bitrate-switching.md). + **Playback Watcher**: This handles seeking to live when playing a live source with a live window, or skipping over gaps in content. This is described in detail [here](). + **Sync Controller**: This will attempt to create a mapping between the segment index and a display time on the player. \ No newline at end of file From 48ca79689f39091b05b592470d5bcfa7cd50191c Mon Sep 17 00:00:00 2001 From: ldayananda Date: Thu, 3 May 2018 15:41:15 -0400 Subject: [PATCH 05/11] fix typo --- docs/glossary.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/glossary.md b/docs/glossary.md index 2a42b3476..22ec6b76a 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -8,10 +8,10 @@ **Media Playlist**: This is a manifest that represents a single rendition of the source. -**Segment Loader**: This controlls the requesting and appending of segments on to the browser's [SourceBuffers](https://developer.mozilla.org/en-US/docs/Web/API/SourceBuffer). +**Segment Loader**: This controls the requesting and appending of segments on to the browser's [SourceBuffers](https://developer.mozilla.org/en-US/docs/Web/API/SourceBuffer). **ABR(Adaptive Bitrate) Algorithm**: This is defined in selectPlaylist and is described more [here](./bitrate-switching.md). **Playback Watcher**: This handles seeking to live when playing a live source with a live window, or skipping over gaps in content. This is described in detail [here](). -**Sync Controller**: This will attempt to create a mapping between the segment index and a display time on the player. \ No newline at end of file +**Sync Controller**: This will attempt to create a mapping between the segment index and a display time on the player. From 28bcb035fff6430b03b789aac7c9d4e503912875 Mon Sep 17 00:00:00 2001 From: ldayananda Date: Mon, 7 May 2018 17:12:46 -0400 Subject: [PATCH 06/11] dash update --- docs/glossary.md | 2 +- docs/intro.md | 24 +++++++++++++++++++----- 2 files changed, 20 insertions(+), 6 deletions(-) diff --git a/docs/glossary.md b/docs/glossary.md index 22ec6b76a..bd9334d78 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -2,7 +2,7 @@ **Playlist**: This is a representation of an HLS or DASH manifest. -**Master Playlist Controller**: This acts as the gateway for the playback engine to interact with the player. It interacts with the SegmentLoaders, PlaylistLoaders, PlaybackWatcher, etc. +**Master Playlist Controller**: This acts as the main controller for the playback engine. It interacts with the SegmentLoaders, PlaylistLoaders, PlaybackWatcher, etc. **Playlist Loader**: This will request the source and load the master manifest. It also interacts with the ABR algorithm to pick a media playlist or wraps a media playlist if it is provided as the source. There are more details about the playlist loader [here](./arch.md). diff --git a/docs/intro.md b/docs/intro.md index 504cfca19..3a8d8f591 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -1,8 +1,8 @@ -# HLS Overview -The HLS project polyfills support for [HTTP Live Streaming](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html) (HLS) video format. This document is intended as a primer for anyone interested in contributing or just better understanding how bits from a server get turned into video on their display. +# Overview +This project supports both [HLS](hls) and [MPEG-DASH](dash) playback in the video.js player. This document is intended as a primer for anyone interested in contributing or just better understanding how bits from a server get turned into video on their display. ## HTTP Live Streaming -HLS has two primary characteristics that distinguish it from other video formats: +[HLS](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html) has two primary characteristics that distinguish it from other video formats: - Delivered over HTTP(S): it uses the standard application protocol of the web to deliver all its data - Segmented: longer videos are broken up into smaller chunks which can be downloaded independently and switched between at runtime @@ -17,13 +17,27 @@ Live mode can work in one of two ways. For truly live events, the most common co If you're interested in a more in-depth treatment of the HLS format, check out [Apple's documentation](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html) and the IETF [Draft Specification](https://datatracker.ietf.org/doc/draft-pantos-http-live-streaming/). +## Dynamic Adaptive Streaming over HTTP +Similar to HLS, [DASH](https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP) content is segmented and and is delivered over HTTP(s). + +A DASH stream consits of a *Media Presentation Description*(MPD) that describes segment metadata. Each segment must contain either ISO base media file format(e.g MP4) or MPEG-2 TS data. Typically the MPD will describe the various *Representations* that map to collections of segments at different bitrates to allow bitrate selection. + +DASH streams can be delivered in both video-on-demand(VOD) and live streaming modes. In the VOD case, the MPD describes all the segments and representations available and the player can chose which representation to play based on it's capabilities. + +Live mode is accomplished using the ISOBMFF Live profile if the segments are in ISOBMFF. There are a few different ways to setup the MPD including but not limited to updating the MPD after an interval of time, using *Periods*, or using the *availabilityTimeOffset* field. A few examples of this are provided by the [DASH Reference Client](https://reference.dashif.org/dash.js/). The MPD will provide enough information for the player to playback the live stream and seek back as far as is specified in the MPD. + +If you're interested in a more in-depth description of MPEG-DASH, check out [MDN's tutorial on setting up DASH](https://developer.mozilla.org/en-US/Apps/Fundamentals/Audio_and_video_delivery/Setting_up_adaptive_streaming_media_sources) or the [DASHIF Guidelines](http://dashif.org/guidelines/). + # Further Documentation -- [Arch](arch.md) +- [Architechture](arch.md) - [Glossary](glossary.md) - [Adaptive Bitrate Switching](bitrate-switching.md) - [Multiple Alternative Audio Tracks](multiple-alternative-audio-tracks.md) # Helpful Tools - [FFmpeg](http://trac.ffmpeg.org/wiki/CompilationGuide) -- [Thumbcoil](http://thumb.co.il/) \ No newline at end of file +- [Thumbcoil](http://thumb.co.il/): web based video inspector + +[hls]: /docs/intro.md#http-live-streaming +[dash]: /docs/intro.md# \ No newline at end of file From 449372c570b21983a5393d724cce5f2fa05d6136 Mon Sep 17 00:00:00 2001 From: ldayananda Date: Tue, 8 May 2018 19:18:06 -0400 Subject: [PATCH 07/11] try fixing links --- docs/intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/intro.md b/docs/intro.md index 3a8d8f591..770321e46 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -1,5 +1,5 @@ # Overview -This project supports both [HLS](hls) and [MPEG-DASH](dash) playback in the video.js player. This document is intended as a primer for anyone interested in contributing or just better understanding how bits from a server get turned into video on their display. +This project supports both [HLS][hls] and [MPEG-DASH][dash] playback in the video.js player. This document is intended as a primer for anyone interested in contributing or just better understanding how bits from a server get turned into video on their display. ## HTTP Live Streaming [HLS](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html) has two primary characteristics that distinguish it from other video formats: @@ -40,4 +40,4 @@ If you're interested in a more in-depth description of MPEG-DASH, check out [MDN - [Thumbcoil](http://thumb.co.il/): web based video inspector [hls]: /docs/intro.md#http-live-streaming -[dash]: /docs/intro.md# \ No newline at end of file +[dash]: /docs/intro.md#dash \ No newline at end of file From beabc6dc202232691ae0e744beb42e860b86323f Mon Sep 17 00:00:00 2001 From: ldayananda Date: Tue, 8 May 2018 19:22:55 -0400 Subject: [PATCH 08/11] using more links --- docs/intro.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/docs/intro.md b/docs/intro.md index 770321e46..69ec71e1d 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -2,7 +2,7 @@ This project supports both [HLS][hls] and [MPEG-DASH][dash] playback in the video.js player. This document is intended as a primer for anyone interested in contributing or just better understanding how bits from a server get turned into video on their display. ## HTTP Live Streaming -[HLS](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html) has two primary characteristics that distinguish it from other video formats: +[HLS][apple-hls-intro] has two primary characteristics that distinguish it from other video formats: - Delivered over HTTP(S): it uses the standard application protocol of the web to deliver all its data - Segmented: longer videos are broken up into smaller chunks which can be downloaded independently and switched between at runtime @@ -15,18 +15,18 @@ HLS streams can be delivered in two different modes: a "static" mode for videos Live mode can work in one of two ways. For truly live events, the most common configuration is for each individual Media Playlist to only include the latest video segment and a small number of consecutive previous segments. In this mode, the player may be able to seek backwards a short time in the video but probably not all the way back to the beginning. In the other live configuration, new video segments can be appended to the Media Playlists but older segments are never removed. This configuration allows the player to seek back to the beginning of the stream at any time during the broadcast and transitions seamlessly to the static stream type when the event finishes. -If you're interested in a more in-depth treatment of the HLS format, check out [Apple's documentation](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html) and the IETF [Draft Specification](https://datatracker.ietf.org/doc/draft-pantos-http-live-streaming/). +If you're interested in a more in-depth treatment of the HLS format, check out [Apple's documentation][apple-hls-intro] and the IETF [Draft Specification][hls-spec]. ## Dynamic Adaptive Streaming over HTTP -Similar to HLS, [DASH](https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP) content is segmented and and is delivered over HTTP(s). +Similar to HLS, [DASH][dash-wiki] content is segmented and and is delivered over HTTP(s). A DASH stream consits of a *Media Presentation Description*(MPD) that describes segment metadata. Each segment must contain either ISO base media file format(e.g MP4) or MPEG-2 TS data. Typically the MPD will describe the various *Representations* that map to collections of segments at different bitrates to allow bitrate selection. DASH streams can be delivered in both video-on-demand(VOD) and live streaming modes. In the VOD case, the MPD describes all the segments and representations available and the player can chose which representation to play based on it's capabilities. -Live mode is accomplished using the ISOBMFF Live profile if the segments are in ISOBMFF. There are a few different ways to setup the MPD including but not limited to updating the MPD after an interval of time, using *Periods*, or using the *availabilityTimeOffset* field. A few examples of this are provided by the [DASH Reference Client](https://reference.dashif.org/dash.js/). The MPD will provide enough information for the player to playback the live stream and seek back as far as is specified in the MPD. +Live mode is accomplished using the ISOBMFF Live profile if the segments are in ISOBMFF. There are a few different ways to setup the MPD including but not limited to updating the MPD after an interval of time, using *Periods*, or using the *availabilityTimeOffset* field. A few examples of this are provided by the [DASH Reference Client][dash-if-reference-client]. The MPD will provide enough information for the player to playback the live stream and seek back as far as is specified in the MPD. -If you're interested in a more in-depth description of MPEG-DASH, check out [MDN's tutorial on setting up DASH](https://developer.mozilla.org/en-US/Apps/Fundamentals/Audio_and_video_delivery/Setting_up_adaptive_streaming_media_sources) or the [DASHIF Guidelines](http://dashif.org/guidelines/). +If you're interested in a more in-depth description of MPEG-DASH, check out [MDN's tutorial on setting up DASH][mdn-dash-tut] or the [DASHIF Guidelines][dash-if-guide]. # Further Documentation @@ -40,4 +40,10 @@ If you're interested in a more in-depth description of MPEG-DASH, check out [MDN - [Thumbcoil](http://thumb.co.il/): web based video inspector [hls]: /docs/intro.md#http-live-streaming -[dash]: /docs/intro.md#dash \ No newline at end of file +[dash]: /docs/intro.md#dynamic-adaptive-streaming-over-http +[apple-hls-intro]: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html +[hls-spec]: https://datatracker.ietf.org/doc/draft-pantos-http-live-streaming/ +[dash-wiki]: https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP +[dash-if-reference-client]: https://reference.dashif.org/dash.js/ +[mdn-dash-tut]: https://developer.mozilla.org/en-US/Apps/Fundamentals/Audio_and_video_delivery/Setting_up_adaptive_streaming_media_sources +[dash-if-guide]: http://dashif.org/guidelines/ \ No newline at end of file From e34682ef7a8f0364bcf9e71941203a860d464687 Mon Sep 17 00:00:00 2001 From: ldayananda Date: Tue, 8 May 2018 19:25:02 -0400 Subject: [PATCH 09/11] fix typo --- docs/intro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/intro.md b/docs/intro.md index 69ec71e1d..d5e949c97 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -18,7 +18,7 @@ Live mode can work in one of two ways. For truly live events, the most common co If you're interested in a more in-depth treatment of the HLS format, check out [Apple's documentation][apple-hls-intro] and the IETF [Draft Specification][hls-spec]. ## Dynamic Adaptive Streaming over HTTP -Similar to HLS, [DASH][dash-wiki] content is segmented and and is delivered over HTTP(s). +Similar to HLS, [DASH][dash-wiki] content is segmented and is delivered over HTTP(s). A DASH stream consits of a *Media Presentation Description*(MPD) that describes segment metadata. Each segment must contain either ISO base media file format(e.g MP4) or MPEG-2 TS data. Typically the MPD will describe the various *Representations* that map to collections of segments at different bitrates to allow bitrate selection. From 8e1ed3a20213ea98cf8cf30ec0266bfebaee6193 Mon Sep 17 00:00:00 2001 From: ldayananda Date: Tue, 15 May 2018 16:43:26 -0400 Subject: [PATCH 10/11] CR comments: corrections --- docs/glossary.md | 14 +++++++++----- docs/intro.md | 4 ++-- 2 files changed, 11 insertions(+), 7 deletions(-) diff --git a/docs/glossary.md b/docs/glossary.md index bd9334d78..32b2fcb44 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -2,16 +2,20 @@ **Playlist**: This is a representation of an HLS or DASH manifest. +**Media Playlist**: This is a manifest that represents a single rendition of the source. + **Master Playlist Controller**: This acts as the main controller for the playback engine. It interacts with the SegmentLoaders, PlaylistLoaders, PlaybackWatcher, etc. -**Playlist Loader**: This will request the source and load the master manifest. It also interacts with the ABR algorithm to pick a media playlist or wraps a media playlist if it is provided as the source. There are more details about the playlist loader [here](./arch.md). +**Playlist Loader**: This will request the source and load the master manifest. It is also instructed by the ABR algorithm to load a media playlist or wraps a media playlist if it is provided as the source. There are more details about the playlist loader [here](./arch.md). -**Media Playlist**: This is a manifest that represents a single rendition of the source. +**Segment Loader**: This determines which segment should be loaded via the Media Segment Loader, decrypts the segment if necessary and passes the result to the Source Updater. + +**Media Segment Loader**: This requests a given segment and returns it to the Segment Loader. -**Segment Loader**: This controls the requesting and appending of segments on to the browser's [SourceBuffers](https://developer.mozilla.org/en-US/docs/Web/API/SourceBuffer). +**Source Updater**: This manages the browser's [SourceBuffers](https://developer.mozilla.org/en-US/docs/Web/API/SourceBuffer). It appends decrypted segment bytes provided by the Segment Loader to the corresponding Source Buffer. -**ABR(Adaptive Bitrate) Algorithm**: This is defined in selectPlaylist and is described more [here](./bitrate-switching.md). +**ABR(Adaptive Bitrate) Algorithm**: This concept is described more in detail [here](https://en.wikipedia.org/wiki/Adaptive_bitrate_streaming). Our chosen ABR algorithm is referenced by [selectPlaylist](../README.md#hlsselectplaylist) and is described more [here](./bitrate-switching.md). -**Playback Watcher**: This handles seeking to live when playing a live source with a live window, or skipping over gaps in content. This is described in detail [here](). +**Playback Watcher**: This attemps to resolve common playback stalls caused by improper seeking, gaps in content and browser issues. Some examples of the ways these issues are handled is by seeking to live when playing a live source with a live window, or skipping over gaps in content. **Sync Controller**: This will attempt to create a mapping between the segment index and a display time on the player. diff --git a/docs/intro.md b/docs/intro.md index d5e949c97..528e12c89 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -7,7 +7,7 @@ This project supports both [HLS][hls] and [MPEG-DASH][dash] playback in the vide - Delivered over HTTP(S): it uses the standard application protocol of the web to deliver all its data - Segmented: longer videos are broken up into smaller chunks which can be downloaded independently and switched between at runtime -A standard HLS stream consists of a *Master Playlist* which references one or more *Media Playlists*. Each Media Playlist contains references one or more sequential video segments. All these components form a logical hierarchy that informs the player of the different quality levels of the video available and how to address the individual segments of video at each of those levels: +A standard HLS stream consists of a *Master Playlist* which references one or more *Media Playlists*. Each Media Playlist contains one or more sequential video segments. All these components form a logical hierarchy that informs the player of the different quality levels of the video available and how to address the individual segments of video at each of those levels: ![HLS Format](hls-format.png) @@ -20,7 +20,7 @@ If you're interested in a more in-depth treatment of the HLS format, check out [ ## Dynamic Adaptive Streaming over HTTP Similar to HLS, [DASH][dash-wiki] content is segmented and is delivered over HTTP(s). -A DASH stream consits of a *Media Presentation Description*(MPD) that describes segment metadata. Each segment must contain either ISO base media file format(e.g MP4) or MPEG-2 TS data. Typically the MPD will describe the various *Representations* that map to collections of segments at different bitrates to allow bitrate selection. +A DASH stream consits of a *Media Presentation Description*(MPD) that describes segment metadata and includes links to the segments themselves. Each segment can contain either ISO base media file format(e.g MP4) or MPEG-2 TS data. Typically the MPD will describe the various *Representations* that map to collections of segments at different bitrates to allow bitrate selection. DASH streams can be delivered in both video-on-demand(VOD) and live streaming modes. In the VOD case, the MPD describes all the segments and representations available and the player can chose which representation to play based on it's capabilities. From 2967b2b03072548156f772f49ca310f6d9b3bc0b Mon Sep 17 00:00:00 2001 From: ldayananda Date: Wed, 16 May 2018 11:14:41 -0400 Subject: [PATCH 11/11] CR comments: corrections, grammar --- docs/glossary.md | 6 +++--- docs/intro.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/glossary.md b/docs/glossary.md index 32b2fcb44..c1683754e 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -8,14 +8,14 @@ **Playlist Loader**: This will request the source and load the master manifest. It is also instructed by the ABR algorithm to load a media playlist or wraps a media playlist if it is provided as the source. There are more details about the playlist loader [here](./arch.md). -**Segment Loader**: This determines which segment should be loaded via the Media Segment Loader, decrypts the segment if necessary and passes the result to the Source Updater. +**Segment Loader**: This determines which segment should be loaded, requests it via the Media Segment Loader and passes the result to the Source Updater. -**Media Segment Loader**: This requests a given segment and returns it to the Segment Loader. +**Media Segment Loader**: This requests a given segment, decrypts the segment if necessary, and returns it to the Segment Loader. **Source Updater**: This manages the browser's [SourceBuffers](https://developer.mozilla.org/en-US/docs/Web/API/SourceBuffer). It appends decrypted segment bytes provided by the Segment Loader to the corresponding Source Buffer. **ABR(Adaptive Bitrate) Algorithm**: This concept is described more in detail [here](https://en.wikipedia.org/wiki/Adaptive_bitrate_streaming). Our chosen ABR algorithm is referenced by [selectPlaylist](../README.md#hlsselectplaylist) and is described more [here](./bitrate-switching.md). -**Playback Watcher**: This attemps to resolve common playback stalls caused by improper seeking, gaps in content and browser issues. Some examples of the ways these issues are handled is by seeking to live when playing a live source with a live window, or skipping over gaps in content. +**Playback Watcher**: This attemps to resolve common playback stalls caused by improper seeking, gaps in content and browser issues. **Sync Controller**: This will attempt to create a mapping between the segment index and a display time on the player. diff --git a/docs/intro.md b/docs/intro.md index 528e12c89..f3ae4333c 100644 --- a/docs/intro.md +++ b/docs/intro.md @@ -20,7 +20,7 @@ If you're interested in a more in-depth treatment of the HLS format, check out [ ## Dynamic Adaptive Streaming over HTTP Similar to HLS, [DASH][dash-wiki] content is segmented and is delivered over HTTP(s). -A DASH stream consits of a *Media Presentation Description*(MPD) that describes segment metadata and includes links to the segments themselves. Each segment can contain either ISO base media file format(e.g MP4) or MPEG-2 TS data. Typically the MPD will describe the various *Representations* that map to collections of segments at different bitrates to allow bitrate selection. +A DASH stream consits of a *Media Presentation Description*(MPD) that describes segment metadata such as timing information, URLs, resolution and bitrate. Each segment can contain either ISO base media file format(e.g MP4) or MPEG-2 TS data. Typically, the MPD will describe the various *Representations* that map to collections of segments at different bitrates to allow bitrate selection. These Representations can be organized as a SegmentList, SegmentTemplate, SegmentBase, or SegmentTimeline. DASH streams can be delivered in both video-on-demand(VOD) and live streaming modes. In the VOD case, the MPD describes all the segments and representations available and the player can chose which representation to play based on it's capabilities.