[Gambas-user] Not a Gambas, but a C++ question: GTKMM, Video and... Threads!

[ML]

On 21/11/18 23:45, Benoît Minisini wrote:
> Le 22/11/2018 à 02:24, First Last a écrit :
>> I want to apologize because this is for a C++ project, not a Gambas one.
>> I'm really clueless at the moment, and I know there are people in
>> this list that knows an awful lot, so I'm trying to pick someone's
>> brains.
>> Once upon a time, I got myself a coupla pan-tilt IPCameras. Nothing
>> fancy really.
>> Zero Linux support, they offer Mac and Win drivers, apps, and maybe
>> even chocolate. But not for Linux.
>> Contacted the manufacturer, they sent me a nice NDA -which I signed-
>> and afterwards an SDK with Linux, Mac and Win dev libs, but just Mac
>> and Win examples.
>> The SDK has an absolute lack of Linux examples, as expected. Also, as
>> I am a mere mortal and not a multibillion corporation, the maker will
>> give me exactly zero support.
>> Because of the NDA I cannot go to details, but let's say I
>> successfully connected to one of the cams (the other, an older model,
>> makes the SDK segfault).
>> I can connect and authenticate to the cam, and I can spawn a video
>> retrieval thread from the main app, which seems to work. All of this,
>> again, in C++ and GTKMM.
>> The worker thread retrieves video frame by frame in a buffer, along
>> with camera events. So far so good, it works.
>> Problem 1: Cannot figure how to dump these frames to a GTKMM window,
>> control, or surface (the Win example uses Direct3D, not applicable
>> here). Can anyone point me in the right direction?
>> Problem 2: I will have to cross the thread boundary to do this.
>> Again, not a clue. Help?
> You can create a pipe in the main thread with the pipe() system call.
> Then the worker thread will write the frame to the pipe, and the main
> thread will read the frames from it.
> That way, your main thread will just have to call select() on the pipe
> to get the data when it is available.
Ok, back to the drawing board. And to the pipe() man pages.
Never thought of them pipes. Big thanks!
>> The SDK is 32bit only. My main machine is 64bit. I am using VSCode in
>> a 32bit VM to develop, but I would really like to have a Gambas
>> version eventually, like in a lib so anyone else can use it. Also,
>> the Win example in a 32bit Win VM does not show video, but it does
>> work in the real hardware. So, I want to make sure that when I don't
>> see anything is not because of the VM, but because something went wrong.
>> Problem 3: Is there any way to make Gambas work as a 32bit, both in
>> the IDE and the interpreter, in a 64bit machine?
>> Problem 4: If it is at all possible to have a solution for Problem 3
>> above: How do I solve the threading issue in Gambas?
>> Thanks, you may now continue talking BASIC.
>> zxMarce.
> Then I suggest you make a 32-bits executable that just implements the
> worker thread, and that writes the frame data to a named pipe.
> Then another 64-bits process will run this 32 bits executable, tell
> him which named pipe to use, and will be able to get the data from
> this pipe.
> That way, the main process can be written in any language, and can do
> what it wants with the frames.
> The only problem you will have is converting the camera frame data
> format into an image that can be displayed by your graphical toolkit.
> But maybe your SDK already handles that?
I will deal with video frame conversion when I have something to put the
frame data on.
For the time being the SDK API has some video format constants defined;
the Win example uses its own named constant of YUYV422 as format, but
Google does not have a clue what that might be.
Closest match is YUV422 and maybe I can use that as real format
definition: The SDK -being chinese- has several obvious typos in
definitions, so maybe this is one of the less obvious for the untrained eye.
> Note: afaik pipes are the fastest and easiest way to exchange data
> between processes or threads on Linux. Shared memory may be faster
> (for big amount of data), but requires additional synchronization
> primitives, so it is harder to use correctly.
> Regards,
Okeydokey. So this reeks the smelly smell of needing a 32bit
"daemon/helper" of sorts that manages comms, buffers, etc, used by a
<whatever>bit app that shows the reality in glorious Technicolor to the
world. Great!
See? I was sure someone would come to the rescue! Thanks again, Benoît.

zxMarce.