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

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

From: Conrad Parker <conrad@metadecks.org>
Date: Sat, 9 May 2009 09:02:21 +0900
Message-ID: <dba6c0830905081702x5dd64be9r43c87c36d80b050@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: Media Fragment <public-media-fragment@w3.org>
2009/5/9 Yves Lafon <ylafon@w3.org>:
> 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...

If the server has already told the client that it understands a
particular syntax, then the client can use that syntax.

Conrad.

>
>>
>> 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 Saturday, 9 May 2009 00:03:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:33 GMT