Re: Review of use cases and requirements

Hi Silvia,

> Yes, I think we are always implicitly dealing with intervals, even if
> just a time stamp is given.
Thanks, I think this short statement clarifies all things we discussed
so far.


> 
> > - Implicitly, if we only have one time-stamp in the URI then the time
> > interval is the time span between the specified time stamp and the next
> > occurring one?
> 
> Or until the end of the file, I would say.
This would be the default behaviour, I agree entirely.

> 
> > - Explicitly, if a named interval, then a named interval would define
> > two time stamps, one for the beginning of the interval and one its End
> > marker. But where would this definition occur, in the URI?
> 
> No, it is implicit to the media resource. It comes from some
> annotation, e.g. cue ranges. And it maps to a time interval, e.g.
> #t=5s-15s . We'd need to further look into this once standard
> annotation structures are defined for video, I think. At the moment,
> this is a little random, I agree. In CMML it was clearly defined - and
> it would be for TimedText and SMIL, too. But everything else would be
> difficult to make to named segments.
I understand how CMML has a way to define these cue ranges and actually,
most captioning formats in fact do that : naming cue ranges. So the
mechanism for naming ranges already exist although it wasn't though of
as a way of addressing named ranges into media.

> 
> 
> >> possibly better as video?time=Chapter1 or video?name=Chapter1
> > What about video?segment=Chapter1 ?
> 
> If you prefer the word "segment" over "name", then I don't see a
> difference - that's fine.
> 
> 
> > Segments have two basic properties that would make it desirable to have
> > them separate in the syntax:
> > a. if the media supports it, 'segments' unlike 'name' or 'time' may
> > refer directly to the structure of the media (Key frames, blocks) and
> > hence yield direct byte ranges.
> 
> That means you are referring to a codec-specific encoding entity. I
> don't see this desirable.
This is probably the case and it's good you pulled the safety net before
I hit the codec.

> In any case, I think this is academic and of little practical use. If
> I see a media resource on the Web and want to address a time range
> into it, I am not going to try and understand its physical encoding
> packets/blocks just to find the closest keyframe to the time range I
> am interested in. I cannot really see a practical use case in
> addressing encoding units. But please correct me if I'm wrong.
The main use case is to select time ranges and even space ranges as
accurately as possible. I presume that if I ask a specific time range,
what I would receive in return would always be some sort of a
self-contained media fragment well rounded to the closest codec logical
block. So yes: we could overlook the whole packet/block business because
we want high level usage and leave the work to the server and client to
agree on something. On the other hand, the user, via the URL, might want
a little bit more control over what he is asking for/retrieving. He
might like to have a more determinist behaviour by linking right to the
specific keyframe if he knows that's it's there in the media. 

We don't want to bother with codec particularities but it may be good to
recognise that all codecs tend to use blocks and that those constitute
the more general self-contained units. 


> 
> This was more what I was talking about - apart from having
> hierarchical subdivisions. I was simply talking about identifier of
> time ranges - often related to e.g. a piece of text, such as a piece
> of caption text that has an identifier. If this identifier was
> "chaper_1_section_2_sentence_5", then my suggestion for addressing
> that as above would be video?name=chaper_1_section_2_sentence_5
> (however, using "segment" as parameter name is ok, too).
Agree, this refers back to the earlier case of naming time ranges. The
naming of time ranges may be made to occur as caption text and it would
be desirable to address these (use them as some sort of anchors).



Nice conclusion ==>

> > To conclude:

> tracks will work for addressing if we can server-side extract them (as
> byte ranges).

> segments (names) will work for addressing if a media resource has a
> mean of attaching names to time segments.


> BTW: None of the two will in the general case create one single byte
> range. Both will need multi-byte-ranges are a reply to that media
> fragement query.

> That said, I do agree with the need for both.

> At this time, however, I think we may be better off focusing on
> solving the "time" use case and getting our first draft out this
> month. That's what our mandate is, right?

Yes absolutely : Time is of the essence !

> 
> Cheers,
> Silvia.
>

Received on Tuesday, 18 November 2008 14:37:23 UTC