Video to DMX data

vvvv beta question
1

Ive quite a large pixel mapping project which were currently R&D’ing and were trying to cut down the amout of processing the show computer has to do.
I was thinking of a way of taking the color data from the pipet which is sampling the video and somehow saving it at 30fps (probably less) with the ability to play it back withouth the need for the PC to use allot of its processing power on the pipet node.

Anyone done anything similar? Not too sure where to start but expect its going to be a good learnign experience trying!

2

http://vvvv.org/tiki-index.php?page=tonfilm-Patches
I’d have a look at toms FFT recorder, that should do it with some adjustments, the text reader plugin that lets you read line by line will also help I imagine!

3

What about a kind of ArtNet-DMX record and playback patch?

could be a universal thingi.

4

Hi catweasel, thanks for that, looks like a good starting point.
Yeah, Kalle, youve put ino words exacty what im trying to acheive ;-)

5

i think you will more easily saturate your Artnet-Ethernet than really have a problem with the performance of Pipet. Pipet is somehow slow; but in the same sense Ethernet is really slow.

What box you want to play back the DMX with? if its a PC based solution, i dont see any advantages in separating the generation part from the playback part.

6

Hi Oschatz, yeah, we found out that vvvv artnet/Ethernet is slower than the GrandMA )as you would expect), but in this case its a good thing as the LED driver nodes couldn’t process the data quick enough but worked well with vvvv, the issues im anticipating is the processing power needed to sample “possibly” 40,0000 pipet locations and mapping it to obviously 40,000 pixels, personally im not sure how even a pc with extreme processing power will handle it, but the company are pretty set on doing it this way due to the endless fexibility!

Not quite sure how Ive found myself in the middle of this project but i know its going to be a tremendous learning curve, or R&D.lol

I patched a DMX recorder from tonfilm’s patch which worked well for lower resolution but hit critical mass on my laptop at about 80x80 sample resolution.

Anyone any thoughts?

7

40,000 x3 (rgb) /512 = 234 universes, even if its just 1 channel per node, thats a lot, pixelmad whichis dedicated to pixel mapping, I think only does 60 universes, I think you may need to network multiple machines to do this.
As for the playback hitting critical mass wheres the bottle neck? Have you looked at the debug ticks? I’ve done higher than 80x80 with pipet on its own, so I imagine its in the file reader…?

8

Yeah, it is allot! Should get the final pixel count after New year and work backwards from there. We managed 70 universes quite easily sampling low res video though each universe wasn’t completely “full”
Yeah cat, i tend to agree about networking multiple machines, bring on the long days an late nights!

9

Whats the latest on this project… Ive been involved with this type of application. There are many solutions for distributing large volumes of 485 data over ethernet. DMX is the issue… you might be better looking at a baud independent latch protocol, but that would mean coming up with DMX converter in to the Fixture… or looking at a possible TTL solution that would allow your fixture to do some of the processing.

Our Solution in the past has been distributed processing, from Software/ PC (ethernet) to Network Swtich (485) to Protocol Converter (TTL) to Fixture.

The Result
120 RGB LED pixels @ 30FPS over Single 485 line @ 115K

10

hi john,
i do not really get the clue?

120 rgb-pixels over a single dmx universe with 30 FPS are IMNSHO also possible?

11

Im running 4956 rgb pixels at the moment via artnet (42 universes),on some custom “Colorweb” copy and im easy hitting 30fps on my humble 2ghz Asus. vvvv processes the data incrediby well, the only issues ive found as pointed out by Oschatz is using multiple pipets to sample an image uses alot of processing but still produces phenominal results. DMX is a bit tricky for this scale of controll, it would be nice to send out 3000bytes in one packet instead of 512.

12

Hi Guys…

Its a bit cryptic Sorry I was in a hurry… I’m very very new to vvvv but its exciting and has a lot of possibilities.
However reading the thread I was curious about the processing issues….

We regularly process way more than 40,000 pixels and mapping points, from a box standard PC Its only when we get to 100,000s of nodes that we start looking at high end PCs and we are looking at projects with 6,000,000+ LED Pixels… err that’s a bit different… and just finishing a project with AL using ARTNET in Macau.

Anyways… The point I was poorly attempting to make was when you start sending multiple DMX universe data from a PC or Controller to 1000,s of nodes you very quickly run in to bandwith issues. Unless you have lots of cash for nice pieces of hardware and even then its very problematic…. Philips had a nightmare with just 20,000 channels on the Bosporus Bridge project granted a bridge is one of the worst places on Earth you would want to place digital networks.

My point about 120 RGB LED Pixels… this was not based on a single DMX universe, but a single 485 cable and at half the speed of DMX. Or to put it another way…240 RGB LED Pixels on a single 485 cable @ DMX speeds. Let me know if this make it a little clearer…

Digipic… ya I agree 5000 rgb pixels should not present and major issues in processing or bandwidth, but 40,000 and syncing the playback without a latch protocol may present additional interesting late night conversations. On the bright side if you have Wayne and his guys working on this you are in good hands… AL guys are cool and fun to work with.

As to your control packets, sending less data is always better than sending more :-) when its comes to Video Walls or lots of Nodes, Are you sending all 512bytes of data, can you send less to control pixels. Not sure if ARTNET supports data compression… I don’t think so… However if you have gone down the route of ARTNET and DMX, changing the protocol is going to prove difficult.

For the record, I don’t use DMX… its just too limiting and the hardware involved is expensive, I do use a serial protocol but the overhead is way smaller then DMX and its a latching protocol… SO we send all the data at a specific time only once and then send a global latch command, this ensures correct timing and keeps bandwith as low as possible.

I tend to use standard off the shelf industrial serial devices that you can get just about anywhere in the world.

13

Did I kill this guys… let me know…

Id also be interested in your bandwidth calcs…

Thanks

John

14

maybe some of us are quite busy atm. but sometimes it helps to keep asking! ;)

15

Any updates Digipic… Thanks

16

Hey, yeah just a quick rundown I’ll put more info on my page when i get some free time. Ive successfully ran arround 400 universes of artnet split between 2 pcs using multiple pipets to sample the color values from the video in a fixed stage show install. The PC’s are 2.4ghz HP’s with gigabit ethernet cards outputting on 2 seperate networks to the relevent led panels & strings. The system runs at arround 20fps and takes its trigger input via a good’ol enttec USBDMX PRO. Overall vvvv performs amazingly, the only bottle neck seems to be in sending this ammount UDP packets or the creation of the packets even though were only using a tiny amount of bandwidth. Not quite figured where this is yet. Found some interesting things with using multiple routers and artnet too which ill try and explain later too.
So all in all 400 Universes @ 20fps makes me a happy man!

17

wow, thats quite a lot…

18

Excellent work, how did you find ART-Net node restrictions max 4 port/node. You also have a fair amount of data bandwidth that is simply not being used.

16 bits for the sub-net of which only 4 bits are used and only 4 bits that can be selected for each port.

Id be interested in seeing the system layout and compairing notes…

Im in the process of adding ART-Net support for some of our controllers and finding some issues mainly around backward compatibility issues with older technology.

19

Hi Sorry for such a late reply, ill try and answer some of your questions. Im not sure what you man by the 4 port/node restrictions, we are using custom ethernet I/O units which read in the artnet data and talks directly to the pixel bus similar to the Philips protocol. Its all constantly developing so were learning more and more things with each new project!

One interesting thing was how some cheaper switches when routing the artnet seem to develop a “slowness” over time, which can only be put down to component tolerance. They can be fine for a month then suddenly just merge wrong packets!