Hello, I think it's best to work from a working apple example if you can.
Or look at how other code might do it. Perhaps have a look at portvideo, and opencv. Also search with google.com/codesearch for ideas. Maybe QTNewGWorldFromPtr would be useful? Also this page seems relevant: http://developer.apple.com/qa/qtmtb/qtmtb57.html 'How do I decompress individual frames into an offscreen'. cheers, On Mon, Jul 6, 2009 at 2:11 AM, Nirav Patel <[email protected]> wrote: > You will presumably have to copy the data out of the buffer. I don't > know exactly how video capturing works in OS X, but I assume there is > a limited number of frames it can buffer and it reuses this buffer. > What is the pixel format of the data in gWorld? You will almost > certainly have to write a C function to do the copying. If it is > already in a packed RGB format, you can simply memcpy the data and set > the correct shifts and masks for the SDL surface. > > However, keep in mind that this will limit the possible surfaces being > output by the camera module to that which the camera buffer contains. > This means that the surface may have to be converted on blitting to > the display surface, which can be a slow operation. Take a look at > how this is being done in the current _camera.c, specifically a > function like rgb444_to_rgb(). > > Though, if it is already in a packed RGB format, you could also just > make a SDL surface with the surface pixels pointing to the gWorld > data, set the shifts and masks correctly, and then just use > SDL_ConvertSurface() to do the conversion to the desired output > Surface if the user specifies one. > > Nirav > > On Sun, Jul 5, 2009 at 1:36 AM, el lauwer<[email protected]> wrote: > > Hoi, > > > > I am trying to put the pixels from the frame I grabbed into an > SDL_Surface, > > but I find it hard to get the gWorld data into the SDL_Surface. how can > you > > fill the buffer of the surface. I have tried to use SDL_Color, but the > > compiler said that the type didn't exist :s. > > > > is copying all the data from one buffer to an other a good idea, since > this > > copying takes a while to complete, definitely because it does it for > every > > frame. > > > > > > Slu > > >
