Xiph & Mozilla's Daala codec

[dapperdan]

Just thought i'd start a generic thread since there doesn't seem to be one yet.

A bit late with this news but apparently there was a get-together last week to "start moving our Daala project from a research platform to a working codec prototype"

http://www.ietf.org/mail-archive/web/video-codec/current/msg00141.html

Some of the work/discussion can be found here:

https://daala.etherpad.mozilla.org/coding-party

[benwaggoner]

Can you give a summary of how and when Daala might be something interesting or useful?

[mandarinka]

It is still in a very alpha stage and the format is not frozen by far. Apparently though you can already test the proto-encoder and decoder. It already does inter prediction, but no scenecut detection and various other features (like rate control) aren't in yet. But I really don't have much insight into it, so you'll have to wait for somebody more relevant to describe the state...

[benwaggoner]

Ah. Sounds like something that wouldn't become relevant until 2015+ as a HEVC competitor then.

[mandarinka]

Note that my "very alpha" comment and the words about limited features having been implemented - all that is about the example encoder/decoder.

AFAIK they have the format's coding schemes laid out for a long time now, so while it has not been yet finalised and still being investigated, it is not like the format design is at the beginning.

[benwaggoner]

Note that my "very alpha" comment and the words about limited features having been implemented - all that is about the example encoder/decoder.

AFAIK they have the format's coding schemes laid out for a long time now, so while it has not been yet finalised and still being investigated, it is not like the format design is at the beginning.
Sure. But few features survive intact between draft design and implementation :).

For myself personally, I start really paying attention to codecs when I can actually make and playback a bitstream that doesn't something notable and new. It sounds like Daala is at least a couple years out from being able to do a real end-to-end test of a reasonably complete implementation of a reasonably final bitstream spec.

[mandarinka]

Xiph foundation has published a presentation about the codec (or rather it seems to be the first in a line of writeups that will follow...). It's be mainly about the lapped transform that is used in the codec.

http://people.xiph.org/~xiphmont/demo/daala/demo1.shtml

[mandarinka]

A third one is out too:

http://people.xiph.org/~xiphmont/demo/daala/demo3.shtml (http://people.xiph.org/~xiphmont/demo/daala/demo3.shtml)

[benwaggoner]

Okay. Now I'm thinking that Daala might actually turn into something brilliant. I've been thinking about the frequency domain prediction approach for a while now, and it's great to see some real evidence. TrueMotion prediction turning into a texture replicator after machine learning suggests some very powerful techniques that could be refined out of that.

I need to lie down and meditate on the potential implications of a lapped TF for video...

[dapperdan]

"Mozilla is organizing a coding party for Sept 30 - Oct 3 at the Mozilla headquarters in Mountain View to continue moving the Daala project further forward as a working codec prototype. Anyone and everyone are welcome to come hack on things."

http://www.ietf.org/mail-archive/web/video-codec/current/msg00143.html

Also, Monty's blog introducing the 3rd write-up that was linked above, suggests the second stage of the TF was discovered while documenting the first, which is interesting.

http://xiphmont.livejournal.com/60856.html

[MoSal]

A 4th demo was published last week (https://people.xiph.org/~xiphmont/demo/daala/demo4.shtml)

[khagaroth]

Also, Monty switched jobs and migrated from Red Hat to Mozilla to focus on Daala. .

[dapperdan]

A video of a talk by one of the Daala team, on the topic of Daala and Opus:

http://people.xiph.org/~xiphmont/video/Free_Codecs_Update_Opus_and_Daala.ogv

Fairly high level, but up-to-date with their progress.

[mandarinka]

Hmm, videos require one to watch through them, unpleasant when you want to quickly extract the information :)

I wish people would return to *writing* reports... /well, I guess for that I need to wait for more Xiph demos./

[nakTT]

A video of a talk by one of the Daala team, on the topic of Daala and Opus:

http://people.xiph.org/~xiphmont/video/Free_Codecs_Update_Opus_and_Daala.ogv

