SkeletonHeaders - Revision history

Silvia: /* Role */ adding a few more roles to match with the HTML spec

2014-03-17T07:07:48Z

Role: adding a few more roles to match with the HTML spec

← Older revision		Revision as of 07:07, 17 March 2014
Line 54:		Line 54:
	* "video/alternate" - an alternative video track, e.g. different camera angle		* "video/alternate" - an alternative video track, e.g. different camera angle
	* "video/sign" - a sign language video track		* "video/sign" - a sign language video track
			* "video/captioned" - the main video track with burnt-in captions
			* "video/subtitled" - the main video track with burnt-in subtitles

	Audio tracks:		Audio tracks:
Line 59:		Line 61:
	* "audio/alternate" - an alternative audio track, probably linked to an alternate video track		* "audio/alternate" - an alternative audio track, probably linked to an alternate video track
	* "audio/dub" - the audio track but with speech in a different language to the original		* "audio/dub" - the audio track but with speech in a different language to the original
	* "audio/audiodesc" - an audio description recording for the vision-impaired		* "audio/audiodesc" - an audio description recording for the vision-impaired
			* "audio/described" - the main audio track mixed with audio descriptions
	* "audio/music" - a music track, e.g. when music, speech and sound effects are delivered in different tracks		* "audio/music" - a music track, e.g. when music, speech and sound effects are delivered in different tracks
	* "audio/speech" - a speech track, e.g. when music, speech and sound effects are delivered in different tracks		* "audio/speech" - a speech track, e.g. when music, speech and sound effects are delivered in different tracks
	* "audio/sfx" - a sound effects track, e.g. when music, speech and sound effects are delivered in different tracks		* "audio/sfx" - a sound effects track, e.g. when music, speech and sound effects are delivered in different tracks
			* "audio/commentary" - commentary on the main audio or video track

	Notice how we are re-using the Content-type approach of specifying the main semantic type of the track first. This is necessary, since mime types don't always provide the right main content type (e.g. application/kate is semantically a text format).		Notice how we are re-using the Content-type approach of specifying the main semantic type of the track first. This is necessary, since mime types don't always provide the right main content type (e.g. application/kate is semantically a text format).

Martin.leese: Converted initial header to text + promoted every other header back to their original levels

2010-11-24T18:25:32Z

Converted initial header to text + promoted every other header back to their original levels

← Older revision		Revision as of 18:25, 24 November 2010
Line 1:		Line 1:
	== [[Ogg Skeleton 4]] ~~Message Headers ==~~		This page describes the Message Headers in [[Ogg Skeleton 4]].

	=== Adding New Message Headers to Skeleton ===		== Adding New Message Headers to Skeleton ==

	With the HTML5 video element, Ogg is now a major format on the Web and is being applied to solve use cases it hasn't had to solve before, but was built to allow, see http://www.xiph.org/ogg/doc/oggstream.html.		With the HTML5 video element, Ogg is now a major format on the Web and is being applied to solve use cases it hasn't had to solve before, but was built to allow, see http://www.xiph.org/ogg/doc/oggstream.html.
Line 11:		Line 11:
	On this wiki page, we are collecting such new information fields.		On this wiki page, we are collecting such new information fields.

	==== Content-type ====		=== Content-type ===

	Right now, there is one mandatory message header field for all of the logical bitstreams: the "Content-type" header field, which contains the mime type of the track. The mime types in use here are listed at http://wiki.xiph.org/MIME_Types_and_File_Extensions#Codec_MIME_types.		Right now, there is one mandatory message header field for all of the logical bitstreams: the "Content-type" header field, which contains the mime type of the track. The mime types in use here are listed at http://wiki.xiph.org/MIME_Types_and_File_Extensions#Codec_MIME_types.

	==== Language ====		=== Language ===

	Content in a track usually originates from a specific language. This language can be specified in a Language message header field. The code is created according to http://www.w3.org/TR/ltli/ and http://www.rfc-editor.org/rfc/bcp/bcp47.txt.		Content in a track usually originates from a specific language. This language can be specified in a Language message header field. The code is created according to http://www.w3.org/TR/ltli/ and http://www.rfc-editor.org/rfc/bcp/bcp47.txt.
