VL.HapPlayer does not play back correctly

[schlonzo]

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.

[lev]

Hi @schlonzo. Can you share some of your source test videos please?
Also, would be nice to see the CrystalDiskMark results in your setup

CrystalDiskMark

[schlonzo]

Ok, back after some extensive testing:

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

Download my test files here.

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.

[lev]

Nice test pattern!
Thanks, doing some checks.
Can you upload high quality mp4 file as well please?

[schlonzo]

Here you go.

Download MP4

[lev]

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.

[lev]

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

[lev]

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)

ffmpeg -i yourSourceFile.mov -c:v hap -compressor none outputName.mov

(from HAP Codecs)

[schlonzo]

Cool, looking forward to the next release! I believe 8192x8192 should suffice. 16K - just wanted to see what hap can do ;)

[lev]

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)

[lev]

This link contains two more nugets:

• 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)

To see the output, use

DebugView - Windows Sysinternals

Sample output:

We aim to <16ms for 2.3.2-pre and <64ms for 2.4.0-pre (divide the time by 4)

16k is also playable now, though not at full speed here.
Would be interesting to see which results and what CPU utilization are you having

[schlonzo]

hi,

I tested your latest nugets, on another machine tough.
Ryzen7 3700X
GTX1080TI
32GB RAM
Same SSD

Will check again when I’m at the office.

2.3.1
8192x8192 very slightly flickers - larger files play but very slowly

2.3.2-pre
8192x8192 very slightly flickers - larger files do play slowly

2.4.0-pre
8192x8192 very slightly flickers - larger files do play slowly

[lev]

@schlonzo

Will check again when I’m at the office.

Hey. If it’s not working well, I’d like to see the DebugView output, and also it’s useful to see the CPU utilization

[schlonzo]

hi @lev

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.

2.3.1 @ 8192x8192 60fps

2.3.1@ 15360x8640 60fps

2.3.1 @ 15440x8684 60fps

2.3.2-pre @ 8192x8192 60fps

2.3.2-pre @ 15360x8640 60fps

2.3.2-pre @ 15440x8684 60fps

2.4.0-pre @ 8192x8192 60fps

2.4.0-pre @ 15360x8640 60fps

2.4.0-pre @ 15440x8684 60fps

[lev]

@schlonzo

runs almost flawlessly but there are little jumps in there. the larger resolutions play but noticeably slow

Hi @schlonzo
Thanks for testing!

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.

Btw for GPU utilization Task Manager was always not too precise, TechPowerUp GPU-Z (v2.44.0) Download | TechPowerUp is way better :-)

Too bad I don’t have any 8-core machine to do tests myself.

[lev]

I’m preparing an updated nuget for testing.

[lev]

Here is a new nuget (use it instead of 2.4.0):

VL.HapPlayer.2.4.1-pre.nupkg

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.

Upd: also try: Dropbox - VL.HapPlayer.2.3.3-pre.nupkg - Simplify your life
It can be faster with 16 chunks

[schlonzo]

Hi lev,

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.

2.3.2-pre 8192x8192-60fps-8chunks

2.3.2-pre 15440x8684-60fps-8chunks

2.4.1-pre 8192x8192-60fps-60fps-8chunks

2.4.1-pre 8192x8192-60fps-60fps-16chunks

2.4.1-pre 15440x8684-60fps-8chunks

2.4.1-pre 15440x8684-60fps-16chunks

[lev]

@schlonzo

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 2T

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

[schlonzo]

hi lev,

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?