Temporal Media Fragments URI in readingOrder, should be time interval instead of playback start timestamp?

[danielweck]

https://www.w3.org/TR/media-frags/#naming-time

If I am not mistaken, a temporal Media Fragments URI such as audio.wav#t=123.45 means "start playback at the given timestamp, and play until the end of the resource is reached".

This in fact corresponds to the TOC processing model ( https://w3c.github.io/audiobooks/#toc-mediafragments ), for example:

https://github.com/w3c/wpub/blob/948442a71610abcc757513dc3313f6ed0e8fd22f/experiments/audiobook/toc-as-json.json#L32

https://github.com/w3c/wpub/blob/948442a71610abcc757513dc3313f6ed0e8fd22f/experiments/audiobook/toc.html#L7

But in the context of readingOrder, shouldn't time intervals be used instead of discrete timestamps, in order to provide both start and end playback boundaries? Otherwise, the playback sequence is not as expected, see for example:

https://w3c.github.io/audiobooks/#example-9-audiobook-reading-order-for-multiple-resources-using-media-fragments

https://w3c.github.io/audiobooks/#example-13-audiobook-with-synchronized-narration

[danielweck]

Current specification text ( https://w3c.github.io/audiobooks/#audio-readingorder ):

An audio resource can be referenced in its entirety via a URL,
or for content where multiple chapters occupy a single file
by using media fragments to locate the exact starting point.

by using media fragments to locate the exact starting point

...should probably say: "by using media fragments time intervals to locate the exact starting and end points"

?

[mattgarrish]

The example here may be the problem -- you're not supposed to list the same resource more than once in the reading order.

I don't see a problem with specifying an offset to begin playback at, but as you say @danielweck, the expectation is that the resource is played all the way to the end before moving to the next. We can allow intervals, but it alone doesn't solve the warning on duplicate resources (which is not advised generally because of the complication of linking into the correct instance).

The table of contents is where links to specific points of interest within a single resource are best expressed.

Is there a need to have granular representation of chunks of audio within a larger resource in the reading order @wareid ?

[wareid]

We need to have granular representations of chunks of audio /somewhere/ but not necessarily in the reading order. There is the odd case of one file containing not only multiple chapters but chapters also spanning multiple files (yay!), but that can be addressed in the TOC. I can add a note.

[HadrienGardeur]

Having media fragments in the readingOrder or resources leads to many problems and I'm not sure what's the use case for them.

Is there any valid reason to allow them at all?

[wareid]

Could you elaborate on the "many problems" please @HadrienGardeur ? Just so we have all of the information.

[HadrienGardeur]

Just to name two issues that immediately come to mind:

• we've talked over and over about the "boundaries" of a publication and fragments raise many questions when we use them in the readingOrder (Should we consider that the whole resource is part of the publication or only its fragment? Should you also reference the resource in resources if only a fragment of it is referenced in readingOrder? What about the TOC?)
• browsers rely on HTTP range requests to access audio/video, but if the server can't support range requests to jump to a specific timestamp then the UA could be forced to download the entire resource (if you reference the last 10 minutes of a 5 hours audio resource, this is less than optimal)

[mattgarrish]

Closing as this issue has been fixed per the original request. The question of whether media fragments should be allowed can be raised separately, although I suspect it's too late now to revisit the group's decision for the first version.