RE: Video resource model

Hi Silvia,

>-----Original Message-----
>From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
>Sent: maandag 6 oktober 2008 10:45
>To: Davy Van Deursen
>Cc: public-media-fragment@w3.org
>Subject: Re: Video resource model
>
>Hi Davy,
>
>That's exactly the kind of discussion I wanted to create with the
>proposal of a video resource model. :-)
>
>On Mon, Oct 6, 2008 at 6:35 PM, Davy Van Deursen
><davy.vandeursen@ugent.be> wrote:
>> Dear all,
>>
>> regarding the video resource model [1] proposed by Silvia: do we
>assume that
>> any video (or media) resource will appear as described in the model,
>i.e.,
>> media resources packed in a container format? Various media resources
>are
>> available as elementary bitstreams, not packed in any container format
>> (e.g., mp3 audio files). We are working towards a format-independent
>> URI-based fragment identifier mechanism, but what do we mean with
>'format'?
>> Coding formats, container formats, or both? I prefer both, since we
>cannot
>> demand that all the media on the web is packed within a container IMO.
>
>I agree that we should be looking at it independent of container
>format and codec format. Therefore we need to make as generic a model
>as possible of the video resource that we are dealing with so we can
>cover all possible representations. All audio or video content that is
>used in audio or video files and is compressed actually needs to be
>packaged and encapsulated, because otherwise you would not be able to
>get a hold of the decoding unit. MP3 is also packed into a "container
>format" in that way, except that MP3 does not really have a "global
>header" (other than ID3) and rather each frame has its own little
>header. (NB: This is actually something I haven't represented in the
>picture: that an audio track generally also comes as a sequence of
>frames).
I agree. Maybe we just use a different definition of the terms 'container
format' and 'coding format'. With container formats, I meant formats which
do not specify any compression scheme and which are usually capable of
encapsulating different coding formats. But indeed, each coding format is
also a bit container format in a way that it provides headers (for instance,
to correctly initialize the decoder) and a high-level syntax to encapsulate
the coded data. 

>
>Even if you take a fully "uncompressed" bitstream, it is packed
>somehow. E.g. 44100Hz sampled stereo 16bit audio in a raw audio file
>has only one track and generally no header, but the "audio frames"
>consists of 32bit, therefore it is packaged. Since the information of
>it being 44100Hz, stereo and 16bit depth needs to be available
>somewhere in order to decode the audio properly, you tend to not find
>raw audio files anywhere, but rather ones with this information in a
>header, e.g. SUN au files.
>
>
>> Hence, for the moment, the model for media resources represents a
>'full
>> option' media resource, containing almost every possible media track
>and
>> packed in a container. Maybe we should also specify which subsets are
>> possible for this model?
>
>
>I think we have to consider the most complex case as the generic case
>that we deal with. All other, simpler cases are then covered by the
>most complex representation of a media resource and are just a
>specialisation.
>
>Do we need to specify subsets in this case? I don't think so, but
>wonder what your argument would be.

It is true that this will have no impact on the specification (as you said,
this needs to deal with the most complex case). The reason I thought about
this is related with the implementation of this specification (i.e., how
need a web server interpret it). Maybe this is a discussion for later, but I
think it will be easier for web servers to interpret URIs pointing to
fragments encapsulated in a container format than fragments pointing to an
elementary bitstream. This is because the headers provided by coding formats
are mainly meant for decoder initialization, not for accessing fragments
somewhere in the bitstream. Container formats such as MP4 do provide much
more support for such operations using additional headers. But as I said,
this might be a discussion for later; the model as it is currently proposed
seems ok for me to develop the specification.

Best regards,

Davy

Received on Monday, 6 October 2008 11:17:05 UTC