- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 21 Sep 2010 22:55:56 +1000
- To: tmichel@w3.org
- Cc: "public-media-annotation@w3.org" <public-media-annotation@w3.org>
- Message-ID: <AANLkTi=Mc30d8SoeRhU6m1xkUR9q6cJ6bFqV3hfJtTfY@mail.gmail.com>
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 UTC