Re: Squid experts

Hi Davy,

That's a very clear statement on the possibilities of a abstract model
of the structure-to-binary relationships of compressed media
resources. I think you may be right and it's not easily possible, if
not impossible, to do with all media types - even though
multi-byte-ranges may help for some of them. Whether that's a killer
for this approach, or whether we could still suggest this approach as
an optimisation in certain cases, I don't know.

Which formats did you find so far it was possible to gain a structure
about? I can certainly say for Ogg that time fragments, tracks and
named fragments when using CMML are all possible. For spatial
fragments, I am not so sure - I'd think rather not...

Cheers,
Silvia.

On Sat, Nov 1, 2008 at 9:45 PM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
> 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 11:00:55 UTC