The VideoLAN Forums

PBO cannot be used under OpenGL ES 2.0. So I think the upload of three textures is the way to go at the moment.

I looked into the source of: qmemoryvideobuffer.cpp There is no VRAM on the gpu provided, its just some simple system memory. So they must to the same, upload the system memory to the GPU every frame update Thats why I wonder whether it is really possible like you said to provide some PBO for libvlc...

I know shared_ptr. But I still don't get it. You have to explain what happens here: m_videoFrame = frame; Imagine that the video surface does not copy VideoFrame(so no increased count usage, he directly use it, and render its content) m_videoSurface->present( newFrame ); the present method take it a...

I don't understand how this will work. when you are doing this: m_videoFrame = frame; The existing frame will be destroyed. This happens in the decoding thread of libvlc. But what, if m_videoFrame is already used by the GUI thread to render it? Note: Since video frames can be expensive to copy, QVid...

I wonder how your code works, without any locks:
https://github.com/RSATom/QmlVlc/blob/m ... Output.cpp

The CPU usage is the same with your own display and with the abstract videosurface.

Can be the drawback of your approach also be, that it is not supported on every platform? There are no any need to support I420 pixel format directly by platform, since it come to shader just as raw data, and there transforming to RGB. And again, if you want to play video, there are big chance you ...

So RV32 hast 32 bit per pixel and I420 12 bit per pixel, so this must be the reason why your code is faster for videos with higher resolution.
You don't need to transfer so much data every frame.

Can be the drawback of your approach also be, that it is not supported on every platform?

How would you do it with VBO, that is used for geomerty data?
Is using PBO not a better approach?

Can I not simply provide some memory space on the VRAM and VLC can directly render to it?

You could do it with VBO (if your hardware supports it) - there is no need of any special support on libvlc side.
I want to try it long time...

and you failed why?

@ Rémi Denis-Courmont
Is there GPU decoding on, when using these callbacks, when no, why?
Can I not simply provide some memory space on the VRAM and VLC can directly render to it?

1) That is not clear from the documentation. And btw. can I not provide some kind of memory space on the VRAM, e.g. a texture, where VLC can directly render to it? 2) RSATom implemented "I420" only, no other option. I at the moment only switched the decoding to "RV32", the resolu...

I guess, this is your answer to 2) I looked into your code and you are using raw OpenGL to to show the image and you are using the "I420" decoder. Your CPU usage in the demo APP was lower, but only when I used 1920x1080 movies. A guy told me that the bottleneck is not the upload of the fra...

When I use this callback, do I then get support for GPU decoding? 1) When not, why? 2) I use this callback for embedding libvlc into QML. Libvlc simply paints into a QImage("RV32"). I get 10%-15% CPU usage. using the same movie in VLC directly, with disabled Hardware-decoding I get 4%-6% C...