[libavg-devel] Subsystem Plugins

Wed Nov 12 21:05:13 CET 2008

On Wed, Nov 12, 2008 at 11:49 AM, Ulrich von Zadow <uzadow at libavg.de> wrote:

> Hi,
> I see what you're getting at, but...
>
> First, there is definitely no problem in adding windows-only code to the
> core. I'm sorry if I caused that misconception.
>
> Second, I've just moved our DirecShow camera support code to the public svn
> :-).
>

Awesome! I will try to get this working soon.

>
> Third, here is my vision for libavg camera support: It should be possible
> to include a finite number of camera classes that cover the camera types
> likely to be used with libavg. Off the top of my head, these are:
>
> - libdc1394v1, libdc1394v2 and Video4Linux2 for linux
> - libdc1394v2 and Quicktime for Mac
> - DirectShow and CMU for Windows
>

> 4 of these 6 classes are already supported in libavg.
>

I agree that support for these should cover our bases pretty well. I will
finish off my CMU camera implementation and submit a patch.

>
> libdc1394v1 should be deprecated as soon as v2 is in all distributions.
> Ideally, DirectShow should cover all camera needs under windows, but it's
> missing support for some advanced firewire features such as trigger and
> strobe, so adding CMU support would help. Quicktime would add support for
> all non-firewire-cameras under Mac OS X, but nobody has asked for, much less
> made an attempt to write a class for that.
>
> So, in effect, once we've got the support I've just outlined in core
> libavg, camera plugins should not be needed anymore. There could be new
> camera types from time to time (GigE comes to mind), but I really think
> support for new camera types should be added to libavg core as well.
>
> On the other hand, adding support for camera plugins would actually hinder
> the addition of new camera types, since it would provide a way to circumvent
> the LGPL - there is no legal reason to publish a plugin!
>
> Cheers,
>
>   Uli
>
> PS: You're right in that I didn't like VideoWrapper at first sight: It
> comes with a lot of dependencies, supports outdated proprietary APIs and
> really doesn't add anything beyond what DirectShow+CMU bring us.
>

Fair enough. I agree that it is not ideal, and only looked at it as an
alternative to writing a native DirectShow capture subsystem. With the DS
camera now released, I am fine letting this library go.

>
> On Nov 10, 2008, at 1:49 AM, Nick Hebner wrote:
>
> Well, my main reason for moving toward a pluggable camera subsystem is a
> perceived resistance to incorporating too much Windows support into the
> core. With this model, it is up to a libavg distributor to include
> subsystems relevant to the target platform. It also frees you the maintainer
> from having to maintain the code that could be implemented in a 3rd party
> plugin. In addition, it allows you to peacefully disagree with the choice of
> camera subsystem made by a 3rd party. For instance, you mentioned that the
> CMU driver looks good, but you might not be so thrilled with VideoWrapper.
> Well if camera plugins are not possible and you are not interested in
> supporting this library, then my only option is to hack the core, and create
> a new libavg branch that still is not officially supported and is difficult
> to keep up to date.
>
> If my perception is not valid, and there is willingness to add new
> Windows-only code into the core, then great, we can do that.
>
> I think that a project like this caters mainly to people who are working in
> unique environments and interacting with various devices, and I think that
> providing a way to easily extend all aspects of the library is a good thing.
>
> Thanks,
>
> Nick
>
> On Sun, Nov 9, 2008 at 1:07 PM, Ulrich von Zadow <uzadow at libavg.de> wrote:
> Hi Nick,
>
> we implemented node plugins to allow for project-specific node types.
> For instance, we're using the plugins right now to add  a fluid
> dynamics node for a wind channel simulation. This node wouldn't make
> sense in generic libavg because it renders stuff that makes little
> sense outside of that specific project.
>
> With that in mind: I'm not convinced that we need a plugin system for
> cameras. Where is the benefit over just implementing new camera
> classes and integrating them into the libavg core? OTOH: Camera
> support for windows other than DirectShow  would be great. In
> particular, the CMU 1394 software looks good at first sight because
> it's standards-based and doesn't require additional libraries and
> exposes lots of camera features.
>
> Cheers,
>
>   Uli
>
> On Nov 9, 2008, at 7:25 PM, Nick Hebner wrote:
>
> > Hey All,
> >
> > As I mentioned in an earlier email, I had some interest in writing a
> > plugin that implemented a new camera subsystem. Well with the new
> > generic plugin registration code in place and a few more changes, I
> > have been able to do just that. Attached is a patch adding a
> > SubsystemManager class that can be used to register and build
> > subsystem instances. Currently the only subsystem that this class
> > manages is cameras, but I just wanted to get something working on a
> > basic level before attempting anything too complicated. In designing
> > this functionality, I made a few assumptions.
> >
> > 1. There are a small number of subsystems that this class will
> > manage (e.g. DisplayEngine, AudioEngine, Camera, etc).
> > 2. Different subsystem types require wildly different initialization
> > information.
> > 3. Similar subsystem types require basically the same initialization
> > information.
> >
> > Based on these assumptions, I decided that the registration and
> > creation functions should be per-subsystem-type. I do not see any
> > merit in providing a single createSubsystem() and having all
> > subsystems implement a Subsystem interface. They are all handled too
> > differently to do so. Instead, I envision a register and create
> > function for each subsystem type.
> >
> > Registration functions will take a subsystem name and builder
> > function. The builder function will take initialization parameters
> > common to that subsystem type and return a pointer to an instance of
> > that subsystem.
> >
> > Create functions will take a subsystem name and the parameters to
> > pass the registered builder function.
> >
> > Because the number of subsystems is small and the parameters to a
> > subsystem are fixed, I do not see a need for the complicated Arg
> > passing mechanisms that are required by Nodes.
> >
> > I have updated the Windows build distribution with the example
> > camera subsystem plugins that I have developed (one using the CMU
> > 1394 driver, the other using the VideoWrapper library, you will need
> > to download these of course). This patch does not represent a
> > complete implementation of this idea, I just wanted to get some
> > thoughts on this. So, what do you think?
> >
> > Thanks,
> >
> > Nick
> > <
> > subsystem_plugin.patch>_______________________________________________
> > libavg-devel mailing list
> > libavg-devel at datenhain.de
> > https://mail.datenhain.de/mailman/listinfo/libavg-devel
>
> --
> Any technology distinguishable from magic is insufficiently advanced.
>
> Ulrich von Zadow | +49-172-7872715
> Jabber: coder at c-base.org
> Skype: uzadow
>
>
>
>
> _______________________________________________
> libavg-devel mailing list
> libavg-devel at datenhain.de
> https://mail.datenhain.de/mailman/listinfo/libavg-devel
>
> _______________________________________________
> libavg-devel mailing list
> libavg-devel at datenhain.de
> https://mail.datenhain.de/mailman/listinfo/libavg-devel
>
>
> --
> Any technology distinguishable from magic is insufficiently advanced.
>
> Ulrich von Zadow | +49-172-7872715
> Jabber: coder at c-base.org
> Skype: uzadow
>
>
>
>
> _______________________________________________
> libavg-devel mailing list
> libavg-devel at datenhain.de
> https://mail.datenhain.de/mailman/listinfo/libavg-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.datenhain.de/pipermail/libavg-devel/attachments/20081112/11edfbf0/attachment-0001.htm 