This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

Player (DX11.Texture)

plugin
Credits: meso for sponsoring development of v.1 - Elias for the architecture of Player (EX9) - vux for dx11 --- meso again supporting v.1.5

about

first off: send massive thanks to meso for sponsoring the development and even more for making it public! now again for supporting a major update.

Player (DX11.Texture 2d)

what's the deal?

if the nodename alone doesn't ring a bell:

optimized playback of picture stacks

asyncronously reads the file into RAM
asyncronously decodes if necessary
swaps the image to GPU and decodes if necessary

tried a direct port of Player (EX9.Texture) by Elias but failed due to reasons.

so what's the differences:

tries to read any file, since it tries to pick up any codec of the OS
doesn't parse the directory async
extra debug output decoding time
not tested with multiple graphicscards

Change Log

2.0

huge rework of the reading and loading pipeline

got rid of the slimdx call, which would allocate memory (and thus cause leaks on stuttering systems)
GPU loader speedup x4 on my dev machine
CPU backend now uses WIC instead of system drawing. 50% speedup
removed restrictions on filetypes by file extension: will try to load and decode anything
compacted reading+decoding: removed one debug timing output
added pin to manually chose the decoder: file format support overlaps between sharpdx and wic and on some formats it depends on your system, which one is actually faster.
wait for frame option, defaults to true: option off means, just show whatever is currently loaded, can result in showing frames more multiple times or skipping ones but wont block the mainloop at all
reading and loading of files has higher priority than disposing and freeing memory.

1.1

compatible from vvvv beta35.2 and dx11 1.0 onward

upgrade to dx11 new interfaces as of dx11 pack 1.0 and .net 4.6 (pullrequest by MrRoundRobin)
fixed output spreadcount not considering all input pins
can handle negative indices properly (exception surfaced when using timebased module)

1.0

initial upload for vvvv version 33.7 + according dx11 pack

src on github

download

PlayerDX11Texture_v2.0.zip
07.03.19 [13:12 UTC] by woei | 1051 downloads
beta 35.2+, dx11 1.0+, AnyCPU

Show 3 older revisions

Older Revisions

PlayerDX11Texture_v1.1.zip
15.12.17 [12:52 UTC] by woei | 874 downloads
beta 35.2+, dx11 1.0+, AnyCPU

Player.DX11Texture.7z
01.09.17 [17:03 UTC] by bjoern | 548 downloads
dx 11 version 1.1

PlayerDX11Texture.zip
04.12.15 [01:42 UTC] by woei | 1127 downloads
dx11 version of beta33.7, AnyCPU

eno 13/12/2015 - 17:14

Fabulous!

motzi 13/12/2015 - 23:37

thanks a lot!

sebl 15/12/2015 - 03:08

thanks meso & woei

Lrinke 31/05/2016 - 13:18

Hi, isn't this node spreadable like the EX9 one from Elias?

woei 14/06/2016 - 21:55

@Lrinke it does, when you use it with dx version of beta33.7 as mentioned in the notes.
there was a change in the dx11 render pipeline after that version which didn't find its way into this contribution (yet)

Lrinke 14/06/2016 - 22:09

Ah ok thanks woei :D

RobertQue 03/08/2016 - 00:13

Hi! thanks a lot, just how to use it? where should i unpack this .dll? (first-timer question)

sunep 04/04/2017 - 11:50

could this somehow end up in the DX11 pack by default, it would be a lot more convenient than tracking it down every time it is needed

sunep 04/04/2017 - 12:41

and does it even work in beta35.2?

featherfurl 08/07/2017 - 08:51

Player(DX11.Texture) doesn't seem to work in b35.8. Works fine in b35.5, but when I load things in b35.8 I get a red node. Doesn't seem to be an issue with not being able to find the contribution, as all my others load in fine. Anyone else have the same issue?

jzzxh 15/07/2017 - 05:38

Me too, b35.8 not work.

jzzxh 15/07/2017 - 05:41

Works in "vvvv-packs-dx11-1.0.1-x64"

catweasel 24/11/2017 - 17:57

I get a red node on loop point, and corresponding mainloop hicup, has anyone else seen this?

05:15:19 ERR : Exception occured in TMPluginWrapperNode.Evaluate
05:15:19 ERR : Index was outside the bounds of the array.
05:15:19 ERR : System.ArgumentOutOfRangeException in mscorlib: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index

Stacktrace:

   at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource)
   at VVVV.DX11.PlayerDX11Node.Update(DX11RenderContext context)

so it seems that any value below 1 s on the doseek time or the start time of the loop does this

velcrome 12/12/2017 - 17:26

@catweasel
this happens to me, when I use any non-zero value for Number of previous frames to preload. Not sure what this pin is supposed to accomplish, surely we don't want to keep old frames lingering when we don't use them anymore?

