W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2008

Re: Review of use cases and requirements

From: Guillaume Olivrin <golivrin@meraka.org.za>
Date: Tue, 18 Nov 2008 10:16:17 +0200
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Media Fragment <public-media-fragment@w3.org>
Message-Id: <1226996177.5690.63.camel@video-lab>

Hi Silvia,

> "Track" has a well-defined meaning in media: a media file can have
> multiple alternative or additive audio tracks, multiple alternative
> video tracks, caption tracks and other timed text tracks. So, tracks
> segment the video into different data types over the whole duration of
> the video.
> When we are talking about "logical splitting" here, the segmentation
> happens along the timeline into time intervals and these intervals are
> given names. So, the logical splitting is really a temporal fragment
> addressing with character labels instead of time markers. Let's not
> use the word "track" for that.

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

> possibly better as video?time=Chapter1 or video?name=Chapter1
What about video?segment=Chapter1 ?

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

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.

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
or more generically (is there a standard or good way to do this?)

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.

Received on Tuesday, 18 November 2008 08:17:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:41 UTC