<br><br><div class="gmail_quote">On Wed, Nov 12, 2008 at 11:49 AM, Ulrich von Zadow <span dir="ltr"><<a href="mailto:uzadow@libavg.de">uzadow@libavg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="">Hi,<div><br></div><div>I see what you're getting at, but...</div><div><br></div><div>First, there is definitely no problem in adding windows-only code to the core. I'm sorry if I caused that misconception.</div>
<div><br></div><div>Second, I've just moved our DirecShow camera support code to the public svn :-).</div><div></div></div></blockquote><div><br>Awesome! I will try to get this working soon.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><br></div><div>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:</div>
<div><br></div><div>- libdc1394v1, libdc1394v2 and Video4Linux2 for linux</div><div>- libdc1394v2 and Quicktime for Mac</div><div>- DirectShow and CMU for Windows</div><div></div></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=""><div><br></div><div>4 of these 6 classes are already supported in libavg.</div></div></blockquote><div><br>I agree that support for these should cover our bases pretty well. I will finish off my CMU camera implementation and submit a patch.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div></div><div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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!</div>
<div><br></div><div>Cheers,</div><div><br></div><div> Uli</div><div><br></div><div>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.</div>
<div><div></div><div class="Wj3C7c"><div></div></div></div></div></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><div class="Wj3C7c"><div><br><div><div>On Nov 10, 2008, at 1:49 AM, Nick Hebner wrote:</div>
<br><blockquote type="cite">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.<br>
<br>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.<br><br>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.<br>
<br>Thanks,<br><br>Nick<br><br><div>On Sun, Nov 9, 2008 at 1:07 PM, Ulrich von Zadow <<a href="mailto:uzadow@libavg.de" target="_blank">uzadow@libavg.de</a>> wrote:<br> Hi Nick,<br> <br> we implemented node plugins to allow for project-specific node types.<br>
For instance, we're using the plugins right now to add a fluid<br> dynamics node for a wind channel simulation. This node wouldn't make<br> sense in generic libavg because it renders stuff that makes little<br> sense outside of that specific project.<br>
<br> With that in mind: I'm not convinced that we need a plugin system for<br> cameras. Where is the benefit over just implementing new camera<br> classes and integrating them into the libavg core? OTOH: Camera<br> support for windows other than DirectShow would be great. In<br>
particular, the CMU 1394 software looks good at first sight because<br> it's standards-based and doesn't require additional libraries and<br> exposes lots of camera features.<br> <br> Cheers,<br> <br> Uli<br> <div>
<div></div><div><br> On Nov 9, 2008, at 7:25 PM, Nick Hebner wrote:<br> <br> > Hey All,<br> ><br> > As I mentioned in an earlier email, I had some interest in writing a<br> > plugin that implemented a new camera subsystem. Well with the new<br>
> generic plugin registration code in place and a few more changes, I<br> > have been able to do just that. Attached is a patch adding a<br> > SubsystemManager class that can be used to register and build<br> > subsystem instances. Currently the only subsystem that this class<br>
> manages is cameras, but I just wanted to get something working on a<br> > basic level before attempting anything too complicated. In designing<br> > this functionality, I made a few assumptions.<br> ><br> > 1. There are a small number of subsystems that this class will<br>
> manage (e.g. DisplayEngine, AudioEngine, Camera, etc).<br> > 2. Different subsystem types require wildly different initialization<br> > information.<br> > 3. Similar subsystem types require basically the same initialization<br>
> information.<br> ><br> > Based on these assumptions, I decided that the registration and<br> > creation functions should be per-subsystem-type. I do not see any<br> > merit in providing a single createSubsystem() and having all<br>
> subsystems implement a Subsystem interface. They are all handled too<br> > differently to do so. Instead, I envision a register and create<br> > function for each subsystem type.<br> ><br> > Registration functions will take a subsystem name and builder<br>
> function. The builder function will take initialization parameters<br> > common to that subsystem type and return a pointer to an instance of<br> > that subsystem.<br> ><br> > Create functions will take a subsystem name and the parameters to<br>
> pass the registered builder function.<br> ><br> > Because the number of subsystems is small and the parameters to a<br> > subsystem are fixed, I do not see a need for the complicated Arg<br> > passing mechanisms that are required by Nodes.<br>
><br> > I have updated the Windows build distribution with the example<br> > camera subsystem plugins that I have developed (one using the CMU<br> > 1394 driver, the other using the VideoWrapper library, you will need<br>
> to download these of course). This patch does not represent a<br> > complete implementation of this idea, I just wanted to get some<br> > thoughts on this. So, what do you think?<br> ><br> > Thanks,<br> ><br>
> Nick<br> > <<br> </div></div>> subsystem_plugin.patch>_______________________________________________<br> > libavg-devel mailing list<br> > <a href="mailto:libavg-devel@datenhain.de" target="_blank">libavg-devel@datenhain.de</a><br>
> <a href="https://mail.datenhain.de/mailman/listinfo/libavg-devel" target="_blank">https://mail.datenhain.de/mailman/listinfo/libavg-devel</a><br> <br> --<br> Any technology distinguishable from magic is insufficiently advanced.<br>
<br> Ulrich von Zadow | +49-172-7872715<br> Jabber: <a href="mailto:coder@c-base.org" target="_blank">coder@c-base.org</a><br> Skype: uzadow<br> <br> <br> <br> <br> _______________________________________________<br> libavg-devel mailing list<br>
<a href="mailto:libavg-devel@datenhain.de" target="_blank">libavg-devel@datenhain.de</a><br> <a href="https://mail.datenhain.de/mailman/listinfo/libavg-devel" target="_blank">https://mail.datenhain.de/mailman/listinfo/libavg-devel</a><br>
</div><br> _______________________________________________<br>libavg-devel mailing list<br><a href="mailto:libavg-devel@datenhain.de" target="_blank">libavg-devel@datenhain.de</a><br><a href="https://mail.datenhain.de/mailman/listinfo/libavg-devel" target="_blank">https://mail.datenhain.de/mailman/listinfo/libavg-devel</a><br>
</blockquote></div><br><div> <div><div><div>--</div><div>Any technology distinguishable from magic is insufficiently advanced.</div><div><br></div><div>Ulrich von Zadow | +49-172-7872715</div><div>Jabber: <a href="mailto:coder@c-base.org" target="_blank">coder@c-base.org</a></div>
<div>Skype: uzadow</div><div><br></div></div></div><br> </div><br></div></div></div></div><br>_______________________________________________<br>
libavg-devel mailing list<br>
<a href="mailto:libavg-devel@datenhain.de">libavg-devel@datenhain.de</a><br>
<a href="https://mail.datenhain.de/mailman/listinfo/libavg-devel" target="_blank">https://mail.datenhain.de/mailman/listinfo/libavg-devel</a><br>
<br></blockquote></div><br>