Re: Review of use cases and requirements

Hi Guillaume,

On Tue, Nov 18, 2008 at 7:16 PM, Guillaume Olivrin
<golivrin@meraka.org.za> wrote:
> Hi Silvia,
>
>> a temporal fragment addressing with character labels
> I understand. A time-stamp could be character based or a logical hash.
>
>
>> and these intervals are given names.
> So Media Fragment URI must be able to define intervals, not just
> position in a media?

Yes, I think we are always implicitly dealing with intervals, even if
just a time stamp is given.

> - 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.

> - 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.


>> 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.


> b. segments are more hierarchical in nature and as opposed to name and
> time, they represent time ranges (selections) rather than positions on
> the time line.

You don't need to go down to the codec level to get time ranges. You
can use time fragment URIs for that.


> The most basic way of addressing logical segments would be to use a
> sequence number:
> (1) video?segment=2 (that might be Chapter 1 for all we know)
> which may depend on the track (or not)
> (2 ambiguous) video?track=3&segment=2
> (3 ambiguous) video?segment=2&track=3
> would examples 1, 2 and 3 yield the same time selections ? It's hard to
> tell. If we would want to keep the syntax commutative, then segment and
> track might have to appear as one parameter (not two in the URI). That's
> only why I was 'confusing' the two as a mode of addressing although they
> are logically separate in nature, they depend on each other.

2 and 3 should/must provide the same result. 1 would probably be
different because your segment number could turn up in each track - it
may not even be unique in this case. So, either you define a segment
number to be unique over tracks - in which case you will not need to
specify the track - or you define it only unique within the track - in
which case you will always need to specify the track.

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.


> If the media supports it (some do), addressing logical segments
> hierarchically (Chapter 1 Section 2 VS entire Chapter 1) will have to be
> encoded in a standard way in the URI syntax
> video?segment=C1S2
> or more generically (is there a standard or good way to do this?)
> video?segment=1-2

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).


> To conclude:
> It seems that 'track' and 'segment' are practical to have as media
> fragments because they provide other ways of getting interesting ranges
> of bytes from media. One consequence though is that by extracting the
> media 'tracks' independently we might change the nature of the media
> itself whereas with segments we might still have a chance to preserve an
> integral media fragment of the primary resource and extract with
> benefits well defined byte ranges boundaries.

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?

Cheers,
Silvia.

Received on Tuesday, 18 November 2008 10:33:28 UTC