Line 32:		Line 32:
	Language: en-US, fr		Language: en-US, fr

	==== Role ====		=== Role ===

	Role describe what semantic type of content is contained in a track. Every track can only have a single role value, so the most appropriate role has to be chosen. The same role can be used across multiple tracks.		Role describe what semantic type of content is contained in a track. Every track can only have a single role value, so the most appropriate role has to be chosen. The same role can be used across multiple tracks.
Line 68:		Line 68:
	There may also be parameters to describe the roles better, such as "video/alternate;angle=nw"		There may also be parameters to describe the roles better, such as "video/alternate;angle=nw"

	==== Name ====		=== Name ===

	This field provides the opportunity to associate a free text string with the track to allow direct addressing of the track through its name.		This field provides the opportunity to associate a free text string with the track to allow direct addressing of the track through its name.
Line 87:		Line 87:
	An example means of addressing the track by name is: track[name="Madonna_singing"]		An example means of addressing the track by name is: track[name="Madonna_singing"]

	==== Title ====		=== Title ===

	A free text field to provide a description of the track content.		A free text field to provide a description of the track content.
Line 94:		Line 94:
	Title: "the French audio track for the movie"		Title: "the French audio track for the movie"

	==== Display-hint ====		=== Display-hint ===

	Media players that do not get informed about how a content author intends a media file to be displayed have no change to display the content "correctly". This is why the Display-hint message header field allows providing of hints on how a certain track should be displayed. A media player can of course decide to ignore these hints.		Media players that do not get informed about how a content author intends a media file to be displayed have no change to display the content "correctly". This is why the Display-hint message header field allows providing of hints on how a certain track should be displayed. A media player can of course decide to ignore these hints.
Line 119:		Line 119:
	Display-hint: transparent(7%)		Display-hint: transparent(7%)

	==== Track order ====		=== Track order ===

	In many applications it is necessary to walk through all the tracks in a media file and address tracks by an index.		In many applications it is necessary to walk through all the tracks in a media file and address tracks by an index.
Line 136:		Line 136:
	This track order is simply to have a means to address tracks through an index in a consistent manner across different media players, such that e.g. JavaScript can always link to the same track reliably across browsers. It has no influence on what should be displayed on top of which other track.		This track order is simply to have a means to address tracks through an index in a consistent manner across different media players, such that e.g. JavaScript can always link to the same track reliably across browsers. It has no influence on what should be displayed on top of which other track.

	==== Altitude ====		=== Altitude ===

	The Altitude (better name?) message header field defines the stack order of the tracks, i.e. which track is displayed further towards the top of the stack and which further down. By default, a "main" track is always displayed bottom-most unless otherwise defined.		The Altitude (better name?) message header field defines the stack order of the tracks, i.e. which track is displayed further towards the top of the stack and which further down. By default, a "main" track is always displayed bottom-most unless otherwise defined.
Line 145:		Line 145:
	Example: Altitude: -150		Example: Altitude: -150

	==== Track dependencies ====		=== Track dependencies ===

	It is tempting to introduce dependencies between tracks - to specify things such as:		It is tempting to introduce dependencies between tracks - to specify things such as:

Martin.leese: Fixed heading levels + removed blank lines + added link back to Ogg Skeleton 4

2010-11-23T20:42:23Z

Fixed heading levels + removed blank lines + added link back to Ogg Skeleton 4

