Something problematic we noticed is that the texture coming out of the video player is always changed.
Just like with TextureFX the texture object should only change when a new video is played or the resolution, etc. changes.
Currently connecting a changed to the texture is always true and therefore can’t be used the same way as for other textures.
Thanks for considering.
It could behave like that when running in the same thread which can be achieved by putting the VideoSourceToTexture node into pull mode. Will probably need a tiny modification to ensure the texture is put back into the pool before asking for a new one. It would then always hand out the same texture.
Sounds good. In the mean time we created a class which just contains a PassThrough TextureFX and dispose the class whenever the video file changes. That way Changed is only triggered down the line when the video actually changes. But it would be more elegant if the texture coming out of the video player just changes when the actual video changes. Otherwise it is hard to detect if a texture has changed further down in the patch. In our case the texture can be a video, textureFX, image, etc. and the videos are currently the only ones that are always changed, therefore making that strategy of detecting a change useless.
But the work around is okay for now.
Upcoming previews will release textures early in pull mode (Prefer Push = false) leading to a non-changing texture output. However you’ll pay a little performance penalty for that, since there’s no more threading involved.
