The VideoLAN Forums

Hi,

I'm currently making an OpenGL video player using libvlc (C++).

I have different behaviors on different hardware using the same OS and
libvlc versions:
I'm using libvlc_video_set_callbacks and
libvlc_video_set_format_callbacks and set the chroma to "RV24".

1. On HW A:
   1. The lock callback is called once after new/play and the
      unlock callback once after calling stop/release. This is not the
      expected behavior. Seems like this is supposed to be fixed cf. ticket 17187.
   2. The format is correctly set to 3*8 bits RGB.
2. On HW B and C:
   1. The lock callback is called before every display call and
      the unlock callback is called after every display.
   2. The format is incorrectly set to 3*8 bits BGR.

I can't avoid tearing (and races) if I can't know when libvlc is writing to the
buffer, I also can't do double-buffering if the only way to change the buffer
address is through the unlock callback.

So here's my questions:

1. Will all my problems be fixed if I upgrade (and manually compile) libvlc?
2. Is the RGB/BGR confusion a bug or my own mistake?
3. Is there a way to know in what order I'll get those bytes?
4. Is there a better way to render a video to memory? I don't know much about
   OpenGL and how libvlc works, but if I understood correctly, using
   libvlc_video_set_callbacks forces libvlc to do all its work on the
   CPU and I have then to copy the buffer over to the GPU, which seems
   suboptimal if libvlc could do its thing on the GPU and updating the texure
   was just a matter of pointing a FBO to the right address.

TL;DR: I don't know what I'm doing.

Thanks for taking the time to read.

The sequence is lock, unlock, display. VLC accesses the buffer only between lock and unlock.

This API is quite inefficient; for efficient rendering, you MUST use window handles instead.

If I can render the window off-screen and get the pixels back, that could work.
I need to render the frames on an OpenGL quad.
I'm not doing a standard player here, I'm integrating a movie in a 3D scene.

If the display callback is called after the unlock that never happens,
I might try to add some synchronization stuff to prevent tearing.
Not as good a proper double-buffering but that'll do.

Do you have any idea what this RGB/BGR confusion is about?