Performance issues VLC DX11 node

Perfonmace issues
Hello everyone!
in a bid for a project (that will hopefully be my first commercial vvvv project ) i am working on a small app that has a few elements.

My main problem is with the FilestreamVLC DX11 node. It needs to play a video 4800x1600 pixels and at the moment the video is HEVC H265 coded. I know it is kinda big, but actually it has less pixels than UHD.

In media player and VLC (standalone) the computer barely knows it is doing anything, but as soon as i put it in vvvv both my CPU and GPU ramp up to about 46-50% just to play that one video on a FullscreenQuad and that is in the help patch for VLC node.
My dev machine is with a Core i7 7700K and a GTX 1080.
But on my production machine it gets even worse. all 24 threads are at 35-40% and the GPU is ramping up to 80-95% .
It is a dual CPU machine with a quadro P4000.

I am assuming vvvv is not using any kind of acceleration for playback but i could be wrong.
I know i could be using the HAP player but with it it gets extremely hard to upload files to the machine due to size and the people that will be making the content might not be able to either compress to hap or upload it to the playout machine.
And i will need to hire someone to help me with the HAP player (playlists crosfades etc.)

Anyone have some ideas about a performance boost or what is going wrong?

Hi, that’s is quite normal situation for a few years already…
vlc plugin vvvv uses is outdated as hell…
HAP should work or dds sequence…

i updated the files from the latest VLC player releas so it can play HEVC files, but considering the power of the machine the whole thing just seems off.
I know HAP is better but how do you transfer 300GB of files every day to refresh the content ?
I just tested with one of the files 10 minutes of it turns out in to 80GB. There will be roughly 2 hours of content every day.

Original idea is to use the CMS by u7angel so no local access to the machine is needed, thus making local file conversion to HAP difficult.

So far VVVV seems unable/unsuitable for the task at hand.
A 16 core system and a Quadro P5000 seems a bit too much of a requirement for a simple video playback that my phone can do with no problem.
I might need to go back to other commercial solutions.

thanks for the input tho.
If anyone else has an idea i am open to suggestions.

Have you tried alternative solutions like ? Or does it miss some fundamental features you need?

@elias in my test (using Alpha 14 05 2019 16:42:28 ) the overview node error:
ERR : Exception of type 'VL.GStreamer.StateChangeException' was thrown.
This happens initially and then after disconnecting the uri, refreshing the node, reconnecting the uri and pressing play.

Test file here:

Well, you can always write to vux and fund update for vlc plug…

Same here, tho after hours of trying because this was happening on every start and reinstalling windows it works now.

However , i found the performance not much better than VLC, also it is quite inconsistent.
Set to loop it sometimes will not loop specially if you give it a spread of files and Getslice+counter to pick what file you want to play.

Second thing that is weird is, when i get the play position and duration to compare them so i get a bang for the counter to play next file in the list no i get no bang.
As if there is values there but the = node does not recognize them.

OK in order to be of any help I’ll need more details. What file are you playing exactly, are you streaming it from web or open from local disk? What version of gstreamer did you install, did you also select the complete option in its installer?
Are you playing one file at a time or are you spreading the node?
With the 4800x1600 video the CPU and GPU usage is still much too high?
And the last paragraph about the position and duration and bangs I didn’t understand maybe a patch would help here.

the file 4800x1600 HEVC H265 coded, streaming from a local raid0 m.2 array. Playing one file at a time with a simple logic to select another file from a spread.
Gstreamer is installed according to your guidance few posts above.

patch attached: (74.6 KB)

And the load:

Just tried gstreamer again, and I get an error on opening the help patch, and no file playing, when I hit playvvvv.exe-exception-2019-07-18.log (72.8 KB)

also since you’re saying updating large files frequently is an issue in your situation, have you considered using an image stack player? with those, instead of updating whole movies, you can update subsequences more easily, in case this is an issue for you.

for options, see:

Forgive me i may sound rude, but i kinda fail to see how exchanging 324000 images every day is easier than 300gb in few files.

Or i missed something in your suggestion ?

Dont want to be nitpicking here, but the Pro contribution leads to a page that does not work, and the free one is a single dll file with no help, usage or anything …

image sequences have the advantage that in cases you don’t need to update a whole movie but only a scene of it, you don’t need to render and transfer the whole movie but only a shorter imagesequence. obviously if your usecase creates totally new movies all the time, this will not help in your case.

regarding the pro i hope @eno can say something?
regarding the free i hope @woei can help?

meanwhile for testing there is also a Player (EX9.Texture) that should be similar to the DX11 one, and it comes with a helppatch.

@catweasel when installing GStreamer 1.14, the installer offers “typical”, “custom” and “complete” options. did you choose “complete” as is stated here?

@joreg good call, however it seems crashy. Start and stopping can cause hangs, do seek every frame then stopping seems to cause hangs, all just with help patch.

Ditto @catweasel. It does seem a little crash happy.

That VLC and Gstreamer - both of which are probably using some GPU accelleration under the hood to decode h265 - have some bottleneck somewhere at the presentation stage is an important issue that probably requires gpu/memory profiling that I’m not technically or intellectually equiped to do.

hola. sorry for the dead link.
For most (semi) professional use cases I suggest to work with an image stack player.
For this one as it seems, the free version should be perfectly fine. It works exactly as the dx9 version.
The pro version targets at very high data rates that reach the performance limits of the drives and pc bus, which is not the case here

GStreamer version: 1.14

Video file: TearsOfSteel_720p_h265.mkv (1280x720)

CPU: 5% GPU: 5%

vvvv-beta-38.1 (DirectX9)
CPU: 5% GPU: 6%

vvvv-beta-38.1 (DirectX11)
CPU: 5% GPU: 6%

vvvv-gamma-2019.1.0-0552 (Skia)
CPU: 11% GPU: 16%

And for reference VLC 2.2.4
CPU: 4% GPU: 6%

Video file: Comp 2_Custom.mp4 (4800x1600)

gst-play-1.0 (looping the file by pressing ‘0’)
CPU: 20% GPU: 15%

vvvv-beta-38.1 (DirectX9 and DirectX11)
CPU: 27% GPU: 35%

And for reference VLC 2.2.4 (set to loop)
CPU: 18% GPU: 19%

Did also a test with GStreamer version 1.16 and same results. So it seems to me while for normal size videos the performance hit of the texture upload is minimal (1%), in case of the large texture size it makes a major difference.
So we probably need to figure out how to let GStreamer produce D3D surfaces directly.

Also noted that Skia is far off the baseline.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.