W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2008

Re: Squid experts

From: Yves Lafon <ylafon@w3.org>
Date: Thu, 6 Nov 2008 08:44:16 -0500 (EST)
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
cc: Media Fragment <public-media-fragment@w3.org>
Message-ID: <Pine.LNX.4.64.0811060831010.25861@ubzre.j3.bet>

On Thu, 6 Nov 2008, Silvia Pfeiffer wrote:

> On Thu, Nov 6, 2008 at 9:20 PM, Yves Lafon <ylafon@w3.org> wrote:
>> On Thu, 6 Nov 2008, Silvia Pfeiffer wrote:
>>
>>> So where 5s ends is a question about making intervals inclusive or
>>> exclusive. Let's go with your understanding. The problem still exists.
>>> Let me try and explain. Also note that we are talking about Web
>>> proxies that do not have the full media resource at hand, while a Web
>>> server that has the full media resource at hand has no such issues.
>>>
>>> So let's assume two temporal fragment URIS. One asks for seconds 1-6
>>> and the next one asks for 6-12. The Web proxy is only give a
>>> colleciton of bytes and told which time segment these map to. It does
>>> not know which byte offset in the original file the map to. Now, we
>>> cannot be sure that the end of 1-6 is exactly before the beginning of
>>> 6-12. There may well be an overlap of bytes in between ending 1-6 and
>>> beginning 6-12, because we deal with the compressed domain and
>>> continuous time. In fact, I would be surprised if there is not an
>>> overlap in bytes by at least one codec packet. This tells us that only
>>> the bytes are uniquely identified, while time is not uniquely
>>> identifyable. This means we have to store not just time in the Web
>>> proxy, but also the mapping to bytes. With the 2-way handshake, I do
>>> not think this is possible (but please correct me if I'm wrong).
>>
>> That is the thing I don't understand, why is it mandatory to have the
>> mapping to bytes? You request fragment 1-6s, you get a fully playable video
>> with this time range (and it may be 0.5s 6.5s). Now you get fragment 6 to
>> 10s, you get once again a fully playable video with this new time range
>> (once again it may even overlap to 5.5 -> 10.5s).
>
> OK, so are you saying that because it overlaps, we can identify the
> bytes that are identical and thus align the ranges? Isn't that asking
> a bit much of the proxy? What if it gets it wrong and identifies the
> overlap at the wrong byte?

Well, if it is a proxy/cache specialized in video content, it's definitely 
not asking for too much; and if the proxy can't do the merge, it's quite 
likely that a client won't be able to do it as well.

> What I'm trying to say is that time is not sufficient. You need to
> identify the exact byte number of the original media resource to say
> with absolute authority where you are up to.

byte number? frame number? decimal seconds?

>> Of course a blind proxy won't be able to do anything with it, but that's not
>> the point. It should know that it's a video, how to navigate from frame to
>> frame, align and merge, then recreate a container around the compressed
>> content (as well as being able to act as a first class server when a client
>> request a time range between the cached time range). No byte offset involved
>> there.
>
> I think the aligning bit is asking a bit much, in particular if we
> expect the proxies to do this for any type of media format. However,
> this is where I think we should write it down in detail and ask the
> squid guys. :-)

Well there are proxies that will _never_ merge big content, even if it is 
byte ranges, so easy to do. In some case asking for the upstream the whole 
content, cache that and server from it fragments is easier to code. This 
can be done as well by proxy/caches in the case of video (but once again 
to extract time ranges, you must know the format, that is an absolute 
precondition :) )

>> Now if you want to have, on top of time ranges, the possibility of using
>> byte ranges as well, then ok, you need to pass the information along, but it
>> means you are starting to mix apples and oranges.
>
> No, I don't think so. Bytes are always authoritative. Time or spatial
> region is just an "annotation", a "label" on a byte or byte range. In
> fact, when you read the SMPTE time specification (and
> http://en.wikipedia.org/wiki/SMPTE_time_code is making a pretty good
> point of it) it actually mentions that Time Codes are just labels and
> may not be 100% accurate (well, in the analog days for different
> reasons to the digital days). I think you can only calculate with the
> apples (bytes) and not with the oranges (time). However, if we always
> provide the bytes with the time regions, we should be safe.
>
> I hope I'm being clearer now.
>
> Cheers,
> Silvia.
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves
Received on Thursday, 6 November 2008 13:44:26 GMT

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