Fairly high level, but up-to-date with their progress.

Hope you could do us a favour by sharing the interesting point raised in the video. Thank you in advance.:thanks:

[dapperdan]

Slides from the talk video above:

https://people.xiph.org/~greg/gstreamer-daala-opus.pdf

[nakTT]

Slides from the talk video above:

https://people.xiph.org/~greg/gstreamer-daala-opus.pdf

Thanks for the link.:thanks:

[dapperdan]

And an article in LWN on the talk:

http://lwn.net/Articles/571978/

[qyot27]

And an article in LWN on the talk:

http://lwn.net/Articles/571978/
I have to admit that the Theora-related "there's only so far you can get by putting rockets on a pig" comment made me chuckle.

I ran another compilation and really basic encoding test with Daala, and it has gotten substantially better since I last tested it several months ago: I can confirm that the claim in the article of artifacts looking grainy or noisy rather than blurry is true. When the ratecontrol and other accuracy and psy features are introduced, then this will be much more interesting - as it stands right now, you can have a 6000kbps stream generated by -v 10 and it still shows the grainy artifacts (although there is a very noticeable improvement going from -v 20, resulting in 3450kbps, to -v 10 @ 6000kbps).

[zerowalker]

How does it compare to VP9 and X265?
I don´t mean in real quality but in the state it is in currently.

From my understanding this is the latest one and has least development to it.

[Procrastinating]

Zero, at this stage daala is almost entirely theoretical. To my knowledge there has not been a single draft released for it yet, where VP9 is finished and h265 is in the final drafting stages.

Don't expect anything for a couple years yet.

[JEEB]

...and H.265 is in the final drafting stages...
Just FYI, H.265 has been a finished specification since April 2013. Range Extensions (>4:2:0 and >10bit support) as well as other additions to the first specification are what are still in draft, and there should be a final ballot on these early next year.

Funny enough, the ISO/IEC still hasn't finalized the same format on their side, but that seems like an issue with bureaucracy.

And yes, Daala is a research project, and you should not expect much from it other than very interesting ideas and test implementations. If we get a nice video format with quite a few new ideas along the road in a few years, that's just extra ;) .

[dapperdan]

How does it compare to VP9 and X265?
I don´t mean in real quality but in the state it is in currently.


In the video I posted earlier, someone asks "where are you today" in the Q&A (at about 39 mins) and they say it's "not as good as VP8 today" but they're currently more a collection of individual experiments which aren't yet integrated together into the main codebase.

The idea is to aim for beyond HEVC/VP9 by the time it's ready (possibly becoming VP10) in a couple of years. But they do have running code right now, it's not just theoretical:

http://git.xiph.org/?p=daala.git;a=shortlog

One of their key development strategies (which they also used for Opus audio) is to deploy in situations where the output is 'disposable' (e.g. Mumble and Skype for Opus) and use that to gain feedback on progress before the format becomes final. They're currently looking for projects where this strategy would work for video, I'm guessing Mozilla's WebRTC might be one of them.

Basically, don't expect them to follow the MPEG/ITU playbook for developing a codec, rather look at the IETF Internet Audio codec process (which eventually gave us Opus).

[dapperdan]

Some more (fairly raw) videos of discussion and presentations about Daala, here:

http://people.xiph.org/~tterribe/daala/coding_party2/

[zerowalker]

It seems i misunderstood a post, which i thought was saying that there has been practical tests, meaning an encoder using the concept has been used, which is how i asked the question.
But if it´s only theoretical, which i myself concluded last time i read about it, than that´s a different story.

I find it impressive that there is now 3 competitive rivals on stage, even if this one is farthest away.

[mandarinka]

They do have an experimental encoder they work with and test stuff on. During one of the coding parties they even bolted inter prediction on IIRC. However, it doesn't produce anything useful (well, nothing does when you compare to x264, but you know what I mean - it doesn't nearly compress well enough, yet).

