similar to: Final Ogg 1.0 submission to IETF

Howdy, yeah, I've finally collected all your feedback on my I-D on the Ogg encapsulation format, many thanks to all of you! Below, I've listed the changes that I have made to the previous version and the attachment contains the complete new I-D. If there are any more change requests, please send me wording proposals as it's easier to include. :) Monty, in case you are doing any

Howdy, yeah, I've finally collected all your feedback on my I-D on the Ogg encapsulation format, many thanks to all of you! Below, I've listed the changes that I have made to the previous version and the attachment contains the complete new I-D. If there are any more change requests, please send me wording proposals as it's easier to include. :) Monty, in case you are doing any

Hi John, all, I still have at least 3 issues: 1) What are we trying to achieve with the "source-ID"? 8 [uint] Source ID (Unique amongst all OggPCM streams in the physical stream) Are we trying to separate the different channels that may be interleaved with each other inside the flat multi-channel sample stream? Interpretation 1: ----------------- So, would each channel be in a

On Wed, Aug 13, 2008 at 3:05 AM, ogg.k.ogg.k at googlemail.com wrote: > And that's the canonical way AFAIK. Comparing times computed from > the granpos you get from pages you get from a bsearch requires good > knowledge of the codec, whereas comparing granpos can seek within > any codec. No. it's in general impossible to calculate the granulepos that corresponds to a

Hello, I recently added discontinuous stream support to libogg1. The patch is attached. I also wrote Writ codec for libogg1 (based on original code by Arc), and sample Writ encoder (SubRip to Writ converter) and decoder. Is anybody interested? WBR, Roman. -------------- next part -------------- Index: include/ogg/ogg.h =================================================================== ---

Hi John, I'm forwarding this email to the relevant developer lists at Xiph.Org, where the format was created and where the experts gather. I'm certain there is a design reason for putting the bos pages of all logical bitstreams together at the start. My guess is that with digital media you usually have a delay time for setting up the decoders for a specific format and by clustering

Hi John, I'm forwarding this email to the relevant developer lists at Xiph.Org, where the format was created and where the experts gather. I'm certain there is a design reason for putting the bos pages of all logical bitstreams together at the start. My guess is that with digital media you usually have a delay time for setting up the decoders for a specific format and by clustering

Good day, FYI, I've just sent the attached email to IETF to progress our I-Ds. There are also links to updated documents in this email. Cheers, Silvia. -------- Original Message -------- Subject: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) Date: Sun, 12 Jan 2003 01:36:31 +1100 From: Silvia Pfeiffer <Silvia.Pfeiffer@csiro.au> Organization: CSIRO To: AVT

Good day, FYI, I've just sent the attached email to IETF to progress our I-Ds. There are also links to updated documents in this email. Cheers, Silvia. -------- Original Message -------- Subject: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) Date: Sun, 12 Jan 2003 01:36:31 +1100 From: Silvia Pfeiffer <Silvia.Pfeiffer@csiro.au> Organization: CSIRO To: AVT

I suggest using the solution that CMML has come to use. The XML file is essentially the same as an unencapsulated physical bitstream. Then there is a mapping into a logical bitstream, where some of the default information - in particular the XML header - are split off and put into the bos packet - nothing really needs to go into the eos packet. There's also a magic number and a version

Hi all, Please find below an I-D for the proposed registration of MIME type audio/rtp-vorbis. All comments most welcome. Barry <p>-----------8<------------- Network Working Group Barry Short Internet-Draft The Ogg Vorbis Community / OpenDrama Expires: July 7, 2003 January 7, 2003 <p>

I'm having trouble getting libvorbis to cut the beginning of a bitstream when I instruct it to do so with granulepos. I have constructed a file which I believe should have its beginning truncated. I have attached it to this mail. Here is a picture of what the bitstream looks like, as output by a python program that uses pyogg/pyvorbis to read the stream and print a representation:

Actually, we have been discussing this kind of addressing for a very long time and it was half the point of the Annodex project (see www.annodex.net). What we have defined for addressing is the following: * temporal addressing: http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.txt Any ogg file can be addresses through temporal offsets. This goes across different logical bitstreams. *

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

Oggz 0.9.3 Release ------------------ Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip, oggz-scan and oggz-validate. liboggz is a C library providing a simple programming interface for reading and writing Ogg files and streams. Ogg is an interleaving data container developed by Monty at Xiph.Org, originally to support the Ogg Vorbis audio format.

Oggz 0.9.3 Release ------------------ Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump, oggzdiff, oggzmerge, oggzrip, oggz-scan and oggz-validate. liboggz is a C library providing a simple programming interface for reading and writing Ogg files and streams. Ogg is an interleaving data container developed by Monty at Xiph.Org, originally to support the Ogg Vorbis audio format.

Another spin-off discussion. The scheme used on <http://wiki.xiph.org/index.php/Metadata> was to packetize XML (split it up into packets at the root level, each of which was self contained (the terminology has temporarily abandoned me), and have the bos packet as the opening <?xml &c. stanza, the eos a </xml>. It is probably more sensible to include a magic number identifying

Thanks Silvia for your response :-) It's good to get constructive discussion on this, and I've been hoping to have exactly this kind of criticism re: OggPCM for some time. On Wed, Nov 09, 2005 at 10:21:04PM +1100, Silvia.Pfeiffer@csiro.au wrote: > > Data pages are identified to be part of a logical bitstream through their > serial number, so don't need any additional

Hello Tim I am referring to the following file https://en.wikipedia.org/wiki/File:Sample_of_%22Another_Day_in_Paradise%22.ogg I opened the file in a HEX editor. I do not see the string OpusHead in the packet. It starts with Oggs. Also checking the occurrence of Oggs, I see that the first packet has BOS, the next all (except last) have 00 (which is not defined in the RFC as continuation) and

Silvia.Pfeiffer@csiro.au wrote: > Hi Ian, > > CMML is still a draft, so we can change the addressing if required. > You're correct, currently something like > > blah.cmml#fragment > > points to a clip (or temporal section) of the stream, but > > blah.cmml#t=12 > > points to a 12 seconds offset. > > (same for annodex, i.e. ogg files with skeleton