Vorbis dev - Jan 2003 - application/ogg is a proposed Internet standard.

The IETF passed the application/ogg MIME type some days ago. I couldn't
bring you the news earlier because of the MS SQL worm that has been
wreaking havoc all over my local networks.

The IETF wants some clarifications in Silivias draft for the Ogg stream
format, but apart from that I think it will also be passed soon.

The RFC and IANA registration of this mimetype will probably be published
soon enough.

Linus

---------- Forwarded message ----------
Date: Thu, 23 Jan 2003 20:30:41 -0800
From: Allison Mankin <mankin@psg.com>
To: Silvia.Pfeiffer@csiro.au, avt@ietf.org, casner@acm.org, csp@isi.edu
Cc: harald@alvestrand.no
Subject: [AVT] Re: New I-Ds for Ogg technologies (Vorbis over RTP,
     Ogg file format, Mimetypes)

Silvia, AVT WG, Chairs,

We IESG passed draft-walleij-ogg-mediatype-08.txt as a Proposed
Standard today.  It had had a four week Last Call some time back and
was not changed, other than now having the internet-draft available to
document the fileformat.  Congratulations!

The accompanying i-d, draft-pfeiffer-ogg-fileformat, was on the agenda
as well and Harald Alvestrand raised a technical question that needs
to be resolved before we can progress it as Informational.  Harald's
written question:

  Technical omission (I think): The document says that the BOS page
  "contains information to identify the codec type and any additional
  information to set up the decoding process.  The format of that page
  is therefore dependent on the codec and therefore MUST be given in
  the encoding specification of that logical bitstream type."

  It's pretty clear that OGG players can identify which codec is being
  used. But this document does not say which bytes of the BOS page can
  be used to identify the codec. (first 4 bytes? first 16 bytes? up to
  the first NUL?)

Thanks,

Allison
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Monday, January 27, 2003, at 11:37  am, Linus Walleij wrote:
> The IETF passed the application/ogg MIME type some days ago. I couldn't
> bring you the news earlier because of the MS SQL worm that has been
> wreaking havoc all over my local networks.
This is excellent news. Thanks so much for all your efforts in this 
direction.

Allison Mankin wrote:
> The accompanying i-d, draft-pfeiffer-ogg-fileformat, was on the agenda
> as well and Harald Alvestrand raised a technical question that needs
> to be resolved before we can progress it as Informational.  Harald's
> written question:
>
>   Technical omission (I think): The document says that the BOS page
>   "contains information to identify the codec type and any additional
>   information to set up the decoding process.  The format of that page
>   is therefore dependent on the codec and therefore MUST be given in
>   the encoding specification of that logical bitstream type."
>
>   It's pretty clear that OGG players can identify which codec is being
>   used. But this document does not say which bytes of the BOS page can
>   be used to identify the codec. (first 4 bytes? first 16 bytes? up to
>   the first NUL?)
Well, this was intentionally vague beyond the idea that identification 
should be possible from the first packet. For vorbis it's the first 7 
bytes of any of the first three packets, but given the open-ended 
nature of the encapsulation intention, it's not possible to be more 
specific than that. I.e. we don't have reserved 4-character codec 
labels or such.

Perhaps it's worth adding a sentence along the lines of: "Such an 
encoding (encapsulation?) specification SHOULD endeavor to make codec 
identification possible through matching some number of initial bytes." 
All current ogg-encapsulated forms work this way afaik.

FWIW,
  -r

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Tirsdag, 28 januar 2003, skrev du:
>Regarding the issue with identifier strings in the Ogg Stream content:
I
>mailed the IETF AVT list on this subject with the idea, that if they
>really want this to be strongly standardized and coordinated, control 
of
>registration of identifier strings should be transferred to the IANA,
>the Internet Assigned Numbers Authority.
I've already tried to discuss this problem here without getting much 
response, since the problem is not just a theoretical one, but it 
also has practical issues. When implementing an Ogg demultiplexer 
for a media framework, the demultiplexer in most cases has to determine 
the content type of each logical stream. E.g. an Ogg file containing 
a Vorbis and a Theora track would be split by the demultiplexer into 
two logical streams with the content types audio/(x-)vorbis and video/(x-
)theora. At the moment, this means that the demultiplexer must be 
able to recognize the content type based on the actual content. This 
is not really difficult, but it means that if the demultiplexer for 
example only knows how to recognize Vorbis, the framework would not 
be able to playback a FLAC stream in an Ogg container, although a 
FLAC decoder is installed. A related problem is also the format of 
the timestamps in the Ogg files. A demultiplexer needs quite extensive 
knowledge about the actual format, before it is able to convert the 
granule position into a meaningful and comparable value.

