Re: Fwd: [whatwg] <video>/<audio> feedback

On Sat, 9 May 2009, Silvia Pfeiffer wrote:

> Hi all,
>
> On the HTML5 WHATWG mailing list, we are having a discussion about
> including or excluding context upon display of media fragments,
> similar to what we have been discussing while getting to
> http://www.w3.org/2008/WebVideo/Fragments/wiki/Issues#In-context_.2F_Out-of-context
> ..
>
> Conrad and David have made the suggestion to give "?" another role in
> the media fragment retrieval process. If one uses "#" to retrieve a
> fragment, one expects to see the full video timeling and the retrieved
> piece is only a small part of it. If one uses "?" to retrieve a
> fragment, a new resource is created and that resource needs to get the
> focus, i.e. when it is displayed, it should display none of the
> context but only the timeline of the new resource.

Remember that a client can't impose the URI syntax to the server...

>
> I wanted to take that discussion back into here, since FAIK we haven't
> made a decision yet on how to separate "?" from "#".
>
> I like the suggestion.
>
> Cheers,
> Silvia.
>
>
> ---------- Forwarded message ----------
> From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> Date: Sat, May 9, 2009 at 12:14 AM
> Subject: Re: [whatwg] <video>/<audio> feedback
>
>
>
> On Fri, May 8, 2009 at 9:47 AM, Conrad Parker <conrad@metadecks.org> wrote:
>> 2009/5/8 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
>>> On Fri, May 8, 2009 at 5:04 AM, David Singer <singer@apple.com> wrote:
>>>> At 8:39  +0200 5/05/09, KÞi?tof Îelechovski wrote:
>>>>>
>>>>> If the author wants to show only a sample of a resource and not the full
>>>>> resource, I think she does it on purpose.  It is not clear why it is vital
>>>>> for the viewer to have an _obvious_ way to view the whole resource
>>>>> instead;
>>>>> if it were the case, the author would provide for this.
>>>>> IMHO,
>>>>> Chris
>>>>
>>>> It depends critically on what you think the semantics of the fragment are.
>>>>  In HTML (the best analogy I can think of), the web page is not trimmed or
>>>> edited in any way -- you are merely directed to one section of it.
>>>
>>> There are critical differences between HTML and video, such that this
>>> analogy has never worked well.
>>>
>>>
>>>> I am also aware that browsers that don't implement fragments will also show
>>>> the whole resource;  so authors can't rely on he trimming.
>>>
>>> This is not a standardisation problem, but an adoption problem. In a
>>> transition phase there may be user agents that cannot deal with
>>> fragments, but ultimately that will not be the case any more.
>>>
>>>
>>>> Given both of these, I tend towards using # as a focus of attention;  if
>>>> trimming is desired, the server should probably do it (maybe using ?).
>>>
>>> Just making sure I understand your suggestion correctly: I assume you
>>> are saying that both # and ? would be able to only deliver the data
>>> fragment that relates to the given specified temporal fragment, but
>>> you are suggesting that by using "#" the user agent is being told to
>>> present the context, while by using "?" the user agent would focus
>>> attention on the fragment only. Is that what you're saying or am I
>>> misunderstanding?
>>>
>>> I'm asking because that has not been the consensus in the media
>>> fragments WG as of today and if there is a discussion to be had, we
>>> should take this back to the mf WG. It is an interesting view and has
>>> actual technical implications - e.g. "#" could deliver the raw data
>>> without requiring an adapted container since it could be assumed that
>>> the core decoding environment is already set up - an adapted container
>>> is however required in the "?" case since the "?" creates a new
>>> resource.
>>
>> by an "adapted container" do you mean something like Ogg Skeleton, ie.
>> a video container that records the desired in/out points?
>
> Yes - as and where necessary.
>
>
>> I agree with David's suggestion, as I understand it in the context of
>> HTML5: the UA may present the context of media segments that use '#'
>> and '?' syntax differently.
>
> Understood.
>
> Right now, the WG has defined that "There should be a way to get the
> context of the fragment through an out-of band measure for
> applications, and a simple change of the URI for users."
> (http://www.w3.org/2008/WebVideo/Fragments/wiki/Issues#In-context_.2F_Out-of-context)
>
> How we are proposing to do that has not been defined FAIK.
>
> We need to take this suggestion back as an option for having the user
> agent decide on whether to display the context or not.
>
> I quite like the idea that a media fragment that was requested with
> the query "?" in the URI displays a focus on the fragment. It makes
> sense since it is a new resource anyway by definition.
> A ""#" specified media fragment however is really only pointing at a
> subpart of a resource, so it would make sense to present the context,
> also making the user experience closer to the HTML fragment user
> experience.
>
>
>> However I don't think this should change how we do data transport (ie.
>> the HTTP and the media container). I'd suggest that the scope that
>> should be covered in HTML5 is to suggest how much seek bar should be
>> displayed for the video.
>
> If the URI specifies which display mechanism to choose, it will not be
> necessary to add anything to HTML5 for it.
>
>> However when the user navigates on that seek
>> bar (by clicking on a random position), the UA may use whatever means
>> are appropriate for the media type [as suggested by the media
>> fragments wg] in order to retrieve that data.
>
> Yes, that section is still in flux. We could well define that if we
> use "#" to retrieve fragments and include the context, it makes sense
> to require from the user agent only to receive the container & codec
> setup information once, while consecutive fragment retrievals on the
> same resource will only need the decodable data byte range. If I'm not
> mistaken, this is the way in which seeking is currently implemented in
> Firefox for the video element with Ogg Theora. "Header" type
> information is not transmitted each time a seek is undertaken. For
> other container/codec formats this may not be possible in this way,
> but similar bandwidth-saving suggestions can be made.
>
>
> Cheers,
> Silvia.
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Friday, 8 May 2009 17:30:01 UTC