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

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 9 May 2009 00:19:57 +1000
Message-ID: <2c0e02830905080719x5d0f9b5fi459d7fa927c59892@mail.gmail.com>
To: Media Fragment <public-media-fragment@w3.org>
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

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.

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.


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


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

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

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

Received on Friday, 8 May 2009 14:20:54 UTC

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