GNOME Bugzilla – Bug 666385
phoenix: Add source element for Active Silicon Phoenix framegrabbers
Last modified: 2014-01-24 12:16:41 UTC
Created attachment 203693 [details] Five patches adding phoenix plugin to gst-plugins-bad Active Silicon Phoenix framegrabbers [1] support Camera Link, CoaXPress, HD-SDI, and LVDS. This has only been tested with a PHX-D48CL-PE1 board (Camera Link), but should work with any other board supported by the Phoenix SDK. Development and testing was under Windows Vista, however the provided Makefiles have been tested for proper building (but not testing) under Linux. Unfortunately the kernel driver and libraries [2] are not publically available, but of course they are useless without a physical board. [1]: http://www.activesilicon.com/products_fg_phx.htm [2]: http://www.activesilicon.com/products_sw-phx.htm
Is that not pointless to add to -bad if we can't even build it if the libs are secret ? Or am I misunderstanding what you mean by "the kernel driver and libraries [2] are not publically available," ?
(In reply to comment #1) > Is that not pointless to add to -bad if we can't even build it if the libs are > secret ? > Or am I misunderstanding what you mean by "the kernel driver and libraries [2] > are not publically available," ? They aren't secret, it's just that the vendor (Active Silicon) doesn't provide a public download of these files, rather after you purchase the physical card they'll provide the files (via a password protected site). I'd prefer them to post them for download publically, as they aren't of use anyways without the physical card. I thought it would belong in bad because there are HD-SDI framegrabbers (a consumer or at least prosumer standard) supported by this in addition to the more scientific/industrial-oriented standards. If there's another place to put this I'd be happy to do so.
Any thoughts on where this plugin and others like it might belong? We also have plugins for National Instruments IMAQ [1], Euresys MultiCam [2], and will create ones for Matrox [3], EDT [4], Imperx [5], EPIX [6], and Teledyne DALSA [7] in the coming year. These are all products supporting machine vision standards like Camera Link [8] and CoaXPress [9], but many also support standards with wider use like analog (NTSC/PAL/LVDS) and HD-SDI. It seems like these plugins might be too niche to even belong in gst-plugins-bad, so perhaps should belong in a new plugin set with a name like gst-plugins-vision. Unfortunately, it would be difficult for me to create and directly maintain such a public facing repository given my current situation. I suppose the best I can do is to keep posting patches here and hope that someone else with an interest in this area creates such a repository. -Josh [1]: http://sine.ni.com/nips/cds/view/p/lang/en/nid/201716 [2]: http://www.euresys.com/Products/MultiCam.asp [3]: http://www.matrox.com/imaging/en/products/frame_grabbers/ [4]: http://www.edt.com/digital_video.html [5]: http://www.imperx.com/framegrabbers [6]: http://www.epixinc.com/products/index.htm#divtab1 [7]: http://www.teledynedalsa.com/mv/products/framegrabbers.aspx [8]: http://en.wikipedia.org/wiki/Camera_Link [9]: http://www.coaxpress.com/
Just a note that we now also have plugins for the EDT framegrabbers (Camera Link), and for the National Instruments IMAQdx library (USB/DirectShow, GigE Vision, FireWire/1394 IIDC, and soon USB3 Vision). EDT is nice in that they freely provide the source code for everything, but of course you need the physical board. IMAQdx has no hardware component, but you'd need a software license. I'm not going to bother making these into a patch for gst-plugins-bad, but if someone has a plugin set where these would fit I'd be happy to create patches for it. Also note that everything is in 0.10 now, but we're hoping to port everything to 1.0 by the summer.
I think it's ok to have them in -bad, they just need to be marked specifically with the license of these libraries.
To recap we currently have seven source elements: - Active Silicon Phoenix: HD-SDI, Camera Link, LVDS - EDT: Camera Link - EPIX PIXCI: analog, LVDS, Camera Link - Euresys MultiCam: analog, Camera Link - IMPERX FrameLink: Camera Link - National Instruments IMAQ: analog, parallel digital, Camera Link - National Instruments IMAQdx: GigE Vision, FireWire, USB3 Vision Do you think it's ok to add all of them to -bad, or just the ones that support consumer interfaces? I was also thinking it's become more feasible for me to create a separate plugin set gst-plugins-vision, but I'll go with whatever is deemed best by you.
For the one that only need a header for a special kernel interface, I would include the interface file in the code (assuming header is GPL or public domain). If including the header is not possible (even though that mean the driver infridge on kernel GPL), I would add configure-check to compile it out if missing. If one need a helper library, I would be more careful, and put it in some other repository with appropriate licence. In the end, unless there is a legal blocker, they all have their place in -bad.
Ack, they're not really different to the linsys or decklink elements in bad.
Unfortunately most machine vision work is done on Windows, so half these framegrabbers don't even support Linux. The other half I haven't even gotten a chance to try on Linux I'm embarrassed to say. Certainly on Windows all of these require a vendor provided library to link against. So to just get it out, I've finally got around to pulling out irrelevant files, and have created gst-plugins-vision: https://github.com/joshdoe/gst-plugins-vision If any of these are suitable to be moved to -bad, I'll be happy to do it, but I'm guessing most aren't. Unfortunately the cmake build is out of date, and I've been using an ugly VS2010 solution because it was most expedient at the moment, a long time ago. Otherwise, I hope someone can find this useful.
Ok, so let's close this bug here then and you just submit whichever plugin you want moved to bad?
Yes, I think that's best.