Adaptive Streaming - Revision history

Annevk at 06:17, 28 September 2014

2014-09-28T06:17:58Z

← Older revision		Revision as of 06:17, 28 September 2014
Line 1:		Line 1:
			{{obsolete\|spec=[https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html Media Source Extensions]}}

	Here is a (rough and incomplete) proposal for doing adaptive streaming using open video formats. Key components of the proposal:		Here is a (rough and incomplete) proposal for doing adaptive streaming using open video formats. Key components of the proposal:

Silviapfeiffer: added url to encoding params for adaptive streaming

2011-04-29T05:07:00Z

added url to encoding params for adaptive streaming

← Older revision		Revision as of 05:07, 29 April 2011
Line 31:		Line 31:
	* It builds upon existing HTTP infrastructure.		* It builds upon existing HTTP infrastructure.
	* It centralizes all intelligence (and control) in the client.		* It centralizes all intelligence (and control) in the client.

			Note: [http://www.streaminglearningcenter.com/blogs/encoding-for-adaptive-streaming---an-overview.html good article on what matters in your encoding parameters for HTTP adaptive streaming]

	== Chunks ==		== Chunks ==

Annevk: /* Rationale */

2011-01-26T12:09:14Z

Rationale

← Older revision		Revision as of 12:09, 26 January 2011
Line 218:		Line 218:
	* With just the QOS metrics (downloadRate and decodedFrames) in place, it will be possible to build adaptive-streaming-like solutions (using range-requests) in javascript. In Flash, this same functionality is supported (and very popular) within both Flowplayer and JW Player. True adaptive streaming (continous switching without buffering) won't be possible, but the experience is good enough to suit people that don't have the encoder or browser (yet) to build or playback adaptive streams.		* With just the QOS metrics (downloadRate and decodedFrames) in place, it will be possible to build adaptive-streaming-like solutions (using range-requests) in javascript. In Flash, this same functionality is supported (and very popular) within both Flowplayer and JW Player. True adaptive streaming (continous switching without buffering) won't be possible, but the experience is good enough to suit people that don't have the encoder or browser (yet) to build or playback adaptive streams.

	[[Category:~~Feature Request~~]]		[[Category:Proposals]]

Annevk: categorize

2011-01-26T11:56:28Z

categorize

← Older revision		Revision as of 11:56, 26 January 2011
Line 217:		Line 217:
	* Ecosystem partners (CDNs, encoding providers, landmark publishers, etc) are already getting used to ánd building tools around the concept of chunked video streams. Examples are log aggregators that roll up chunks servings into a single logline, or encoders that simultaneously build multiple stream levels, chunk them up and render their manifests.		* Ecosystem partners (CDNs, encoding providers, landmark publishers, etc) are already getting used to ánd building tools around the concept of chunked video streams. Examples are log aggregators that roll up chunks servings into a single logline, or encoders that simultaneously build multiple stream levels, chunk them up and render their manifests.
	* With just the QOS metrics (downloadRate and decodedFrames) in place, it will be possible to build adaptive-streaming-like solutions (using range-requests) in javascript. In Flash, this same functionality is supported (and very popular) within both Flowplayer and JW Player. True adaptive streaming (continous switching without buffering) won't be possible, but the experience is good enough to suit people that don't have the encoder or browser (yet) to build or playback adaptive streams.		* With just the QOS metrics (downloadRate and decodedFrames) in place, it will be possible to build adaptive-streaming-like solutions (using range-requests) in javascript. In Flash, this same functionality is supported (and very popular) within both Flowplayer and JW Player. True adaptive streaming (continous switching without buffering) won't be possible, but the experience is good enough to suit people that don't have the encoder or browser (yet) to build or playback adaptive streams.

			[[Category:Feature Request]]

Jluther: /* Chunks */

2010-11-10T20:10:02Z

Chunks

← Older revision		Revision as of 20:10, 10 November 2010
Line 47:		Line 47:
	In its most low-tech form, chunks can be stored as separate files-on-disc on a webserver. This poses issues around transcoding (no ecosystem yet) and file management (not everybody loves 100s of files). There are at least two solutions:		In its most low-tech form, chunks can be stored as separate files-on-disc on a webserver. This poses issues around transcoding (no ecosystem yet) and file management (not everybody loves 100s of files). There are at least two solutions:

	1. A serverside module accepts chunk requests, pulls the correct GOP(s) from a video and wraps the necessary metadata.		# A serverside module accepts chunk requests, pulls the correct GOP(s) from a video and wraps the necessary metadata.
	2. Clients can accept and process video without headers and use HTTP range-requests to directly get the video data.		# Clients can accept and process video without headers and use HTTP range-requests to directly get the video data.

	== Manifests ==		== Manifests ==

Jluther at 20:08, 10 November 2010

2010-11-10T20:08:46Z

← Older revision		Revision as of 20:08, 10 November 2010
Line 5:		Line 5:
	* The user-agent parses manifests and switches between stream levels.		* The user-agent parses manifests and switches between stream levels.
	* An API provides QOS metrics and enables custom switching logic.		* An API provides QOS metrics and enables custom switching logic.




	== Introduction ==		== Introduction ==
Line 34:		Line 31:
	* It builds upon existing HTTP infrastructure.		* It builds upon existing HTTP infrastructure.
	* It centralizes all intelligence (and control) in the client.		* It centralizes all intelligence (and control) in the client.




	== Chunks ==		== Chunks ==
Line 55:		Line 49:
	1. A serverside module accepts chunk requests, pulls the correct GOP(s) from a video and wraps the necessary metadata.		1. A serverside module accepts chunk requests, pulls the correct GOP(s) from a video and wraps the necessary metadata.
	2. Clients can accept and process video without headers and use HTTP range-requests to directly get the video data.		2. Clients can accept and process video without headers and use HTTP range-requests to directly get the video data.




	== Manifests ==		== Manifests ==
Line 91:		Line 82:

	The M3U8 playlist format also provides a mechanism for stream interruptions (#EXT-X-DISCONTINUITY) and for encryption (#EXT-X-KEY). Moreover, regular ID3 tags can be used to enrich the manifest with metadata.		The M3U8 playlist format also provides a mechanism for stream interruptions (#EXT-X-DISCONTINUITY) and for encryption (#EXT-X-KEY). Moreover, regular ID3 tags can be used to enrich the manifest with metadata.



	== User-agents ==		== User-agents ==
Line 125:		Line 114:
	</channel>		</channel>
	</rss>		</rss>


	Like the manifest parsing, the switching heuristics are upon the user-agent. They can be somewhat of a secret sauce. As a basic example, a user-agent can select a quality level if:		Like the manifest parsing, the switching heuristics are upon the user-agent. They can be somewhat of a secret sauce. As a basic example, a user-agent can select a quality level if:
Line 140:		Line 128:

	There is a tie-in between the length of a chunk, the bufferLenght and the speed with which a user-agent adapts to changing conditions. For example, should the bandwidth drop dramatically, 1 or 2 high-quality chunks will still be played from buffer before the first lower-quality chunk is shown. The other way around is also true: should a user go fullscreen, it will take some time until the stream switches to high quality. Lower bufferLenghts increase responsiveness but also increase the possiblity of buffer underruns.		There is a tie-in between the length of a chunk, the bufferLenght and the speed with which a user-agent adapts to changing conditions. For example, should the bandwidth drop dramatically, 1 or 2 high-quality chunks will still be played from buffer before the first lower-quality chunk is shown. The other way around is also true: should a user go fullscreen, it will take some time until the stream switches to high quality. Lower bufferLenghts increase responsiveness but also increase the possiblity of buffer underruns.



	== Scripting ==		== Scripting ==

	Certain user-agents might not offer access to adaptive streaming heuristics. Other user-agents might, or should even do so. The obvious case is a webbrowser supporting the <video> element and a javascript engine:		Certain user-agents might not offer access to adaptive streaming heuristics. Other user-agents might, or should even do so. The obvious case is a webbrowser supporting the <video> element and a javascript engine:


	=== QOS Metrics ===		=== QOS Metrics ===
Line 160:		Line 145:
	* '''width''': The current width of the video element (already exists).		* '''width''': The current width of the video element (already exists).
	* '''videoWidth''': The current width of the videofile (already exists).		* '''videoWidth''': The current width of the videofile (already exists).


	=== Native adaptive streaming ===		=== Native adaptive streaming ===

JeroenW: /* API adaptive streaming */

2010-10-28T09:57:44Z

API adaptive streaming

← Older revision		Revision as of 09:57, 28 October 2010
Line 212:		Line 212:
	The '''bufferlength''' getter reports upon the actual amount of data that's in the buffer. Scripts cannot presume any video they append to the videoElement is immediately available: the URL has to be resolved, the data has to be fetched and the data has to be demuxed.		The '''bufferlength''' getter reports upon the actual amount of data that's in the buffer. Scripts cannot presume any video they append to the videoElement is immediately available: the URL has to be resolved, the data has to be fetched and the data has to be demuxed.

	~~This~~ call implies that properties such as ''duration'', ''videoHeight'' and ''videoWidth'' may change during a playback session.		The '''appendVideo''' call implies that properties such as ''duration'', ''videoHeight'' and ''videoWidth'' may change during a playback session.

	A number of rules have to be set up as to how the concatenation will actually work. For example:		A number of rules have to be set up as to how the concatenation will actually work. For example:

JeroenW: /* API adaptive streaming */

2010-10-28T09:56:59Z

API adaptive streaming

← Older revision		Revision as of 09:56, 28 October 2010
Line 202:		Line 202:

	* '''appendVideo(url,[range])''': fetch the URL and append the video to the currently playing video.		* '''appendVideo(url,[range])''': fetch the URL and append the video to the currently playing video.
			* '''bufferlength''' (read-only): get the current video buffer amount, in seconds.

	~~This~~ single call allows developers to build adaptive HTTP streaming inside the javascripting layer. Manifest parsing and stream level APIs are not needed. The quality of service metrics are still needed though:		The single call allows developers to build adaptive HTTP streaming inside the javascripting layer. Manifest parsing and stream level APIs are not needed. The quality of service metrics are still needed though:

	* When the video plays fine, chunks fro the same quality level are constantly appended.		* When the video plays fine, chunks fro the same quality level are constantly appended.
	* When a switch to a different quality level is made, chunks from a different quality level are appended.		* When a switch to a different quality level is made, chunks from a different quality level are appended.
	* When the user seeks to a different position in the video, it's '''src''' is simply set to the appropriate chunk at that position.		* When the user seeks to a different position in the video, it's '''src''' is simply set to the appropriate chunk at that position.

			The '''bufferlength''' getter reports upon the actual amount of data that's in the buffer. Scripts cannot presume any video they append to the videoElement is immediately available: the URL has to be resolved, the data has to be fetched and the data has to be demuxed.

	This call implies that properties such as ''duration'', ''videoHeight'' and ''videoWidth'' may change during a playback session.		This call implies that properties such as ''duration'', ''videoHeight'' and ''videoWidth'' may change during a playback session.

JeroenW: /* API adaptive streaming */

2010-10-26T10:40:37Z

API adaptive streaming

← Older revision		Revision as of 10:40, 26 October 2010
Line 203:		Line 203:
	* '''appendVideo(url,[range])''': fetch the URL and append the video to the currently playing video.		* '''appendVideo(url,[range])''': fetch the URL and append the video to the currently playing video.

	This single call allows developers to build adaptive HTTP streaming inside the javascripting layer. Manifest parsing and stream level APIs are not needed. The quality of service metrics are still needed though.		This single call allows developers to build adaptive HTTP streaming inside the javascripting layer. Manifest parsing and stream level APIs are not needed. The quality of service metrics are still needed though:

			* When the video plays fine, chunks fro the same quality level are constantly appended.
			* When a switch to a different quality level is made, chunks from a different quality level are appended.
			* When the user seeks to a different position in the video, it's '''src''' is simply set to the appropriate chunk at that position.

	This call implies that properties such as ''duration'', ''videoHeight'' and ''videoWidth'' may change during a playback session.		This call implies that properties such as ''duration'', ''videoHeight'' and ''videoWidth'' may change during a playback session.
Line 214:		Line 218:

	The optional ''range'' parameter instructs the user-agent to only request a certain byterange.		The optional ''range'' parameter instructs the user-agent to only request a certain byterange.


	== Rationale ==		== Rationale ==

JeroenW: /* Adaptive Video Streaming */

2010-10-26T10:29:59Z

Adaptive Video Streaming

Show changes