Guillaume (Jean-Louis) Olivrin
Davy Van Deursen
Related to a discussion started by Guillaume .
A media fragment URI can be used for addressing, for example, a particular audio track of a mkv movie, or a particular key-frame of a video. What is the resulting mime type of the secondary resource specified by the fragment (audio, thumbnail, text)? Should we specify it in the recommendation?
What RFC3986 does say about the mime type of a fragment ?
Side issue: in case we create a new resource (i.e. using the query '?' parameter instead of the fragment '#' parameter), how do we make explicit the relationship with the parent resource it was extracted from?
Do we use Link: rel="part_of" <video_uri> as suggested by Yves ?
Add notes (no markup allowed, URIs get automatically hyperlinked):
The mime type of a media fragment is the *same* mime time of its parent resource. Hence, a media fragment addressing a single frame of a video would be of mime type video. If the media format constrains the playability of such resource (e.g. MP4 or 3GP explicitly forbid to have video with a zero duration), then the selection of this fragment will fail. In other words, media fragment URI are bound to the limitations of the underlying coding and container formats.
Addressing a single frame of a video as an image will create a *new* resource. It is therefore *NOT* a fragment. It might be possible to create such a resource using a '?' followed by the same syntax of the media fragment URI. It might be possible to use the link header provided by http to provide a (typed) link towards the video resource from which the image comes from. The mime type of this new resource would certainly be image/*.
The summary is, returning an image frame from a video is not a fragment of this video.