← Older revision		Revision as of 20:42, 23 November 2010
Line 1:		Line 1:
	= Ogg Skeleton 4 Message Headers =		== [[Ogg Skeleton 4]] Message Headers ==

	== Adding New Message Headers to Skeleton ==		=== Adding New Message Headers to Skeleton ===

	With the HTML5 video element, Ogg is now a major format on the Web and is being applied to solve use cases it hasn't had to solve before, but was built to allow, see http://www.xiph.org/ogg/doc/oggstream.html.		With the HTML5 video element, Ogg is now a major format on the Web and is being applied to solve use cases it hasn't had to solve before, but was built to allow, see http://www.xiph.org/ogg/doc/oggstream.html.
Line 11:		Line 11:
	On this wiki page, we are collecting such new information fields.		On this wiki page, we are collecting such new information fields.

			==== Content-type ====
	=== Content-type ===

	Right now, there is one mandatory message header field for all of the logical bitstreams: the "Content-type" header field, which contains the mime type of the track. The mime types in use here are listed at http://wiki.xiph.org/MIME_Types_and_File_Extensions#Codec_MIME_types.		Right now, there is one mandatory message header field for all of the logical bitstreams: the "Content-type" header field, which contains the mime type of the track. The mime types in use here are listed at http://wiki.xiph.org/MIME_Types_and_File_Extensions#Codec_MIME_types.

			==== Language ====
	=== Language ===

	Content in a track usually originates from a specific language. This language can be specified in a Language message header field. The code is created according to http://www.w3.org/TR/ltli/ and http://www.rfc-editor.org/rfc/bcp/bcp47.txt.		Content in a track usually originates from a specific language. This language can be specified in a Language message header field. The code is created according to http://www.w3.org/TR/ltli/ and http://www.rfc-editor.org/rfc/bcp/bcp47.txt.
Line 34:		Line 32:
	Language: en-US, fr		Language: en-US, fr

			==== Role ====
	=== Role ===

	Role describe what semantic type of content is contained in a track. Every track can only have a single role value, so the most appropriate role has to be chosen. The same role can be used across multiple tracks.		Role describe what semantic type of content is contained in a track. Every track can only have a single role value, so the most appropriate role has to be chosen. The same role can be used across multiple tracks.
Line 71:		Line 68:
	There may also be parameters to describe the roles better, such as "video/alternate;angle=nw"		There may also be parameters to describe the roles better, such as "video/alternate;angle=nw"

			==== Name ====
	=== Name ===

	This field provides the opportunity to associate a free text string with the track to allow direct addressing of the track through its name.		This field provides the opportunity to associate a free text string with the track to allow direct addressing of the track through its name.
Line 91:		Line 87:
	An example means of addressing the track by name is: track[name="Madonna_singing"]		An example means of addressing the track by name is: track[name="Madonna_singing"]

			==== Title ====
	=== Title ===

	A free text field to provide a description of the track content.		A free text field to provide a description of the track content.
Line 99:		Line 94:
	Title: "the French audio track for the movie"		Title: "the French audio track for the movie"

			==== Display-hint ====
	=== Display-hint ===

	Media players that do not get informed about how a content author intends a media file to be displayed have no change to display the content "correctly". This is why the Display-hint message header field allows providing of hints on how a certain track should be displayed. A media player can of course decide to ignore these hints.		Media players that do not get informed about how a content author intends a media file to be displayed have no change to display the content "correctly". This is why the Display-hint message header field allows providing of hints on how a certain track should be displayed. A media player can of course decide to ignore these hints.
Line 125:		Line 119:
	Display-hint: transparent(7%)		Display-hint: transparent(7%)

			==== Track order ====

	=== Track order ===

	In many applications it is necessary to walk through all the tracks in a media file and address tracks by an index.		In many applications it is necessary to walk through all the tracks in a media file and address tracks by an index.
