Re: OGG container

Hi Thierry,

I saw the two sections and my reply was indeed targeted at the container
format section. As I said: skeleton should be regarded as part of the
container format and because Skeleton includes metadata, it should be
counted (see
http://github.com/cpearce/OggIndex/blob/master/Skeleton-4.0-Index-Specification.txt).
My point was that all of the information you are after is already included
in the previous table everywhere where it says "skeleton".

Anyway, happy to help - here is the table:

<table class="ta20" border="1">

  <tbody>
    <tr class="ro-header">
      <th class="col-mawg">MAWG</th>

      <th class="col-relation">Relation</th>
      <th class="col-attribute">OGG</th>

      <th class="col-how">How to do the mapping</th>


      <th class="col-datatype">Datatype</th>
      <th class="col-xpath">XPath</th>

    </tr>
    <tr class="ro-header">
      <td class="ma" colspan="6">Descriptive Properties (Core Set)</td>

    </tr>
    <tr class="ro-header">


      <td class="col-mawg" colspan="6"><em>Identification</em></td>

    </tr>
    <tr class="ro-even">
      <td class="ma">ma:identifier</td>

      <td>exact</td>
      <td>Name</td>
      <td>Name field in skeleton header (new)</td>

      <td>String</td>

      <td>N/A</td>
    </tr>

    <tr class="ro-header">
      <td class="col-mawg" colspan="6"><em>Content description</em></td>

    </tr>
    <tr class="ro-even">
      <td class="ma">ma:description</td>

      <td>related</td>

      <td>Title</td>
      <td>Title field in skeleton header (new)</td>

      <td>String</td>
      <td>N/A</td>
    </tr>

    <tr class="ro-header">
      <td class="col-mawg" colspan="6"><em>Technical Properties</em></td>

    </tr>

    <tr class="ro-even">
      <td class="ma">ma:frameSize</td>

      <td>N/A at container level</td>
      <td></td>
      <td></td>

      <td></td>
      <td></td>
    </tr>

    <tr class="ro-odd">
      <td class="ma">ma:compression</td>

      <td>exact</td>
      <td>Content-type</td>
      <td>Content-type field of Skeleton header</td>

      <td>MIME type</td>
      <td>N/A</td>
    </tr>

    <tr class="ro-even">
      <td class="ma">ma:duration</td>

      <td>exact</td>
      <td></td>
      <td>calculate as duration = last_sample_time -

        first_sample_time of OggIndex header of skeleton</td>
      <td>Float (or rather: rational - rational)</td>

      <td>N/A</td>
    </tr>

    <tr class="ro-odd">

      <td class="ma">ma:format</td>
      <td>exact</td>

      <td>Content-type</td>
      <td>Content-type field of Skeleton header</td>

      <td>MIME type</td>
      <td>N/A</td>
    </tr>

    <tr class="ro-even">
      <td class="ma">ma:samplingRate</td>

      <td>exact</td>
      <td></td>
      <td>calculate as granulerate = granulerate_numerator /

        granulerate_denominator of Skeleton header</td>
      <td>Rational (or rather int / int)</td>
      <td>N/A</td>

    </tr>

    <tr class="ro-odd">
      <td class="ma">ma:frameRate </td>

      <td>exact</td>
      <td></td>
      <td>calculate as granulerate = granulerate_numerator /

        granulerate_denominator of Skeleton header</td>
      <td>Rational (or rather int / int)</td>
      <td>N/A</td>

    </tr>

    <tr class="ro-even">
      <td class="ma">ma:averageBitRate</td>

      <td>exact</td>
      <td></td>
      <td>calculate as bitrate = length_of_segment / duration from

        OggIndex headers of skeleton</td>
      <td>Float</td>
      <td>N/A</td>

    </tr>

    <tr class="ro-odd">
      <td class="ma">ma:numTracks</td>

      <td>N/A on container level</td>
      <td></td>
      <td></td>

      <td></td>
      <td></td>
    </tr>

  </tbody>
</table>

Cheers,
Silvia.


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

> Silvia,
>
> I think you are misunderstanding/missing what we have decided during our
> last F2F in Sophia.
>
> Your contribution is still included in the latest draft of the Ontology
> specification
>
>
> http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.html#d0e8203
>
> Your OGG table is included in the following section
> 5.2.2 Multimedia metadata formats mapping tables
>
> but we have created a new section for
> 5.2.3 Multimedia container formats mapping tables
>
> where we have added these containers: 3gp, flv, mov, mp4, ogg, webm
>
> Feel free to update the OGG container table, if you have expertize on this
> container,
> the file is at:
>
> http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mappings/container-OGG.htm
>
> Thierry.
>
>
>
>
>
>
> Le 21/09/2010 14:55, Silvia Pfeiffer a écrit :
>
>  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
>>>
>>>
>>>
>>