> 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@xxxxxxxxx>
> > > > ---
> > > >
> > > > 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