Line 144:		Line 136:
	This track order is simply to have a means to address tracks through an index in a consistent manner across different media players, such that e.g. JavaScript can always link to the same track reliably across browsers. It has no influence on what should be displayed on top of which other track.		This track order is simply to have a means to address tracks through an index in a consistent manner across different media players, such that e.g. JavaScript can always link to the same track reliably across browsers. It has no influence on what should be displayed on top of which other track.

			==== Altitude ====
	=== Altitude ===

	The Altitude (better name?) message header field defines the stack order of the tracks, i.e. which track is displayed further towards the top of the stack and which further down. By default, a "main" track is always displayed bottom-most unless otherwise defined.		The Altitude (better name?) message header field defines the stack order of the tracks, i.e. which track is displayed further towards the top of the stack and which further down. By default, a "main" track is always displayed bottom-most unless otherwise defined.
Line 154:		Line 145:
	Example: Altitude: -150		Example: Altitude: -150

			==== Track dependencies ====
	=== Track dependencies ===

	It is tempting to introduce dependencies between tracks - to specify things such as:		It is tempting to introduce dependencies between tracks - to specify things such as:

Cpearce at 02:09, 23 November 2010

2010-11-23T02:09:28Z

← Older revision		Revision as of 02:09, 23 November 2010
Line 1:		Line 1:
	~~{{draft}}~~		= Ogg Skeleton 4 Message Headers =

	= Ogg Skeleton 3.4 ~~with new~~ Message Headers =

	~~'''DRAFT, last updated 23 March 2010'''~~

	~~'''This specification is still a work in progress, and does not yet constitute an official Ogg specification.'''~~


	== Adding New Message Headers to Skeleton ==		== Adding New Message Headers to Skeleton ==

Silvia: removed transparentcolor

2010-03-24T01:18:47Z

removed transparentcolor

