[SDL] SDL 2.0.1 RC1

Gabriele Greco gabriele.greco at darts.it
Wed Oct 23 06:31:42 PDT 2013


On Wed, Oct 23, 2013 at 5:46 AM, Sam Lantinga <slouken at libsdl.org> wrote:

> SDL_UpdateYUVTexture() just allows you to update the texture without
> having to make sure your Y, U, and V planes are in a contiguous block of
> memory.  It otherwise works just like the normal texture update function
> and you would use it the same way with the same textures.
>
> The only time this is advantageous is if your video decoder returns
> separate YUV planes, and you can avoid a buffer copy.  Otherwise it doesn't
> matter.
>
>
Sorry Sam,

Let me understand better:

Actually I thought the best way to display video with SDL was:

- Create a STREAMING texture
- decode the frame
- lock texture
- copy my framedata into the "pixels" of the texture
- unlock the texture

This will imply a data copy more than needed since I have to copy my
decoded frame (that I have to keep, to decode the following frame) to the
"shadow" texture allocated inside the hidden part of the SDL_Texture
structure, the pixels modified between lock/unlock are then sent to the
hardware through glTexSubImage2D or similar.

I've looked inside the renderer implementation and I've seen that using
SDL_UpdateYUVTexture will directly upload with three calls
of glTexSubImage2D my "decoded frame" to the real HW opengl texture(s)
without intermediate copy (I suppose there is a pixel shader that create a
single RGB color from the 3 differents Y U V textures), so my conclusion is
that:

For video output purpose there is no advantage in using a streaming texture
and low level lock/unlock over a "not streaming" yuv texture and
SDL_UpdateYUVTexture that is really the most performing way to do this kind
of operation.

Actually I'm trying to verify this modifying my h.264 "multiviewer" to
using this approach :)

-- 
Bye,
 Gabry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20131023/a565af48/attachment-0009.htm>


More information about the SDL mailing list