XSPF Wish List - Revision history

Fredo at 18:54, 21 January 2008

2008-01-21T18:54:56Z

← Older revision		Revision as of 18:54, 21 January 2008
Line 16:		Line 16:
	** This idea taken further brings a related one: separate sublist blocks each with own base.		** This idea taken further brings a related one: separate sublist blocks each with own base.
	*** Possibly nestable?		*** Possibly nestable?
			*** Sublist blocks could share more information than just baseurl: It would allow album-like collections that share, e.g., creator, album, image.
	* Request: Semantics for next playlist. This would enable a player to follow the playlist to another playlist URI in order to form linked playlists.		* Request: Semantics for next playlist. This would enable a player to follow the playlist to another playlist URI in order to form linked playlists.
	** I realize this is available in some extensions, but thought it may be relevant enough to add to the core specification		** I realize this is available in some extensions, but thought it may be relevant enough to add to the core specification

	[[Category:XSPF]]		[[Category:XSPF]]

Saoshyant: cat

2007-12-21T19:18:46Z

cat

← Older revision		Revision as of 19:18, 21 December 2007
Line 18:		Line 18:
	* Request: Semantics for next playlist. This would enable a player to follow the playlist to another playlist URI in order to form linked playlists.		* Request: Semantics for next playlist. This would enable a player to follow the playlist to another playlist URI in order to form linked playlists.
	** I realize this is available in some extensions, but thought it may be relevant enough to add to the core specification		** I realize this is available in some extensions, but thought it may be relevant enough to add to the core specification

			[[Category:XSPF]]

Jheiselman at 18:10, 26 September 2007

2007-09-26T18:10:55Z

← Older revision		Revision as of 18:10, 26 September 2007
Line 17:		Line 17:
	*** Possibly nestable?		*** Possibly nestable?
	* Request: Semantics for next playlist. This would enable a player to follow the playlist to another playlist URI in order to form linked playlists.		* Request: Semantics for next playlist. This would enable a player to follow the playlist to another playlist URI in order to form linked playlists.
			** I realize this is available in some extensions, but thought it may be relevant enough to add to the core specification

Jheiselman: Added Request for linked playlists

2007-09-26T18:07:36Z

Added Request for linked playlists

← Older revision		Revision as of 18:07, 26 September 2007
Line 16:		Line 16:
	** This idea taken further brings a related one: separate sublist blocks each with own base.		** This idea taken further brings a related one: separate sublist blocks each with own base.
	*** Possibly nestable?		*** Possibly nestable?
			* Request: Semantics for next playlist. This would enable a player to follow the playlist to another playlist URI in order to form linked playlists.

Robsbox at 15:21, 3 June 2007

2007-06-03T15:21:50Z

← Older revision		Revision as of 15:21, 3 June 2007
Line 1:		Line 1:
	This page is a place to file requests for features for [[XSPF]]. Any kind of feature can be entered here, please don't be bashful.		This page is a place to file requests for features for [[XSPF]]. Any kind of feature can be entered here, please don't be bashful.

	* Request: track start and end attributes. ~~In many~~ media ~~players, a parameter, such as '~~range~~' can be used for video files~~, to specify the start and stop positions of the content for the track. ~~An example of specifying this in the URI for the content:~~		* Request: track start and end attributes. Some media servers permit range headers in the http request, to specify the start and stop positions of the content for the track.

	~~<track><location>http://<myserverurl>/video.mpg?range=0-1145600</location></track>~~


	where 0 is a long long integer denoting the ''start'' byte offset of the content and 1145600 is a long long integer denoting the ''end'' byte offset of the content. For large video files the specification of ''start'' and ''end'' positions within the content for the track would relieve us from splitting or recoding videos just because we want to play a part of the content for the track.

	See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35		See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35

	~~Rather than specifying this as~~ a ~~parameter in~~ the ~~example URI above,~~ include tags to denote the byte offset within the file for the track, and require long long integers.		For large video files the specification of ''start'' and ''end'' positions within the content for the track would relieve us from splitting or recoding videos just because we want to play a part of the content for the track. Please include tags to denote the byte offset within the file for the track, and require long long integers.

	* Request: MIME type of linked media		* Request: MIME type of linked media

Robsbox at 14:50, 3 June 2007

2007-06-03T14:50:35Z

← Older revision		Revision as of 14:50, 3 June 2007
Line 7:		Line 7:

	where 0 is a long long integer denoting the ''start'' byte offset of the content and 1145600 is a long long integer denoting the ''end'' byte offset of the content. For large video files the specification of ''start'' and ''end'' positions within the content for the track would relieve us from splitting or recoding videos just because we want to play a part of the content for the track.		where 0 is a long long integer denoting the ''start'' byte offset of the content and 1145600 is a long long integer denoting the ''end'' byte offset of the content. For large video files the specification of ''start'' and ''end'' positions within the content for the track would relieve us from splitting or recoding videos just because we want to play a part of the content for the track.

			See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35

	Rather than specifying this as a parameter in the example URI above, include tags to denote the byte offset within the file for the track, and require long long integers.		Rather than specifying this as a parameter in the example URI above, include tags to denote the byte offset within the file for the track, and require long long integers.

Robsbox at 15:27, 30 May 2007

2007-05-30T15:27:22Z

