libgphoto2 wrapper

[pfeatherstone]

I've recently needed to control a DSLR camera. And it turns out ffmpeg can't read them! All the tutorials online mention using gphoto2 command line tool, forward raw decoded YUV to a v4l2loopback virtual device then use ffmpeg or opencv to read that device. That seems a bit dumb. It would be better to wrap libgphoto2 and consume the YUV data directly. This shouldn't be too difficult.

[davisking]

Yeah if the api you have setup could transparently do that that would be real cool

[pfeatherstone]

I actually disagree. I think decoupling backends would be better. Otherwise, you might end up having to download, install and link to a library when you don't need to. Some users might want to use a gphoto2 wrapper without having to use the ffmpeg wrapper.

Eventually we could maybe have a unified wrapper, a bit like what cv::VideoCapture does, but then you're forced to pull in every dependency under the sun.

I envisage having dlib objects like:

• dlib::ffmpeg::demuxer
• dlib::gphoto2::demuxer
• dlib::v4l2::demuxer
• dlib::intelrealsense::demuxer
• ...

There are some APIs that ffmpeg currently doesn't handle, like Intel realsense and ghoto2. So having different backends are necessary.
For V4L2, ffmpeg supports that out of the box, but there is a use case where you want to read a camera device, but don't want the ffmpeg dependencies. We can provide that. It doesn't require a lot of code.

Anyway, in any case, I'm in favour of decoupling everything as much as possible, then down the line, if we really want to, have a unified wrapper. But that's providing syntactic sugar for the sake of it really.

[davisking]

Yeah, it depends. You could make it optional so when it's available then the other formats are supported. But only if the API you would want to have for it doesn't put API demands on the API in dlib. So it depends on the APIs of the libraries involved. But I take your point for sure. At a base level it's better to wrap C libraries, and let those wrappers have only the responsibility of nicely presenting the utility of that one library. Then to build higher level tooling on top of those C++ APIs. If that's what makes the most sense for this other library (IDK, I haven't used it, but I'll take your word for it :) ) then that's cool with me.