Adding bit shifting or not does not change anything visually. When SVP is enabled (not even going 60, just doubling), the playback is already choppy.But it's so small that I can't visually notice any difference. The shiftings takes a bit more time (around 0.5ms more) than the leaves. In number, Deinterleave and interleave both take around 1ms in both 10-bit and 16-bit. Even with the CPU handicap, bit shifting consumes around 1-2% CPU.SVP on 16-bit, doubling fps from 24 -> 48: 91%, still choppy (understandable since this is 4K HDR).You don't have to stick to it, just an experiment.Įnvironment: MPC-HC + LAV Filters + madVR If not, try LAV + madVR in MPC-BE/MPC-HC.First try LAV Filters in PotPlayer, see if anything changes.Since the video is HDR, and I believe EVR doesn't support HDR while madVR does, this could be issue specific to how your system handles HDR in fullscreen. madVR in fullscreen does not drop frames with AVSF. I can't reproduce the issue you describe.On the other hand, LAV Filters works as expected. So there could be some magic in the format negotiation logic, but since PotPlayer is closed source there is no way for me to fix it. But if the codec is directly connected to the renderer (EVR/madVR), it outputs P010. What's weird is, AVSF tells the player it supports P010, but PotPlayer still chooses NV12. Lastly, the player chooses which format it outputs. Then AVSF tells the player what AVSF supports based on that input list. This is how it works internally: when the player initially launches, it tells AVSF the list of formats it can outputs. ![]() I can confirm that if that PotPlayer's colorspace setting is Auto, PotPlayer prefers to give AVSF NV12 output from its built-in codec.You are using PotPlayer's built-in codecs (instead of LAV Filters). Basically the video is 4:2:0 10-bit HDR encoded with H.264. Thanks to the video name, I now can (almost) replicate your environment.According to my test, with SVP enabled, P010 has at most 1% CPU overhead in my environment comparing to P016. I don't think adding 3ms is a big deal for 4K, especially when all these numbers are amortized by multi-threading.Īnd since it's madVR we are talking about here, if you really don't like the shifting, just uncheck P010 and P210 in AVSF. Since all these functions basically go through each pixel and do some SIMD stuff, they should have approximately same cost. Still able to maintain stable 48fps output The turnaround time of a frame is 388ms, note that due to throttling this is not how much time the script actually spent on If I turn off hwdec, CPU usage becomes around 13%Īssuming your log is taken with the same no-op, they are basically doubling my numbers all-around.Īfter enabling SVP (doubling 24fps to 48fps): LAV hardware decoding is set to D3D11 (I think it's reasonable to expect user enabling hwdec for 4K videos) I tested the same video and here's the average numbers I'm seeing:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |