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.
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.
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.
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
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.
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.
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 :/