similar to: Converting RGB YUV and back

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

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

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

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

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

> 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

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

Hey all! I'm sure you've all been missing my webcam stream, so I decided to start it up again (also, I wanted to do it for my family overseas). However, this time, I'm doing things a little bit differently. For starters, the encoder is the current (as of about an hour ago) ptalarbvorm branch which is destined to become libtheora 1.2. Another difference is that I'm using

Hey, ::: I'm sending a patch for liboggplay for comments. It adds - runtime cpu extension detection - fixed mmx implementation - added sse2 yuv to rgb conversion - added a faster vanilla implementation ::: currently it works fine on unix systems, the MSVC implementation needs a bit of a hacking, but basically you get the concept of the refactoring. If you have any

Arc wrote: >Not the camera, only the application which goes between the camera and >OggStream. Plus, changing between packed and planar is easy, my reason for >wanting to avoid packed is there's simply too many different ways to do it. > > My argument is that that application shouldn't have to convert to a fixed format. It should be able to say here's some YUY2

I'm evaluating some video codecs for a online conference system. I'm encoding images (640x480) from a webcam. I've been playing around with theora and xvid. First of all, using theora, the decoded image looks strange: http://integrasoft.ro/~mgliga/theora/comparison.png <http://integrasoft.ro/%7Emgliga/theora/comparison.png>. On the left side the image from the webcam, on

Hello, We are working on the Radio station project and we are trying to implement the Live Video Streaming module using Icecast server with VLC player. We have installed and configured the Icecast into our server. Also, we have installed the VLC player in our local desktop computer. The USB webcam(200 CMOS UCAM - DLC220T) has been connected into my machine. Now we are trying to live video

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.

Hi everybody. I have a problem using Theora in a specific way. I am going to explain that. I have downloaded ogg codecs for Windows on the Theora website. More precisely there are DirectShow Filters. I try to use Theora codec in a commercial application and the application crash. It doesn't with another codec like XviD, so the problem may be Theora codec. Note that I can use Theora outwards

On Fri, 4 Jun 2004, Makc wrote: > Here's what you can find in the net on YUV scheme: Hmm? What prompted this? > The statement I care to make here, is simply that there ain't neither > such thing as "luminance", which details "the eye is more sensitive to", "ain't neither"? Double negative, so I take your statement to mean that there *is* such

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.