
Daala: Modern video compression for the internet - setra
https://github.com/xiph/daala
======
MrRadar
Daala uses quite a few innovative approaches to video encoding. There's a good
set of articles on some of the approaches they've tried at
[https://www.xiph.org/~xiphmont/demo/](https://www.xiph.org/~xiphmont/demo/).

Since the formation of the Alliance for Open Media, Mozilla/Xiph's work has
mainly shifted towards helping them develop AV1 (for standardization by the
IETF hopefully next year) which is mostly based on what would have been
Google's VP10. That said, their work on Daala was not wasted as they are
working on integrating the most successful parts of Daala into AV1 where it
makes sense, such as their entropy coder.

~~~
tornadoboy55
They'll also need to make sure they stick to AV1 for a long-ass time. H264 is
fully accelerated. VP8 was supposed to become a bigwig thing, some (alpha)
hardware supported started to pop up and then Google nixed it and switched to
VP9. Only now are VP9 accelerated CPUs popping up and now they're already
planning to switch to AV1 soon.. no damn way the smaller CPU builders
(everyone not Intel or AMD) will build in decoding support for another
standard that'll be nixxed in a few years. That's also why H265 will (sadly)
be victorious, even despite heavy licensing. H264 has been in use for so long
without big changes that CPU builders felt comfortable dedicating silicon to
it. Unless AOmedia (= Google, Cisco etc.) give a guarantee they won't switch
up to 'AV2' or whatever in a few years, it won't see large hardware support.

On a sidenote: screw Google for switching YouTube over to VP9 for some
bandwidth savings, full well knowing 95%+ of people does not have VP9
acceleration and thus having YouTube absolutely slaughter their laptop
battery. H264ify fixes this, but still. ALWAYS put the user first.

Edit: to be clear, I know all the big builders (Intel, Nvidia, AMD etc) are
part of AOMedia. However, they also all promised VP8 support which never
happened, and VP9 support which is more than a generation late.

~~~
TD-Linux
I don't see how VP9 hardware decoders shipping late means that H.265 wins?
There's _zero_ H.265 content on the web right now, so if anything H.265 would
need to catch up. Also, the ffvp9 software decoder in Firefox is quite
efficient. Hopefully Chrome will eventually ship it too.

~~~
tornadoboy55
VP9 is already in all Chromium based browsers. And no, its not nearly as
efficient, because there's no hardware acceleration/ You can clearly see this
in any Chromium browser: Watch a YouTube video without the H264ify extension
and Activity Monitor open. Your 'Energy Use' will spike to about 100. With
H264ify its only 40. Safari even stays in the upper 20s.

~~~
TD-Linux
But it uses the libvpx decoder, not ffvp9.
[https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-
fastes...](https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-
vp9-decoder-ffvp9/)

Also check that you're getting the same resolution on both. H.264 requires
more bits, so you might be getting a lower resolution (which also takes less
energy to decode).

~~~
tornadoboy55
Both are 1080p60FPS. Also, VP9 will never be more efficient than H264 on my
machine since I have a 2015 13" Macbook Pro, and that model only has H264
acceleration in the CPU. And the 2015 Pro is more modern than 90% of the
machines out there..

~~~
clouddrover
But doesn't that have an Intel Iris 6100 in it
([https://www.apple.com/macbook-
pro/specs-2015/](https://www.apple.com/macbook-pro/specs-2015/))? If so you
should have accelerated VP8 and VP9 decoding. Maybe it's not exposed by the
drivers on macOS.

~~~
tornadoboy55
Nope, only VP8 (which is dead). I meant fixed hardware acceleration (Intel
Quick Sync). Draws a lot less power than the GPU. This is the full Quick Sync
acceleration sheet for each generation:

Version 1 (Sandy Bridge) Quick Sync was initially built into some Sandy Bridge
CPUs, but not into Sandy Bridge Pentiums or Celerons.

Version 2 (Ivy Bridge) The Ivy Bridge microarchitecture included a "next-
generation" implementation of Quick Sync.

Version 3 (Haswell) The Haswell microarchitecture implementation is focused on
quality, with speed about the same as before (for any given clip length vs.
encoding length).[citation needed] It has seven hard-coded quality/performance
levels (called "target usages"), compared to the three in previous
generations. The highest-quality TU1 setting is intended to be higher quality
than Ivy Bridge's version, and the highest speed TU7 setting should be faster,
higher-quality, and more battery-friendly for mobile devices. This generation
of Quick Sync supports the H.264/MPEG-4 AVC, VC-1 and H.262/MPEG-2 Part 2
video standards.

Version 4 (Broadwell) The Broadwell microarchitecture adds VP8 hardware
decoding and encoding support. Also, it has two independent bit stream decoder
(BSD) rings to process video commands on GT3 GPUs; this allows one BSD ring to
process decoding and the other BSD ring to process encoding at the same time.

Version 5 (Skylake) The Skylake microarchitecture adds a full fixed-function
H.265/HEVC main/8-bit encoding and decoding acceleration, hybrid and partial
HEVC main10/10-bit decoding acceleration, JPEG encoding acceleration for
resolutions up to 16,000×16,000 pixels, and partial VP9 encoding and decoding
acceleration.

Version 6 (Kaby Lake) The Kaby Lake microarchitecture adds full fixed-function
H.265/HEVC Main10/10-bit encoding and decoding acceleration & full fixed-
function VP9 8-bit & 10-bit decoding acceleration & 8-bit encoding
acceleration.[13][14]

~~~
clouddrover
Broadwell has VP9 acceleration with the right drivers:

[https://communities.intel.com/thread/59216](https://communities.intel.com/thread/59216)

[https://en.wikipedia.org/wiki/Broadwell_(microarchitecture)#...](https://en.wikipedia.org/wiki/Broadwell_\(microarchitecture\)#New_features)

So you just have a driver problem. Apple was playing with adding WebP support
in beta versions of iOS a while back. So maybe they'll add WebP and WebM
support in the next major version of macOS and iOS.

~~~
tornadoboy55
> GPU Accelerated

Not what I'm looking for. The GPU still uses about 2x more energy than the
dedicated Quicksync silicon, although its better than only using the CPU.

In case you're wondering, I did read the second link, it actually uses the
first link as a source.

I'm not trying to be contrarian btw, for me (and my Macbooks battery) I just
feel that the distinction between GPU acceleration and a dedicated decode core
is an important one.

------
Klasiaster
Part of Daala will be reused in AV1 [http://aomedia.org/](http://aomedia.org/)

------
vdnkh
How does this compare to VP9/10 by a "human quality" metric? There's lots of
cherry-picking about stats which makes an encoding sound impressive on paper
but result in a worse perceptible quality. This is a really good article about
testing encoders: [https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-
best-v...](https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-
vp9-encoder-eve-2/)

Additionally, adoption is really slow of VP9 already so I don't see anyone
switching to Daala soon.

~~~
mbebenita
We use a wide variety of metrics to compare codecs, not just the usual PSNR
metric:

[https://arewecompressedyet.com/?job=av1_rt_ctrl_new_twitch%4...](https://arewecompressedyet.com/?job=av1_rt_ctrl_new_twitch%402016-12-20T09%3A23%3A43.974Z)

While none of these metrics are as good as the "human quality" metric, some
are better than others, in different ways, so we try to optimize across the
board.

~~~
wyoh
On that note, have you considered adding Netflix's VMAF to AWCY?

------
Animats
Last time this was discussed on YC: [1] Except that time it was the "Thor"
codec.

MPEG-2 is effectively out of patent now for almost all uses. Here's MPEG-LA's
patent list.[2] The one remaining unexpired patent [3] only applies to error
correction for pay-per-view satellite broadcasts.

[1]
[https://news.ycombinator.com/item?id=10042469](https://news.ycombinator.com/item?id=10042469)
[2]
[http://www.mpegla.com/main/programs/M2/Documents/m2-att1.pdf](http://www.mpegla.com/main/programs/M2/Documents/m2-att1.pdf)
[3]
[https://www.google.com/patents/US7334248](https://www.google.com/patents/US7334248)

~~~
clouddrover
But what's the advantage of MPEG-2 over VP9? VP9 is royalty-free for all use
cases and outperforms MPEG-2. Are there particular expired MPEG-2 patents that
make sense to include in AV1?

~~~
MrRadar
The key is that now all royalty-free codecs can use MPEG-2 technologies as
their base instead of having to work around the lack of them.

~~~
clouddrover
Okay, but which technologies in particular? Since they've already been worked
around, what's the advantage?

~~~
mkesper
Workarounds might have had to sacrifice efficiency or simplicity.

~~~
clouddrover
Might have, but again what's an example? What's a technique from MPEG-2 now
available that could have improved VP9 or can improve AV1?

~~~
derf_
B-frames.

------
XorNot
This all reminds me that modular smartphones would be awesome if the hardware
video codec chip could be a module.

------
shmerl
How far did Daala progress? They planned to start beating H.265 both in
quality and in efficient decoding in 2016/2017\. Did that happen?

~~~
mbebenita
Here is the most recent update on Daala, from IETF 97:

[https://www.ietf.org/proceedings/97/slides/slides-97-netvc-d...](https://www.ietf.org/proceedings/97/slides/slides-97-netvc-
daala-update-01.pdf)

~~~
CharlesW
> _They planned to start beating H.265 both in quality and in efficient
> decoding in 2016 /2017\. Did that happen?_

If I'm not missing something, this suggests that Daala's quality will be
comparable to H.265. No doubt encoders for both will continue to get better.

~~~
shmerl
Not just comparable, the goal was to be ahead.

~~~
CharlesW
A good goal to be sure, but one that it doesn't look like they'll make.

IMHO, "comparable to H.265" may not be as inspiring but is still very
impressive. If they can do this without stepping on existing IP, it'll be an
incredible achievement.

------
visakanv
Does it use a middle-out algorithm?

