Daala: Are We Compressed Yet?(air.mozilla.org)
air.mozilla.org
Daala: Are We Compressed Yet?
https://air.mozilla.org/daala-are-we-compressed-yet/
8 comments
It was a bit of a surprise to wake up and see myself on HN! I'm the presenter in the video - I can answer any questions you might have here.
A bit off-topic, but the player does not load if I have the referer disabled, i.e.
network.http.sendSecureXSiteReferrer;true
network.http.sendRefererHeader;2
network.http.referer.trimmingPolicy;0
network.http.referer.spoofSource;true
network.http.referer.XOriginPolicy;1In the video you mentioned that you worked on a bit of RTL for the codec. I am curious on how the codec can be accelerated. You didn't talk much about it, so I am interested in what you have learned. Do you have some info on where most of the CPU time is spent in the codec? What did you try out?
My RTL accelerated the transform stage of the codec. Because Daala has no pixel domain dependencies, the frequency domain coefficients can just be offloaded to hardware, which returns the pixel domain result. There is more information on timing on my website [1].
The transforms no longer take as much CPU time as they used to, due to having better SIMD accelerated versions. Much of the time is now spent on the PVQ decoder, which is not optimized for speed at the moment.
One thing I learned after writing large fixed-function transform hardware is that it doesn't take much extra hardware to turn them into microcoded programmable pipelines, much like a GPU. In fact, this approach is very common internal to hardware video decoders, though the firmware is not exposed to the user. One notable exception is Broadcom's Videocore IV, which is quite an interesting architecture [2].
Also, with the latest mobile processors having 8 or more ARM cores, we can also exploit CPU parallelism in much the same way. I feel it is very important to have the codec perform well on CPU alone, as not everyone will have hardware that can decode it right away. This is something I would like to play with a lot more.
[1] http://thomasdaede.com/wordpress/?cat=9 [2] http://www.broadcom.com/docs/support/videocore/VideoCoreIV-A...
The transforms no longer take as much CPU time as they used to, due to having better SIMD accelerated versions. Much of the time is now spent on the PVQ decoder, which is not optimized for speed at the moment.
One thing I learned after writing large fixed-function transform hardware is that it doesn't take much extra hardware to turn them into microcoded programmable pipelines, much like a GPU. In fact, this approach is very common internal to hardware video decoders, though the firmware is not exposed to the user. One notable exception is Broadcom's Videocore IV, which is quite an interesting architecture [2].
Also, with the latest mobile processors having 8 or more ARM cores, we can also exploit CPU parallelism in much the same way. I feel it is very important to have the codec perform well on CPU alone, as not everyone will have hardware that can decode it right away. This is something I would like to play with a lot more.
[1] http://thomasdaede.com/wordpress/?cat=9 [2] http://www.broadcom.com/docs/support/videocore/VideoCoreIV-A...
Cool stuff. Thanks a bunch. I agree with you that software optimization takes preference, but I have also seen optimized crypto code in assembly that was completely undocumented and unreadable. I hope that Daala won't fall into that trap.
All functions in Daala have a C version, along with corresponding assembly versions which have tests to make sure that the assembly version matches the C reference.
Given this is funded by Mozilla, I'm surprised its not written in Rust. Any particular reasons?
ARM and its partners will probably start supporting HSA in 2016 and beyond, so you might want to look at that, too.
https://arewecompressedyet.com/ is the actual benchmark website.
Is there a list of all the arewe* sites Mozilla runs? I know of arewefastyet[0], areweslimyet[1] and arewee10syet[2]. Are there others?
[0] http://arewefastyet.com/
[1] https://areweslimyet.com/
[2] http://arewee10syet.com/
[0] http://arewefastyet.com/
[1] https://areweslimyet.com/
[2] http://arewee10syet.com/
There's also http://www.areweplayingyet.org/ which appears to be by SoundCloud, not Mozilla.
http://arewewebyet.com/
Not mozilla though.
Not mozilla though.
There is http://arewemetayet.com/ but it is probably incomplete.
There also is/was an arewe* site for Firefox installer size by releases, but I can't remember the URL.
arewesmallyet.com, it seems to be expired and grabbed by domain squatters. And (what is probably related) Firefox installer size is now much more than 5Mb it was then :)
Also: https://github.com/ttaubert/arewesmallyet
Also: https://github.com/ttaubert/arewesmallyet
for fun bug tracking in the web audio tools, arewedubstepyet[0].
[0]http://arewedubstepyet.com/
[0]http://arewedubstepyet.com/
[deleted]
For some textual context: http://xiph.org/daala/
The tech demo series is fantastic.
Link to the full set (top of the page): https://people.xiph.org/~xiphmont/demo/
About damned time we had a codec with lapped transforms.
It seems like the HTML5 player is finally working :-)
Not for me (I use Chrome). Had to download the video.
Well it used to be that mozilla's web player didn't work in mozilla's browser, and now it does, and that's nice :-). (Linux / no flash).
Didn't work for me either. After I refreshed the page, it did.
[deleted]