Suggestion for better bandwidth for non-http transmitting of matrices

[isubasinghe]

This can be implemented in the web browser as well, but it will be a bit harder to do so, im only providing a very simple example.

Better bandwidth may be achieved if the jpeg frame being sent is the difference between the previous Matrix and the current matrix we are about to send. This is because for small periods of time, not much in the matrix would change significantly, this means subtracting these matrices would leave a lot of values near zero, this means when we do jpeg compression on this matrix, it is more efficient. If you want more detail you can look up how jpeg and discrete fourier transforms work.

Unfortunately I am unfamiliar with the opencv interface for go lang but here is an implementation in c++. If you do implement this the client will have to change as well, it will have to add the incoming matrix to the previous matrix it received.

As you can see the size of the data to transmit is a lot lower.

[gen2brain]

Thanks for suggestion. That looks complicated, what about client, you have example of that? I wanted to switch html to draw images with WebGL by default (there is an option now), that would further complicate everything.

Also, what about CPU usage, that would probably increase it. I guess that in Go Image At() needs to be used to get RGBA values for the pixel etc.

[isubasinghe]

It isnt really much complicated, it just looks that way because of c++ and opencv library. All you would have to do is have the ability to change the pixel values of a webgl frame(?, sorry i have no idea about webgl).

0. [Server]: Send the frame size first. store into ->fsize

1. [Server & Client]: First you would have a initial previous frame in both server and client, say an all black image of size fsize. Store into -> prev

2. [Server]: fetch next image. store into -> next

3. [Server]: get the difference in the previous one and and next. Store into -> diff

4. [Server]: Jpeg compress into a buffer. Store into -> jpegbuff

5. [Server]: Send jpegbuff to client

6. [Client]: receive jpegbuff. Sotre into -> jpegbuff

7. [Client]: uncompress jpegbuff. Store into -> diff

8. [Client]: Add diff to prev. -> Store in next

9. [Client]: next is the received frame, print it out in the browser.

10. Go to 2

CPU usage isnt a worry at all, in my case I have to do an extra 307, 200 integer operations (640x480). This is obviously really tiny compared to what modern computers can do. Lets assume that we have a computer with a clock rate of 1 mega hertz, that is 1, 000, 000 cycles per second, lets also assume this cpu takes 1 cycle to add a 32 bit integer( note we use 8 bit integer in our matrix, meaning ours should be faster), we still can compute the matrix values in 0.3 seconds( Note that even in 1990 cpu speeds were about 25 Mega hertz, meaning back then we could process this in 0.012 seconds).

In conclusion cpu usage is insignificant.

I am actually writing something really similar to your project, i will update with a link after november 14th ( I have my university exams until then)

[isubasinghe]

@gen2brain The process for multiple clients is actually way more complicated, you need to keep the buffers in sync, I think this approach to save bandwidth is not worth the time. Closing this issue