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

On Fri, 08 May 2009 16:19:57 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> 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.

Does the Media Fragments WG really need to concern itself with how an UA  
handles "#"? While I certainly agree that it makes the most sense for the  
full context to be visible, the spec shouldn't need to say anything about  
it  as even the HTML5 spec says next to nothing about how time is  
represented visually.

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

I agree that the difference between queries and fragment identifiers  
should be clarified if it could be confusing, perhaps as non-normative  
text in the spec (or elsewhere).

Philip

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



-- 
Philip Jägenstedt
Opera Software

Received on Friday, 8 May 2009 14:30:49 UTC