Open windelbouwman opened 2 years ago
Its only used by depthai-core as of right now. The fork is from: https://github.com/openvinotoolkit/openvino/tree/master/src/plugins/intel_myriad/third_party/XLink
As of right now, the usage is equivalent to other core dependencies, and I think is adequate as the code isn't as relevant to core in terms of number of changes to it. (I guess if we'd work more on it, we could merge it in)
Thanks for the upstream link, that's useful!
Main advantage of merging xlink into the depthai-core repo would be packaging effort. If depthai-core is to be packaged as deb/rpm/pacman/emerge/bitbake, then each recipe will probably not use hunter, and will have to face this extra repository. Since xlink is only used in depthai-core, there is no real benefit in having it as a seperate reposiroty.
One additional benefit of merging xlink is being able to browse code by opening the depthai-core in vs-code, if xlink is there, the headers are found, and code can be navigated easily. How is this done at this moment?
I hope I can convince you to merge xlink into depthai-core, as I created a bitbake recipes for depthai-core, and its dependencies, and it is in my interest to reduce the amount of packages / recipes I have to create :).
Has the status changed? I am looking to connect to the OAK cameras via C#. I don't really care to use depthai-core
unless I need to. If this repo is current and provides everything needed to talk with the cameras standalone, that's what I'm after. So, specific questions.
1) Is this repo everything I need to establish comms with the cameras, stream video feeds?
2) beyond this repo, is there anything in depthai-core
I'm likely to want as well? I do not care about doing any AI for VPU-level processing. I just want to get the video / data feeds. Perhaps core does something additional like encode the data? Or higher level abstractions pertaining to the device object model?
@aggiehorns the status have not changed yet. No, the core
is the main requirement, XLink is only the "protocol" / communication layer / library that core relies upon.
We might merge XLink into Core one day, if we C++ify it also, but only when we iron out some issues that it has at the moment (or we'll submodule it).
Gotcha, and I now see it's pure C. There's nothing about that to prevent including it in the same core repo though. Is there something I'm missing? To build core I just need to pull this repo as well and manually copy the files into the core directory structure so they can be included....?
@aggiehorns yes, not an issue per se, just that if we'd merge codebases, I'd bring it under dai
namespace, etc...
You may do this already, clone wherever/submodule/etcc and then do cmake [build/dir] -D XLINK_LOCAL=[path/to/xlink]
Rewrite to C++ sounds like a good idea, and a good first step in this direction is in my opinion to merge the xlink repository as-is into this repository. This makes this transition simpler as well.
This xlink fork seems only used at the moment in the
depthai-core
library.Is this library used anywhere else? If not, it might be simpler to include this xlink code in a subfolder in the depthai-core repository.
Notable benefits:
Downsides:
This is an idea I had when browsing through the code-base, but maybe I'm missing something? Is there any reference to the original xlink library? I was not able to find it.