Re: Review of use cases and requirements

On Thu, Nov 13, 2008 at 12:28 AM, Guillaume Olivrin
<golivrin@meraka.org.za> wrote:
>
> Dear Jack and all,
>
> On Wed, 2008-11-12 at 11:04 +0100, Jack Jansen wrote:
>> Browsing media:
>> Scenario 1: I think a logical pagination here would make a more
>> powerful example, so could "20 minutes" be replaced by something like
>> topics?
>
>> Scenario 2: again, logical splitting may be more powerful. Daisy
>> books, for example, allow jumping by chapter, section, paragraph,
>> sentence.
>
> 'Logical splitting' is inherent to the media itself (i.e. if the media
> is structured as a document, as in "a video document" which would rarely
> be the case). In fact "logical splitting" is more the issue of "track
> addressing".

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


> Still I think you've got a point Jack : maybe we could capture what I
> would call "Editorial Splitting" as new scenarios for the 'Browsing
> media' use-case.

I agree - I think we need to add more use cases. I shall give it a try.


> "Editorial splitting" is a more high level view (hence a good use
> case) of the task of splitting timewise. The scenario consists in
> giving an interesting name to a time. Let's not confuse the issue of
> "naming anchors" VS the issue of "named anchors in media".
>
> For me, giving a "pretty editorial even logical" name to a timestamp
> would just be a supplementary parameter passed in the URL syntax whether
> or not we decide to support "named anchors in media types".
>
> Examples (schematically) :
>
> Time splitting:
> video?time=T0545+0405
>
> Logical splitting:
> video?track=Chapter1

possibly better as video?time=Chapter1 or video?name=Chapter1


> Editorial splitting:
> video?time=T0545+0405&name=Down%20The%20Rabit%20Hole
> - if Media doesn't supported named anchors then we just gave an
> Editorial Name to this time-place in the Media

this is an interesting use case that I haven't even though of yet:
using URIs to do editing of the media resource, such as associating a
name with a time anchor. Is this something we'd like to add or is it
out of scope?


> * video?name=Down%20The%20Rabit%20Hole
> - if supported i.e. the Media has Named Anchors (such as in specially
> compiled Flash) then we don't need to specify the time, although it
> would probably be advisable

I think it is more advisable to only use one addressing scheme at a
time - otherwise what do you expect the server to do in case of
conflict? What if the time given and the name given point to different
time offsets? What do you return?


>> Recompositing media fragments:
>> This section I have the most problems with. For all of these I would
>> *not* use url fragments, but in stead use SMIL (also for scenario 1
>> and 4: SMIL tiny was done specifically for playlists). There's
> little
>> added value in using url fragments here: the UA will have to
> implement
>> (part of) the work anyway, so I see little advantage in specifying
>>      < video src="http://example.com/myvideo.ogg#t=20-30"/>
>> over
>>      <video src="http://example.com/myvideo.ogg" clipBegin="20"
>> clipEnd="30"/>
>> Same for spatial clipping.
>>
> One instance has no context (URI-FRAG) the other instance has context
> (SMIL clip start/end).
> Confusing but then what happens if
> < video src="http://example.com/myvideo.ogg#t=20-30"/ clipBegin="20"
> clipEnd="30">
> this has added value as I see it (preserve context or not yet still
> navigate or structure with SMIL). So I'd keep the use case as something
> desirable and to show MediaFrag-URI and SMIL interaction.

I agree. It's what I tried clumsily to explain in my last email. This
combined use of time in the video tag needs to be explaind though. I'd
specify that clipBegin and clipEnd still refer to the original
timeline, i.e. if you wanted to retrieve #t=20-30, you could still
locally specify to only use clipBegin="22" to clipEnd="28" if that was
what you needed.

Cheers,
Silvia.

Received on Wednesday, 12 November 2008 18:01:56 UTC