I have OggPCM (as currently defined) support implemented in mencoder and mplayer. I'd like to request that we settle on modifications to this header by the middle of next week or freeze the current header as the official major version 1.0, so I can get the patches cleaned up and released. We will be shipping a separate product based on this work in the near-term future, and compatability with a community standard is a desired bullet. Thanks.. John
John Koleszar wrote:> I have OggPCM (as currently defined) support implemented in mencoder and > mplayer. I'd like to request that we settle on modifications to this > header by the middle of next week or freeze the current header as the > official major version 1.0, so I can get the patches cleaned up and > released.One week is very little time to get public comment from other interested parties.> We will be shipping a separate product based on this work in > the near-term future, and compatability with a community standard is a > desired bullet.Please edit the wiki and remove the original Format and make the Alternative Format the only format. The original Format has been superceded. I also haven't figured out whether this header is included in every ogg packet or just the stream. From what I know of the Ogg container format the stream cannot be decoded if the file header is lost. Therefore adding header data to each packet is just redundant. There is also no discussion on the wiki on how data is packed into an ogg packet. A sensible constrain would be that an ogg packet cannot be constructed with a partial frame (ie the samples for all channels for a single sampling period). I repeat, we need to correct and complete the spec, remove all contradictory and/or wrong information and then ask for comments from others. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo +-----------------------------------------------------------+ "There is only a small difference between a strong atheist and a Christian: they agree on a very long list of gods that don't exist, and disagree about only one of them."
On Fri, Nov 11, 2005 at 07:03:51AM +1100, Erik de Castro Lopo wrote:> One week is very little time to get public comment from other > interested parties.Agreed, though things are becoming more sane quickly. :)> I also haven't figured out whether this header is included in every ogg > packet or just the stream. From what I know of the Ogg container format > the stream cannot be decoded if the file header is lost. Therefore adding > header data to each packet is just redundant.It should be included just at the head of the stream, it's redundant to put it on every packet and I don't see any advantage to that.> There is also no discussion on the wiki on how data is packed into an > ogg packet. A sensible constrain would be that an ogg packet cannot > be constructed with a partial frame (ie the samples for all channels > for a single sampling period).Agreed. I think this is a sufficient contraint, though perhaps "applications SHOULD use a fixed block/packet size for predictable buffering." and discuss the tradeoffs of packet and page sizes between latency and overhead. -r
On Thu, Nov 10, 2005 at 02:43:02PM -0500, John Koleszar wrote:> I have OggPCM (as currently defined) support implemented in mencoder and mplayer.Wow, you work fast! :-)> I'd like to request that we settle on modifications to this > header by the middle of next week or freeze the current header as the > official major version 1.0, so I can get the patches cleaned up and > released.I think it may be possible to get this soon, but I want to make sure everyone's kosher with it before it's frozen. A big part of this is getting a "nod" from Monty, Josh, and Jean-Marc, developers (respectivly) of Vorbis, FLAC, and Speex. I'm unsure if a week is long enough, but we'll see how things go. We work in a decentralized manner, after all, so we shouldn't leave port without making sure everyone's onboard first.> We will be shipping a separate product based on this work in > the near-term future, and compatability with a community standard is a > desired bullet.Awesome. -- The recognition of individual possibility, to allow each to be what she and he can be, rests inherently upon the availability of knowledge; The perpetuation of ignorance is the beginning of slavery. from "Die Gedanken Sind Frei": Free Software and the Struggle for Free Thought by Eben Moglen, General council of the Free Software Foundation
I take it you are talking about what is listed under alternative format ? If you have an implementation... you must have a list of enumeration fields... could you put them on the wiki. If we are asking for final comments... the wiki should be tidied up. The original format removed if the general consensus is that this is more on the right track... which it looks to be. Zen. ----- Original Message ----- From: "John Koleszar" <jkoleszar@on2.com> To: <ogg-dev@xiph.org> Sent: Friday, November 11, 2005 3:43 AM Subject: [ogg-dev] OggPCM version / header finalization>I have OggPCM (as currently defined) support implemented in mencoder and >mplayer. I'd like to request that we settle on modifications to this header >by the middle of next week or freeze the current header as the official >major version 1.0, so I can get the patches cleaned up and released. We >will be shipping a separate product based on this work in the near-term >future, and compatability with a community standard is a desired bullet. > > Thanks.. > > John > > > > > _______________________________________________ > ogg-dev mailing list > ogg-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev >
On Fri, Nov 11, 2005 at 12:59:31PM +0800, illiminable wrote:> > If we are asking for final comments... the wiki should be tidied up. The > original format removed if the general consensus is that this is more on > the right track... which it looks to be.The current format listed at top is a combination of the two minus surround sound information, which it feels like we're reaching a conclusion that this information either belongs as a Comment or in a seperate metadata codec. The primary reason for this is that Vorbis and FLAC lack surround sound data too, and there was expressed need to have the channels of some surround sound systems have different encoding parameters between the channels. For these reasons, and more that Sylvia pointed out, I believe we're going to handle it as a seperate metadata codec. The feedback box is still open, if something is missing or horribly broken. But due to time constraints on John's development, they should come soon as we're headed rapidly toward a release canidate to be approved by the audio codec crew (which consists of Monty, JeanMarc, and Josh). To echo JeanMarc's comments from IRC, he believes it's missing ulaw and alaw encoding, but other than that it looks fine. On the subject of (m)ulaw and alaw: http://en.wikipedia.org/wiki/Mu-law_algorithm http://en.wikipedia.org/wiki/A-law_algorithm I disagree with him, as these are both compression formats (albiet primitive), and while implemented by .au, .wav, and .aiff, I think these should exist (if needed at all) in a seperate codec. Nothing requires OggPCM to be the /ONLY/ supported input/output codec from compressed codec plugins, after all. He has not yet responded to this. -- The recognition of individual possibility, to allow each to be what she and he can be, rests inherently upon the availability of knowledge; The perpetuation of ignorance is the beginning of slavery. from "Die Gedanken Sind Frei": Free Software and the Struggle for Free Thought by Eben Moglen, General council of the Free Software Foundation