← Older revision		Revision as of 15:27, 30 May 2007
Line 6:		Line 6:


	For large video files the specification of ''start'' and ''end'' positions within a track would relieve us from splitting or recoding videos just because we want to play ~~just~~ a part of the track.		where 0 is a long long integer denoting the ''start'' byte offset of the content and 1145600 is a long long integer denoting the ''end'' byte offset of the content. For large video files the specification of ''start'' and ''end'' positions within the content for the track would relieve us from splitting or recoding videos just because we want to play a part of the content for the track.

	Rather than specifying this as a parameter in the example URI above, include tags to denote the byte offset within the file for the track.		Rather than specifying this as a parameter in the example URI above, include tags to denote the byte offset within the file for the track, and require long long integers.

	* Request: MIME type of linked media		* Request: MIME type of linked media

Robsbox at 14:44, 30 May 2007

2007-05-30T14:44:28Z

← Older revision		Revision as of 14:44, 30 May 2007
Line 1:		Line 1:
	This page is a place to file requests for features for [[XSPF]]. Any kind of feature can be entered here, please don't be bashful.		This page is a place to file requests for features for [[XSPF]]. Any kind of feature can be entered here, please don't be bashful.

	* Request: track start and end attributes. In many media players, a parameter, such as 'range' can be used for video files, to specify the start and stop positions of the content for the track.		* Request: track start and end attributes. In many media players, a parameter, such as 'range' can be used for video files, to specify the start and stop positions of the content for the track. An example of specifying this in the URI for the content:

			<track><location>http://<myserverurl>/video.mpg?range=0-1145600</location></track>

	~~Example: http://<myserverurl>/video.mpg?range=0-1145600~~

	For large video files the specification of ''start'' and ''end'' positions within a track would relieve us from splitting or recoding videos just because we want to play just a part of the track.		For large video files the specification of ''start'' and ''end'' positions within a track would relieve us from splitting or recoding videos just because we want to play just a part of the track.

Robsbox at 14:40, 30 May 2007

2007-05-30T14:40:19Z

← Older revision		Revision as of 14:40, 30 May 2007
Line 1:		Line 1:
	This page is a place to file requests for features for [[XSPF]]. Any kind of feature can be entered here, please don't be bashful.		This page is a place to file requests for features for [[XSPF]]. Any kind of feature can be entered here, please don't be bashful.

			* Request: track start and end attributes. In many media players, a parameter, such as 'range' can be used for video files, to specify the start and stop positions of the content for the track.

			Example: http://<myserverurl>/video.mpg?range=0-1145600

			For large video files the specification of ''start'' and ''end'' positions within a track would relieve us from splitting or recoding videos just because we want to play just a part of the track.

			Rather than specifying this as a parameter in the example URI above, include tags to denote the byte offset within the file for the track.

	* Request: MIME type of linked media		* Request: MIME type of linked media
Line 7:		Line 15:
	* Request: Semantics for M3U-like '#CURTRACK'		* Request: Semantics for M3U-like '#CURTRACK'
	* Request: Track creation & last modified dates		* Request: Track creation & last modified dates
	* Request: track start and end attributes (seconds). example: for large video files the specification of ''start'' and ''end'' positions within a track would relief us from splitting or recoding videos just because we want to play just a part of the track.
	* Request: playlist relativization: separate the base from the file locations relativized from the base. This apparently should be optional, because some (but i suppose not many) playlists might be desired to have entries with no common path entries. This will allow UI's to provide rebasing of playlists -- imagine a media set accessible locally, via FS, and remotely, via, say, HTTP.		* Request: playlist relativization: separate the base from the file locations relativized from the base. This apparently should be optional, because some (but i suppose not many) playlists might be desired to have entries with no common path entries. This will allow UI's to provide rebasing of playlists -- imagine a media set accessible locally, via FS, and remotely, via, say, HTTP.
	** This idea taken further brings a related one: separate sublist blocks each with own base.		** This idea taken further brings a related one: separate sublist blocks each with own base.
	*** Possibly nestable?		*** Possibly nestable?

Deepfire at 07:48, 22 May 2007

2007-05-22T07:48:37Z

← Older revision		Revision as of 07:48, 22 May 2007
Line 9:		Line 9:
	* Request: track start and end attributes (seconds). example: for large video files the specification of ''start'' and ''end'' positions within a track would relief us from splitting or recoding videos just because we want to play just a part of the track.		* Request: track start and end attributes (seconds). example: for large video files the specification of ''start'' and ''end'' positions within a track would relief us from splitting or recoding videos just because we want to play just a part of the track.
	* Request: playlist relativization: separate the base from the file locations relativized from the base. This apparently should be optional, because some (but i suppose not many) playlists might be desired to have entries with no common path entries. This will allow UI's to provide rebasing of playlists -- imagine a media set accessible locally, via FS, and remotely, via, say, HTTP.		* Request: playlist relativization: separate the base from the file locations relativized from the base. This apparently should be optional, because some (but i suppose not many) playlists might be desired to have entries with no common path entries. This will allow UI's to provide rebasing of playlists -- imagine a media set accessible locally, via FS, and remotely, via, say, HTTP.
			** This idea taken further brings a related one: separate sublist blocks each with own base.
			*** Possibly nestable?