XSPF Wish List: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
No edit summary
No edit summary
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?

Revision as of 07:40, 30 May 2007

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
    • 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.
    • Proposal: a new extension element defined as the result of a HEAD on the link.
  • Request: Semantics for M3U-like '#CURTRACK'
  • Request: Track creation & last modified dates
  • 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?