Texture streaming from v4 to v4

vvvv beta question
#1

Hello to all!

Has anybody been successful in streaming textures with an acceptable quality
from one instance to another?

I tried all sharedmemory modules(AsString, AsVideo…), UDP send/receive, fugstream (frustrating fullscreen issue and AsVideo = cpu intensive), … but I didn’t find a way which really works fine.

I also was thinking to use the fantastic VLC plugin as receiver, but I don’t
know if it is possible and how to send data to it…

Or is there a virtual device driver in the web for sending it through VideoOut (DShow9 Device)? I tried VH Screen Capture Driver, but it only appears in VideoIn (DShow9) as driver…

I want to transmit 800x600@30 fps…

#2

I was now successfull in receiving data from the UDP send node through the VLC plugin. The problem remains AsString which uses too much CPU power. The VLC plugin is perfect because it uses just 0.8 and fullscreen works (instead of the UDP receive node which uses about 150) tackles to read from UDP…
But there is a delay in transmission.

to read with the VLC plugin just write:

udp://@x.x.x.x:port

#3

hey nice finding with the vlc plugin
what resolution did you test? and how big is the latency

dunno if it’s the same approach (AsString + udp) but in max/msp the matrix jit.send / receive can stream a 720*576 very very low latency
on the network

#4

I tested it with 800x600, but the AsString module eats a lot of cpu power (about 250 tickles!!) If I only find another module or a way for sending textures through UDP which is not so CPU intensive…

#5

that’s what wddm’s shared resources would be for. but that should be programmed to share a resource and that works only on win7. the point is that any dx9 surface could be shared across several processes on the vram without copying. if the current plugin interface would have texture input pin, creating a shared texture (which can be accessed by any other vvvv instances) could be done easily. (same as creating whatever surface in dx9, just a shared one has to be created in the default pool and a handle must be defined for it)

#6

That sounds interesting. You mean something like a TextureIn module? I hope that the vvvv team or some smart programmer will develope this in future, because it could be very useful.

#7

yeah feature request: “Share” boolean input pin and “share Handle” output pin for renderers, textures and meshes for win7 users:D

#8

This would pretty much close the gap between multiple instances. Is this really possible?

#9

that’d be almost as good as magic for me.

then just need span mode for win7 and i’d be happy

#10

according to this http://msdn.microsoft.com/en-us/library/bb219800(v=VS.85).aspx#Sharing_Resources you just have to create a surface in the default pool define a share-handle for it and that surface could be accessed from any other application with the share-handle you defined

#11

available for testing on irc…

#12

ai joreg
nothing describing this in the changelog!

#13

right. not yet ready for changelog. still experimental…

#14

k btw
to launch 2 instances of vvvv don’t forget to copy .config file

#15

or simply launch second instance with
/allowmultiple

#16

and how it works in that build? i found the shared handle pin in dx9texture though (however if i hover it it drops an error: list out of bounds (0) and outputs zero (i’m on win7 x64, ati gpu). is there any node to receive it?

ok above error occurs only if the texture output is not connected to an active renderer but i still haven’t discover how to receive it.

i found it:D

#17

funny in the newer (04.12.11) 26.1 dx9ex build this texture sharing was the least experimental stuff of all. it works just fine without a problem and it’s fast as well. so i think this absolutely could be written in the changelog’s “upcoming” session.
(however everything else was buggy as hell. especially the drawing of the patches)

#18

@joreg… where can I get a test of this ‘share texture between instances of vvvv’? could be useful for a project we’ve got going on right now.

#19

@joreg - what’s the progress on this technique? has there been much development and testing? mircodee seems to have had some success.

Could this be used as a work around for getting a texture in to own nodes?

#20

hei xd,

latest available testrelease with this is here. no further progress/testing since. could be used as workaround, but not as the solution.

please report all your findings about this in the forums-alpha.