RE: Squid experts

Hi Silvia, all,

>-----Original Message-----
>From: public-media-fragment-request@w3.org [mailto:public-media-
>fragment-request@w3.org] On Behalf Of Silvia Pfeiffer
>Sent: Saturday, November 01, 2008 10:04 AM
>To: Media Fragment
>Subject: Squid experts
>
>
>Hi all,
>
>I had a discussion with a squid expert and wanted to share some of the
>points that were made.
>
>First, they asked why we didn't have a squid expert in the group,
>since this seems to be such a difficult topic to get right. If
>somebody in the squid community would be interested, would we want
>them to join?
>
>One technical point that was made is that doing time ranges in proxies
>may be really difficult since time is inherently continuous and so the
>continuation from e.g. second 5 to second 6 may not easily be storable
>in a 2-way handshake in the proxy.
>
>Instead there was a suggestion to create a codec-independent media
>resource description format that would be a companion format for media
>resources and could be downloaded by a Web client before asking for
>any media content. With that, the Web client would easily be able to
>construct byte range requests from time range requests and could thus
>fully control the download. This would also mean that Web proxies
>would not require any changes. It's an interesting idea and I would
>want to discuss this in particular with Davy. Can such a format
>represent all of the following structural elements of a media
>resource:
>* time fragments
>* spatial fragments
>* tracks
>* named fragments.

You can compare the above described approach with the RTSP protocol (btw., I
added some information on the wiki regarding an RTSP implementation for
media fragments [1]). In RTSP, the client first sends a DESCRIBE message, in
order to receive a description of the requested media resource (typically
using SDP). Such a description contains information about the available
tracks and the coding format they use. However, no information regarding
time, spatial, or named fragments is available in this context. The idea to
first send a description of the requested media resource to the client could
work for us. However, there are some important issues that need to be taken
into account. 

I think that our model for multimedia bitstreams is one example of such a
codec-independent media resource description format. For the moment, this
model supports time and spatial fragments and could be easily extended to
support tracks and named fragments. Hence, the answer to the question
whether such a description format could represent tracks, time, spatial, and
named fragments is yes. However, there are some requirements for this
statement. Such formats are only able to describe these structural elements
if the underlying multimedia bitstream allows to describe these elements on
a high level, i.e., if these structures are addressable in terms of bits and
bytes. Let me give an example. Consider an image containing a Region of
Interest (ROI) and we want to describe this ROI (i.e., spatial fragment)
with our description format. If the image is encoded with JPEG2000 and the
encoding parameters were tweaked to support the extraction of the ROI, then
it is perfectly possible to describe the ROI on a high level using the
description format. However, if the image was encoded with JPEG, it is
impossible to address the ROI in terms of bytes (because JPEG does not allow
ROI extraction in the compressed domain). Hence, with JPEG images, the
solution with the description format will fail. What we need to remember
here is that codec-independent media resource description (and also
adaptation) is a very nice and elegant technique to tackle the coding format
heterogeneity, but it only works if the media resources are prepared for
this approach. More specifically, the media resources should support the
addressing of structural elements such as tracks, time, spatial, and named
fragments in terms of bits and bytes so that extraction of these fragments
can occur in the compressed domain. Specially for spatial fragments, this
could be a big issue.

Another issue regarding codec-independent media resource descriptions is
their overhead in terms of file size. Until now, these descriptions were
represented in XML (and recently RDF in case of our model). In our test
cases, these descriptions introduced an overhead of 6-10% of the size of the
media resource. You could solve this issue by compressing the descriptions,
but they need to be uncompressed at client side anyway (specially for mobile
devices, this could be a problem). Another possibility is to define a binary
description format. 

[1] http://www.w3.org/2008/WebVideo/Fragments/wiki/RTSP_implementation

Best regards,

Davy

-- 
Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems Multimedia Lab
URL: http://multimedialab.elis.ugent.be

Received on Saturday, 1 November 2008 10:46:04 UTC