Video transmission from one computer to another computer over TCP

[constructionworker]

-30 FPS speeds are required for both cameras.

-The idea of creating a new server for each video is not bad, but I think the idea of a client for each video would be better.

Do you mean that the server architecture to connect to multiple clients should be similar to what we did in the previous example?this example.I tested this example by adding the receiver part.

When I tested it with the example I sent before, it makes the data flow smoothly. There is no slowdown at all.

[constructionworker]

Actually, the problem has been solved. Here Mark_Yedinak provided the basis for the problem, but the last example I provided and discussed in previous posts was based on this idea.To summarize the situation in general terms, if we send and receive video over TCP, using "unflatten to string" reduces the size of the data to be transferred, resulting in faster processing of the data. Then, providing data exchange with the multi-server method allows faster data transfer. This is how the problem was solved.

[Bob_Schor]

Sorry to chime in again at this late date, but do you really need multiple computers and client/server architecture?  A colleague of mine wanted to view image streams from multiple cameras (say 8), with the option to save videos (30 FPG, 640x480 RGB, if I remember correctly).  The key to getting this to work was to use a camera that transmitted images over TCP/IP, with each camera showing up in MAX with a slightly different IP.  The PC launched a series of "clones" (pre-allocated reentrant routines) that attached to a single camera and handled the IMAQdx setting up the camera, showing images (I think he only looked at one camera at a time), and saving the Image stream as an AVI file.  At noted in previous replies, handling this much TCP/IP traffic limits the number of simultaneous streams -- with 100-baseT, I think 4 cameras was easy, 8 was pushing it.  Needless to say, this works better on a fast multi-core CPU ...

[I think an attempt was made to do the same thing with conventional USB-2 Webcams, but hubs were a problem.  This was done about 8 years ago, so more modern technology might yield better outcomes ...].

Bob Schor

[constructionworker]

---

@Bob_Schor wrote:

Sorry to chime in again at this late date, but do you really need multiple computers and client/server architecture?  A colleague of mine wanted to view image streams from multiple cameras (say 8), with the option to save videos (30 FPG, 640x480 RGB, if I remember correctly).  The key to getting this to work was to use a camera that transmitted images over TCP/IP, with each camera showing up in MAX with a slightly different IP.  The PC launched a series of "clones" (pre-allocated reentrant routines) that attached to a single camera and handled the IMAQdx setting up the camera, showing images (I think he only looked at one camera at a time), and saving the Image stream as an AVI file.  At noted in previous replies, handling this much TCP/IP traffic limits the number of simultaneous streams -- with 100-baseT, I think 4 cameras was easy, 8 was pushing it.  Needless to say, this works better on a fast multi-core CPU ...

[I think an attempt was made to do the same thing with conventional USB-2 Webcams, but hubs were a problem.  This was done about 8 years ago, so more modern technology might yield better outcomes ...].

Bob Schor

---

Actually, I tested it with my previous example for 30 FPS 2 camera at 640-480 resolution. I was able to watch both videos at the same time. There is no noticeable decrease in transfer rate.
But for larger videos, I guess faster data can be sent using a server and multiple clients.
I just used the built-in ethernet port on computers.

By the way, there was some slowdown in the video due to the way of loading and reading the sample data shared by Mark_Yedinak.

I think it was because the client  were providing data flow over timeout.