W3C home > Mailing lists > Public > public-media-fragment@w3.org > May 2009

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

From: Yves Lafon <ylafon@w3.org>
Date: Fri, 8 May 2009 13:29:51 -0400 (EDT)
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
cc: Media Fragment <public-media-fragment@w3.org>
Message-ID: <alpine.DEB.1.10.0905081329320.23321@wnl.j3.bet>
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.

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

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