search for: oggyuv

...fixed format. It should be able to say here's some YUY2 data and OggStream could figure out how to encode that to Theora by using an intermediate filter. >Um, other formats? I don't grok your statement. This is what I'm talking about: > >[Theora] -> Theora plugin -> [OggYUV:420] -> Colorspace Plugin -> [OggYUV:444] -> Media Player > >The current design of OggStream lets you build a chain, if needed, to decode. > Agreed. I'm focusing on the encode side: [Opaque] -> Import plugin -> [Arbitrary raw format] -> Colorconvert Plugin -> [Og...

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...

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...

...he wheel. I don't care either way, since while I understand it's important to have support on Windows, I'll never develop on it, and it's likely to be your time spent to port codecs to that proprietary platform. While you port them, you'll change their format from OggPCM and OggYUV to whatever the equivelent FourCC formats are and you'll be happy with that. Your filters use the DirectShow framework directly, after all, and you should use whatever native format your framework uses. As I said in the last email on this subject, if at some point you (or some other Windo...

...porting interlace and the chroma sampling it's likely to be needed for. This is also interesting work in that, once we're done, we'll have a standard to use for a compressed lossless format.. a FLAC for video, for editing or archival purposes, similar to HuffYUV. I'm drafting OggYUV and OggRGB on the wiki right now, so everyone can be on the same page for what the result of this will look like. The questions we need to answer are which colorspaces are needed and which encoding methods are needed. -- The recognition of individual possibility, to allow each to be what she...

...eption being application that > actually generate images, rather than extract/transcode, I suppose) I disagree with this, most decoders using OggStream are unlikely to be using FourCC, or at least the ones I care most about, and this places a complexity burden on all implementations which use OggYUV such that they *MUST* have a table of FourCC -> format mappings, whereas software which already supports FourCC should already have a table of these mappings and be able to quickly see if a OggYUV stream is directly mappable to a raw YUV FourCC codec. Also, as you pointed out, many FourCC im...

...eable, as these things combined would make for a very large number of possible raw codecs. If there is a limited set, then please paste to the list (or a URL) a list of what those formats are. Oh and I really, REALLY don't want to hear anymore from you about wanting to combine OggRGB and OggYUV into a single codec... if FourCC supports so many different YUV and RGB codecs, consolidating these into 2 is very reasonable by comparison. > As far as i see it there's no reason not to use such a simple fourcc based > format for the common cases, and use a more complete/complicat...

> 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 in the packet... that's the whole point of putting it in a container. > Now, if

...Like i said, it makes little sense for my implementation. All i see are > fourcc's, why would i want to write code for something that won't be used. But you already stated that you won't be using OggStream with DirectShow. So your Xiph/Ogg codec plugins will not export to OggPCM, OggYUV, or OggRGB, but rather to FourCC within DirectShow itself. None of these are expected for distribution, people will surely compress them (even losslessly) to save bandwidth and/or disk space so it's unlikely, should an implementation for these not be available to your filters, that your fi...

> But chroma subsampling? no. And this is where much of the complexity > comes. > > If we were to combine them, we would be, essentially, doing it something > like > this: > Value Meaning > 0 RGB > 1 YUV444 > 2 YUV422 > 3 YUV420 > 4 YUV411 > ..... Yes. > And then spend an additional field on bits/channel, whereas both chroma

> But chroma subsampling? no. And this is where much of the complexity > comes. > > If we were to combine them, we would be, essentially, doing it something > like > this: > Value Meaning > 0 RGB > 1 YUV444 > 2 YUV422 > 3 YUV420 > 4 YUV411 > ..... Yes. > And then spend an additional field on bits/channel, whereas both chroma

Here's a shot at a list of fields: // High level data Displayed Width&Height Stored Width&Height Aspect Ratio (Fractional) Frame Rate (Fractional) FourCC (Optional, set to zero to use values below) Colorspace (enum, R'G'B', Y'CbCr, JPEG (not sure proper name), etc) // Subsampling data U Channel X Sample Rate (Fractional) U Channel Y Sample Rate (Fractional) U Channel

...yer only takes 4:4:4 then an intermediary plugin will be needed to do the convertion. Some media frameworks already have functions for these, so they'll just take whatever format is being outputted and do the convertion themselves before sending to the media player. So what I propose for OggYUV is to cover the capabilities of Ogg video codecs, everything Theora is capable of and prehaps a bit more that we've seen from other codecs. 4:4:4, as I recall, is supported by the Theora spec (even if the current implementation doesn't). > Also, on another issue, i already find t...

...yer only takes 4:4:4 then an intermediary plugin will be needed to do the convertion. Some media frameworks already have functions for these, so they'll just take whatever format is being outputted and do the convertion themselves before sending to the media player. So what I propose for OggYUV is to cover the capabilities of Ogg video codecs, everything Theora is capable of and prehaps a bit more that we've seen from other codecs. 4:4:4, as I recall, is supported by the Theora spec (even if the current implementation doesn't). > Also, on another issue, i already find t...

> For a lossless codec, the luxury of a "small number of useful formats" > may not be advisable. I can't tell you how many times I've had some raw > data and been completely unable to play it with e.g., mplayer, because > mplayer did not have an apporpriate fourcc. And mplayer has made up many > of their own non-standard fourcc's (which not even all of mplayer

On Tue, Nov 08, 2005 at 04:59:33PM -0800, Arc wrote: > This is also interesting work in that, once we're done, we'll have a standard to > use for a compressed lossless format.. a FLAC for video, for editing or archival > purposes, similar to HuffYUV. Well, we're talking about an uncompressed format. OggMNG is already "FLAC for video". However, it doesn't do

Timothy B. Terriberry wrote: >Chapter 4 of the Theora specification does a reasonable job of laying >out all of the possible parameters for a Y'CbCr-style color space, which >includes as a subset those needed for RGB. Much more detailed >information is available from Charles Poynton's Color and Gamma FAQs: >http://www.poynton.com/Poynton-color.html >If you wish to do any

...ompressed lossless format.. a FLAC for video, for editing or > archival > purposes, similar to HuffYUV. I think that's something completely different. Any specialised lossless compression, as opposed to raw data will have it's own special setup requirements. > I'm drafting OggYUV and OggRGB on the wiki right now, so everyone can be > on the > same page for what the result of this will look like. The questions we > need to > answer are which colorspaces are needed and which encoding methods are > needed. At the end of the day, the reason such a codec does...

On Wed, Nov 09, 2005 at 10:52:53AM +0800, illiminable wrote: > > "fourcc" 's of rgb types > http://www.fourcc.org/rgb.php I'm prowd to say that http://wiki.xiph.org/OggRGB supports all of these losslessly as well as PNG for non-indexed bitmaps. These are video formats, correct? Not just single frames? > raw yuv formats only > http://www.fourcc.org/yuv.php

...YUV411 ..... And then spend an additional field on bits/channel, whereas both chroma channels in YUV is are going to have the same size. Oh, please, let there not be an exception to this. Now, keep in mind, that calling two codecs different is a conceptual one. If the difference between OggYUV and OggRGB ends up being changing the three character identifier, eliminating chroma subsampling field, and adding an extra bits per channel field and prehaps some other RGB-centric things. There are additional YUV-centric things which are not on the wiki now, as well, which Theora has fields t...