I would like to use Fugstream for streaming a black/white video to my pc, but sadly, it doesnt work at UDP and (working) TCP has an remarkable delay. So, I thought about a workaround:
I do need a BW-video, which is actually 1bit each pixel only.
My resolution is quite small 400x166px - in fact I need 66400bit/sec to be transfered. (I think its possible to reduce this amount to a forth of it - 16600)
Sketch1:
Is it possible to take two PCs and boygroup them. Take FugStream at no.1, using MEM to get video and read out all pixel by pipet.
This spread would be transfered by boygrouping to Pc no.2. And reorganized - somehow, still no idea how to do it - into a BW-video.
Sketch2:
I get video by FugStream/MEM as well, but put it into Contour-Plugin first and transfer contour-data by boygrouping only. Reorganize it in BW-video as well.
I never did boygrouping and have just a diffuse idea how it is working. As far as I know its kind of synchronized for marked io-boxes.
Some comments or suggestions are highly appreciated.
Ohh, by the way.
Udp help patch is not working well, because as far as I’ve seen Udp node is working with one node per patch only. So, in help patch sending and recieving there’s always a second node blocking it (and the help as well).
It’s the “see here also:” node.
thnaks for editing the VideoStreaming page. but i’d say maximum udp packet size is typically 1500byte! if you send the .jpg AsString you get compressed data already, so thats ql. but the resolution/size limit cannot be calculated that easily. would you agree?
Ohh, Joreg if you say it - its probably true ;D Just what I recognize is, that you cant go higher than 65535. Somewhere in web I read this as well. But in fact, i dont know how its compressed in that AsString node.Anyway, feel free to correct that calculations. Im not to deep in it.
But always nice to see how easily V4 works.
finally had the time to dig into udping, and here are the details as i understand them now:
the maximum udp packet size is indeed 65507bytes, which are 64k minus a header of 28bytes. the 1500bytes i mentioned above are the typical mtu-size at which udp packets are being fragmented and sent as individual ip-packets and refitted together on the receiver side by the ip network layer. the mtu-size also includes the mentioned header, so the biggest unfragmented packet to send via network is typically 1472bytes and to make optimal usage of fragments you’d try to fill your packages up to multiples of 1472bytes. note though that packages whose fragments are not completely received are trashed completely, so it seems to me that the risk of packetloss increases with fragmentation.
an mtu-size of 1500bytes seems to be default on windows systems, but may vary in networks and can even be changed manually. also switches and hubs may introduce different mtu-sizes! a way of finding the mtu-size in your network seems to be using the ping command. in a console type:
ping -f -l 1472 192.168.0.x
like this you ping a specified ip of your network with a non-fragmentable packet of size 1472. this will work with mtu-sizes of 1500bytes, but trying more than 1472bytes will return an error.
understanding that, i found that there is currently a limitation of 8k in the UDP (Network Server) node (which is the udp-receiver), while UDP (Network Client) (the udp-sender) can already send up to a maximum of 64k-28bytes. those 8k seem to be a good default maximum for udp-servers. beta>16 will have an additional BufferSize pin on the udpserver, that will allow you to experiment with buffersizes up to 65507bytes.
the value that comes out of Length (String) is already bytes and thus doesn’t need to be multiplied by 8. then you’ll see that you’re currently stuck with ~8k of imagesize.
since you’re using jpg compression (which is good) it doesn’t make sense to specify X1R5G6B5 as the texture format on sender/receiver sides, as .jpg does its own compression anyway, indee the picturequality should be better if you leave the texture at 24bit.
the ; as delimiter on the receivers UDP (Network Server) doesn’t make sense, doesn’t seem to harm either.
