Player (DX11.Texture)
| Author: | woei |
| Date: | 04 Dec, 2015 |
| Category: | 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 |
Download
64bit
beta 35.2+, dx11 1.0+, AnyCPU
beta 35.2+, dx11 1.0+, AnyCPU
dx 11 version 1.1
dx11 version of beta33.7, AnyCPU
Description
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
1. asyncronously reads the file into RAM
1. asyncronously decodes if necessary
1. 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
Comments
Comments are no longer accepted.Please create a new topic in the vvvv beta forum to discuss this contribution.
Fabulous!
thanks a lot!
thanks meso & woei
Hi, isn't this node spreadable like the EX9 one from Elias?
@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)
Ah ok thanks woei :D
Hi! thanks a lot, just how to use it? where should i unpack this .dll? (first-timer question)
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
and does it even work in beta35.2?
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?
Me too, b35.8 not work.
Works in "vvvv-packs-dx11-1.0.1-x64"
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
@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?
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.
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.
@bjoern no offence!
@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?
@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.
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.
@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.
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.
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.
so basically people should prefer using pooled filetexture?
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
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.
a) it's (currently) for free – no creative commons shenanigans b) it's open source
Try and fix it.
this totally rocks, thank you guys!
thanks @woei and meso for the update!
Thank you and I agree it rocks!