IMHO, a good solution for the content problem would simply be to 
specify the actual content type as a string somewhere in the Ogg 
file. I can't see an easy solution for doing this and remain backward 
compatible though.

Tor

<p><p>==================================================================EASY
and FREE access to your email anywhere: http://Mailreader.com/
==================================================================
<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

as far as the identification problem goes --
 
I had a reasonably long discussion with Monty about this.  The present theory of
operation is as follows (Monty as always, please correct if I'm wrong):
 
Each logical stream has an identification header.  By convention, this header
must include magic data that uniquely identifies the required codec.  IE, after
the packet ID, vorbis headers contain the string "vorbis"; theora
headers say "theora", etc.
 
Perhaps we should codify this convention.  But even if we didn't, it's
entirely reasonable to have each codec take a look at the ID header and report
as to whether it can parse this stream.  If all codecs fail, you haven't
installed (linked in) a codec that can deal with this data.  This situation is
identical to the case in Quicktime or Windows Media where you have a file but
don't have the codec.  If the codec is installed, you send it the data; if
it's not installed, you don't.  The ID query should be nearly
instantaneous, so it shouldn't be any kind of latency or performance
problem.
 
As for the timing/seeking issues, I'm just getting up to speed on it, but I
suspect the answer is similar: yes, the methods necessary to locate position in
a stream are codec-dependent, but that's fine; either you have the codec or
you don't.  If not, what are you going to do with the data other than
discarding it?  If you do have the codec, then the interface provides the
functionality necessary to map packets (granules??) or whatever to actual time
stamps.
 
As has been mentioned, it is very important to distinguish between the spec
itself and the existing apps and libraries that support the spec.  While the
existing implementation may not support a specific feature (for instance,
run-time codec binding), there is nothing in the spec itself that prevents
anyone from developing an application with that feature.  The spec itself should
not be modified unless it is shown that some feature is not possible to
implement reasonably within the specification as it now exists.
 
-dbm

        -----Original Message----- 
        From: Tor-Einar Jarnbjo [mailto:Tor-Einar_Jarnbjo@grosch-link.de] 
        
        I've already tried to discuss this problem here without getting much
        response, since the problem is not just a theoretical one, but it
        also has practical issues. When implementing an Ogg demultiplexer
        for a media framework, the demultiplexer in most cases has to determine
        the content type of each logical stream. E.g. an Ogg file containing
        a Vorbis and a Theora track would be split by the demultiplexer into
        two logical streams with the content types audio/(x-)vorbis and
video/(x-
        )theora. At the moment, this means that the demultiplexer must be
        able to recognize the content type based on the actual content. This
        is not really difficult, but it means that if the demultiplexer for
        example only knows how to recognize Vorbis, the framework would not
        be able to playback a FLAC stream in an Ogg container, although a
        FLAC decoder is installed. A related problem is also the format of
        the timestamps in the Ogg files. A demultiplexer needs quite extensive
        knowledge about the actual format, before it is able to convert the
        granule position into a meaningful and comparable value.
        
        IMHO, a good solution for the content problem would simply be to
        specify the actual content type as a string somewhere in the Ogg
        file. I can't see an easy solution for doing this and remain
backward
        compatible though.
        
        Tor
        
        
        
        ==================================================================      
EASY and FREE access to your email anywhere: http://Mailreader.com/
        ==================================================================
        
        --- >8 ----
        List archives:  http://www.xiph.org/archives/
        Ogg project homepage: http://www.xiph.org/ogg/
        To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
        containing only the word 'unsubscribe' in the body.  No subject
is needed.
        Unsubscribe messages sent to the list will be ignored/filtered.
        

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 7335 bytes
Desc: winmail.dat
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20030128/60265f05/winmail-0001.bin