In all versions till the recent release (2021.4.0) above pre-455 the “AsSharedTexture” node (VL.Stride.Windows) is changing constantly its handler (pointer) when the image source is “dynamic” like when I am using VideoPlayer or VideoIn, this is not happening with other static textures like loaded images.
I tried also to copy the texture as @tonfilm proposed before I send it to the AsSharedTexture but this didnt make the trick.
can you elaborate when/where this is a problem?
have you tried with Spout instead of texture sharing?
Sure, my use case is as follows:
because I have an OEM video capture device which is not compatible with VidoeIn (Stride, Skia, OpenCV) I am using vvvv beta as my final renderer and I am sending there three complementary video sources (three webcams where they can be recognized only by gamma - this is a paradox but a totally different story) as shared textures from gamma.
So vvvv beta hosts the OEM device and the shared textures from gamma in order to render them out.
I still prefer to use AsSharedTexture since I am in vvvv environment, Spout has disappointed me many times in the past and if it is not needful (like in my case) I do not prefer it.
*regarding the 3 webcams: All of them are by the same manufacturer and the same model so vvvv(beta) is not capable to recognize each one separately (I get an enum with three entries - same name - and order does not seem to affect it - it always picks one and this ends to a crash for the other two videoIn). In the other hand on gamma I get them properly as different devices with a hash and a number - Logitec #1 #2 and so on) So I use VideoIn (Stride) which is much more reliable rather than the VideoIn(dx.11) on beta in any case.
As a workaround you could try something like this:
so this is the actual issue!? if that device was available in VL, you’d use gamma only?
if so: what device exactly is this?
@joreg I am afraid it is not the only issue but yes it is the major one. I am using an easy cap clone like this one (this specific model is being produced by different labels -I don’t have it in front of me to tell you which label is mine):
It was even really hard to find drivers (win10) on the web for this thingy.
One or two more reasons that I didn’t use gamma instead of beta are the audio file playback support and the texture effects. The first one was hard to achieve so I tried to build my own VLC lib but I couldnt relay on that and regarding the texture fx I have noticed that compilation takes time when I update their parameters (even for basic blend, some times it works some other times it doesn’t - especially if I combine it with an ADSR) but I can open a new thread for them.
To answer your initial question, attached you find a node which does what you were asking for - copying the upstream texture into the one and only output texture thereby keeping a stable shared handle
CopyToSharedTexture.vl (13.3 KB)
ok, this looks like an issue with this device only supporting the Directshow API, but not the more modern MediaFoundation API, as i described here: Gamma RC1 Video.MediaFoundation VideoIn issues - #2 by joreg. there i also mention how i’d assume to best go about adding support for Directshow devices.
please definitely open a separate topic for this with step-by-step description of how to reproduce.
also please start a separate topic for any problems you have here.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
