As you have described, G Web Development Software does not have explicit support for web cam streaming. These are some of the things I have done for different projects:
Send images over SystemLink Tags
The pattern there is to capture the images, convert them to the Data URL string format that can be displayed in the URL Image control on a WebVI, and write it to a SystemLink Tag. The forum Displaying LV Current Gen FP in NXG WebVI discusses that approach and uses capturing images of the LabVIEW Front Panel as an example but it is a similar concept.
Some Pros:
- The NI Web Server and tags can handle multiple connections from different WebVIs well reading tags or multiple applications publishing tags
- Works with tools and libraries included with LabVIEW + Drivers and G Web Development Development Software
- WebVIs are not trying to connect directly to the running LabVIEW application
- Tags have built-in robust access control / permissions
Some Cons:
- 1-2 Hz updates for tags may not be sufficient for all applications
- Some overhead encoding everything as a string to store as a tag
Send images over WebSockets
The workflow in LabVIEW would look like:
- Create a WebSocket server in LabVIEW. For libraries that can help make a WebSocket server see: How Do I Use WebSockets for Data Communication in LabVIEW?
- Wait for connections on the WebSocket server
- On connection start sending images captured over the WebSocket connection as binary. You likely want to use some compression like jpeg and keep the image resolution small for quick transfer.
- Manage the connection, in particular handling multiple connections (WebVIs opened in multiple tabs or a page is refreshed) and disconnects.
The workflow in G Web Development would look like:
- Open a WebSocket connection to the LabVIEW server
- Read for a binary response from the LabVIEW server. Use the Synchronous Image for WebVI example to efficiently pass the image to a custom control designed for efficient updates.
- Handle WebSocket disconnects and reconnection logic
Some Pros:
- There is no longer a server in the middle that both sides need to talk to so theoretically could have lower latency and higher throughput.
Some Cons:
- This is fundamentally a faster way of sending individual images compared to a network video stream protocol designed for efficient video streaming. Probably not building the next video streaming service this way (well with a lot of effort maybe you could like the zoom video conferencing app did).
- Have to manage how many clients you want to allow to connect to the LabVIEW application.
- The WebVI needs to know the url of the WebSocket LabVIEW Server to connect to. Some options:
- Have a static ip address / DNS name for that LabVIEW application that is well known
- Have the LabVIEW application publish its WebSocket server URL as a tag the WebVI can read. I've had a LabVIEW application publish its WebSocket URL to a tag regularly so I can use the timestamp of the tag last update as a watchdog.
- Have to figure out patterns for access control / permissions / security
Use camera hardware / software designed for browser integration
Some webcams have built-in servers that can give you a URL that can be used with the URL Image control. For example in the Embed Content into a WebVI example the URL Image control is given a URL to an mjpeg video stream from a webcam.
There is probably web cam software that can create servers for video formats compatible with the browser native HTML <video> tag. While G Web does not have support for the HTML 5 <video> tag out of the box one could use the JavaScript Library Interface and the Placeholder HTML Container control to use one as described in the topic Creating UI Elements with JavaScript.
Milan
