Streaming texture over network

vvvv beta question
#1

Hi vvvvorum,
I’m trying to stream an EX9.Texture over network with TCP protocol. I red the documentation page and looked at the girlpower example but, as listed in the patch, “some frames will be dropped or even the whole stream will be received wrong. Some more logic will be done…”

How can I fix this problem? Any example patch?

Look at girlpower>Video>12_Network_Streaming.v4p

Thanks guys…

#2

I saw only now that the example in girlpower launches a cmd window with /c argument and if I move the cmd window foreground the stream works fine. I don’t understand what is the function on the cmd window.

Any help to try to understand?

Thanks…

#3

That’s just a link to a patch, which path you can see in the title bar once opened.

Then on my senior machine - read it old - if I put any other non vvvv window in front the renderer’s content is quite fine, because it goes to 30fps. If you create a mainloop node and set foreground to 30 fps you’ll see it’s fine.
That said, I really don’t know how to improve fps performances.

Could this happen because original collada animation it’s based on 30fps?

Let’s hope that someone more expert than both of us will give a some tips.

#4

@@h99: yep, you are right. What stupid reason! :)

Someone can give us some tips to implement the logic for the receiver patch as listed in the girlpower example?

#5

To be honest, I don’t think there’s anything stupid in that patch, or related to that patch. I’d rather say I’m ignorant on topic, thus my question.
Anyway, patch any other content, sound-reactive maybe?, and see if it runs smoothly on “client” renderer with >30 fps.

#6

@@h99: there’s a misunderstanding. I’m stupid not your answer/question! Stupid beacuse I didn’t understand that the streaming behavior was influenced by the fps changing of vvvv in background/foreground mode.

#7
#8

try tcpspout ;)

#9

@@microdee: TCPSpout works for you? I downloaded Spout 2.004 and run Spout vvvv sender patch, but TCPSpoutServer doesn’t show anything in the SpoutSender menu.

I’m using b34.2 x64 on Win10 x64.

Any suggestion?

#10

did you follow vvvv examples in the spout folder?

#11

also instead of using TCP try via ZeroMQ sockets that do exactly that kind of “more logic” that is needed here.

#12

@@joreg: I already tried ZeroMQ but seems it doesn’t work. Look at the attached patch. Where I’m wrong?

@@microdee: yes, I followed vvvv examples in the Spout folder. Any tips?

Streaming Texture ZeroMQ.v4p (20.8 kB)

#13

maybe we can ask @velcrome to chime in here re zeroMQ

#14

If I modify ZeroMQ help patch or copy dealer and recieve nodes in a new patch they work. The patch attached in my last post is compiled from empty patch.

#15

@idab I have seen similar behavior with other contributions, where a node is red, but you can double-left-click it and it shows up in the list, and you can then select it and it works.

This looks like a vvvv bug that has to do with paths. I have noticed when this happens, hovering over the red nodes will show (%VVVV%) and/or an x64 path under x86 or vice-versa.

But still after fixing your patch, I do not see anything received, and the send success goes off after a few seconds.

Ahhh, you do not have “Bind” turned on in Herr Inspektor for the send dealer! Then it works. So as a note, one and only one of the dealers needs to bind to the socket.

#16

Yeah, you always need one Socket to bind any used endpoint (i.e. address). Only then, one (or many) other Sockets which are connected to that endpoint will be able to communicate over that endpoint.

Technically, it does not matter, which Dealer is binding, this is a design decision you have to do yourself (for example if you send Textures from many devices to one machine, you’d bind the receiver, if you send Textures from one device to many, you’d bind the sender)

ask yourself, what kind of communication is it, if you consider scaling up from the beginning

if it is a 1:1 relation, you might want to use two Pair (Network ZSocket), but trust me, that hardly ever scales well.

if it is 1:n or n:1, you will need to Bind the 1, but not the n

if you find yourself in need of an advanced n:n situation, it will be necessary to dissolve it into a n:1 <-> 1:n situation (kindly helped by Proxy (Network ZSocket))).

A few weeks back I was talking about this Configuration setting in Inspector with joreg. I thought, that it is ok to be only accessible with Herr Inspector, because one has to decide what to bind very conciously, instead of just switching it on and off until it works.
Would it have helped you, if the Bind choice would have been a regular pin?

Streaming Texture ZeroMQ.v4p (23.2 kB)

#17

Yep, If I bind one dealer it works. I didn’t see the configuration pin in the Inspector.

I have to send a texture from 1 PC to 4 PCs. The relation is 1:4 but if I bind the 1 and not the 4 the 1 Dealer node becomes red and nothing works. It works only if I bind the 4 Dealer and not the 1. Something wrong?

Also some frames of the stream drop during the streaming. I try to change texture resolution and fps of the sender/receiver patch but I have always some drops. Any suggestion to fix this problem?

#18

hey @idab

thanks for the feedback on the config pin.

the behaviour you are describing is actually intentional, you unwittingly discovered a load balancing mechanism:
each time you hit send, only one of your four dealers gets the message (like a real-life dealer really, only one player gets a specific card when the deck is dealt, this is done in a fair and circular way).

so a quick fix would be to simply select your raw payload as many times, as you have recipients (4 in this case), so each recipient gets a copy of “the card”.

however, your scenario would probably be served better, if you use a publisher/subscriber pattern, where receivers can express interest to the sender, and everything else is done automatically.

#19

@@velcrome: thanks man! Useful network tips. I’m not exactly a network guru… :)