You can compile it and test encoding with it. I don't know about anybody making a windows build for normal people :devil: though.

Edit: there is a guy in the irc channel #daala at freenode who is running tests of Sintel trailer with it, he can show you his results /I don't want to put links to his ftp here.../

[zerowalker]

Ah then i understood it correctly more or less.
But yeah as you say comparing head to head with x264 is impossible for anything at this stage, at least in normal situations. Low bitrate is another story, at least with vp9 from my tests.

But well doens´t seem like anything useful for me then, even if it would be fun to play around with. My compiling skills are non-existent;P

[mzso]

If I understand correctly the "big thing" in Daala is some sort of overlapped block transformation. Isn't anything possible beyond that, which doesn't use blocks at all?

[LoRd_MuldeR]

sn't anything possible beyond that, which doesn't use blocks at all?

Wavelet Compression

Though, AFAIK, Wavelets could be block-based as well and DCT doesn't necessarily have to use (small) blocks. It's just how they are used in real-world to exploit the individual strength of each type of transform.

See also:
http://x264dev.multimedia.cx/archives/317

[mzso]

Wavelet Compression

Though, AFAIK, Wavelets could be block-based as well and DCT doesn't necessarily have to use (small) blocks. It's just how they are used in real-world to exploit the individual strength of each type of transform.

See also:
http://x264dev.multimedia.cx/archives/317

I'm assuming. It's not without a reason that DCT codecs don't have one frame-size block.

I read that actually about wavelets. It's not promising. Guess I should have asked "anything good".

[vivan]

There once was http://forum.doom9.org/showthread.php?t=116229 but it's kinda hard to understand how it actually works.

[LoRd_MuldeR]

I read that actually about wavelets. It's not promising. Guess I should have asked "anything good".

Well, apparently nobody has come up with something practical that was clearly superior to the state-of-the-art block-based DCT compression schemes in the last two decades ;)

Even HEVC/H.265, which is supposed to be the next big improvement in video compression, sticks with block-based DCT - though they made the macroblock sizes much more flexible (and now call them "coding tree units").

Maybe video compression has reached a point where things evolve gradually rather than using radically new concepts? SIF1 sounds interesting, but has anybody made a comprehensive comparison? :confused:

[benwaggoner]

Maybe video compression has reached a point where things evolve gradually rather than using radically new concepts? SIF1 sounds interesting, but has anybody made a comprehensive comparison? :confused:
Codecs are much more about the aggregation of refinements than any "one big idea." I think the HEVC folks said that no one new feature added even 1% of a compression efficiency improvement.

The challenge for radically different transforms is that they don't have to compete against basic DCT, but all the DCT refinements we've accumulated over 20+ years of codec development. So it's perfectly possible there is some fundamentally better alternative to block-based DCT-like encoding, but it'd take thousands of scientist/developer years to get it refined to a competitive place.

Daala's got some good ideas, though. Staying in the frequency domain for prediction and treating the output pixels as an out-of-loop rasterization for display is enormously promising. The broader approach of not thinking in output pixels so much could be very promising.

Variable-sized and shaped intra coded blocks is another thing I'd like to see more of.

[foxyshadis]

AVC wouldn't have been possible in 1995, HEVC wouldn't have been possible in 2005; processing power gains contribute a huge amount to what's possible to put in a widely used standard. Likewise, some of the new advances are mostly for higher-def video, so that the encoding methods scale with the data. HEVC's original TMuC had lots of other cool stuff, like 64x64 DCT, rotated transforms (both primary and post-DCT), variable qpel algorithms, but the speed and complexity tradeoff just wasn't worth it. Someday they might be. (The rotated transforms especially would be extremely useful for a still-image format, since they're intra-only.)

Some incremental advances were to correct AVC's over-reliance on serial algorithms. Wavefront is the most obvious, but CABAC was heavily tweaked to be more parallel and longer-term (bigger dictionary in rar or 7-zip terms) instead of replacing it with one of the other suggested methods.

