similar to: Converting RGB YUV and back

Hello list, When I convert an yuv pixel into rgb using the recipies in http://www.fourcc.org/fccyvrgb.php I get an accurate color conversion but the contrast seems to be decreased. If i write, e.g., the pixel directly into an sdl yuv_overlay, I get a well-contrasted frame, however, if I convert the pixel to rgb and call SDL_MapRGB, I get a contrast-decreased frame. Thanks, Ribamar

hi folks! once again i am trying to decode a yuv_buffer to a 24 bit RGB buffer. last time nobody seemed willing to tell me how to do this, so i am trying again. i try to make my questions more simple. what i need to know is: how many bytes are in each y, u, v array? what for are these strides? what exactly is a "plane" in a frame, and what does it do? what i want to achieve is

Hello all, I'd like to convert the theora yuv_buffer to RGB that I can render onto a texture. Googling around, there are a tone of different formulae to do so. There is this (with lots of corrections and amendments further down the page): http://www.fourcc.org/fccyvrgb.php <http://www.fourcc.org/fccyvrgb.php> and there is the MSDN stuff that says you need to convert 4:2:0 and

Hello, I'm trying to use Theora video codec with DirectX 8 and DiretX 7. The problem seems to be out format of Theora decoder wich is YV12 and incompatible with DirectShow Video Renderer Filter. Do you know a filter able to convert YV12 to RGB, usable in a commercial application ? May I have to make such a filter myself ? Is is said in the README file of oggdsf archive : "You need

> 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 06:08:25PM +0800, illiminable wrote: > Why not just make it OggRawFOURCC, do we really need one stream format for > rgb, and one for yuv ? [snip] > I just meant oggRaw, not fourcc. Oh, thank god you corrected this. :-) I was contemplating an "OggVid" format, and here is why I'm steering against it (though, yes, this has been a topic of

On Tue, Nov 08, 2005 at 06:08:25PM +0800, illiminable wrote: > Why not just make it OggRawFOURCC, do we really need one stream format for > rgb, and one for yuv ? [snip] > I just meant oggRaw, not fourcc. Oh, thank god you corrected this. :-) I was contemplating an "OggVid" format, and here is why I'm steering against it (though, yes, this has been a topic of

I've spent the weekend or so trying to get my head around Theora and I'm just not having any luck. First of all, I really don't have any interest in immersing myself in video encoding--I just have one simple thing I'd like to do--so I haven't spent any time reading about the theory or specs or anything like that. I'm attempting to write a "render-to-theora"

hi folks! i would like to know whether there will be some function to decode to some plain 24 bit RGB buffer in the future. i think this feature is sometimes important, especially when using different surface layers, or when modifying the buffer in realtime. if this feature will definitely not be, could someone tell me how i can convert to some RGB buffer in realtime? i already tried different

hi folks! i would like to know whether there will be some function to decode to some plain 24 bit RGB buffer in the future. i think this feature is sometimes important, especially when using different surface layers, or when modifying the buffer in realtime. if this feature will definitely not be, could someone tell me how i can convert to some RGB buffer in realtime? i already tried different

> > FourCC is a codec identifier, nothing more. It's four letters which can > be > referenced against a table to see what codec it is, it's a standard used > by RIFF > (aka, wav and avi) and older Macintosh formats, and in my opinion, its > obsolete. > While it's true there are a bunch of FOURCC's that represent non-raw formats like DIVX etc, the ones

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

This also includes, other non raw formats... http://www.fourcc.org/codecs.php "fourcc" 's of rgb types http://www.fourcc.org/rgb.php raw yuv formats only http://www.fourcc.org/yuv.php Registered fourcc codecs http://www.microsoft.com/whdc/archive/fourcc.mspx Enumeration of actual types that are used in directshow (bottom of page)

On Tue, Nov 08, 2005 at 09:36:52PM +0800, illiminable wrote: > > Then there's YUY2 which is interleaved Y0 U0 Y1 V0 Y2 U1 Y3 V1, and YVYU > (Y0 V0 Y1 U0 Y2 V1 Y3 U1), and UYVY (U0 Y0 V0 Y1 U0 Y2 V0 Y3)... and then > there's AYUV, which has a 4th alpha channel. We will only be doing [A]YUV ordered planar encoding, no other order, not packed using one of several methods.

On Tue, Nov 08, 2005 at 09:36:52PM +0800, illiminable wrote: > > Then there's YUY2 which is interleaved Y0 U0 Y1 V0 Y2 U1 Y3 V1, and YVYU > (Y0 V0 Y1 U0 Y2 V1 Y3 U1), and UYVY (U0 Y0 V0 Y1 U0 Y2 V0 Y3)... and then > there's AYUV, which has a 4th alpha channel. We will only be doing [A]YUV ordered planar encoding, no other order, not packed using one of several methods.

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

libshout 2.2 has just been released. It's a fairly minor update: * Speex support (this is why it's 2.2 instead of 2.1.1) * Theora timing fix * Double-free bug, response parser bug on failed login fixed. It's at http://www.icecast.org/download.php

Hi, > > static const uint32_t virtio_gpu_cursor_formats[] = { > > +#ifdef __BIG_ENDIAN > > + DRM_FORMAT_BGRA8888, > > +#else > > DRM_FORMAT_ARGB8888, > > +#endif > > DRM formats are supposed to be little endian, so this isn't really > correct. Well, maybe they where *intended* to be little endian at some point in the past. The actual code

Hi, > > static const uint32_t virtio_gpu_cursor_formats[] = { > > +#ifdef __BIG_ENDIAN > > + DRM_FORMAT_BGRA8888, > > +#else > > DRM_FORMAT_ARGB8888, > > +#endif > > DRM formats are supposed to be little endian, so this isn't really > correct. Well, maybe they where *intended* to be little endian at some point in the past. The actual code

Mike Melanson: I want to store RGB values instead of YUV. I don't understand the theoretical and practical implications of this and that's why I'm asking about it. I would like to know whether it cannot work and why. I'm targeting a minimum Pentium 4 Celeron, 256MB RAM. Video resolution are about 200 X 200 pixels with a maximum of 2 playing simultaneously as the game is playing