libvlc lock / unlock and format callback chroma

[lp0]

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:

Code: Select all

$ lsb_release -d Description: Ubuntu 16.04.2 LTS $ apt show libvlc-dev 2> /dev/null | head -n 2 Package: libvlc-dev Version: 3.0.0~~git20160813+r65787+62~ubuntu16.04.1

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.

[Rémi Denis-Courmont]

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.

[lp0]

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?