WIP: Automatically set tiles according to number of CPUs. #1370
Conversation
Limit to 8 to keep quality loss acceptable.
|
No resolution/speed guards? |
|
Not yet, I'm going to do some AWCY runs as I have no idea what reasonable guards are tbh. |
tdaede
changed the title
|
👍 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. |
|
Is it really that high? |
|
beta.AWCY shows a couple percent hit with even 2 tiles: |
|
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? |
|
@tdaede can we have this 0.4.0 release? Is it a good idea? |
Limit to 8 to keep quality loss acceptable.