← Older revision		Revision as of 01:18, 24 March 2010
Line 77:		Line 77:

	There may also be parameters to describe the roles better, such as "video/alternate;angle=nw"		There may also be parameters to describe the roles better, such as "video/alternate;angle=nw"


			=== Name ===

			This field provides the opportunity to associate a free text string with the track to allow direct addressing of the track through its name.

			Characters allowed are basically all the characters that are also allowed for XML id fields:

			the first character has to be one of:
			[A-Z] \| "_" \| [a-z] \| [#xC0-#xD6] \| [#xD8-#xF6] \| [#xF8-#x2FF] \| [#x370-#x37D] \| [#x37F-#x1FFF] \| [#x200C-#x200D] \|
			[#x2070-#x218F] \| [#x2C00-#x2FEF] \| [#x3001-#xD7FF] \| [#xF900-#xFDCF] \| [#xFDF0-#xFFFD] \| [#x10000-#xEFFFF]

			any following characters can be one of:
			[A-Z] \| "_" \| [a-z] \| [#xC0-#xD6] \| [#xD8-#xF6] \| [#xF8-#x2FF] \| [#x370-#x37D] \| [#x37F-#x1FFF] \| [#x200C-#x200D] \|
			[#x2070-#x218F] \| [#x2C00-#x2FEF] \| [#x3001-#xD7FF] \| [#xF900-#xFDCF] \| [#xFDF0-#xFFFD] \| [#x10000-#xEFFFF] \|
			"-" \| "." \| [0-9] \| #xB7 \| [#x0300-#x036F] \| [#x203F-#x2040]

			The name needs to be unique between all the track names, otherwise it is undefined which of the tracks is retrieved when addressing by name.

			An example means of addressing the track by name is: track[name="Madonna_singing"]


			=== Title ===

			A free text field to provide a description of the track content.

			Example:
			Title: "the French audio track for the movie"


Line 104:		Line 132:
	Display-hint: transparent(7%)		Display-hint: transparent(7%)

	* transparentcolor(colorcode) on a video track - turn all pixels of the color identified by the colorcode into transparent pixels.

	~~Examples:~~
	~~Display-hint: transparentcolor(#454545)~~
	~~Display-hint: transparentcolor(#777777)~~

	~~=== Name ===~~

	~~This field provides the opportunity to associate a free text string with the track to allow direct addressing of the track through its name.~~

	~~Characters allowed are basically all the characters that are also allowed for XML id fields:~~

	~~the first character has to be one of:~~
	~~[A-Z] \| "_" \| [a-z] \| [#xC0-#xD6] \| [#xD8-#xF6] \| [#xF8-#x2FF] \| [#x370-#x37D] \| [#x37F-#x1FFF] \| [#x200C-#x200D] \|~~
	~~[#x2070-#x218F] \| [#x2C00-#x2FEF] \| [#x3001-#xD7FF] \| [#xF900-#xFDCF] \| [#xFDF0-#xFFFD] \| [#x10000-#xEFFFF]~~

	~~any following characters can be one of:~~
	~~[A-Z] \| "_" \| [a-z] \| [#xC0-#xD6] \| [#xD8-#xF6] \| [#xF8-#x2FF] \| [#x370-#x37D] \| [#x37F-#x1FFF] \| [#x200C-#x200D] \|~~
	~~[#x2070-#x218F] \| [#x2C00-#x2FEF] \| [#x3001-#xD7FF] \| [#xF900-#xFDCF] \| [#xFDF0-#xFFFD] \| [#x10000-#xEFFFF] \|~~
	~~"-" \| "." \| [0-9] \| #xB7 \| [#x0300-#x036F] \| [#x203F-#x2040]~~

	~~The name needs to be unique between all the track names, otherwise it is undefined which of the tracks is retrieved when addressing by name.~~

	~~An example means of addressing the track by name is: track[name="Madonna_singing"]~~

Silvia: added descriptions to the roles

2010-03-24T01:02:07Z

added descriptions to the roles

← Older revision		Revision as of 01:02, 24 March 2010
Line 49:		Line 49:

	Text tracks:		Text tracks:
	* "text/caption"		* "text/caption" - transcription of all sounds, including speech, for purposes of the hard-of-hearing
	* "text/subtitle"		* "text/subtitle" - translation of all speech, typically into a different language
	* "text/textaudiodesc"		* "text/textaudiodesc" - description/transcription of everything that happens in a video as text to be used for the vision-impaired through screen readers or braille
	* "text/karaoke"		* "text/karaoke" - music lyrics delivered in chunks for singing along
	* "text/chapters"		* "text/chapters" - titles for sections of the media that provide a kind of chapter segmentation (similar to DVD chapters)
	* "text/tickertext"		* "text/tickertext" - text to run as informative text at the bottom of the media display
	* "text/lyrics"		* "text/lyrics" - transcript of the text used in music media
	* "text~~/activeregion"~~		* "text/metadata" - name-value pairs that are associated with certain sections of the media
	* "text/metadata"		* "text/annotation" - free text associated with certain sections of the media
	* "text/annotation"		* "text/linguistic" - linguistic markup of the spoken words
	* "text~~/transcript"~~
	* "text/linguistic"
	* "text/chapters"

	Video tracks:		Video tracks:
	* "video/main"		* "video/main" - the main video track
	* "video/alternate" (e.g. different camera angle)		* "video/alternate" - an alternative video track, e.g. different camera angle
	* "video/sign" ~~(for~~ sign language)		* "video/sign" - a sign language video track
	* "video~~/alpha" (a~~ track ~~to alpha blend)~~

	Audio tracks:		Audio tracks:
	* "audio/main"		* "audio/main" - the main audio track
	* "audio/alternate" (probably linked to an alternate video track)		* "audio/alternate" - an alternative audio track, probably linked to an alternate video track
	* "audio/dub"		* "audio/dub" - the audio track but with speech in a different language to the original
	* "audio/audiodesc"		* "audio/audiodesc" - an audio description recording for the vision-impaired
	* "audio/music"		* "audio/music" - a music track, e.g. when music, speech and sound effects are delivered in different tracks
	* "audio/speech"		* "audio/speech" - a speech track, e.g. when music, speech and sound effects are delivered in different tracks
	* "audio/sfx" (sound effects)		* "audio/sfx" - a sound effects track, e.g. when music, speech and sound effects are delivered in different tracks

	Notice how we are re-using the Content-type approach of specifying the main semantic type of the track first. This is necessary, since mime types don't always provide the right main content type (e.g. application/kate is semantically a text format).		Notice how we are re-using the Content-type approach of specifying the main semantic type of the track first. This is necessary, since mime types don't always provide the right main content type (e.g. application/kate is semantically a text format).

Silvia: added multi-value to language

2010-03-24T00:46:47Z

added multi-value to language

← Older revision		Revision as of 00:46, 24 March 2010
Line 35:		Line 35:

	Examples are: en-US, de-DE, sgn-ase, en-cockney		Examples are: en-US, de-DE, sgn-ase, en-cockney

			The Language field will have the dominating language specified as the first language. It is possible to specify less non-dominating languages as a list after the main language.

			Example:
			Language: en-US, fr

Silvia: added intro

2010-03-23T05:45:22Z

added intro

← Older revision		Revision as of 05:45, 23 March 2010
Line 1:		Line 1:
	== Adding New ~~Required~~ Headers to Skeleton ==		{{draft}}

			= Ogg Skeleton 3.4 with new Message Headers =

			'''DRAFT, last updated 23 March 2010'''

			'''This specification is still a work in progress, and does not yet constitute an official Ogg specification.'''


			== Adding New Message Headers to Skeleton ==

	With the HTML5 video element, Ogg is now a major format on the Web and is being applied to solve use cases it hasn't had to solve before, but was built to allow, see http://www.xiph.org/ogg/doc/oggstream.html.		With the HTML5 video element, Ogg is now a major format on the Web and is being applied to solve use cases it hasn't had to solve before, but was built to allow, see http://www.xiph.org/ogg/doc/oggstream.html.

Silvia: /* Display-hint */

2010-03-23T05:22:13Z

Display-hint

← Older revision		Revision as of 05:22, 23 March 2010
Line 73:		Line 73:
	Media players that do not get informed about how a content author intends a media file to be displayed have no change to display the content "correctly". This is why the Display-hint message header field allows providing of hints on how a certain track should be displayed. A media player can of course decide to ignore these hints.		Media players that do not get informed about how a content author intends a media file to be displayed have no change to display the content "correctly". This is why the Display-hint message header field allows providing of hints on how a certain track should be displayed. A media player can of course decide to ignore these hints.

	Currently ~~available~~ hints are:		Currently proposed hints are:

	* pip(x,y,w,h) on a video track - picture-in-picture display in relation to the zero coordinates of the display area of the video with x,y providing the origin of the top left corner of the PIP video and w,h the width and height in pixels which are optional. x, y, w, and h can be specified in percentage, thus allowing persistent placement independent of the scaling of the video display.		* pip(x,y,w,h) on a video track - picture-in-picture display in relation to the zero coordinates of the display area of the video with x,y providing the origin of the top left corner of the PIP video and w,h the width and height in pixels which are optional. x, y, w, and h can be specified in percentage, thus allowing persistent placement independent of the scaling of the video display.

Silvia at 11:25, 21 March 2010

2010-03-21T11:25:58Z

← Older revision		Revision as of 11:25, 21 March 2010
Line 1:		Line 1:
	== Adding Required Headers to Skeleton ==		== Adding New Required Headers to Skeleton ==

	With the HTML5 video element, Ogg is now a major format on the Web and is being applied to solve use cases it hasn't had to solve before, but was built to allow, see http://www.xiph.org/ogg/doc/oggstream.html.		With the HTML5 video element, Ogg is now a major format on the Web and is being applied to solve use cases it hasn't had to solve before, but was built to allow, see http://www.xiph.org/ogg/doc/oggstream.html.