rav1e
rav1e copied to clipboard
xiph
WIP: Automatically set tiles according to number of CPUs.
Coverage increased (+0.08%) to 82.782% when pulling 7caa2b0f2430f9348534d05aa0e5a3840734e7d4 on tdaede:auto_tiles into eae72f992adc5f68fa082adb833dbf4285a8e691 on xiph:master.
Not yet, I'm going to do some AWCY runs as I have no idea what reasonable guards are tbh.
👍 Waiting to see what AWCY shows. I can't image 8 tiles on a 240p stream is great.
Looking at AWCY results, a default constraint of tiles no smaller than 512x512 seems like a good middle ground.
I feel like a lot of people would expect the default behavior to not use tiles at all, and it might be better to have this as '--auto-tiles' or something. Since it's at least a 2-3% BD-rate hit (and more on a lot of content), it seems like something you'd want off by default.
beta.AWCY shows a couple percent hit with even 2 tiles:
https://beta.arewecompressedyet.com/?job=master-343461dcbb671b601da34b3477532fa1ef2edf83&job=2tilesb-343461dcbb671b601da34b3477532fa1ef2edf83%402019-06-20T22%3A32%3A27.206Z
Seems fairly consistent across the test clips in that last link that the difference is greatest at lower bits-per-pixel and disappears as it rises.
The bd rate reports break out averages by resolution, (and you might be able to see resolution dependent effects just by comparing the different file rows, but this effect seems the same regardlesss of resolution, how would it look if thinsg were broken down by that metric instead?
It quickly becomes resolution dependent at greater tile counts: https://beta.arewecompressedyet.com/?job=4tiles-343461dcbb671b601da34b3477532fa1ef2edf83%402019-06-20T23%3A09%3A03.664Z&job=master-343461dcbb671b601da34b3477532fa1ef2edf83
I want to treat this sorta like a speed feature, e.g. for doubling encode time by going from 2->1 tiles, there might be a better speed feature to enable instead.
Possibly I'm misreading the graphs, but I still don't see an obvious dependency on resolution even for 8 tiles. It gets worse from 360p to 720p, then better again as resolution increases to 1080p on the test set for 2,4,8 tiles (compared with one tile or a smaller number of tiles) rather than consistently worse at lower resolutions.
A more consistent dependency is on quality. Seems like whether you'd want this on by default depends more on what VMAF/quality you're targetting than the resolution of the video, as at higher qualities it seems the impact is greatly reduced and so judging by the average is perhaps misleading if you're targetting either a high or low quality. (Presumably the first few bits used are heavily affected by the split in some way, but as more and more bits are spent to increase quality it affects them less and that initial hit gets amortized across the higher bitrate as a mostly fixed cost)
@tdaede I would like to run some performance and bdr tests, could you resolve the conflicts and rebase this branch?
