https://wiki.xiph.org/api.php?action=feedcontributions&user=Robsbox&feedformat=atomXiphWiki - User contributions [en]2024-03-19T04:58:25ZUser contributionsMediaWiki 1.40.1https://wiki.xiph.org/index.php?title=XSPF_Wish_List&diff=6843XSPF Wish List2007-06-03T15:21:50Z<p>Robsbox: </p>
<hr />
<div>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.<br />
<br />
* 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. <br />
<br />
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35<br />
<br />
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. <br />
<br />
* Request: MIME type of linked media<br />
** This would be parallel to the RSS enclosure 'type' attribute. It is for user-agents to use in guessing whether they would want to traverse some link.<br />
** Proposal: a new extension element defined as the result of a HEAD on the link.<br />
<br />
* Request: Semantics for M3U-like '#CURTRACK'<br />
* Request: Track creation & last modified dates<br />
* 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.<br />
** This idea taken further brings a related one: separate sublist blocks each with own base.<br />
*** Possibly nestable?</div>Robsboxhttps://wiki.xiph.org/index.php?title=XSPF_Wish_List&diff=6842XSPF Wish List2007-06-03T14:50:35Z<p>Robsbox: </p>
<hr />
<div>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.<br />
<br />
* 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:<br />
<br />
<track><location>http://<myserverurl>/video.mpg?range=0-1145600</location></track><br />
<br />
<br />
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.<br />
<br />
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35<br />
<br />
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. <br />
<br />
* Request: MIME type of linked media<br />
** This would be parallel to the RSS enclosure 'type' attribute. It is for user-agents to use in guessing whether they would want to traverse some link.<br />
** Proposal: a new extension element defined as the result of a HEAD on the link.<br />
<br />
* Request: Semantics for M3U-like '#CURTRACK'<br />
* Request: Track creation & last modified dates<br />
* 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.<br />
** This idea taken further brings a related one: separate sublist blocks each with own base.<br />
*** Possibly nestable?</div>Robsboxhttps://wiki.xiph.org/index.php?title=XSPF_Wish_List&diff=6790XSPF Wish List2007-05-30T15:27:22Z<p>Robsbox: </p>
<hr />
<div>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.<br />
<br />
* 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:<br />
<br />
<track><location>http://<myserverurl>/video.mpg?range=0-1145600</location></track><br />
<br />
<br />
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.<br />
<br />
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. <br />
<br />
* Request: MIME type of linked media<br />
** This would be parallel to the RSS enclosure 'type' attribute. It is for user-agents to use in guessing whether they would want to traverse some link.<br />
** Proposal: a new extension element defined as the result of a HEAD on the link.<br />
<br />
* Request: Semantics for M3U-like '#CURTRACK'<br />
* Request: Track creation & last modified dates<br />
* 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.<br />
** This idea taken further brings a related one: separate sublist blocks each with own base.<br />
*** Possibly nestable?</div>Robsboxhttps://wiki.xiph.org/index.php?title=XSPF_Wish_List&diff=6789XSPF Wish List2007-05-30T14:44:28Z<p>Robsbox: </p>
<hr />
<div>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.<br />
<br />
* 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:<br />
<br />
<track><location>http://<myserverurl>/video.mpg?range=0-1145600</location></track><br />
<br />
<br />
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.<br />
<br />
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. <br />
<br />
* Request: MIME type of linked media<br />
** This would be parallel to the RSS enclosure 'type' attribute. It is for user-agents to use in guessing whether they would want to traverse some link.<br />
** Proposal: a new extension element defined as the result of a HEAD on the link.<br />
<br />
* Request: Semantics for M3U-like '#CURTRACK'<br />
* Request: Track creation & last modified dates<br />
* 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.<br />
** This idea taken further brings a related one: separate sublist blocks each with own base.<br />
*** Possibly nestable?</div>Robsboxhttps://wiki.xiph.org/index.php?title=XSPF_Wish_List&diff=6788XSPF Wish List2007-05-30T14:40:19Z<p>Robsbox: </p>
<hr />
<div>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.<br />
<br />
* 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. <br />
<br />
Example: http://<myserverurl>/video.mpg?range=0-1145600<br />
<br />
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.<br />
<br />
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. <br />
<br />
* Request: MIME type of linked media<br />
** This would be parallel to the RSS enclosure 'type' attribute. It is for user-agents to use in guessing whether they would want to traverse some link.<br />
** Proposal: a new extension element defined as the result of a HEAD on the link.<br />
<br />
* Request: Semantics for M3U-like '#CURTRACK'<br />
* Request: Track creation & last modified dates<br />
* 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.<br />
** This idea taken further brings a related one: separate sublist blocks each with own base.<br />
*** Possibly nestable?</div>Robsbox