Aside from that, a huge amount of video research is heavily patented, and some useful inventions get dropped because the inventor demands too much or isn't willing to participate. Wavelets never gained much traction for this reason, they're a giant patent minefield. (To say nothing of curvelets, ridgelets, etc, which are all much better at modelling edges, but much more complex.) Because of the low uptake, there's also less research into how to make them nearly as fast as the modern DCT; it's a circular problem.

Daala's dropping of the "binary" part of BAC without using VLC is similar to TMuC's V2V entropy, and I've been eager to see what comes of it ever since it was described. That might be a free couple % gain right there, whereas most other advances require speed hits.

[MoSal]

I think the HEVC folks said that no one new feature added even 1% of a compression efficiency improvement.


Does that apply to the 'larger block sizes' feature?!

[LigH]

I was not yet able to compile a Windows binary using MSYS/MinGW with my little experience. There are always some packages missing. One of the two MinGW environments I got available misses a package 'check'; I downloaded the sources and configured it, but make failed immediately...

Is there anyone else interested in trying to make an EXE?

[qyot27]

I've been building snapshots from Daala's git repository every few months, whenever I think it's been a while since I last tested it (and yes, I do mean Windows binaries). You need to have libogg, SDL, and libpng, and a working autotools environment. Which, all things considered, makes it easier to do if you forgo MSys and just cross-compile everything. Build instructions for all that fun stuff are available in the tedious cross-compilation guide I wrote for mpv (https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt) (Daala's not included in there because nothing other than its own test suite uses it). My general guess would be that the guide would *probably* work as-is under MSys, just remove any references to --build= --host= --cross-prefix= or whatnot in the instructions (although the hoops needed for SDL are just icky).

