Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Tile encoding #1126
(description updated on 16 april 2019)
This PR implements tile encoding (#631).
Encoding a frame first involves frame-wise accesses (initialization, etc.), then tile-wise accesses (to encode tiles in parallel), then frame-wise accesses using the results of tile-encoding (deblocking, cdef, …):
As you know, in Rust, it is not sufficient not to read/write the same memory from several threads, it must be impossible to write (safe) code that could do it. More precisely, a mutable reference may not alias any other reference to the same memory.
There are several structures to be tiled, which form a tree:
Most of them exist both in const and mutable version (e.g.
2 times, most recently
Mar 18, 2019
But since I added
I think we should replace all
3 times, most recently
Mar 22, 2019
Here is my first working tiled (2×2) video encoded with rav1e:
From this version: https://github.com/rom1v/rav1e/commits/tiling.100
Of course, there is a cost in quality (SSIM, PSNR…) because it loses the possibility to exploit some redundancy across tiles in the same frame. For now, the current version only saves CDF from tile 0 (it should choose the bigger tile in bytes instead), and always store tile sizes on 4 bytes. It can (and will) be improved.
The encoding time is worse with tiling on AWCY because I think that it uses only 1 core per instance.
Unfortunately (but as expected), the tiling structures are not a zero cost abstraction. They add an overhead in encoding time between 1~3%.
Concretely, if we compare the version compiled from
As an example, on my laptop, an encoding takes 3mn33,245 on
You can compare encoding times on AWCY for 1 tile: https://beta.arewecompressedyet.com/?job=master-70005e353aa8ce21e3ecd257c927f71d4012a117&job=%402019-04-05T21%3A29%3A59.430Z_ref_1_tile
Maybe some work could be done to minimize this overhead (for example using more
EDIT: now there is no overhead (even a negative overhead with more inlines than on
ycho left a comment •
I think it is ready to land now.
As I observed, BD Rate change by this PR is:
1 tile -> 4x2 (col x row) tiles:
Apr 20, 2019
I published a blog post about this feature: https://blog.rom1v.com/2019/04/implementing-tile-encoding-in-rav1e/