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).

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.

Cheers,
Silvia.

Received on Monday, 6 October 2008 08:45:54 UTC