daala_r797-g377312e.7z (http://www.mediafire.com/?1fj09bfeo32tj30)

Daala build instructions:
Daala
=====

# libpng might not be necessary if --disable-dump-images is used
# SDL is required for the player.
# libogg is required to output ogg-encapsulated Daala streams.

git clone git://git.xiph.org/daala.git
cd daala
./autogen.sh
PKG_CONFIG_PATH=/usr/i686-w64-mingw32/lib/pkgconfig \
./configure --prefix=$HOME/daala_build --disable-shared \
--disable-unit-tests --disable-doc --disable-dump-images \
--host=i686-w64-mingw32
make
make install
mkdir -p ~/daala_build/bin
cp examples/*.exe ~/daala_build/bin
cd ~/daala_build/bin
for n in *.exe ; do strip "$n" ; done

[LigH]

Thank you for providing a build and advices. I'll see how far I'll get...

[EncodedMango]

Point a nab in the direction of the commandline arguments documentation?

[LigH]

There is very little.

encoder_example -h
Usage: encoder_example [options] video_file

Options:

-o --output <filename.ogg> file name for encoded output;
If this option is not given, the
compressed data is sent to stdout.

-v --video-quality <n> Daala quality selector from 0 to 511.
511 yields the smallest files, but
lowest video quality; 1 yields the
highest quality, but large files;
0 is lossless.

-k --keyframe-rate <n> Frequence of keyframes in output.

-V --video-rate-target <n> bitrate target for Daala video;
use -v and not -V if at all possible,
as -v gives higher quality for a given
bitrate.

-s --serial <n> Specify a serial number for the stream.
encoder_example accepts only uncompressed YUV4MPEG2 video.

The default mode is encoder_example -v 10, according to the tests I ran.

It is hardly optimized yet. The SDL player is not even able to play 640x272 in real time.

[mandarinka]

Slides from a talk Monty Montgomery gave about Daala got published, in case people are interested: http://xiphmont.livejournal.com/63285.html

[mzso]

How does the encoder perform these days?

[mandarinka]

I haven't tried it myself yet. It's not going to be practical by any measure for a long time, and you have to build it yourself, naturally.

[xooyoozoo]

Did they ever have a stated quality goal? If it was ~50% of HEVC's filesize for equal quality, then they have roughly 10 years to get something together. ;)

[benwaggoner]

Did they ever have a stated quality goal? If it was ~50% of HEVC's filesize for equal quality, then they have roughly 10 years to get something together. ;)
Slide 10 has "Be best-in-class or go home"

Given this is a presentation from the VP9 conference, it's surprisingly full of digs at VP9 as a technology and a process throughout.

Anyone who's read this much really should read the deck. It's good.

There's lots of interesting ideas in there, but it's waaay too early and raw to make any kind of prediction for how it'll stack up against HEVC or other alternatives.

[Nintendo Maniac 64]

Given this is a presentation from the VP9 conference, it's surprisingly full of digs at VP9 as a technology and a process throughout.

Most of the slides are exactly the same as those found in the presentation given back in October that was linked on the first page of this thread:
http://people.xiph.org/~xiphmont/video/Free_Codecs_Update_Opus_and_Daala.ogv

HEVC wouldn't have been possible in 2005; processing power gains contribute a huge amount to what's possible to put in a widely used standard

Actually, the Athlon 64 x2 was released in mid 2005 with a clockrate range of 2GHz to 2.4GHz, so real-time decoding of HEVC would have been possible:
https://en.wikipedia.org/wiki/List_of_AMD_Athlon_64_microprocessors#Dual-core_desktop_processors

For reference I can decode 1280x720 30fps HEVC with "only" around 70% CPU usage on my 2.5GHz Brisbane (65nm) via MPC-HC v1.7.5 32bit. Compared to the original 90nm Athlon 64 x2 CPUs, the 65nm Brisbane CPUs have half the L2 cache which, as Tom's Hardware determined, results in them being slower than the original 90nm versions:

http://media.bestofmicro.com/I/O/298752/original/overall.png

[foxyshadis]

Actually, the Athlon 64 x2 was released in mid 2005 with a clockrate range of 2GHz to 2.4GHz, so real-time decoding of HEVC would have been possible:
https://en.wikipedia.org/wiki/List_of_AMD_Athlon_64_microprocessors#Dual-core_desktop_processors

For reference I can decode 1280x720 30fps HEVC with "only" around 70% CPU usage on my 2.5GHz Brisbane (65nm) via MPC-HC v1.7.5 32bit. Compared to the original 90nm Athlon 64 x2 CPUs, the 65nm Brisbane CPUs have half the L2 cache which, as Tom's Hardware determined, results in them being slower than the original 90nm versions:

Well, CoreAVC with multithreading was first released in March 2006, the ffmpeg with slice-based threading in late 2006 and with frame-based threading in early 2008, whereas now it's part of the initial HEVC implementations. I'll definitely admit it's not as much harder to decode relative to the prior best codec as the jump from ASP to AVC, though. (Excluding multi-point GMC, which brought my XP2400+ to its knees.)

[ckmox]

found this on there IRC channel
Daala passes JPEG and VP8, matches H.264, and closes in on HEVC
...on still images at least :-)
http://people.xiph.org/~xiphmont/demo/daala/update1.shtml

[Nintendo Maniac 64]

If it passes VP8 on still images, then it's already made WebP obsolete.

That was fast, and now it gives Mozilla more justification for not supporting WebP.

[MasterNobody]

More or less good but at some samples Daala artifacts (repeating not natural patterns instead of fine detail on textures; I am not sure to call this ringing which was mentioned as current Daala primary fault) looks visually (dunno about metrics) very annoying even in compare to VP8 blurring or JPEG blocking. You can see such artifacts in full resolution samples (http://people.xiph.org/~xiphmont/demo/daala/update1-tool2b.shtml):

Mercado dos Lavradores - textures on the ground (gravel and tiles);
Crepuscular Rays - grass and leaves;
Washington Monument - trees leaves.

Also while photos are good for still image comparison I would also include some CGI or anime samples to see it reaction for not so natural pictures with a lot of hard edges and gradients.