action 217

I finally reviewed the error-semantics section that Davy edited. Here's my comments:

- somewhat unrelated: section 6.1.2, second bullet, states "e < 0", shouldn't this be "e >= 0"? Or "e > 0"?

- somewhat unrelated: all of section 6 uses "play from x to y", play from x until y" and various other wordings. I would suggest using a single phrase, and in the preamble of the section defining what is meant by it (i.e. whether the final frame is played or not).

- somewhat unrelated: ccording to section 6.1.2, bullets 5 and 6, we don't allow zero-sized media resources (spatially). Is that indeed correct?

- somewhat unrelated: the spatial cases also don't state whether the right and bottom pixels are part of the displayed image.

- t=a, is missing. The discussion has gone back-and-forth so often that I now no longer know whether it's legal (in which case it should go into 6.1.2) or illegal (it should go into 6.2.2).

- 6.3.2, third bullet, defines what happens in case of mismatched smpte timecode in the URI and the resource. However, it is nowhere stated what happens in case the timecode formats do match. In addition, it also isn't specified what happens. Actually, IIRC we said that SMPTE timecode could only be applied to media containers that actually record timecodes, but the phrasing here suggest that having the right framerate is enough. Is this correct? If we indeed want timecodes in the media we need two errors cases here" smpte applied to media without timecodes and smpte-mismatch.

- 6.3.2 for smpte we have additional error cases, such a<s and b<s and various combinations (because smpte timecodes don't have to be zero-based).

- 6.3.2 In addition, smpte timecodes don't have to be contiguous, and don't even have to be monotonically increasing. Finding all possible corner cases is going to be hell, my suggestion is that we simply say that in case of media items with non-monotonically-increasing timecodes the outcome is undefined. MF 2.0 can worry about it if needed.

- 6.3.3 what about spatial dimensions that are partially valid, i.e. the underlying video item switches resolution half way through?

- 6.3.4 just realised that there are some media containers (quicktime, notably) where tracks aren't valid for all temporal ranges, i.e. tracks can come and go. In this case, will all available tracks be known at the time the headers of the media have been received? Dave?

- 6.3.4 it we allow for tracks that don't extend over the whole media duration, how about applying track=track1&t=10,20 to a media item where there is no overlap between the given track and the time range?

- 6.3.5 we should explicitly state what happens if you apply a chapter MF to a media format that doesn't support chaptering.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman

Received on Tuesday, 14 June 2011 20:33:22 UTC