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

Re: Review of section 7

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 14 Apr 2009 23:52:14 +1000
Message-ID: <2c0e02830904140652x40dbb9a6ia424b2d141982925@mail.gmail.com>
To: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Cc: Media Fragment <public-media-fragment@w3.org>
Hi Raphael,

2009/4/14 RaphaŽl Troncy <Raphael.Troncy@cwi.nl>:
>> * we need to mention that the replies are not cachable for the full
>> resource, but cache only the fragmented resource, which can result in
>> n copies of some subset of the resource in caching web proxies. Since
>> it is typically expected that a fragment request will be used
>> repeatedly (e.g. a fragment URI being shared around), this is
>> potentially acceptable. But we have no experimental data to confirm or
>> deny that this may pose a challenge to caching web proxies.
> The section 7.3, discussion is meant to contains such information. Is that
> not captured yet?

I wasn't able to clearly read that out of 7.3. I found 7.3 really
messy and un-readable, which is why I suggested to split it up and add
it to 7.1 and 7.2.

>> * further we need to mention that there are encapsulation formats
>> (such as MP4) that have an index in their headers that can provide a
>> seconds->byte mapping for any offset. For such cases, an optimisation
>> is possible where a client retrieves the index part of the media file
>> first and then uses that to make byte range requests rather than time
>> range requests. These requests are cachable by any caching Web proxy
>> without replication for differing fragment requests. This is in fact a
>> third means of retrieving fragment URIs, which we might want to make
>> explicit as a section 7.3.
> Yes, this is what it is written (in a one line summary :-) in 7.3, point 3
> of the pros.

That is not the way in which I read 7.3. But ok, if that's what it is
supposed to mean. Though, I don't see the relationship between the
index in the header being an advantage to the 1-step GET, since it
also works for the 2-set GET.

>> Section 7.2
>> Even though this section is taking a different approach to temporal
>> URIs, it still follows the basic principles of temporal URIs (as
>> described in
>> http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html#anchor6).
>> I therefore have some change requests to this section, since it is not
>> quite consistent as it is.
> Should we put a reference here to the temporal URIs spec?

Maybe ... but I don't think that's necessary, because it may just
confuse people. There are differences and they are quite substantial.

>> † †Example:
>> † †HTTP/1.1 200 OK
>> † †Date: Fri Feb 11 14:47:12 EST 2005
>> † †Server: Apache/2.0(Unix)
>> † †Content-Type: video/mp4
>> † †Location: http://example.com/fragf2f.mp4
>> † †X-Range-Redirect: bytes=1113724-2082711
>> † †Vary: X-Accept-Range-Redirect
>> † †X-Accept-TimeURI: npt, smpte-25
>> † †Message body: control section of fragf2f.mp4#12,21 (if required)
> I have modified both:
> †- http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_implementation and
> †- http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/
> Could you please check it is right now?

Yes, I think so (apart from a "is" where there should be an "it", but
that's minor). I think the F2F will discuss this through again and fix
any further issues. :-)

>> * can somebody clarify why "2-way handshake allows to extract a
>> spatial region from a Motion JPEG2000" while 4-way does not? I don't
>> understand the reasoning behind this.
> Does
> http://lists.w3.org/Archives/Public/public-media-fragment/2009Mar/0055.html
> (and the whole thread) satisfy you?

That's not the point. This document should be self-contained and not
require to go back to an email conversation. We need to include the
reasoning into the document. And no, I am unclear even from the email
discussion why it would be a problem.

>> * can somebody clairfy why "2-way handshake achieves what we want
>> without needing HTTP protocol extension"? I think that both, 2-way and
>> 4-way require a protocol extension - at minimum they require the
>> creation of new range types.
> I think it meant that, yes, we need to create new range unit, but no new
> headers in the case of the single-step partial GET.

Some of the headers are actually helpful for both alternatives. But
ok, if we regard the addition of a header as a protocol extension,
that's fine. Adding a header is actually very cheap, while adding a
new range type is rather expensive.

>> Also, I would suggest creating
>> Accept-TimeURI, Accept-SpaceURI, Accept-TrackURI and Accept-NameURI
>> headers such that the server can indicate to the client whether it is
>> indeed capable of returning fragments and which type. (we could
>> certainly turn this into a singe "Accept-FragmentURI:
>> time,space,track,name" header, but then we cannot communicate which
>> types of headers are supported).
> Thanks for this suggestion: I put it on the agenda for the f2f meeting,
> first slot hour when we will discuss the single-step and dual-step partial
> GET (aka, 2-ways, 4-ways handshakes :-)

Cool. I think there is lots to discuss. :)

>> Section 7.3, third paragraph (starting "Using HTTP byte ranges...")
>> I do not understand this paragraph and I think it is fundamentally
>> wrong. I think there is a misunderstanding for the 4-way handshake
>> between how to handle the control section that is non-cachable and
>> transferred in the first GET action, and how to handle the data
>> section which is transferred in the second GET action. All the data
>> that is transferred in the second GET action is simply a byte range
>> request on the original resource, which means it can be stored in the
>> exact same way in which existing caching Web proxies store byte range
>> requests, so there is no extra implementation cost. The control
>> section is generally small and is returned with the first GET action.
>> Indeed, there are not an infinite number of resources created in this
>> way, but exactly only one in the proxies. This is a big advantage of
>> the 4-way handshake and not a disadvantage.
>> Of course the whole idea of caching and reducing bandwidth use falls
>> down when we need to transcode media resources. Those are never
>> cachable other than for the exact same fragment URI. For those, the
>> 2-way handshake is probably more appropriate.
> Hum, I think the paragraph in the document says the same thing than your
> †explanation above, or at least, I don't see the contradiction. But I
> acknowledge as well that the whole story of caching these media fragments
> and the exact role of the proxies is still heavily discussed within the
> group. I would suggest to wait for our discussion during the next f2f
> meeting before doing more changes.

Yeah, I think we need a lot more images and detailed specifications on
these, maybe even implementations. Looking forward to the f2f sorting
through some of this!

Received on Tuesday, 14 April 2009 13:53:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:42 UTC