My problem is different though: I get a different exception (SEHException), and a massive mem leak (about 50meg/sec) when the harddrive cannot keep up. Is anyone else seeing this unfortunate handling of IO problems?

woei 12/12/2017 - 17:49

haven't used this one for a while

@catweasel @velcrome
the issues you two are referring to both stem from the module/patch where plugin is wrapped. didn't even know it was uploaded with a wrapping patch.
so in case you work with fixed fps, use the vanilla plugin.

the error cat is getting and also the one velcrome metioned is due to a negativ index in preloaded frames, which is somehow calculated in the patch.

bjoern 13/12/2017 - 01:44

The module is Player (EX9.Texture Timebased) only with the plugin swapped iirc. The upload is just a folder from a project I zipped, didn't even think about the patch.

woei 15/12/2017 - 14:05

@bjoern no offence!

bjoern 15/12/2017 - 14:17

@woei None taken.

I suppose the EX9 plugin handles indices differently and also deals with negative indices. Guess previous frames to preload then could be handy for reversing playback direction?

woei 15/12/2017 - 14:23

@catweasle: ArgumentOutOfRangeException should be handled with 1.1 upload

@velcrome: does your memory recover if you stop the player from loading further frames?
increasing memory is expected when the harddrive cannot keep up, since it's starting more and more async filereads which are not aborted until the reading is completed. reading chunkwise would be possible, and checking the cancelation between every chunk. that, however, degraded performance of reading time. therefore i only abort before copying.
SEHException however sounds like some slimdx stuff. which filetype was your imagesequence? if it also happens with dds or not i know better where to start looking.

velcrome 17/12/2017 - 03:12

No, it never freed those gigs until vvvv.exe was terminated.
Disabling the Player only stopped it from eating even more (with the Play toggle, or the modules Evaluate).

The use case was displaying up to 16 image sequences in parallel, images were around 320x240 or something.
Customer provided jpg, which obviously didn't help the io performance either.

I admit freely, the general setup was not ideal and bound to lag with a hdd. However, IO can always be diminished (involuntary windows update download, anyone?) and frame drops should be handled gracefully.

woei 18/12/2017 - 13:57

@velcrome
if memory wasn't freed on pause, the leak happens during copying to the gpu. more than that i can't diagnose from afar. SEHException is some generic exception windows is throwing on unhandled errors in unmanaged code.

quote:
However, IO can always be diminished (involuntary windows update download, anyone?) and frame drops should be handled gracefully.

as mentioned before, safetychecks were omitted in favour of performance.
if it's crucial in your opinion, you're welcome to give it a try and send a pullrequest.

imho the player should serve for frameprecise playback, which cannot be done if the hardware already can't deliver. if one doesn't care about framedrops and jitters, there are other contributions, which probably better fit that usecase.

velcrome 18/12/2017 - 17:08

To overcharge the plugin and cause the mem leak (and the Exception) should be a piece of cake with any jpg sequence running in a loop.
Sorry that I don't have the time to fix the node, but if you have some thing I can test, just holler.

About your other thoughts, I guess, it depends on how you define crucial. In my case I was lucky to have found it and worked around the issue.
Other people might not be so lucky (or thorough), and let is slip, because "everything works smoothly", and get wrecked completely, once a little io stutter happens for some time.

So I guess I'll just leave this warning here: In professional environments such as long-term museum installations or mission-critical event patches Player should be used only with utmost care, because even a temporary IO lag could cause the plugin to crash vvvv.

StiX 20/12/2017 - 13:56

so basically people should prefer using pooled filetexture?

woei 20/12/2017 - 16:06

if your harddrive is too slow read the images, you won't be seeing anything with filetexture pooled either. in that case you won't run into a memoryleak with filetexture pooled. you will just have stuttering and probably black frames.

if your harddrive matches the necessary bandwidth, there's no problem with player and last time i checked it was faster.

producing an installation i'd assume one calculates the required performance of the hardware anyways

mediadog 20/12/2017 - 20:33

Yes, system performance is certainly considered, but part of that is considering that there is always a chance for things to take transient performance hits, particularly in a long-term installation. Things should fail gracefully. Risk of a crash is just not an option, and does not fit into my idea of "performance"! There is a WORLD of performance difference between occasional dropped/black frames and just stopping entirely. Real performance is not what something can do for a short period of time, but what it can do 24/7. I would LOVE to use this, but it just sounds too risky.

bjoern 20/12/2017 - 21:56

a) it's (currently) for free – no creative commons shenanigans
b) it's open source

Try and fix it.

schlonzo 09/08/2018 - 16:13

this totally rocks, thank you guys!

motzi 13/03/2019 - 00:17

thanks @woei and meso for the update!

metrowave 16/03/2019 - 22:53

Thank you and I agree it rocks!