Re: [PATCH 4/4] qv4l2: add OpenGL video render

["Bård Eirik Winther" <bwinther@cisco.com>]

> On Wednesday, July 17, 2013 01:03:44 PM you wrote:
> Hi Bård,
> 
> On Tuesday 16 July 2013 14:59:04 Bard Eirik Winther wrote:
> > On Tuesday, July 16, 2013 02:01:45 PM you wrote:
> > > Hi Bård,
> > > 
> > > Thank you for the patches.
> > > 
> > > 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.
> > > > 
> > > > Signed-off-by: Bård Eirik Winther <bwinther@cisco.com>
> > > > ---
> > > > 
> > > >  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(-)
> > > 
> > > 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.
> > 
> > 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.
> 
> 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.