similar to: warning re: IceShare

This is intended for those interested in IceShare development.. The earlier drafts of the IceT protocol (sorry, not back on the wiki yet) used SHA1 hashes for pages. This, AFAIR, is the same that bittorrent uses for .torrent files, except ours are transfered "live" between the peer and the tracker as the data is being transfered. The first method, where the Tracker sent a seperate

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

I've rehashed the model for the libogg2 convience library, seperating it into two libraries in the effort to allow 3rd party media frameworks to more directly utilize the functions provided by OggFile, while still providing VorbisFile-like convience for the most common uses of Ogg encoders/decoders. In this new model, liboggstream provides the functionality of "codec plugins",

Moved off OggYUV thread as this is off-topic for it.. On Wed, Nov 09, 2005 at 04:51:51PM +0800, illiminable wrote: > > > >Um, data packets consist of a 32-bit header followed by PCM data. Where > >did you get the idea that "sync" data was in the packet? > > That's what the first 32 bits of "header" are. Um, no, the first 32 bits of the header is

On Wed, Nov 09, 2005 at 09:31:29AM -0800, Ralph Giles wrote: > > > > I am open to eliminating it, if it can be shown that the act of reading or > > skipping this data complicates implementation or makes it less efficient, > > however, the decidion to do so should include several people (Monty, Ralph, etc) > > who haven't joined this discussion yet. > >

On Thu, Nov 10, 2005 at 05:30:10PM +0100, oliver oli wrote: > John Koleszar wrote: > >I hadn't even heard > >of ambisonics until your post, to be honest. > > because people don't know how to distribute ambisonics. no way to play > it in a DVD player. there are no easy to use software players that > decode ambisonic files and there are no widely used audio

On Fri, Nov 11, 2005 at 05:29:52PM +0800, illiminable wrote: > > (quote:"and thus the subject of FourCC labeling in OggStream's native video > interchange formats is closed.") > > ... doesn't sound like community debate to me. > > Maybe i missed the meeting where you became god here. If you are going to > make claims that you somehow are in charge

Just a quick note, realizing that many interested parties on vorbis-dev may not be subscribed to ogg-dev.. We're working out the details for an OggPCM codec, an uncompressed audio interchange format which will be used by the next generation Ogg framework. You can read what's taken place on this so far on the wiki and list: http://wiki.xiph.org/RawCodecs http://wiki.xiph.org/OggPCM

On Wed, Nov 09, 2005 at 01:14:08PM +0800, illiminable wrote: > > >I agree, which is why I wrote the OggPCM draft when we already have FLAC. > >These > >formats are not difficult to design or implement, and I think the added > >efficiency and simplicity will more than make up for it. > > Which i looked at... and i'm wondering why on earth it has a sync code

On Tue, Nov 08, 2005 at 03:33:57PM -0500, John Koleszar wrote: > > In terms of colorspaces, it seems to me that the only way to completely > describe the colorspace is to provide the transform matricies to or from > some reference colorspace. Is this a valid statement? Except there are not enough colorspaces in use to need to do this, as far as I've read at least.. a set of

(second try at sending this) --- This is getting very dangerous. We cannot take our flamewar to outside mailing lists without making a complete fool of ourselves. Arc, would you please refrain from doing so in future and rather come to an internal agreement beforehand? Arc, there are a few things you have missed: The discussion on OggPCM2 was friendly and constructive and there were no flame

On Wed, Nov 09, 2005 at 09:59:02AM +0800, illiminable wrote: > > While it's true there are a bunch of FOURCC's that represent non-raw > formats like DIVX etc, the ones which represent raw YUV types are pretty > well defined. Yes you certainly still need the width, height, aspect ratio > and frame rate. Since FourCC is an identifier for a different codec, what you are

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

I've noticed many people manually entering .. [[User:*|*]] on the talk pages to sign their contributions.. Just a friendly note that "--~~~~" is shorthand for your signature w/ timestamp. I just recently learned that, myself. In addition, I'd like to say how awesome our little community of hackers have been oven the past week. IRC, email, the lists, and the wiki have

This is getting very dangerous. We cannot take our flamewar to outside mailing lists without making a complete fool of ourselves. Arc, would you please refrain from doing so in future and rather come to an internal agreement beforehand? Arc, there are a few things you have missed: The discussion on OggPCM2 was friendly and constructive and there were no flame wars and the spec got much further

In the effort of reducing list traffic, I've consolidated two replies into one: On Tue, Nov 08, 2005 at 08:24:33PM -0800, Ralph Giles wrote: > > BTW, there are already a number of general "raw" video formats in > professional use; it's not just AVI we have as prior art. :) > I'd like to see some discussion of the merits of adopting one of those > if we

On Tue, Nov 15, 2005 at 03:10:22AM +1100, Erik de Castro Lopo wrote: > That spec is being superceded by: > > http://wiki.xiph.org/index.php/OggPCM2 The project has been forked, not superceded. Work on OggPCM is continuing, the team working on OggPCM2 is free to submit their own draft but some are not welcome to continue work on OggPCM due to their recent social conduct. I'm

On Fri, Nov 11, 2005 at 09:13:01AM +1100, Erik de Castro Lopo wrote: > > However, support for (ie) 48-bit-float should not have to be created, > > Where are you going to find a 48 bit float? Is there an IEEE > standard for that? It's not about what's now, it's about what could be, and nobody has been able to make good predictions, except your logic here: > If

Hi Arc, illi, I think it would be advantageous if we take the emotion out of this discussion , so let's just argue technically. My experience with xiph is that we are a very friendly community and trying to help each other and listen, so let's keep that culture up. I think we all agree: it is a good idea to have an media mapping for ogg for uncompressed PCM. As for what is required in a