Re: Squid experts

Hi Davy, all,


On Sun, Nov 2, 2008 at 8:52 AM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
> If we want to support caching of media fragments without modifying the
> existing Web caches and proxies, then this will only work under the
> following circumstances (and suppose multi-byte-ranges are possible):
> 1) the media fragments can be extracted in the compressed domain
> 2) no syntax element modifications in the bitstream are needed to perform
> the extraction

I think this is a general condition on all media types for which we
want to deliver fragments. Some formats are capable of delivering
fragments, others aren't. It will be good for us to deliver a table at
the end of our work with the list of formats which we see fit, which
we see conditionally fit, and which we see unfit for supporting media
fragments. I'm certain that such conditions will indeed lead further
codec development efforts in the future.


> Spatial fragments
> *****************
> This one is probably the hardest to deal with and depends, just like time
> fragments, on the coding format. For image coding formats, JPEG2000 and HD
> Photo (to some extent) provide support to independently encode spatial
> regions. With other image coding formats such as JPEG, GIF, and PNG, it is
> not possible to describe spatial regions in terms of bytes. For video coding
> formats, we can consider the motion variants of the image coding formats
> JPEG2000 and HD Photo. Further, H.264/AVC and its scalable extension SVC are
> able to encode spatial regions independently by making use of the coding
> tool Flexible Macroblock Ordering (FMO). MPEG-4 Visual allows to code
> objects independently of each other (i.e., object-based video coding).
> However, for video formats, I think that there are very few media resources
> in the wild that were encoded with provisions for spatial fragment
> extraction in the compressed domain. For example, only a few H.264/AVC
> decoders support FMO and I never saw an MPEG-4 Visual encoded bitstream
> which was encoded in objects.

Even if there is barely a current image and video codec format that
supports spatial fragments, it may be important for us to standardise
the format, since it may lead to future formats supporting it.


> Named fragments
> ***************
> To the best of my knowledge, no coding format provides support for named
> fragments. I think we should look at container formats for this feature. As
> you said, Ogg combined with CMML does the trick. In fact, if a container
> format allows the insertion of metadata describing the named fragments, then
> the container format supports named fragments. For example, you can include
> a CMML description in an MP4 container and interpret this CMML description
> to extract fragments based on a name.

Attachment of TimedText will have the same effect, I think.


> Finally, it is important to remark that coding formats supporting fragment
> extraction in the compressed domain are not enough. The right encoding
> parameters also need to be enabled to support this fragment extraction. For
> example, it is impossible to extract a spatial fragment from a JPEG2000
> image in the compressed domain if this spatial fragment is not independently
> coded from the rest of the image.

That falls under "conditionally fit" in my view, but it is good to know so!

Awesome analysis - we should but that in the wiki! :-)

Cheers,
Silvia.

Received on Saturday, 1 November 2008 23:52:08 UTC