Skip to contentSkip to conversation

qv4l2: add OpenGL video render

PATCH Bård Eirik Winther 1 participant 1 message Jul 17, 2013 1 message not in the archive Media (V4L/DVB)

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw
Quoted 42 lines · you

Hi Bård,

Quoted 26 lines · On Tuesday 16 July 2013 14:59:04 Bard Eirik Winther wrote:
Quoted 20 lines · you

Hi Bård,

Thank you for the patches.

Quoted 7 lines · On Tuesday 16 July 2013 13:24:08 Bård Eirik Winther wrote:

The qv4l2 test utility now supports OpenGL-accelerated display of video. This allows for using the graphics card to render the video content to screen and to performing color space conversion.

---

Quoted 7 lines
 configure.ac                |   8 +-
 utils/qv4l2/Makefile.am     |   9 +-
 utils/qv4l2/capture-win.cpp | 559 +++++++++++++++++++++++++++++++++++--
 utils/qv4l2/capture-win.h   |  81 ++++++-
 utils/qv4l2/qv4l2.cpp       | 173 +++++++++++---
 utils/qv4l2/qv4l2.h         |   8 +
 6 files changed, 782 insertions(+), 56 deletions(-)
Quoted 4 lines

Is there a chance you could split the OpenGL code to separate classes, in a
separate source file ? This would allow implementing other renderers, such as KMS planes on embedded devices.

Quoted 4 lines

Hi.

Do you mean to separate the GL class only or all the different shaders/renderes as well?

Basically, what would be nice to get is an easy way to extend qv4l2 with different renderers. OpenGL is fine on the desktop, but for embedded devices a KMS planes backend would work best given the mess that the embedded GPU situation is. Instead of adding #ifdef ENABLE_OGL and if (use_ogl) through the code, abstracting the rendering code in a separate base class that renderers could inherit from would make the code simpler to read, maintain and extend.

Quoted 4 lines

I haven't looked at the details so I'm not sure how much work that would be, but if the effort is reasonable I think it would be a nice improvement.

I belive I have found a workable solution that should not take that much of time to implement. The current interface for adding more render/display options is simply to extend this class:

class CaptureCanvas {
public:

        CaptureCanvas(){}
        virtual ~CaptureCanvas();

        virtual void setFrame(int width, int height, unsigned char *data, __u32 format);
        virtual void start();
        virtual void stop();
        virtual void hasNativeFormat(__u32 format);
        virtual static bool isSupportedRender();
};

It should cover any needs for display afaik, but then again I do not know every system that exists which might require more interaction.