Hi @lev, thx for updating the nuget this week. We gave your hap player a try. Unfortunately, it does not work as expected. We tried playing back 4K, 8K and 16K. We encoded the videos using Adobe Media Encoder and FFMPEG. All Hap Q @ 60fps.
4K does work. 8K shows the correct framerate and videolength, but does play at one half to a third of the original speed. Cpu @40-50%, graphics card @ 25%. 16K did not work for us.
We tried this on three different machines. All with fast pcie ssds, 8-16 core processors and capable gpus.
3840x2160@60 working
4096x4096@60 working
8192x4608@60 working
8192x8192@60 NOT working (slow playback)
15360x8640@60 NOT working (displays correct framerate and length. Just wont start)
15440x8684@60 NOT working (displays correct framerate and length. Just wont start)
I know the last resolution is not 16:9 but I setup AE to export 16000x9000 and out came 15440x8684. It seems like the problem occurs with resolutions larger then 4K, that have another aspect than 1,78.
Also, if the player loads a not supported format (like the last two) I have to F8F5 the patch, or it won’t play videos that do actually work.
What resolution do you recommend for 16K playback?
Here a screenshot of my ssd, it should not be the bottleneck.
Ryzen7 3800X
Quadro RTX4000
32GB RAM
Encoded with ffmpeg: ffmpeg.exe -i “xxx.mp4” -c:v hap -format hap_q -chunks 8 “xxx.mov”
I tried setting different chunk sizes, but it did not matter much. As I understand chunk size should not exceed cpu core count.
So, I did some checks - it’s actually close to the practical limit to play 2x8K@60fps HapQ videos even on very fast machine. And 8192x8192 is same as 2x8K videos.
I will see if I can do some more optimizations during next days if you’re still interested.
It’s quite unlikely that you’ll be able to play 15440x8684@60, for that you will need 2 machines, given that I’ll manage to do the optimizations to play 2x8K.
It’s also possible to use simple Hap (about 1.5x-2x faster) and/or slightly lower framerate (probably not something you’re looking for).
For now I can only recommend trying 16/32 chunks and see if it makes any difference. Sometimes it helps in my experience (Ryzen7 3800X have 16 threads, so you can play with it).
Btw your test video have relatively small datarate indeed, for more complex content types it will be much much higher, but your SSD looks just fine for handling that.
Hi @schlonzo
I’ve finished the first iteration of optimizations I’ve been planning to do for extreme high-resolution videos (over 8k). Got 25% speedup here (average 24ms VS 32ms for decompressing a single frame). For 60fps that needs to be further stripped down to at least 16ms. But it’s just laptop’s i7-7700HQ. I’ve checked the benchmarks, probably it will be around 18ms on Ryzen7 3800X.
We have some options, like overclocking or using some more extreme multi-core optimizations. Are you still interested? Or have you decided to go some other way?
Regarding the 16K resolution, I din’t look at it yet (I expected the playback will work at least), but I will take a look soon. Unfortunately it’s very tricky to play such Hap Q file on a single machine. I think my personal achievement was something like 12K Hap.
Update: got the prototype of massively multi-core decompression working! I expect it can give 50-100% speedup in scenarios where you have both super fast SSD and many CPU cores (like 8+). So 8192x8192@60 Hap Q should be playable now. Also, 16K playback started to work (not at full speed on my laptop) after these modificatins
I’ve just realized another thing you can try: to compress without snappy compression enabled. It will save CPU from additional work at cost of higher datarate.
-compressor snappy or -compressor none (default is snappy; when set to none may marginally reduce CPU usage in exchange for much larger file sizes that are a fixed bit-rate)
Hey. Just updated the nuget: 2.3.1
It should give 25-40% speedup for 8192x8192 Hap Q.
Please let me know if you’re able to play at full speed with it already (8 chunks should be ok)
VL.HapPlayer.2.3.2-pre.nupkg - same as 2.3.1 but with profile output enabled
VL.HapPlayer.2.4.0-pre.nupkg - second optimization included (4 frames are being decoded simultaneously) - was able to play at full speed even on my laptop, but the looping may be not 100% smooth, also with profile output
To install use those commands in vvvv gamma’s Manage nugets → Commandline: nuget install -pre VL.HapPlayer -version 2.3.2-pre -Source C:\Full\Path\To\Directory\With\Nugets nuget install -pre VL.HapPlayer -version 2.4.0-pre -Source C:\Full\Path\To\Directory\With\Nugets
(make sure that you’re using the right one, when running the patches, e.g. I suspect to use 2.3.2-pre you need to manually remove folder with 2.4.0-pre - check which one you’re using in the Dependencies menu)
back in office, here are some tests from the original machine with different hapPlayer versions. For me the 2.3.x versions work best. 2.4 is noticeably slower. also interesting: GPU shows 84%+ but when I enter the GPU Tab its just 15%3D and 25% copy.
8192x8192 runs almost flawlessly but there are little jumps in there. the larger resolutions play but noticeably slow. on 2.4.0 even 8192 runs slower than on previous verisons. framejumps are more visible.
Really hard to say what’s happening without seeing the DebugView output (see my post above) in 2.3.2-pre and 2.4.0-pre.
There we will see the time needed for decoding a single frame.
Use 16 chunks for best performance!
I recommend testing 8192x8192 on 2.3.2-pre and 2.4.1-pre and check (mainly) DebugView output and CPU utilization.
More tests are good of course.
ja I got that wrong, all those nice screenshots ;) ok here are some new tests with the proper debug view and gpu-z. I tried encoding without -snappy, but tbh those filesizes get too crazy. one 2TB ssd for 7min footage is no option for me.
Hi @schlonzo
Do you get stable 8192x8192 playback on 2.3.2-pre? With 8 chunks I see from the screenshot decode time is 14-17 ms which may give stable playback (we need below 16 ms). I still recommend go for 16 chunks there. And yeah, probably a little bit of CPU overclocking won’t hurt, if that’s an option for you.
According to another screenshot you can get stable 15440x8684@30 playback (decode time below 30 ms)
I’m likely to find a way how to improve 2.4.1-pre, but I’d need remote access for that :/
after a lot of testing we decided to use beta for this project. your beta hap player seems to cache frames in vram. is there a possibility to disable that?
