https://wiki.xiph.org/api.php?action=feedcontributions&user=Deepfire&feedformat=atomXiphWiki - User contributions [en]2024-03-29T05:09:41ZUser contributionsMediaWiki 1.40.1https://wiki.xiph.org/index.php?title=XSPF_Wish_List&diff=6750XSPF Wish List2007-05-22T07:48:37Z<p>Deepfire: </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: 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: 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.<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>Deepfirehttps://wiki.xiph.org/index.php?title=XSPF_Wish_List&diff=6749XSPF Wish List2007-05-22T07:47:16Z<p>Deepfire: </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: 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: 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.<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.</div>Deepfire