W3C home > Mailing lists > Public > public-media-annotation@w3.org > September 2010

Re: OGG container

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 21 Sep 2010 22:55:56 +1000
Message-ID: <AANLkTi=Mc30d8SoeRhU6m1xkUR9q6cJ6bFqV3hfJtTfY@mail.gmail.com>
To: tmichel@w3.org
Cc: "public-media-annotation@w3.org" <public-media-annotation@w3.org>
I think you misunderstand some of the way in which Ogg works. Skeleton is
actually part of the container format and thus all the metadata that
skeleton supports has to be attributed to Ogg.  See:
http://github.com/cpearce/OggIndex/blob/master/Skeleton-4.0-Index-Specification.txt

May I ask what happened to the Ogg mapping table that I previously
contributed and why that is not being used? I have contributed a mapping
table for Ogg files, which I think is now at
http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.html#d0e8203.
It includes the skeleton metadata, which should be counted as
container-level metadata.

Cheers,
Silvia.



On Tue, Sep 21, 2010 at 8:28 PM, Thierry MICHEL <tmichel@w3.org> wrote:

>
> I have investigated into the OGG container to fill our OGG mapping table
> [1]
>
> Ogg does not know anything about the content it carries and leaves it to
> the media mapping of each codec to declare and describe itself. There is no
> meta information available at the Ogg level about the content tracks
> encapsulated within an Ogg physical bitstream.
>
> read more at
> http://www.xiph.org/ogg/doc/skeleton.html
>
>
>
> Ogg does not replicate codec-specific metadata into the mux layer in an
> attempt to make the mux and codec layer implementations 'fully separable'.
> Things like specific timebase, keyframing strategy, frame duration, etc, do
> not appear in the Ogg container. The mux layer is, instead, expected to
> query a codec through a centralized interface, left to the implementation,
> for this data when it is needed.
>
> Though modern design wisdom usually prefers to predict all possible needs
> of current and future codecs then embed these dependencies and the required
> metadata into the container itself, this strategy increases container
> specification complexity, fragility, and rigidity.
>
> read more at
> http://www.xiph.org/ogg/doc/oggstream.html
>
> Therfore I guess there is not much to fill in our OGG mapping table.
>
> Thierry
>
>
> [1]
> http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.html#d0e12764
>
>
Received on Tuesday, 21 September 2010 12:56:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 September 2010 12:56:55 GMT