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

RE: video use-case

From: Hausenblas, Michael <michael.hausenblas@joanneum.at>
Date: Mon, 6 Oct 2008 12:19:19 +0200
Message-ID: <768DACDC356ED04EA1F1130F97D29852018F5E3F@RZJC2EX.jr1.local>
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: Yannick Priť <yannick.prie@liris.cnrs.fr>, "Media Fragment" <public-media-fragment@w3.org>, "Jack Jansen" <Jack.Jansen@cwi.nl>

Silvia, I guess you are basically right.

For some background reading see also [1] and the appendix of [2] (Diagram of the Web's Retrieval Algorithm) is also utterly useful. Please note that I've added these two references to [3], already ;)


[1] http://www.w3.org/DesignIssues/Fragment.html
[2] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
[3] http://www.w3.org/2008/WebVideo/Fragments/wiki/State_of_the_Art

 Dr. Michael Hausenblas
 Institute of Information Systems & Information Management
 JOANNEUM RESEARCH Forschungsgesellschaft mbH

>-----Original Message-----
>From: public-media-fragment-request@w3.org 
>[mailto:public-media-fragment-request@w3.org] On Behalf Of 
>Silvia Pfeiffer
>Sent: Monday, October 06, 2008 12:04 PM
>To: Jack Jansen
>Cc: Yannick Priť; Media Fragment
>Subject: Re: video use-case
>Hi Jack,
>On Thu, Oct 2, 2008 at 8:43 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>> On  1-Oct-2008, at 23:13 , Yannick Priť wrote:
>> I can consider a fragment of a video as a fragment of a 
>video. In that case
>> it begins at 30s, I can explicitly manipulate both the 
>fragment and the
>> video (e.g. jump to a frame before the fragment beginning, 
>let's say at
>> 20s).
>> This is, in my view, a completely different issue. I tend to 
>think of this
>> as referring to the fragment "in context", whereas the 
>previous use case was
>> referring to the fragment "out of context". But: these are 
>terms we're using
>> internally, if anyone has better/official terms: please let me know.
>> An analogy outside of the video domain (where we actually 
>first started
>> considering this) is digital talking books for the blind. 
>Think of an audio
>> file with markers that index into an accompanying HTML 
>document. While
>> playing the audio fragment you want to render the corresponding text.
>> However, the interpretation of "text.html#id12345" depends 
>on how you are
>> going to render it:
>> 1) If you're sending it to a braille display you want only 
>the content of
>> the node referred to by the ID, and show that on the braille display.
>> 2) If you are sending it to a normal display (for people 
>with limited vision
>> or dyslexia) you want to render the whole page and only 
>scroll/highlight the
>> selected area.
>> The first use case is out-of-context, the second in-context. 
>Often, as in
>> this example, the choice can only be made by the user agent. 
>And making the
>> wrong choice either leads to horrible inefficiency 
>(architecture providing 2
>> when 1 is needed) or a really bad user experience 
>(architecture providing
>> only 2 when 1 is needed).
>That's a very interesting example.
>My understanding of the URI RFC (now at
>http://www.ietf.org/rfc/rfc3986.txt) is that a fragment is a secondary
>resource that is addressed through the primary resource. For something
>like http://www.example.com/text.html#id12345 the primary resource is
>a html page. Seeing as the URI RFC states that the fragment is not
>being communicated to the Web server, but only handled within the UA,
>this request will always mean that a Web server will return the full
>html page and the UA has to do something with the fragment.
>So, the only way in which I can see this working is that the UA
>displays full-context for a screen display (as is customary), but when
>dealing with braille it strips out only the relevant part. Is that how
>it works?
>I'm asking this because with media we cannot work in this way, since
>we may not want the full video to download to the UA in order to apply
>the fragment offset. This is the reason why we were not able to use
>the "#" URI fragment for specifying temporal URIs, but had to use the
>"?" URI query mechanism.
Received on Monday, 6 October 2008 10:21:21 UTC

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