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.

[mzso]

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.

I disagree. It produced much the same artifacts as x264, but it's more exaggerated. It looks a bit like sharpening, so in some places it's benevolent.
It also smudges things more on other parts.

[Nintendo Maniac 64]

I believe the "ringing" in question may be the artificial noise that was mentioned in the slides just a few posts up. Such artificial noise was also mentioned in the video posted on the first page of this thread.

[ckmox]

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. ;)

we're targeting 20% better than state of the art in 2015 source: http://www.reddit.com/r/linux/comments/1grbe8/introducing_daala_the_nextnextgeneration_free/can4eih

about the "ringing" artifacts they are trying to solve it here are my sources

https://wiki.xiph.org/DaalaMeeting20140603
https://wiki.xiph.org/DaalaMeeting20140624

you can get more previous weekly meetings here https://wiki.xiph.org/Daala

[Gravitator]

Anyone can write their comments and conjectures on the parallel forum > Daala-vs-HEVC (http://forum.videohelp.com/threads/365788-Create-a-theme-Daala-vs-HEVC)

[MoSal]

Image Painting
https://people.xiph.org/~jm/daala/paint_demo/

[foxyshadis]

Very cool. The old Daala lost badly to x264, x265, and vp9 when I tested it on still images in June. (Was going to post shots but forgot.) I'll make a build of this and test it tomorrow.

[MoSal]

Very cool. The old Daala lost badly to x264, x265, and vp9 when I tested it on still images in June. (Was going to post shots but forgot.) I'll make a build of this and test it tomorrow.

They still have a long way to go, and they know it (they want Daala to be better, not just competitive).
But the gap is definitely getting smaller.

[qyot27]

So, uh, it was just called to my attention that VLC supports decoding and encoding of Daala now (http://git.videolan.org/?p=vlc.git&a=search&h=HEAD&st=commit&s=daala) (in git). The decoder and demuxer were committed on August 28th, the encoder was committed 5 days ago. It's disabled by default, but yeah.

It's been a long, long time since I've messed with compiling VLC (and only did so with a native Linux build), so I'll have to brush up, but I'd consider this fairly significant in general. It's almost certainly more comfortable than the example player in the Daala source code.

[Nintendo Maniac 64]

I'll make a build of this and test it tomorrow.

So uh, 2 days later...

[foxyshadis]

So uh, 2 days later...

Sorry, I have a real bad habit of doing that. I used it on linux, but futzed with mingw until I started working on another project and forgot all about it. I got it to build properly now, but it's dynamic, sorry about that. I have no idea how to make static builds.

daala jm branch 20140929 (https://dl.dropboxusercontent.com/u/54412753/daala/daala-20140929-jm.7z) (commit 898f970, the most recent)

[Tommy Carrot]

Thanks for the build. I've previously tried a build from april, it has definitely improved a lot since then. It's still very far from being usable, it's very slow and has problems with ringing and temporal stability, but the detail retention is actually quite remarkable. I had doubts about this project, but if they can fix these issues, it could be fairly promising.

[mandarinka]

https://people.xiph.org/~jm/daala/pvq_demo/

New demo has been released, about the perceptual vector quantization (hmm, I thought it was called pyramid VQ before, not that it matters...).

[Nintendo Maniac 64]

https://people.xiph.org/~jm/daala/pvq_demo/

They encoded their Daala images as JPEG.

o...kaaaaaaaayyyyy....

[LigH]

Suitable for a visual demonstration. If the video compression artefacts are a magnitude more obvious than the JPEG artefacts, it won't hurt too much.

With low quantization, JPEG can be quite exact; and with block adaptive quantization, it doesn't even waste too much space (I just wish there was any other tool than xat JPEG Optimizer, preferably freeware, which can create them).

[foxyshadis]

Yay, I figured out how to make a static build! SDL sucks. Latest stuff, fresh from my terrible karaoke night: daala-20141118 (https://dl.dropboxusercontent.com/u/54412753/daala/daala-20141118.7z)

Difficulty: Last week, the entire frequency-domain intra prediction scheme was scrapped. (Demo2 is no more (https://people.xiph.org/~xiphmont/demo/daala/demo2.shtml).) Hopefully other improvements have made up for it.

[Tommy Carrot]

Nice! Thanks for the new build (and for making win32 build for us xp users). I must admit, the visual quality has not improved as much as i hoped for after looking at the commit log, but still, slow but steady improvement.

[foxyshadis]

I'm setting up a weekly-or-so build folder: Daala builds (https://www.dropbox.com/sh/e1xnuxga4vshbte/AACEE-RGUEcjrHQYqdReMWbka?dl=0). Check-ins are pretty slow at this point, just 2-3 a week, but hopefully things will ramp up again soon.

[LigH]

:thanks:

At the moment, Daala is not yet really useful, rather slow and with little support, just like x265 in very early development... but times will change, and it is certainly an advantage to be able to participate, your auto-builds being an important factor.

[mandarinka]

:thanks:

At the moment, Daala is not yet really useful, rather slow and with little support, just like x265 in very early development... but times will change, and it is certainly an advantage to be able to participate, your auto-builds being an important factor.

x265 in the very early state was a functional encoder for a completed and standardized format. Daala has not reached bitstream freeze yet, much less completion of the research phase on the format and compression scheme.

I'd say in its current state it is more comaparable to the demonstration encoders for the various HEVC proposals.

[Kurtnoise]

A windows binary (https://www.mediafire.com/?4my77zfj4rd1az9) from today...

The changelog available here (https://git.xiph.org/?p=daala.git;a=shortlog).

[Nintendo Maniac 64]

Hey, perfect for comparing to the newest BPG (HEVC image) build that just came out today!

libbpg-0.9.4 is out. Extract of the changelog:


http://bellard.org/bpg/libbpg-0.9.4.tar.gz

[LigH]

BFG-9000? "Big F**ing Gun"? ... Ah, no, BPG = Better Portable Graphics (http://en.wikipedia.org/wiki/Better_Portable_Graphics) ... bold name. :rolleyes:

[Nintendo Maniac 64]

Clearly you'd use it for big freaking graphics so that you don't have huge filesizes, right? :p

Nevertheless, typo fixed.

[mzso]

BPG didn't amaze me, it looks around equal to jpg at sizes which provide acceptable quality. And is sometimes worse, by smudging, bluring away detail.

[LigH]

Similar to WebP and WebM, both based on vpx. There are people recompressing already coarse quantized JPEG to WebP to reduce the image file size even more... nonsensical.

[mandarinka]

In case anyone missed, the Daala intra compression demo was finally officially released (I don't really get why they had it on their web for half a year before finishing it and officially releasing to the world?)

https://people.xiph.org/~xiphmont/demo/daala/update1.shtml

I think the encoded images in the comparison tool are updated to match with never versions:

The update text (and demo code) was originally for a July update, as still image work was mostly in the beginning of the year. That update get held up and hadn't been released officially, though it had been discovered by and discussed at forums like doom9. I regenerated the metrics and image runs to use latest versions of all the codecs involved (only Daala and x265 improved) for this official better-late-than-never progress report!

[foxyshadis]

There haven't been many changes in the past month, but in the spirit of the new year, here's the latest Windows build: daala-20141229 (https://dl.dropboxusercontent.com/u/54412753/daala/daala-20141229.7z)

[Kurtnoise]

@foxy : did you use the libjpeg-turbo lib or the old libjpeg one ? The 1st one should be faster...

Did you succeed to compile it as a x64 arch ?

[foxyshadis]

@foxy : did you use the libjpeg-turbo lib or the old libjpeg one ? The 1st one should be faster...

Did you succeed to compile it as a x64 arch ?

This doesn't call for jpeg at all, but I always use turbo when I build with it. It's a lot more stable, too, compared to the newer versions of ijg jpeg. My builds always include x64 too.

[ckmox]

technical explanation about Daala https://www.youtube.com/watch?v=Dmho4gcRvQ4 a noob like me did not understand anything, he also explained their current progress, i only like the question and answer in the end although short

[LigH]

It is in fact very interesting and entertaining. Things to avoid in your algorithms to avoid patent infrigement ... that requires a fundamentally different look on very conventional methods to encode video. Just one example: Do not calculate differences between pixels of video frames to get the residual as base for motion prediction; instead, calculate differences of already transformed parameters.

Highlight of the video around 42:10 is the demonstration of a Daala decoder implemented in JavaScript (https://people.xiph.org/~xiphmont/demo/daala/player-demo.shtml).

[Nintendo Maniac 64]

technical explanation about Daala https://www.youtube.com/watch?v=Dmho4gcRvQ4

Well that's interesting - they claim currently better than x265 at texture and, above 1bit per pixel, also on clean edges. I wonder how this compares for the overall image quality?

[ckmox]

this is the javascript demo of daala he presented on the youtube video https://people.xiph.org/~xiphmont/demo/daala/player-demo.shtml

the bitrate is high though, i wish they made a low bitrate video one like 400kbps to really compare its video quality to x265 at the moment

[vivan]

Nice demo ;D
http://i.imgur.com/2yLXELVl.png (http://i.imgur.com/2yLXELV.png)

Those parts that decode correctly look pretty badly, so I see no point in decreasing bitrate even more...

[foxyshadis]

Just one example: Do not calculate differences between pixels of video frames to get the residual as base for motion prediction; instead, calculate differences of already transformed parameters.

I thought they got rid of that. Well, the logs say that Frequency Domain Intra Prediction was removed, which is what a couple of Monty's demos were about, but I'm not sure if they've reworked it since.

Daala's had quite a bit of activity this week, more than in the last two months! Here's a fresh build (https://dl.dropboxusercontent.com/u/54412753/daala/daala-20150127.7z).

Edit: Haha, vivan, very nice. :p

[LigH]

The encoder_example still does not yet support piping a video source?

And: For me as half-educated video enthusiast, motion compensation is inter-frame prediction, not intra, correct? But yes, there were more topics covered in this video. And some parts may cover previous efforts as well as current ones.

[foxyshadis]

It supports y4m, ffmpeg and all of the common avisynth pipes work with it. 8-bit YV12 only, though.

[LigH]

Well, the help screen does not mention any way to feed it with something that's not a physical file.

Usage: encoder_example [options] video_file
...
encoder_example accepts only uncompressed YUV4MPEG2 video.

Documentation is very sparse here. If "-" as input file name is supported for piping, then I guess Selur may add it to Hybrid soon... ;)

BTW: I am impressed how small the static-built encoder still is.

[Kurtnoise]

Well, the help screen does not mention any way to feed it with something that's not a physical file.
it's just an example of how to use the library...this should be tuned as well in the future.

[LigH]

OK, a command line like this works:

avs2yuv *.avs -o - | encoder_example -o *.ogm -

Count the dashes carefully. ;)

[Tommy Carrot]

Thanks for the build, Foxyshadis.

Well that's interesting - they claim currently better than x265 at texture and, above 1bit per pixel, also on clean edges. I wonder how this compares for the overall image quality?

Daala is nowhere near as mature as the other codecs. It still has fairly strong ringing and chroma artifacts, and the overall efficiency is not competitive with them yet. However, daala has some promising characteristics, like it tries to preserve the low contrast textures, so the fine details or the grain doesn't get smoothed out, like in x265 or vp9.

The latest build is quite a big improvement on the last one, the motion stability has improved a lot in the last month. If the development continues at this pace, and they can fix the ringing without blurring out the image, in half a year or so daala could become quite interesting.

[LigH]

A little something to compare: Tears of Steel, 640×272, 60 s action

x265 --crf 25 (https://www.mediafire.com/download/f8xfdzdri3nissf/tos_60s_360_medium.hevc.mp4) (v1.4+424-2b93cf2a5ac8)

Daala encoder_example -v 50 (https://www.mediafire.com/download/4316ialglsb166i/tos_60s_360_v50.ogm) (daala-20150127, ^foxyshadis)

Most annoying: The Daala player_example runs in full CPU speed... :rolleyes:

File sizes are as close as it gets without trying for hours in 1-pass quality modes...

[foxyshadis]

Oh yeah, I guess it'd be handy to specify that the exact git rev was bf0663a65926 (still the current head).

[Gravitator]

Nice demo ;D
http://i.imgur.com/2yLXELVl.png (http://i.imgur.com/2yLXELV.png)

Those parts that decode correctly look pretty badly, so I see no point in decreasing bitrate even more...

Imperceptibly this artifact from the speech > https://www.youtube.com/watch?v=Dmho4gcRvQ4&feature=player_detailpage#t=2548

[uneedme]

Using -v 30 to encode a clip, the output is pretty good. But I found no player could play the daala-clip.

Should it be any containers support?

[LigH]

The player_example in the daala package is about the only player supporting this video format at all. The development may still be too early and experimental for authors of usual players and decoder libraries (libav, ffmpeg, vlc) to consider including it already.

Unfortunately, it plays it as fast as the decoder works, doesn't care about frame rates.

[qyot27]

VLC supports playing back Daala-encoded files (http://git.videolan.org/?p=vlc.git&a=search&h=HEAD&st=commit&s=daala) (I even mentioned it in this thread back in September (http://forum.doom9.org/showthread.php?p=1695141#post1695141)), but unless something's changed with the official builds, you'd have to build it yourself to get it to do that since the decoder is disabled by default.

The particular posts on VLC-devel about API stability concerns:
https://mailman.videolan.org/pipermail/vlc-devel/2014-August/099405.html
https://mailman.videolan.org/pipermail/vlc-devel/2014-August/099407.html


I'd far prefer it to get in libavcodec instead, since I really don't want to try building VLC for Windows. I'm in the mplayer (well, mpv now) camp, always have been. mpv is simple to build for Windows.

[foxyshadis]

You don't really need to build all of VLC to build the daala decoder, it's just more convenient that way. You could build it from Daala, too, so I might try that with my next build. It's handy that VLC already has all the glue code ready to go, it's just a matter of keeping it up to date.

[qyot27]

I meant that enabling Daala support in VLC requires rebuilding VLC, because VLC doesn't have its libdaala support enabled by default, not that building Daala itself doesn't build the decoder.

When I build Daala, I usually rename/move the *_example binaries to alternate names in the /bin directory. player_example becomes daalaplay, decoder_example becomes daaladec, encoder_example becomes daalaenc.

[foxyshadis]

Because it's just a dll/so, you should be able to build libdaala in and add it into the codecs folder, without rebuilding everything. I haven't tried it yet, but as long as the headers aren't too tangled, it should be fairly simple. Software that uses monolithic codec files like ffmpeg are more annoying.

[uneedme]

use same clip having a daala test

the daala one's performance is truly good！ (-v30)


......I forgot I have already had the post......


......here it is...

http://pan.baidu.com/s/1jGh5K1K

x265 1.5
daala foxyshadis's latest build (dedicated)

[Tommy Carrot]

Daala got a new block size RDO algorithm, which supposedly brings decent quality/efficiency improvements. I'm curious how it performs now, so i'd be grateful if someone could make a new build.

[MoSal]

Daala got a new block size RDO algorithm, which supposedly brings decent quality/efficiency improvements. I'm curious how it performs now, so i'd like to request a new build.

Tested with intra frames only. The progress is good. But ringing is still a major issue.

[Kurtnoise]

Vanilla builds from today : x86 (http://www.mediafire.com/download/wshpt1gj55jt539/daala-42549bc_x86.zip) | x64 (http://www.mediafire.com/download/yxfkbk9472nuv6j/daala-42549bc_x64.zip)

Note that these builds have been compiled w/ Visual Studio 2013...

[dapperdan]

The IETF decided to formed a working group to develop a royalty-free video codec for internet usage, after their success with Opus in the audio space.

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

This might be Daala or some future variant, as the Daala team are heavily involved, but it could well follow the Opus path where tech from rival companies was combined into something new. Rubber stamping VP9 (or 10?) isn't entirely out of the question either though it seems like beyond VP9/H265 is seen as the target space.

[mandarinka]

Hopefully the "internet" target doesn't impact its compression strength in other less constrained settings. I'd like more changes in the high fidelity, high bitrate space too. Currently, that usage is ruled by x264 and since circa 2011, little has changed :/

[Tommy Carrot]

Thanks for the new build.

Yeah, the ringing is still pretty bad, in fact in many cases it has gotten worse, perhaps due to the tendency to prefer larger blocks (so the ringing spreads further). Also, the motion artifacts are still very noticable. On the other hand, the level of detail and the overally efficiency has definitely improved a lot since the previous build.

[wiak]

Most annoying: The Daala player_example runs in full CPU speed... :rolleyes:

wut am stuck at 1 core on my 8 core cpu encoding daala :D

[mandarinka]

You have read on some FLOSSy blog that "Xiph is finishing Daala and it already looks very good" or something like that, didn't you :)

Well, the reality is that they don't even know yet how will they go about finishing the bitstream format (last time I checked, the intra prediction was still unsolved problem and they have other issues). So multithreading in the *example/reference* encoder is something that hasn't even been touched on. It is simply not time for bothering with such stuff when you are still in a format-design phase. Since it is in no way suitable or usable for actual use, it doesn't matter if it only uses 1 thread.

[wiak]

You have read on some FLOSSy blog that "Xiph is finishing Daala and it already looks very good" or something like that, didn't you :)

Well, the reality is that they don't even know yet how will they go about finishing the bitstream format (last time I checked, the intra prediction was still unsolved problem and they have other issues). So multithreading in the *example/reference* encoder is something that hasn't even been touched on. It is simply not time for bothering with such stuff when you are still in a format-design phase. Since it is in no way suitable or usable for actual use, it doesn't matter if it only uses 1 thread.

i know, its still fun to check out stuff, daala has improve alot since last time i checked it out around a half a year ago

[mandarinka]

Everything improves. Theora was making those "huge strides" all the time. If you start with no rate control and untuned stuff, it is natural that you improve. It still doesn't mean that the format will end up good or usable.

IMHO it is better to not put too much hope into these things for now and wait till it is more finished. Once everything is done and implemented in a realistic production encoder (which tend to have speedup optimizations that sacrifice quality), it might turn up that it has more artifacts, worse compression and is harder to decode than HEVC... Not that I would want that, but to be honest I think it will be very hard to beat HEVC and I'm not really sure Xiph&Co.'s resources and design approach can deliver that. The royalty-free requirement is an obvious burden too. </scepticism>

[mzso]

You have read on some FLOSSy blog that "Xiph is finishing Daala and it already looks very good" or something like that, didn't you :)

Well, the reality is that they don't even know yet how will they go about finishing the bitstream format (last time I checked, the intra prediction was still unsolved problem and they have other issues). So multithreading in the *example/reference* encoder is something that hasn't even been touched on. It is simply not time for bothering with such stuff when you are still in a format-design phase. Since it is in no way suitable or usable for actual use, it doesn't matter if it only uses 1 thread.

Any chance they'll make the format decode to RGB? And forget about limited range and chroma subsampling at the same time.

[mandarinka]

Any chance they'll make the format decode to RGB? And forget about limited range and chroma subsampling at the same time.

I'm pretty sure they do want to have 4:4:4 option. But if your source is YUV, then it makes sense to encode it as YUV. And if your source is RGB, it is much more efficient to first convert to YUV, the gains due to decorelation are massive. That's why there is no serious codec that would store as RGB.

AFAIK Daala is designed for YUV, with techniques like luma-to-chroma prediction especially.

[mzso]

I'm pretty sure they do want to have 4:4:4 option. But if your source is YUV, then it makes sense to encode it as YUV. And if your source is RGB, it is much more efficient to first convert to YUV, the gains due to decorelation are massive. That's why there is no serious codec that would store as RGB.

AFAIK Daala is designed for YUV, with techniques like luma-to-chroma prediction especially.

You misunderstood. I didn't suggest they encode as RGB only to decode to RGB. Internally they could use something unique, something more fitting for compression than YUV if possible. It might as well be variable. And the decoder would output appropriate RGB which doesn't need to be processed before presentation.

[mandarinka]

But that would be silly - why move the RGB conversion into the decoder when it can be completely standalone. If they were changing the storage format to get more compression, they would instead use something even more complex than YUV and even more different from RGB.

[mzso]

But that would be silly - why move the RGB conversion into the decoder when it can be completely standalone.

I think it explained it fairly well why I think the should decode to RGB.

If they were changing the storage format to get more compression, they would instead use something even more complex than YUV and even more different from RGB.
I also mentioned this. Feels like you don't read my posts. Anyway one of the points is: RGB is universal and necessary since that's what you need to feed to the displays. So being different/more-complex is only an argument towards decoding to RGB. You'd prevent adding yet another colorspace for software/hardware to support and prevent poorly made HW/SW from butchering the video with their conversions.

[captainadamo]

I think it explained it fairly well why I think the should decode to RGB.

No, you really didn't explain it that well at all. You made some vague, hand-waving statement but nothing that provides a provable, technical benefit for the decoder to decode straight to RGB.

[mzso]

No, you really didn't explain it that well at all. You made some vague, hand-waving statement but nothing that provides a provable, technical benefit for the decoder to decode straight to RGB.

You mean compatibility with every renderer or whatever else you have in the pipeline while having an arbitrary color space internally is too vague?
Or bringing a consistent video quality, by not relying on inconsistent hardware/software environment for scaling is too vague?

[nevcairiel]

A decoder should always decode to its native storage format, anything else just eats massive performance. A conversion to RGB can be done much much more efficient on the GPU.
If you are afraid of bad conversions, just use a software converter that you control yourself.

[captainadamo]

You mean compatibility with every renderer or whatever else you have in the pipeline while having an arbitrary color space internally is too vague?

I've yet to see a renderer have any issues with 8-bit YV12 output which encompasses pretty much all consumer home videos.

Or bringing a consistent video quality, by not relying on inconsistent hardware/software environment for scaling is too vague?

Only if you sacrifice all the performance benefits of hardware-accelerated colorspace conversion and scaling that the renderer can take advantage of. If you do, though, make the decoder use the GPU for doing the colorspace conversion then you run into the exact same inconsistent hardware/software issue. So I don't see a single benefit to your idea over simply outputing the native pixel format and using madVR to convert to RGB and scale when rendering the video.

[mzso]

A decoder should always decode to its native storage format, anything else just eats massive performance. A conversion to RGB can be done much much more efficient on the GPU.
If you are afraid of bad conversions, just use a software converter that you control yourself.

I see. Well, the format/decoder doesn't have be CPU only. :) Particularly now that CPUs with IGPs are becoming the norm. (HEVC and VP9 were already designed for GPU accelerated decoding, weren't they?)

I was also thinking that format of the video might not be something usual that renderers support. Maybe it could be a vector graphics hybrid, or who knows what people could come up with if they don't restrict themselves and just make sure that the output is RGB. (Just thinking, I don't know how realistic these things would be)

[vivan]

I was also thinking that format of the video might not be something usual that renderers support. Maybe it could be a vector graphics hybrid, or who knows what people could come up with if they don't restrict themselves and just make sure that the output is RGB. (Just thinking, I don't know how realistic these things would be)If it's something weird - there's nothing wrong with decoder outputting RGB... and even scaling. Just like Flash does :)
Nobody is limiting you to YV12, it's just that with conventional codecs outputting internal format is quite benefitial, at least with HQ renderers.

[captainadamo]

I see. Well, the format/decoder doesn't have be CPU only. :) Particularly now that CPUs with IGPs are becoming the norm. (HEVC and VP9 were already designed for GPU accelerated decoding, weren't they?)

But that doesn't solve the hardware issues you alluded to as the reason you need RGB output. Hardware decoders have varying levels of performance/features and that's even before you factor in driver bugs. Your idea would just move any hardware issues to another place in the playback chain. All it accomplishes is moving the deck chairs around.

I was also thinking that format of the video might not be something usual that renderers support. Maybe it could be a vector graphics hybrid, or who knows what people could come up with if they don't restrict themselves and just make sure that the output is RGB. (Just thinking, I don't know how realistic these things would be)

But you're still adding unnecessary overhead and complexity to the decoder which is doesn't need by having it also be responsible for conversion to RGB. It's much easier to just use a better renderer than make the decoder responsible for something it really doesn't need to be.

[wiak]

if anyones interested am doing up-to-date win64 cygwin build(s)
http://nwgat.ninja/daala

meanwhile over at ietf
ietfmemes.tumblr.com

[Nintendo Maniac 64]

So I stumbled upon the following graph and couldn't help but notice that I didn't see it posted or linked anywhere in this thread (unless I'm blind):

http://www.tomshardware.com/news/ietf-standardizes-netvc-daala-codec,28821.html[/url]"]http://i.minus.com/i0XqipocDw3p9.png

[wiak]

So I stumbled upon the following graph and couldn't help but notice that I didn't see it posted or linked anywhere in this thread (unless I'm blind):
:stupid:

you should read https://people.xiph.org/~xiphmont/demo/daala/update1.shtml
and the rest of monty's excellent demo articles (Daala & Opus mostly)
https://people.xiph.org/~xiphmont/demo/

[Nintendo Maniac 64]

That's not quite the same since the chart itself looks different and it lacks any 2015 builds.

Of course, a 2015 build for x265 would be nice as well...

More importantly, this was not linked anywhere in this thread:
Daala Blog-Like Post 20150325: Bug or Feature (https://people.xiph.org/~xiphmont/demo/daala/random.shtml)

[wiak]

That's not quite the same since the chart itself looks different and it lacks any 2015 builds.

Of course, a 2015 build for x265 would be nice as well...

More importantly, this was not linked anywhere in this thread:
Daala Blog-Like Post 20150325: Bug or Feature (https://people.xiph.org/~xiphmont/demo/daala/random.shtml)
i think i saw it somewhere in a video or slide deck

you can find daala related videos here
https://www.youtube.com/playlist?list=PLEeMksZoEQ1xQEuLF50w0RwDwLgDGwSG-
and you can find them with slides here
https://wiki.xiph.org/Daala#Presentations

[benwaggoner]

So I stumbled upon the following graph and couldn't help but notice that I didn't see it posted or linked anywhere in this thread (unless I'm blind):
That certainly is promising progress. I'm wary of relying too much on SSIM or any other single-image comparison metric for video, as they don't take into account the critical temporal component of video encoding. There are good optimizations will reduce single-frame metrics but improve overall quality by burying artifacts and error in very short-lived elements of the image.

[Tommy Carrot]

That certainly is promising progress. I'm wary of relying too much on SSIM or any other single-image comparison metric for video, as they don't take into account the critical temporal component of video encoding. There are good optimizations will reduce single-frame metrics but improve overall quality by burying artifacts and error in very short-lived elements of the image.

I don't think they rely solely on metrics for the development. Some techniques they use, like activity masking for example decrease psnr and ssim quite considerably, but increase visual quality.

Temporal quality is still somewhat a weak point of daala, but it has improved considerably in the last half year or so. I think using bidirectional prediction could fix this issue though.

[benwaggoner]

I don't think they rely solely on metrics for the development. Some techniques they use, like activity masking for example decrease psnr and ssim quite considerably, but increase visual quality.

Temporal quality is still somewhat a weak point of daala, but it has improved considerably in the last half year or so. I think using bidirectional prediction could fix this issue though.



I mean no criticism of Daala in providing SSIM charts. I'm confident that they are optimizing for perceptual quality. SSIM was a reasonable metric to make that kind of graph as well. I just wanted to warn against reading more into it than the data merits. Graphs can be oh so terribly seductive :)...


-Ben Waggoner (via TapaTalk)

[dapperdan]

That particular slide was discussed when presenting Daala progress to the IETF, as part of the decision for work to commence on a NetVC codec project:

https://www.ietf.org/proceedings/92/slides/slides-92-netvc-0.pdf

There's accompanying audio on http://wiki.xiph.org/Daala under the heading "2015-03-24 IETF 92 NetVC Meeting".

If I recall correctly they said that FastSSIM was the best for them in that particular test, there are 3 other objective metrics that they track currently which made for less impressive graphs. On the other hand, I think they state that the Daala version tested was missing a few basic tools that they haven't added yet. They also state that they are not relying on metrics alone to drive development, and have put a lot time into engineering a process whereby they can get the encodes back within 20 minutes to allow for them to check each change with their own eyes, and that they are looking at actual results "constantly", whereas some other codec efforts require literal days of encoding at this stage in the process which breaks an important feedback loop.

The use of multiple objective codecs reminds me of the phrase known as Segal's Law:

"A man with a watch knows what time it is. A man with two watches is never sure."

In this case I think the uncertainty created by the multiple objective metrics accurately reflects the fact that they only correlate with subjective viewer opinion in aggregate, and are only an imperfect map, not the territory they seek to represent.

[LigH]

If I recall correctly they said that FastSSIM was the best for them in that particular test...

Sounds like another proverb, or aphorism, I like to quote sometimes:

The advantage of {standards|metrics} is that you can choose one of so many.

Of course, why not select the most convenient metric with the most impressive result in your favour... who doesn't. Pimp my Presentation! :sly:

Meanwhile in the Ivory Tower, an ABX comparison gets prepared. :D

But, not to be misunderstood: My best wishes for success. So that we will have so many good codecs to choose one from.

[MoSal]

Discussing Daala and metrics is incomplete without linking to AWCY:

https://arewecompressedyet.com/

AWCY was originally the work of a Mozilla intern, not Daala developers. And no, they are not specifically optimizing for any of the four metrics. Nor are they making any broad claims based on them.

Metrics do have limited usefulness when used to track the development of a specific encoder. But they are nearly useless (and usually deceitful) when used to compare different codecs. Daala developers are well aware of all that.

[benwaggoner]

They also state that they are not relying on metrics alone to drive development, and have put a lot time into engineering a process whereby they can get the encodes back within 20 minutes to allow for them to check each change with their own eyes, and that they are looking at actual results "constantly", whereas some other codec efforts require literal days of encoding at this stage in the process which breaks an important feedback loop.
This is a really good point. The faster iterations on quality tuning can be done, the faster the codec will be. This is the big reason why reference encoders tend to offer subjective quality so much worse than actual implementations of it a few years later. It is a tricky balance, designing a bitstream format that allows for all sorts of psychovisual optimizations when you can't actually see those optimizations. So far, the MPEG process has produced codecs with lots of room for visual refinement. I do wonder sometimes about added features that could have been, but weren't because they didn't help PSNR. I don't have any examples offhand, but it seems probable.

Anyway, kudos to Daala for taking this approach. The more novel the fundamental approach of the codec, the more rapid fine tuning and testing is required.

The use of multiple objective codecs reminds me of the phrase known as Segal's Law:

"A man with a watch knows what time it is. A man with two watches is never sure."

In this case I think the uncertainty created by the multiple objective metrics accurately reflects the fact that they only correlate with subjective viewer opinion in aggregate, and are only an imperfect map, not the territory they seek to represent.
Indeed. Having just one metric can drive pathological curve fitting, optimizing for what's easily measured instead of what's important.

I'd really like to see objective interframe metrics included by default in testing, as that captures a whole other axis. I don't know which ones are better than others, though.

[Kurtnoise]

Fresh windows builds from today...x86 (http://www.mediafire.com/download/au4b2sqv0l858dc/daala-0.0-997_x86_20150604.7z)|x64 (http://www.mediafire.com/download/kit572ado51v561/daala-0.0-997_x64_20150604.7z)

Changelog (https://git.xiph.org/?p=daala.git;a=summary)

Patches incoming (https://review.xiph.org/)

[wiak]

Fresh windows builds from today...x86 (http://www.mediafire.com/download/au4b2sqv0l858dc/daala-0.0-997_x86_20150604.7z)|x64 (http://www.mediafire.com/download/kit572ado51v561/daala-0.0-997_x64_20150604.7z)

Changelog (https://git.xiph.org/?p=daala.git;a=summary)

Patches incoming (https://review.xiph.org/)
FEI: https://mf4.xiph.org/jenkins/job/daala-mingw64/lastBuild/
:stupid:

[Tommy Carrot]

FEI: https://mf4.xiph.org/jenkins/job/daala-mingw64/lastBuild/
:stupid:

That's nice, but Kurtnoise makes static builds, so there's no need to mess with dlls, and he also makes 32 bit builds, which for some reason produces different (in many cases better quality) output (not to mention they also work on older OSes too), so his builds are much appreciated.

[wiak]

That's nice, but Kurtnoise makes static builds, so there's no need to mess with dlls, and he also makes 32 bit builds, which for some reason produces different (in many cases better quality) output (not to mention they also work on older OSes too), so his builds are much appreciated.
xiph builds are static
huh 32-bit produces better quality than 64-bit?
where does it say that?

[mzso]

xiph builds are static
huh 32-bit produces better quality than 64-bit?
where does it say that?

What do you mean "it"? He said it. Probably based on experience.

[foxyshadis]

xiph builds are static
huh 32-bit produces better quality than 64-bit?
where does it say that?

xiph builds are only partially static. They still bundle non-daala dlls, instead of static building libogg, libiconv, and SDL. (Which actually increases the overall size, since a lot of SDL & libiconv isn't even necessary.) Kurtnoise and I make builds that only depend on native Windows dlls.

[LigH]

Parallel to autobot builds of x265 (https://encoder.pw/x265/), x265.cc also installed regular builds for Daala (https://encoder.pw/daala/).

[wiak]

just me fooling around
http://screenshotcomparison.com/comparison/137173

and in other news
posted some newer x64 cygwin builds
http://awesome.nwgat.ninja/daala/win64/

the example_encoder got some improvements in latest builds

[Tommy Carrot]

the example_encoder got some improvements in latest builds
The ringing got reduced quite significantly in the last few weeks, there is still some but it's starting to reach acceptable levels. Unfortunately, the detail retention got worse in exchange. In my opinion the most promising feature of daala was that it tried to preserve every details, even the finer ones, unlike most other codecs which blur out the 'non-important' details. Now it behaves closer to those other codecs, but daala is in the middle of a tuning process, hopefully they will find a way to bring back the older behaviour with reduced compression artifacts.

[wiak]

The ringing got reduced quite significantly in the last few weeks, there is still some but it's starting to reach acceptable levels. Unfortunately, the detail retention got worse in exchange. In my opinion the most promising feature of daala was that it tried to preserve every details, even the finer ones, unlike most other codecs which blur out the 'non-important' details. Now it behaves closer to those other codecs, but daala is in the middle of a tuning process, hopefully they will find a way to bring back the older behaviour with reduced compression artifacts.
i suspect this one (https://github.com/xiph/daala/commit/10979badd2ea9bcc6fb011967c705a68b110210c) is the one your talking about

tested with some other settings aka -v 14 -z 10 the other one was v20 (with default z7)
http://screenshotcomparison.com/comparison/137274

i was bored so i made a simpler script to encode with
http://nwgat.ninja/daala-simple-encoder/

[jmvalin]

i suspect this one (https://github.com/xiph/daala/commit/10979badd2ea9bcc6fb011967c705a68b110210c) is the one your talking about


The move to 4-point lapping is one of the changes that reduced ringing at the expense of fewer details, but there's also some changes in the distortion metric (https://github.com/xiph/daala/commit/b4fa1838b766b03d49800f474d5888ab10e78fc1) and the addition of late skip (https://github.com/xiph/daala/commit/faa8b4394852f76a9cfd78226c6880055de9953e). Feedback on the visual quality of these changes is welcome. They looked like a win overall, but it's always possible to revert if they're not.

[wiak]

just compiled a newer build under cygwin 64
http://awesome.nwgat.ninja/daala/win64/

this one has a 8-direction deringing filter
https://github.com/xiph/daala/commits/master

[Tommy Carrot]

Thanks, the official builds sometimes crash or produce corrupt videos on my computer, your build works fine.

I did a few tests with this build. The ringing is almost completely gone, in fact the output is almost artifact-free. The detail-retention is still worse than it was a couple months ago, but i guess this is the trade-off for getting rid of the artifacts.

[mandarinka]

Talk on Daala from VDD 2015: https://www.youtube.com/watch?v=g7fVwIZBW8Q

I'm not sure if it contains completely new info on the techniques (those paying close attention might already know the actual state), but there is one highlight there. Finalization is planned under the IETF NetVC project (so probably in combination with Thor and perhaps other IP) and the current goal is for the format to get finalized in May 2017. Which means it is long way in the future, if you add the time needed for polished encoders to happen (if they happen).

[CruNcher]

This is really nice Assessment of a former Itterated Fractal Encoder Employer (he was in the Marketing department) before the AFOMC was formed tough :)

https://www.youtube.com/watch?v=9GjgCQbIMYA

Wonder what his assessment would look like now that AFOMC was formed ;)

[LigH]

I remember the IFS approach from Iterated System, used in ClearVideo (RealVideo Fractal), from a long time ago; never heard of it again since. Some of the main disadvantages were slow speed and low precision. And I wouldn't be surprised about a pocket full of patents...

[CruNcher]

Yeah Clearvideo is still partly mind blowing so freaking diferent when you watch it in Motion :)

his assumptions about PERSEUS he would better understand it reading the patents i guess but hes a marketing guy so maybe not really ;)

[wiak]

Thanks, the official builds sometimes crash or produce corrupt videos on my computer, your build works fine.

I did a few tests with this build. The ringing is almost completely gone, in fact the output is almost artifact-free. The detail-retention is still worse than it was a couple months ago, but i guess this is the trade-off for getting rid of the artifacts.
i updated the builds again, a month worth of commits
http://awesome.nwgat.ninja/daala/win64/

[Jamaika]

A few words about the codec Daala 0.0-1311-g7049228-dirty:
https://encoder.pw/daala/x86_64/
Daala codec isn't created for animation. There hasn't function RGB or alpha channel.
Not function for a bit depht above 8.
Can I use it to create individual photo? Certainly yes.

The newest codec is running slow now, but as they go progress?
- the codec hasn't problems with the use of low GOP.
- the codec still doesn't support the bitrate. {-V}
- the codec has problems when the quality is equal to {-v 40} and complexity equal to {-z 4} color-matching for yuv420p (approximate bitrate ~4700kbps). These unwanted splashes of color. For yuv444p it is well.
- the codec has a viewer who isn't running smoothly. You can't play movies on players. Lack of of decoders.

ffmpeg.exe -loglevel warning -i "input_uyvy422.avi" -s 1920x1080 -r 30000/1000 -an -sn -f yuv4mpegpipe -pix_fmt yuv420p - | encoder_example.exe --keyframe-rate 30 --video-quality 40 --complexity 4 --output "xiph_0.0.1311_yuv420p.ogg" -

[Tommy Carrot]

I don't know what's the deal with the encoder.pw builds, but they produce completely different (and noticeably worse quality) output than the xiph.org builds. Also, there were some changes recently which made encoding much slower than before, but the latest encode.pw build still has similar encoding speed to the older versions. I might be completely wrong, but it seems to me that the buildbot somehow stuck on a few months old version.

[Jamaika]

I don't know what's the deal with the encoder.pw builds, but they produce completely different (and noticeably worse quality) output than the xiph.org builds.
Oops... you surprised me. Where can the latest encoder Daala download?

[Tommy Carrot]

Here is the latest official build: https://mf4.xiph.org/jenkins/job/daala-mingw64/lastBuild/

I must warn you though, it's very slow.

[Jamaika]

Thanks. All clear.
PS I see that new versions viewers don't support of old files ogg. Interesting...

[wiak]

Thanks. All clear.
PS I see that new versions viewers don't support of old files ogg. Interesting...
xiph builds are the most updated offical ones, i also has some that i do manually, and there is also encoder.pw

btw, daala is not yet finalized, thats why you cant play a file encoded in another build version

[wiak]

A few words about the codec Daala 0.0-1311-g7049228-dirty:
https://encoder.pw/daala/x86_64/
Daala codec isn't created for animation. There hasn't function RGB or alpha channel.
Not function for a bit depht above 8.
Can I use it to create individual photo? Certainly yes.

The newest codec is running slow now, but as they go progress?
- the codec hasn't problems with the use of low GOP.
- the codec still doesn't support the bitrate. {-V}
- the codec has problems when the quality is equal to {-v 40} and complexity equal to {-z 4} color-matching for yuv420p (approximate bitrate ~4700kbps). These unwanted splashes of color. For yuv444p it is well.
- the codec has a viewer who isn't running smoothly. You can't play movies on players. Lack of of decoders.

ffmpeg.exe -loglevel warning -i "input_uyvy422.avi" -s 1920x1080 -r 30000/1000 -an -sn -f yuv4mpegpipe -pix_fmt yuv420p - | encoder_example.exe --keyframe-rate 30 --video-quality 40 --complexity 4 --output "xiph_0.0.1311_yuv420p.ogg" -
well its not set in stone, the spec is expected to be finalized in 2017*
you can spank them at their freenode channel (http://webchat.freenode.net/?channels=%23daala) or stalk them on their github page (https://github.com/xiph/daala)

FYI: they are watching this thread too
:stupid:

[Jamaika]

Thanks for the info. I don't know whether I want to register to freenote.net? I don't know what the interest is of codec Daala. I understand that this is now a website that analyzes the opinion of users.

[foxyshadis]

Freenode is an IRC server, a group chat. You don't need to register, you just pick a name, enter, and talk. The link even takes you to webirc if you don't have one. It's a very good idea to file your requests on github where they'll be tracked; they'll probably ask you to anyway.

[MoSal]

For this application [Screencasting], an important requirement is the support of a wide range of video formats (e.g., RGB) in addition to YUV 4:2:0 and YUV 4:4:4.


I expect Daala developers to do this eventually. But there is so much work to do before getting to those requirements.

-------------------

Daala developers made a lot of progress in the last few months. Basic B-frame support landed. More work is in progress.

Encoding is way slower than the last time I tested.

Decoding is way faster than the last time I tested. It already looks like a (future) multi-threaded Daala decoder will be capable of doing real-time decoding in most hardware.

I tested Daala, x264, x265 with a very grainy 720p/23.976fps sample (low movement, low details).

Daala: VBR / ~2700kbps / defaults, 2 B-frames
x265 : CRF / ~2700kbps / defaults
x264 : CRF / ~2700kbps / defaults, slower preset

Daala already handles grain very well. But retains less details than x265 in some frames. x264 is still the clear winner, at least with this type of content.

The overall result:
x264 > Daala > x265

It's funny how metrics (all of them) draw a very different picture.

[qyot27]

Decoding is way faster than the last time I tested. It already looks like a (future) multi-threaded Daala decoder will be capable of doing real-time decoding in most hardware.
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/185959.html

It'll be interesting to see what kind of performance it'll get after it's refined enough for commit.

[Bloax]

The overall result:
x264 > Daala > x265

It's funny how metrics (all of them) draw a very different picture.
Well yes, x265 is more tuned towards metrics while x264 has dropped that a very long time ago and went down the psychovisual optimization rabbit hole.

[Tommy Carrot]

Well yes, x265 is more tuned towards metrics while x264 has dropped that a very long time ago and went down the psychovisual optimization rabbit hole.
The daala devs are paying a little too much attention to the metrics as well, in my opinion. They recently added a couple of new techniques which are improving the metrics pretty considerably, but their effect on the visual quality is not really positive, to say the least.

[Jamaika]

Originally Posted by https://tools.ietf.org/html/draft-ietf-netvc-requirements-00
For this application [Screencasting], an important requirement is the support of a wide range of video formats (e.g., RGB) in addition to YUV 4:2:0 and YUV 4:4:4
Me interested the facts rather than the far future.
encoder_example accepts only uncompressed YUV4MPEG2 video.
Encoding is way slower than the last time I tested.
It isn't really advert. 100 frames in 3h.

I tested Daala 4:4:4. Unfortunately, the codec doesn't retain the color. They are faded ie. in the X265 1.8.0.188.
FFplay daaladec: Implement a native Daala decoder
When? Another distant future.
Current ffplay 31122015 doesn't accept dalla.

[wiak]

http://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/185959.html

It'll be interesting to see what kind of performance it'll get after it's refined enough for commit.
https://0x0.st/Xmi.pdf is the pdf presentation

[jmvalin]

The daala devs are paying a little too much attention to the metrics as well, in my opinion. They recently added a couple of new techniques which are improving the metrics pretty considerably, but their effect on the visual quality is not really positive, to say the least.

We've made a lot of improvements recently, but it's indeed possible we also hurt visual quality in some cases. It would be good if you could identify what are the changes that you think had a negative effects on quality so we can address the problem.

[mandarinka]

Hmm, so AOM/NetVC will end up as something built on top of libvpx? That's a bit troubling thing to hear. I hope this time the reference implementation really won't be the go to (much less the only) production one, too...

[Bloax]

The daala devs are paying a little too much attention to the metrics as well, in my opinion. They recently added a couple of new techniques which are improving the metrics pretty considerably, but their effect on the visual quality is not really positive, to say the least.
That is terrible screeching to my ears. :-(

[Tommy Carrot]

We've made a lot of improvements recently, but it's indeed possible we also hurt visual quality in some cases. It would be good if you could identify what are the changes that you think had a negative effects on quality so we can address the problem.
Golden frames are one of them. The golden frames have noticeably higher quality than the rest of the frames, and in some cases this makes a very noticeable effect during playback. Periodically the video 'jumps' as the previously lost details are popping back. It can be very distracting during playback, and it makes the quality uneven. I've reported this issue a few months ago with example videos, but apparently you disagreed with my concerns.

The other issue is the over-quantization of b-frames at lower bitrates. The b-frames are so overcompressed above -v 25 that many motions are simply skipped, so during playback the video looks choppy, it almost looks like you've divided the framerate with the number of b-frames.

[LigH]

^ a similar effect as the notorious half-second "quantization pumping" on DVDs with larger I:P quant ratios (I remember "Animatrix" as an example).

[jmvalin]

Golden frames are one of them. The golden frames have noticeably higher quality than the rest of the frames, and in some cases this makes a very noticeable effect during playback. Periodically the video 'jumps' as the previously lost details are popping back. It can be very distracting during playback, and it makes the quality uneven. I've reported this issue a few months ago with example videos, but apparently you disagreed with my concerns.

I mean I see what you're talking about, but I think this issue essentially comes down to personal taste. Boosting golden frames causes the "jumps" you're noticing, but at the same it reduces the number of smaller, more frequent jumps, which I find even more annoying. When we did some visual comparisons with different golden frame boosts, two of us preferred an even stronger boost than we are using now, while two more people (including you) preferred a weaker boost. So we decided that it "roughly in the middle". The sample size is of course too small for a definite answer, but it's actually easy to revisit this later as it's just a single parameter to change. And yes I agree that this particular feature is something for which metrics are particularly unreliable since the artefacts are temporal, but the metrics are computed on one frame at a time. That's why we've relied on visual inspection only here.

The other issue is the over-quantization of b-frames at lower bitrates. The b-frames are so overcompressed above -v 25 that many motions are simply skipped, so during playback the video looks choppy, it almost looks like you've divided the framerate with the number of b-frames.

B-frames are a very recent development that I've not been involved with, so I can't say very much here. Just that there's probably a lot of room for improvement.

Are there other areas where you think we've made the wrong decision quality-wise?

[MoSal]

@jmvalin

I see the deringing filter was changed from on/off to 6 level recently.
I think less/weaker filtering might help at high bit-rates if the user strongly prefers preserving high frequencies as much as possible.

[Tommy Carrot]

^ a similar effect as the notorious half-second "quantization pumping" on DVDs with larger I:P quant ratios (I remember "Animatrix" as an example).
Yep.
I mean I see what you're talking about, but I think this issue essentially comes down to personal taste. Boosting golden frames causes the "jumps" you're noticing, but at the same it reduces the number of smaller, more frequent jumps, which I find even more annoying.
In my opinion the regularly repeating jumps are much more perceptible than random smaller ones. Once you notice the pattern, it's too obvious to ignore it.

Also, these issues are usually solved as a codec is getting more mature and fine-tuned (for example x264 and x265 do not really have the "jumpy block" problem at all). Golden frames on the other hand inherently have this problem, no amount of tuning will solve it, the only way to mitigate it if you decrease the boost to a minimum - which makes almost the entire gain disappear.

[Gravitator]

It has not been updated since 2014. https://people.xiph.org/~xiphmont/demo/daala/update1-tool2b.shtml

[dapperdan]

There's a photo comparison tool on their arewecompressedyet site (assuming you want something like the above link, but with newer examples):

https://arewecompressedyet.com/

I can't seem to make a direct link, but there's an "images" tab at the top of the page.

[Gravitator]

There's a photo comparison tool on their arewecompressedyet site...
Thank you :) It is seen as a struggle with the ringing / comb at the edges.

[jmvalin]

Just thought some people here might be interested in a new demo we just published explaining the Daala deringing filter. (https://people.xiph.org/~jm/daala/deringing_demo/)

[foxyshadis]

That's fascinating! I bet that filter would do a fine job of cleaning up even a JPEG, as well. I'm really looking forward to seeing AV1 in action.

[mzso]

Now that Mozilla is part of the Alliance for Open Media (AOM), we are integrating technology from Daala into the new AV1 codec. This new codec combines technology from Google's VP9 codec, Cisco's Thor codec, our Daala codec, as well as new technology developped within AOM. For this reason, we are now putting significant effort into the AOM project. We will also continue to improve Daala and use it as a research test bed for new coding techniques.

So maybe this thread should be renamed. Daala is now only a testbed and won't be a usable codec.

[Clare]

Hey I updated an old image comparison page made by forum member xooyoozoo.
It includes the new codec AV1 with the deringing filter by jmvalin enabled. (and other formats like FLIF, Daala, VP10…)

See my signature.

[Jamaika]

See my signature.

Good job, but for me the test is tendentious.
Why do almost all of the pictures are made dark or at night?
BPG looks great when there is a lot of detail.
I don't understand also why isn't the codec BPG RGB(A) range full, preset placebo -m 9?
Why aren't the codecs Daala, VP10(range limited), AOM, FliF in yuv444p?
All images have been subsampled to full range YCbCr prior to compression. All lossy images are encoded with chroma subsampling 4:2:0
Why is color range and scan type all lossy images?

Writing '+d649065' isn't legible. I guess what is the version of the codec?

[Clare]

Good job, but for me the test is tendentious.
Why do almost all of the pictures are made dark or at night?
There are 50 images, most of them not dark.
BPG looks great when there is a lot of detail.
Actually from what I gathered, BPG is the best at keeping detail at extremely low settings, which wouldn't be typical. In average settings, Daala and AV1/VP10 take precedence in keeping details.
I don't understand also why isn't the codec BPG RGB(A) range full, preset placebo -m 9?
Why aren't the codecs Daala, VP10(range limited), AOM, FliF in yuv444p?All images have been subsampled to full range YCbCr prior to compression. All lossy images are encoded with chroma subsampling 4:2:0
Why is range all lossy images?
Because to compare the formats, I had to convert them to the lowest possible denominator, i.e. Daala, VP10, and AV1 only take Y4M as input, hence YCbCr. And I don't see the point in using full chroma for a lossy comparison.

Writing '+d649065' isn't legible. I guess what is the version of the codec?
It's the git revision when built from master, i.e. the dev version on the 1st of April.

[Jamaika]

Because to compare the formats, I had to convert them to the lowest possible denominator, i.e. Daala, VP10, and AV1 only take Y4M as input, hence YCbCr. And I don't see the point in using full chroma for a lossy comparison.
You're right. Now I see that for the option tiny YUV 420 effect subsampling doesn't matter. I read a comments that is visible to the naked eye.

[Nevilne]

Just fyi it's fine to use subsampling for tests like these, however in general codecs after and including h264 will be more size/quality efficient with yuv444.

[Tommy Carrot]

Hey I updated an old image comparison page made by forum member xooyoozoo.
It includes the new codec AV1 with the deringing filter by jmvalin enabled. (and other formats like FLIF, Daala, VP10…)

See my signature.

Nice, good job. AV1 and VP10 are looking quite good, they seem to be similarly efficient as BPG in the high contrast areas, but with way less blurring in the low-contrast parts.

[LigH]

Really impressive results already. I guess not all of these encoders are currently available for own tests?

[Clare]

Really impressive results already. I guess not all of these encoders are currently available for own tests?
Which ones do you mean?
The ones on my webpages are all compiled from the public gits. (although I think the one you publish for VP10 is from the master branch, whereas the one I used is from the branch nextgenv2)

[jmvalin]

So maybe this thread should be renamed. Daala is now only a testbed and won't be a usable codec.

This is not quite what I said in the demo. Daala will not be used as a standalone video codec in the short term, but that may still happen in the longer term.

[BadFrame]

Which ones do you mean?
whereas the one I used is from the branch nextgenv2)

Yes this seems to be where VP10 development is currently happening, quite active branch:

https://chromium.googlesource.com/webm/libvpx/+log/nextgenv2

[LigH]

Which ones do you mean?

AV1, BPG, etc. — all these funky new encoders I was not yet aware of, don't even know if they are for images only or even videos. Will search for more...

Now that I wanted to look at your site again, it seems to be gone.

http://wyohknott.github.io/ ==> HTTP 404

[mzso]

AV1, BPG, etc. — all these funky new encoders I was not yet aware of, don't even know if they are for images only or even videos. Will search for more...

Now that I wanted to look at your site again, it seems to be gone.

http://wyohknott.github.io/ ==> HTTP 404

AV1 was just mentioned as the video codec of Alliance for Open Media. BPG appeared in earlier demos. Wikipedia says it's basically a HEVC I-frame.

[jon]

Because to compare the formats, I had to convert them to the lowest possible denominator, i.e. Daala, VP10, and AV1 only take Y4M as input, hence YCbCr. And I don't see the point in using full chroma for a lossy comparison.

It's the git revision when built from master, i.e. the dev version on the 1st of April.

For FLIF, two remarks:
- FLIF (currently) does not take 4:2:0 YCbCr as input, so it is encoding things as if it were 4:4:4 RGB (converted to YCoCg internally). It would not be hard to make it support YCbCr and chroma subsampling natively, which should shave off some bytes.

- FLIF's lossy encoder has improved slightly in this commit:
https://github.com/FLIF-hub/FLIF/commit/8f7d3dda30652b7df0da9814a660f20d7ec5fd3c

[Clare]

AV1, BPG, etc. — all these funky new encoders I was not yet aware of, don't even know if they are for images only or even videos. Will search for more...
AV1, VP10, and Daala are video-only codecs, but I have a glimmer of hope that somebody will do like my fellow Fabrice Bellard did with HEVC and BPG.
Or maybe the Alliance for OpenMedia will also propose a new still image codec, with Microsoft, Mozilla and Google on board, it could be doable to initiate a change. JPEG seems unbeatable though.


Now that I wanted to look at your site again, it seems to be gone.

http://wyohknott.github.io/ ==> HTTP 404

Yeah Github was being a **** yesterday because the files are too heavy when I update :/

[foxyshadis]

AV1, VP10, and Daala are video-only codecs, but I have a glimmer of hope that somebody will do like my fellow Fabrice Bellard did with HEVC and BPG.

Any video codec can be trivially wrapped in a RIFF or TIFF container that holds the relevant photographic metadata, like WebP. BPG is particularly interesting because he modified the bitstream to be container agnostic without giving up any metadata, and saving unnecessary space as well, but at the cost of a bit more overhead all of that can be grafted onto any modern format.

[dapperdan]

Some recent Daala slides:
https://www.ietf.org/proceedings/95/slides/slides-95-netvc-2.pdf

Other stuff from the same meeting, includes Thor, testing protocols, requirements for the netvc codec:
https://www.ietf.org/proceedings/95/minutes/minutes-95-netvc

[Jamaika]

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

-d --buf-delay <n> Buffer delay (in frames). Longer delays
allow smoother rate adaptation and
provide better overall quality, but
require more client side buffering and
add latency. The default value is the
keyframe interval for one-pass encoding
(or somewhat larger if --soft-target is
used) and the total remaining length of
the video for two-pass encoding.

--soft-target Use a large reservoir and treat the
rate as a soft target; rate control is
less strict but resulting quality is
usually higher/smoother overall. Soft
target also allows an optional -v
setting to specify a minimum allowed
quality.

PS Unfortunately, lack of implementation of FFmpeg 20160525. Nor do I know at what stage of of implementation codec is AV1. ):

[jmvalin]

Here's a new Daala demo (https://people.xiph.org/~jm/daala/revisiting/). This one is actually revisiting all of our previous technology demos to see what worked, what didn't and how things changed.

[Jamaika]

All beautifully. So far codec is a sham. Message is displayed:
None of the functions don't work.
av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
It took some time to understand that these patterns were caused by successive accumulation of "noise" coming from the interaction between the lapping filters and the rounding that was taking place when the 12-bit "intermediate" images were being rounded down to 8 bits for use as reference in future frames. Trying to change how the rounding was done or how the lapping was done went nowhere, originally causing some concerns over the viability of lapping itself. Fortunately, two solutions eventually emerged. One was to simply store all reference frames in 12 bits rather than 8. This requires more memory and more memory bandwidth, but also improves coding efficiency for all sequences (even those that did not trigger the problem). It's something that's also needed anyway for 10-bit and 12-bit input support.
About importing files 10/12 bit we can forget.

[Nintendo Maniac 64]

About importing files 10/12 bit we can forget.
10bit or more is necessary for good HDR, otherwise you'll have visible color banding.

[Kurtnoise]

frankly, what did you smoke ?

[wiak]

AV1, VP10, and Daala are video-only codecs, but I have a glimmer of hope that somebody will do like my fellow Fabrice Bellard did with HEVC and BPG.
Or maybe the Alliance for OpenMedia will also propose a new still image codec, with Microsoft, Mozilla and Google on board, it could be doable to initiate a change. JPEG seems unbeatable though.



Yeah Github was being a **** yesterday because the files are too heavy when I update :/
well heard of WebP? that was basicly a VP8 frame, pretty sure someone at aomedia will do the same to AV1 and call it WebP v2, much like they did with WebM and added VP8, VP9

i expect the webm v3 spec to include AV1 with Opus

WebM v1 = VP8 + Vorbis
WebM v2 = VP9 + Opus
WebM v3 = AV1 + Opus

Here's a new Daala demo (https://people.xiph.org/~jm/daala/revisiting/). This one is actually revisiting all of our previous technology demos to see what worked, what didn't and how things changed.
thanks btw would been cool if there was AV1 demo pages too :)

[benwaggoner]

VP8 isn't competitive against HEVC for still images. The power of intra-frame prediction is huge, as are the variety and flexibility of block sizes. Plus the ability to losslessly encode individual TUs for graphics or text.


Sent from my iPad using Tapatalk

[Nintendo Maniac 64]

VP8 isn't competitive against HEVC for still images.

...no dip? Who was arguing that?

[mzso]

By the way, how far past jpeg are we with HEVC? Too bad the IETF doesn't push for a new image format too like with video. If it became widespread on the internet it'd soon seep down to digital photography too.

JPEG is surpassed technology, yet it's pretty much the only lossy image format worth mentioning.

[Jamaika]

JPEG is surpassed technology, yet it's pretty much the only lossy image format worth mentioning.
Off the topic at Daala, but ...

There was a lot of advertising for a five years to replace JPEG. He had to enter photos WEBP with codec VP9/VP10. He was BPG (HEVC), which is already very old and not updated. Advertising codecs FLIF.
The truth is that hardware manufacturers don't want to replace JPEG. JPEG evolved. He became a container 8/10/12/16 depth bit. It is with compression mode progress, which took over the technology of Adobe DNG. There isn't colormatrix bt2020 and has an old packer libzip 1.2.7. (options not supported by ffmpeg)

The program which implemented a partial identification of BPG image is MediaInfo, it is not too much.
VP8 isn't competitive against HEVC for still images. The power of intra-frame prediction is huge, as are the variety and flexibility of block sizes. Plus the ability to losslessly encode individual TUs for graphics or text.
There are no miracles. They strive for perfection.

Comparison of codecs: bitrate=3000kbps
Warning. Bitrate is false, applies to all one hundred frames and not the individual.
Original:
Daala codec v0.0-1598-g7290550
daalaenc.exe --b-frames 4 --keyframe-rate 50.000 --complexity 5 --video-rate-target 3000k --soft-target --output "image.ogg" - {functions disabled: bit-depth=10+}
Selur codec vpxenc v1.5.0-936-g6f397b8
vpxenc.exe --bit-depth=8 --input-bit-depth=8 --threads=4 --i420 --profile=0 --best --codec=vp9 --fps=50000/1000 --cpu-used=0 --passes=1 --pass=1 --drop-frame=0 --disable-kf --target-bitrate=3000
--end-usage=vbr {recommended: --end-usage=cbr --gf-cbr-boost=200} --aq-mode=1 --output="image.webm" -
Komisar codec x264 r2705kMod
x264.exe --demuxer y4m --preset veryslow -tune stillimage --input-depth 8 --input-res 1920x1080 --input-csp i420 --output-depth 8 --fps 50000/1000 --keyint 250 --bitrate 3000 --output "image.h264" -
El Heggunte GCC 5.3.0 v2.0+2
x265.exe --y4m --no-info --preset veryslow --no-open-gop --input-depth 8 --input-res 1920x1080 --input-csp i420 --output-depth 8 --fps 50000/1000 --keyint 250 --bitrate 3000 --output "image.h265" -
nwgat.ninja (https://awesome.nwgat.ninja/aomedia) aomenc.exe GCC 5.3.0 v0.1-daf841b (12.07.2016)
aomenc.exe --threads=4 --i420 --profile=0 --best --codec=av1 --fps=50000/1000 --cpu-used=0 --passes=1 --pass=1 --drop-frame=0 --disable-kf --target-bitrate=3000
--end-usage=vbr {recommended: --end-usage=cbr --gf-cbr-boost=300} --aq-mode=1 --output="image.webm" - {functions disabled: pass=2, bit-depth=10+}
Themselves evaluate codecs. :)

[BadFrame]

By the way, how far past jpeg are we with HEVC?

Wyohknott at github offers a wide range of comparisons, AOM AV1, BGP, Daala, Webp, FLIF, VP10 ... and of course jpeg

Here's a comparison between OAM AV1 and HEVC:

http://wyohknott.github.io/image-formats-comparison/#mascot&aom=m&bpg=m

There are lots of images to compare with as well, just choose your combinations from the drop down lists.

[mandarinka]

well heard of WebP? that was basicly a VP8 frame, pretty sure someone at aomedia will do the same to AV1 and call it WebP v2, much like they did with WebM and added VP8, VP9

VP9 never made it into webp, which is a shame. Their excuse for not doing it was "we don't want fragmentation" which was IMHO pretty bad idea/mistake, because webp still has very little support (and where it is, it is software/browser based, so what are we even talking about?) and hence you can still update it like that.

[Quikee]

The truth is that hardware manufacturers don't want to replace JPEG. JPEG evolved. He became a container 8/10/12/16 depth bit. It is with compression mode progress, which took over the technology of Adobe DNG. There isn't colormatrix bt2020 and has an old packer libzip 1.2.7. (options not supported by ffmpeg)

JPEG wasn't replaced because it has a good enough compression ratio, has low complexity and its support is practically 100%. Also in all the years there was no viable alternative available - by that I mean a format that has a much better 50%+ compression ratio, is free (no patent issues), standarized, has reasonable complexity and has support in majority of browsers.

JPEG/JFIF - the standard format that has largest support didn't evolve much. Yes, it become faster to encode/decode, it gained quality/size because of more clever compression techniques that don't require to break the bitstream. However it didn't gain support for 10+ bit or anything such. Even the support for arithmetic coding (which should be part of the standard) instead of huffman can be problematic so you don't want to use it (and nobody does) for compatibility reasons.

[Jamaika]

However it didn't gain support for 10+ bit or anything such. Even the support for arithmetic coding (which should be part of the standard) instead of huffman can be problematic so you don't want to use it (and nobody does) for compatibility reasons.
Can see more and more converters JPEG 10+ bit on standard 9.2 (https://libraries.io/nuget/libjpeg/9.2.0.1).
12-bit JPEG codec on CUDA (http://www.fastcompression.com/products/jpeg/12-bit-jpeg-codec.htm)

[foxyshadis]

Can see more and more converters JPEG 10+ bit on standard 9.2 (https://libraries.io/nuget/libjpeg/9.2.0.1).
12-bit JPEG codec on CUDA (http://www.fastcompression.com/products/jpeg/12-bit-jpeg-codec.htm)

libjpeg isn't the JPEG standard, and in fact libjpeg7+ have been shunned because they break JPEG compatibility for no good reason, and the guy's frankly a little nutty. The recent 10-bit support is actually a good reason, but again, broken compatibility -- everyone writing and using decoders is too conservative to care about anything but the same JPEGs everyone's been using for over 20 years, and so no minor variant of it will ever matter.

DejaVu might've been successful years ago if it wasn't a giant pile of patents. Otherwise, storage and network speeds have improved too much, and the benefits of deep color too slim, for the masses to ever demand an update.

[Quikee]

libjpeg isn't the JPEG standard, and in fact libjpeg7+ have been shunned because they break JPEG compatibility for no good reason, and the guy's frankly a little nutty. The recent 10-bit support is actually a good reason, but again, broken compatibility -- everyone writing and using decoders is too conservative to care about anything but the same JPEGs everyone's been using for over 20 years, and so no minor variant of it will ever matter.

Yes, the mostly used open source library is libjpeg-turbo which is generally an fork of an old version of libjpeg with performance improvements added. libjpeg-turbo stopped following changes from libjpeg when they started with adding non-standard stuff and breaking ABI for no reason, so very few projects actually use libjpeg library today.

There is also JPEG-XT which is relatively new. The point of this format is to be compatible with JPEG and can be decompressed as a standard JPEG file. Additionally to that it would have extensions embedded in the container like high bit depth and lossless support which a JPEG-XT supported decoder could use. Nice idea but I don't think it will catch on..

[Jamaika]

libjpeg isn't the JPEG standard, and in fact libjpeg7+ have been shunned because they break JPEG compatibility for no good reason, ...
You're right, but recently a lot of advertising on 10bit MOV MJPEG. It is fiction, but I let myself be fooled.

http://www.acrovid.com/footagestudio.htm
http://www.cinemartin.com/next/

10bit lossy is Cineform, but it isn't MJPG.
How do I find a compact camera with 10bit JPEG images, I add a link.
http://www.shikino.co.jp/eng/products/JPEG-IP%20Leaflet_Ver1.01E_HP.pdf
http://www.shikino.co.jp/eng/products/
http://www.shikino.co.jp/eng/products/ip-1.html
http://www.sansmirror.com/cameras/a-note-about-camera-reviews/panasonic-camera-reviews/panasonic-gx7-review.html

[BadFrame]

There is also JPEG-XT which is relatively new. The point of this format is to be compatible with JPEG and can be decompressed as a standard JPEG file. Additionally to that it would have extensions embedded in the container like high bit depth and lossless support which a JPEG-XT supported decoder could use. Nice idea but I don't think it will catch on..

I'd say not a chance, given that a lot of the standard is patented and subject to royalties.

Like you said, for a new format to come and replace jpeg, it needs to be royalty free (ain't no way the 'web' is going to start paying royalties for serving images), and a worthwhile improvement in compression, the ~50% you mentioned sounds reasonable.

I also think that widely supported hardware accelerated decoding would be needed, since the new format would most likely be more expensive cpu-wise.

I believe the only realistic option would be if AV1 was also offered as a image codec, Intel, AMD, ARM, NVidia are all aboard to support the AV1 codec, and Android SoC manufacturers like Qualcomm, Samsung will of course support it, and it's royalty free which means it can gain traction on the web and in apps (as in being supported).

As for the existing offerings, WebP was never good enough in lossy mode (lossless is great though), BGP is based on HEVC and thus patented/royalties = dead in the water, FLIF and Daala are promising but I can't see them ever gain hardware accelerated support.

[Quikee]

You're right, but recently a lot of advertising on 10bit MOV MJPEG. It is fiction, but I let myself be fooled.

It's not that it can't be done and looks like some try to add support for 10bit, but doing this is like adding 10bit support to MPEG2 - it can be done but you can't use any existing MPEG2 equipment to play it back - so what's the point of doing it.


10bit lossy is Cineform, but it isn't MJPG.
How do I find a compact camera with 10bit JPEG images, I add a link.

They use JPEG (extended) for 12bit which I think is JPEG XT (XT - extended) that I described in my previous post. So again - you will need a special decoder for such images to get all 12bits back, with a standard JPEG decoder you will get only 8bits.

They also talk about JPEG XR which is a completely different codec.

[Quikee]

I'd say not a chance, given that a lot of the standard is patented and subject to royalties.

I didn't look into royalties as I assumed JPEG (the committee) learned its lessons regarding patents.


I also think that widely supported hardware accelerated decoding would be needed, since the new format would most likely be more expensive cpu-wise.

Sure, that would be a bonus but I don't think this is required for success of a image codec. I think hardware manufacturers would fill this gap regardless if they are on-board from the start or not.


I believe the only realistic option would be if AV1 was also offered as a image codec, Intel, AMD, ARM, NVidia are all aboard to support the AV1 codec, and Android SoC manufacturers like Qualcomm, Samsung will of course support it, and it's royalty free which means it can gain traction on the web and in apps (as in being supported).

Yes, a new image codec from AOM would probably be successful but it doesn't need to be based on AV1. It could be based on Daala. A image codec is not priority now for AOM but I think they will looking into it when AV1 is launched.

[Jamaika]

So again - you will need a special decoder for such images to get all 12bits back, with a standard JPEG decoder you will get only 8bits.
It's just me not surprised. It is worse with the comfort of work. :(
It remains to use the DNG.
https://photographylife.com/dng-vs-raw

[BadFrame]

I didn't look into royalties as I assumed JPEG (the committee) learned its lessons regarding patents.

One would think so with the history of jpeg and unused potential due to patents, however that is not the case.

From what I've read, not even XR baseline profile is guaranteed to be free from royalties (!), it's clear to me that the jpeg committee has lost any relevance, attempting to introduce a patent-burdened image codec today when even video is going towards royalty free is just insane.


Sure, that would be a bonus but I don't think this is required for success of a image codec. I think hardware manufacturers would fill this gap regardless if they are on-board from the start or not.
Depending on your definition of success, I think I disagree, as my definition would be replacing jpeg as the de facto (lossy) image format. Given how mobile is increasingly becoming the way people consume web content, I think the chance of gaining the necessary traction without hardware decoding is very unlikely.


Yes, a new image codec from AOM would probably be successful but it doesn't need to be based on AV1. It could be based on Daala.

Sure, Mozilla/Daala are part of the AOM so it's certainly not impossible, my doubt again comes back to hardware support, AV1 will be hardware supported, which most likely means it should be easier to implement a hardware accelerated image codec based upon it.

A image codec is not priority now for AOM but I think they will looking into it when AV1 is launched.

Here's hoping.

Of course, AV1 itself also needs to survive what I expect to be a massive patent aggression from the MPEG LA group, they won't give up their patent cash cow business model of : 'pick a bunch of patents from the pool, implement a slight improvement on the current video codec standard, charge royalties, rinse and repeat' : without a fight.

That said, with the companies behind AOM, I think we have the best chance ever of seeing royalty laden video codecs be history.

[mandarinka]

they won't give up their patent cash cow business model of : 'pick a bunch of patents from the pool, implement a slight improvement on the current video codec standard, charge royalties, rinse and repeat' : without a fight

It is fine to be a fan of royalty free codecs, but I think you give the MPEG technology a little bit too small credit.
HEVC isn't just a small slight improvement. And are we forgetting already that VP9 is basically just a copy of HEVC with some nerfs (worse reference structure, weird hacky b-frames, lack of weighted prediction or SAO, IIRC)? On2 still did it the usual way: take ideas from the MPEG standard, and obfuscate them a bit to not be directly exposed to patent lawyers.

And currently, VP9 is the format that AV1 is being built on! So I'd say we should get a bit more mature on the freetard/fanboy feelings toward MPEG. Not to mention when the best video coding technology to this day (x264) was based on their codec.


Also, MPEG-LA royalties are sane and okay. It is the greedy companies that split off from MPEG-LA pool that went overboard and caused a SNAFU.

[dapperdan]

... So I'd say we should get a bit more mature on the freetard ...

Yes, maturity is definitely required here.



Also, MPEG-LA royalties are sane and okay. It is the greedy companies that split off from MPEG-LA pool that went overboard and caused a SNAFU.

MPEG is not the same as MPEG-LA (despite the confusing name), but it is MPEG policies (e.g. being patent-blind) that create the opportunity for both MPEG-LA and competing entities to stuff the proposals with their patents without any credible legal requirement to give access to the patents under sensible terms.

This has continually caused problems, e.g. the big drama when Apple held Quicktime 6 hostage until they dropped per-use royalties on AAC all the way up to the current HEVC nonsense (which again caused Apple remove any mention of HEVC from their iPhone page). You know it's gone too far when Apple, who generally have no big issue with patent encumbered formats, is calling you out.

[BadFrame]

HEVC isn't just a small slight improvement.
Actually, considering how old h264 is and the amount of extra cpu time HEVC needs in order to actually see those benefits, I can't say I'm overly impressed with the improvements. That said this will most likely hold just as true for AV1.

And are we forgetting already that VP9 is basically just a copy of HEVC with some nerfs

Need something to back this up with.


On2 still did it the usual way: take ideas from the MPEG standard, and obfuscate them a bit to not be directly exposed to patent lawyers.

Need something to back this up with.


And currently, VP9 is the format that AV1 is being built on!

From what I've read, it's built on VP10, which was supposed to be the VP9 successor, and is now to become AV1.

So I'd say we should get a bit more mature on the freetard/fanboy feelings toward MPEG.

Are you seriously pretending to be mature while using words like 'freetard' ? And then accusing others of being 'fanboys' while sounding like a MPEG LA advertising pamphlet...


Not to mention when the best video coding technology to this day (x264) was based on their codec.

No argument that h264 is a great codec, but with the vast pool of patents at the MPEG LA disposal, and the hinderance they pose for alternate codecs to appear which in turn could have been better had they not have to work around what is often ridiculously broad patents, it's not surprising.


Also, MPEG-LA royalties are sane and okay.

That's your opinion.

[Quikee]

Depending on your definition of success, I think I disagree, as my definition would be replacing jpeg as the de facto (lossy) image format. Given how mobile is increasingly becoming the way people consume web content, I think the chance of gaining the necessary traction without hardware decoding is very unlikely.

I would agree if we would talk about a video codec but for image codec I can't say that hardware support is the deciding factor. Of course it is important that the codec is designed with hardware implementation in mind as it can't be successful otherwise but I don't think it would be the feature that is important initially.

Consider that we don't need to decompress images at constant rate of at least 21 FPS so even most mobile should be able to handle it reasonably fast and if you factor the download time I think it wouldn't in most cases cause a considerable lag at page loading.

[Quikee]

It is fine to be a fan of royalty free codecs, but I think you give the MPEG technology a little bit too small credit.
HEVC isn't just a small slight improvement.

I agree MPEG did a good job with HEVC, however they were totally agnostic regarding patents and I think they need some "beating" for this mistake and I think AOM with AV1 will do this. This will force them to require some patent commitments from participants or their technology won't be adapted in the standard. Maybe we would also see a standard that is partially or completely royalty free.

And are we forgetting already that VP9 is basically just a copy of HEVC with some nerfs (worse reference structure, weird hacky b-frames, lack of weighted prediction or SAO, IIRC)? On2 still did it the usual way: take ideas from the MPEG standard, and obfuscate them a bit to not be directly exposed to patent lawyers.

I'm not an expert and don't have a much knowledge of video coding techniques but at least I find VP9 "hacky b-frames" quite ingenious solution. It generally makes the decoder agnostic of what kind of frame (past or future) is currently decoding as this is not part of the bitstream. A future frame is only flaged for not showing and I think this makes it a more flexible concept than b-frames. You could also have a frame that is neither past nor the future by maybe a hybrid of more frames - however I don't know if this would be beneficial.

libvpx doesn't exploit all the possibilities that the format has to offer and I think it would come much closer to the quality of HEVC if an alternative implementation emerges and starts exploiting such things (my hope is Eve will better show what VP9 is capable of).

[mzso]

I believe the only realistic option would be if AV1 was also offered as a image codec, Intel, AMD, ARM, NVidia are all aboard to support the AV1 codec, and Android SoC manufacturers like Qualcomm, Samsung will of course support it, and it's royalty free which means it can gain traction on the web and in apps (as in being supported).

Hopefully people in the AOM come to the same conclusion, and they'll pester IETF into standardizing a still image format too.

[mzso]

I agree MPEG did a good job with HEVC, however they were totally agnostic regarding patents and I think they need some "beating" for this mistake and I think AOM with AV1 will do this.

It's countries like the US that truly need a good beating, because they allow software patents. There wouldn't be any need for this pathetic comedy with "free" formats and patented formats. They could just take HEVC and improve upon it...

[mandarinka]

IMHO the only problem with HEVC is that payments got too high because of HEVC Advance and then Technicolor or which company it was that went rogue as the third party. The mistake was not having/enforcing binding agreements that would guarantee sane royalties/terms of use.

Otherwise, I don't see a problem with codec not being completely beer-free if it means better technology/compression (and indirectly, incentive for further development). H.264 showed it works well, although some people think it is some catastrophe or something. :rolleyes:

[BadFrame]

I
Otherwise, I don't see a problem with codec not being completely beer-free if it means better technology/compression (and indirectly, incentive for further development).

I disagree with the notion that software patents and the subsequent royalty fees are somehow the main driving force for better technology, if this was the case we would never have seen great audio codecs like Opus and FLAC, and had it not been for having to navigate around the broad video encoding patent minefield, efforts like Daala would have had an entirely different outlook.

Instead I'd argue that in reality software patents obstructs and slows down technology, and I think the MPEG LA pool is a perfect example of that, they dictate when and how much progress in video codecs will be made available by holding a vast array of encoding techniques locked under what is again aggressively broad software patents.

IMHO we'd be further along in video encoding if we did not have software patents, as we can see with AOM's effort with AV1 and what Google has done all along with the VP series, there is huge commercial incentive beyond cashing in on royalties to improve technology, and yet again even this effort is hampered by software patents, and will likely be attacked by software patents as MPEG LA fights to keep their business model of piecemealing video encoding progress.

I
H.264 showed it works well, although some people think it is some catastrophe or something. :rolleyes:

I don't think it's a catastrophe, but I also don't think the system works 'well'.

Now, I (and I assume you) want to see the best video compression technology possible, in my/your hands as soon as possible, MPEG LA's business model of controlling video compression progress through software patents means we will get what they deem is enough of a step forward to create enough demand for them to kickstart a new codec and royalties cycle, rinse and repeat, continously artificially limiting progress in order for them to milk as much royalties as possible.

Take AOM as a comparison, since their model is not based upon royalties at all, there's no reason whatsoever for them to artificially limit the capacity of their codec, in fact the better the codec is, the more money they save on bandwidth, and the more attractive their services are to customers, but here again the sad concept of software patents rear it's ugly head, as it will limit what AV1 can provide, just as it limits video compression progress as a whole.

[mandarinka]

I disagree with the notion that software patents and the subsequent royalty fees are somehow the main driving force for better technology, if this was the case we would never have seen great audio codecs like Opus and FLAC, and had it not been for having to navigate around the broad video encoding patent minefield, efforts like Daala would have had an entirely different outlook.

Instead I'd argue that in reality software patents obstructs and slows down technology, and I think the MPEG LA pool is a perfect example of that, they dictate when and how much progress in video codecs will be made available by holding a vast array of encoding techniques locked under what is again aggressively broad software patents.

IMHO we'd be further along in video encoding if we did not have software patents, as we can see with AOM's effort with AV1 and what Google has done all along with the VP series, there is huge commercial incentive beyond cashing in on royalties to improve technology, and yet again even this effort is hampered by software patents, and will likely be attacked by software patents as MPEG LA fights to keep their business model of piecemealing video encoding progress.



I don't think it's a catastrophe, but I also don't think the system works 'well'.

Now, I (and I assume you) want to see the best video compression technology possible, in my/your hands as soon as possible, MPEG LA's business model of controlling video compression progress through software patents means we will get what they deem is enough of a step forward to create enough demand for them to kickstart a new codec and royalties cycle, rinse and repeat, continously artificially limiting progress in order for them to milk as much royalties as possible.

Take AOM as a comparison, since their model is not based upon royalties at all, there's no reason whatsoever for them to artificially limit the capacity of their codec, in fact the better the codec is, the more money they save on bandwidth, and the more attractive their services are to customers, but here again the sad concept of software patents rear it's ugly head, as it will limit what AV1 can provide, just as it limits video compression progress as a whole.

You insist that the non-royalty-free codecs limit the pace of overall development of compression. I don't think that is a clearly demonstrable thing at all. Note that while the technology they (MPEG etc) develop is patented, that doesn't mean it is exclusive and other development projects can't use it. If you look into the past, that was not the case - Real (RV40), Sorenson (SVQ3 IIRC?) licensed H.264 IP for their own incompatible codecs. They were allowed to do exactly what you think the baddies make impossible - make their own thing on top of MPEG IP. So as long as you accept to pay, you are not really left out and barred from using the stuff to do your own innovation on top of it.

I would much rather see efforts like AV1/Daala to happen this way, together with the commercial development, so that the best of all camps can be combined. I'd say that it is those projects limiting themselves from use of patented technology, rather then the patented technology makers limiting them, strictly speaking.

Of course, it is very unlikely that Xiph/Mozilla/On2 will change their policy and license patented stuff for themselves (well, Google did that, for VP8/9, actually), given how their whole goal is to be royalty free. But it is their choice, not result of somebody harassing them into it and denying them the option to do otherwise.

[Jamaika]

I disagree with the notion that software patents and the subsequent royalty fees are somehow the main driving force for better technology, if this was the case we would never have seen great audio codecs like Opus and FLAC, and had it not been for having to navigate around the broad video encoding patent minefield, efforts like Daala would have had an entirely different outlook.
...but there are some suggestions.
Video streaming services and video creation companies pay licensing fees for not only the hours and hours of movies and TV shows that viewers watch but also the basic coding technology that enables files to be created and displayed. The cost to license this technology has become a major impediment to innovation for companies trying to make content easily available to millions (billions!) of consumers, which is why Adobe is proud to join the Alliance for Open Media.

Of course, it is very unlikely that Xiph/Mozilla/On2 will change their policy and license patented stuff for themselves (well, Google did that, for VP8/9, actually), given how their whole goal is to be royalty free. But it is their choice, not result of somebody harassing them into it and denying them the option to do otherwise.
Adobe Joins Alliance for Open Media to Develop Next Generation Video Platform (http://blogs.adobe.com/conversations/2016/06/alliance-for-open-media.html)
Not only for himself royalty free.
Along with other members like Amazon, Cisco, Google, Intel Corporation, Microsoft, Mozilla, Netflix, and many others, Adobe is working to develop technology for open video compression and delivery across numerous devices. As a member of the alliance, Adobe will collaborate with industry leaders to create a leading edge and royalty-free video codec. Bottom line: this means faster and higher resolution video is on its way at a lower cost to the consumer.

Wonder, will it be free plugin like to VP9?

[dapperdan]

Daala update from IETF 96:

https://www.ietf.org/proceedings/96/slides/slides-96-netvc-4.pdf

And video (Daala section starts 1 hour in):

http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_NETVC&chapter=chapter_1

Probably the headline is that "main development switched to AV1, Daala is primarily being used as a testbed to implement ideas that then get moved to AV1, though it might be revived as a standalone codec at a future date when some of the techniques they've come up with have matured".

[littlepox]

In short, daala is dead.

[LigH]

If so, then it should be buried gracefully, having delivered useful experience for the next step in the evolution of codecs... ;)

[mandarinka]

If so, then it should be buried gracefully, having delivered useful experience for the next step in the evolution of codecs... ;)

To a large degree however, many of its lessons just say what doesn't work and that it is not at all easy to beat established technology (Mpeg, VP9) with new (or more precisely, not used yet) ideas.

[littlepox]

Another thing is the design of encoder is much more challenging than design of format. Today, if I am to encode a video without x264/x265, honestly, I'd use Easy Real Producer. I've seen how it beats those crappy H.264/H.265/VP9 encoders.

R.I.P. daala, hope AV1 can fulfill its destine.

[mzso]

If so, then it should be buried gracefully, having delivered useful experience for the next step in the evolution of codecs... ;)

More like delivered useful experience in circumnavigating obvious solutions to problems that are already patented.

[Nevilne]

Which they succeeded at... don't get the hostility of people here.

[mandarinka]

Which they succeeded at... don't get the hostility of people here.

In case you meant me by the "hostility", I have been "fan" of it probably longer than almost all people on the internet. I followed the development (or preparation) maybe since 2011 or so, since time when there were no demos or public announcements yet, only Xiph wiki page and talk in #Theora.

The only "hostility" is in me not caring about the topic of "encumbered" or "free" things, which lots of people here put into the front. I just want to see technical progress regardless of whichever party will bring it about. Daala was quite interesting in that regard (at least in theory), whereas On2's stuff, not much - hence lack of respect from me.

The fact that lots of stuff projected for Daala failed in practice is true, though (sadly). Their attempt to reconcile intra prediction with lapping/OBMC is probably the most important part there, because it has lead to problems for the whole codec, need to add 1-2 loopfilters that the design originally didn't mean to use etc. Their lapping itself had a tough ride, for a long while they didn't even know if it they should really keep it (I am not up to date on how that ended up). These things are what I meant when I said that thing about nature of Daala's lessons. It doesn't mean I hate them/it. I'm not even disappointed in the sense that I would blame them or think they did a bad job. I know that this happens when you do scientific work - you go through number of theories but most of them are ruled out as wrong, with positive results/inventions being rare.

The jury is still out on AV1, but currently it seems like it will mostly inherit On2 DNA, so I don't expect much there. Hopefully Xiph/Mozilla will still manage to influence it in a good way, though.

[Jamaika]

The jury is still out on AV1, but currently it seems like it will mostly inherit On2 DNA, so I don't expect much there. Hopefully Xiph/Mozilla will still manage to influence it in a good way, though.
To this day I don't know what codec Daala improved the codec AV1. I have no way of comparison VP10 vs AV1. You may find that they are comparable in quality.

[mzso]

Which they succeeded at... don't get the hostility of people here.

You mean toward the degenerate legislation(s) that allow software patents? What is there not to get? :)
Without such they could effort into actual developments instead of circumventions...

[Nevilne]

Just so we're on the same page here I was saying that Daala devs succeeded in making a competitive video codec.
I'm really not sure what you're trying to say - do you think it was somehow daalas fault that we still have software patents?

To mandarinka: personally i'm optimistic about AV1, the spec will be good enough that we will likely get a good encoder software finally (and also some good encoding hardware).

[mzso]

Just so we're on the same page here I was saying that Daala devs succeeded in making a competitive video codec.
I'm really not sure what you're trying to say - do you think it was somehow daalas fault that we still have software patents?

To mandarinka: personally i'm optimistic about AV1, the spec will be good enough that we will likely get a good encoder software finally (and also some good encoding hardware).

I don't know why you don't get that that I was cursing software patents and not Daala...

[CruNcher]

Another thing is the design of encoder is much more challenging than design of format. Today, if I am to encode a video without x264/x265, honestly, I'd use Easy Real Producer. I've seen how it beats those crappy H.264/H.265/VP9 encoders.

R.I.P. daala, hope AV1 can fulfill its destine.

I still hope one day we gonna see those results from Real coming back for now all the NGV Results are buried somewhere deep in some Intel Restroom, though Intel is AOM member as well so who knows ;)

Sure Intel, AMD and Nvidia are mostly only there for getting their Hardware Decoding ready to go but they also have valuable R&D in different parts that might become interesting if they decide to share them :)

So there might be a possibility we gonna see Intel contributing some NGV IP there would be actually no better time then now for it instead of leaving everything taking dust in the Restroom :D

[Jamaika]

Daala finally provides color depth 10 bit. Unfortunately, the lack of support the CPU very limited coding. (max. fullhd) It's very slow. Still need to improve the player because he doesn't work.:rolleyes:
daalaenc.exe --b-frames 4 --keyframe-rate 23.976 --complexity 5 --video-quality 18 --fpr --output "image_rate18.ogg" -
Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
date : 2016-09-07T08:27:49+02:00
encoder : Lavf57.50.100
Stream #0:0: Video: wrapped_avframe, yuv444p10le, 4096x2304, q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc
Metadata:
encoder : Lavc57.57.101 wrapped_avframe
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
File '-' is 4096x2304 23.976 fps 444p10 video.
Compressing...
frame= 7 fps=0.6 q=-0.0 size= 387072kB time=00:00:00.29 bitrate=10860790.5kbits/s speed=0.0241x
https://github.com/xiph/daala/commit/05243557bc3e59872fd043c99dc4c17ca33bcb1b
https://github.com/xiph/daala/commit/4f0cf4203d09399515a824f1056dcbec9f5d1b63
https://github.com/xiph/daala/commit/8af4b2fb8021b5b4da5212c0e25c6066cddf1f41

[Clare]

A poster summarizing Daala's technologies:
https://jmvalin.ca/video/mmsp2016_poster.pdf

[mzso]

A poster summarizing Daala's technologies:
https://jmvalin.ca/video/mmsp2016_poster.pdf

So AV1 is a tweaked(vp9), tweaked (vp10), tweaked(av1) VP8. Is it worth the fuss? They could have just renamed and released VP9, or whichever state was VP10 at that point as AV1.

Then they could have moved on to AV2 with drastic/revolutionary changes.

[Quikee]

So AV1 is a tweaked(vp9), tweaked (vp10), tweaked(av1) VP8. Is it worth the fuss? They could have just renamed and released VP9, or whichever state was VP10 at that point as AV1.

No, I don't know where you've read that. On the poster it clearly says that AV1 is VP9 as base + parts from Daala, Thor (and VP10) and new contributions (work that has been done exclusively on AV1 codebase).

Then they could have moved on to AV2 which drastic/revolutionary changes.

AV1 was never meant to have revolutionary changes - it needs to get to the market rather quickly (to still take advantage of HEVC licensing uncertainty).

[mzso]

On the poster it clearly says that AV1 is VP9 as base + parts from Daala, Thor (and VP10) and new contributions (work that has been done exclusively on AV1 codebase).

AKA. Tweaked VP9, the way I see it. :)


AV1 was never meant to have revolutionary changes - it needs to get to the market rather quickly (to still take advantage of HEVC licensing uncertainty).

Missed my second point too. :) If that was the most significant aspect they should have just released as soon as they got an agreement upon AV1. VP10 + throw in whatever is considered "mature" and gainful from the others. Then start optimizing the encoder/decoder.

[Nevilne]

Well thankfully they don't listen to you

[benwaggoner]

Missed my second point too. :) If that was the most significant aspect they should have just released as soon as they got an agreement upon AV1. VP10 + throw in whatever is considered "mature" and gainful from the others. Then start optimizing the encoder/decoder.
For a codec (COMpressor, DECompressor, remember) you can't just "+ throw in whatever." Even if individual algorithms are mature, there are all kinds of changes to bitstream syntax that need to be made, probabilities of code values to be statistically analyzed and optimized in the bitstream, etcetera. AV1 is actually going pretty fast for what's aiming to be an industry standard codec. One little bug in the encoder that goes into the bitstream and then the decoder assumes can break clean-room optimizations and bake in non-optimal behaviors for a decade.

There are plenty of little weird things in the VPx history where a symmetrical bug in the encoder and decoder caused strange and painful limitations for 3rd party implementations. And anything like that in AV1 couldn't be fixed until AV2, because once you have decoders shipping in hardware, you need to stay compatible with them FOREVER. There are 10+ year old H.264 Baseline Profile decoders that modern encoders can make perfectly compatible streams for.

If a codec is just running as software in web browsers, things can be a lot more fluid. But not if it's going into fixed-function hardware! Or on any device that doesn't reliably get automatic firmware updates.

[Quikee]

AKA. Tweaked VP9, the way I see it. :)

OK, I agree - it is a tweaked VP9, but that doesn't mean anything. Why start from scratch when you can take a proven stable baseline and "tweak" that.

Missed my second point too. :) If that was the most significant aspect they should have just released as soon as they got an agreement upon AV1. VP10 + throw in whatever is considered "mature" and gainful from the others. Then start optimizing the encoder/decoder.

I (still) don't understand your point - that is exactly what they do now. PVQ, daala EC and deringing filter is what worked good in daala and they are integrating it into AV1. Same with CLPF from thor and things like rANS in VP10. However you can't do this overnight.. it is still a lot of work.

[Nintendo Maniac 64]

To me, VP9 --to-> AV1 isn't that different from Dothan --to-> Conroe in CPUs.

[CruNcher]

For a codec (COMpressor, DECompressor, remember) you can't just "+ throw in whatever." Even if individual algorithms are mature, there are all kinds of changes to bitstream syntax that need to be made, probabilities of code values to be statistically analyzed and optimized in the bitstream, etcetera. AV1 is actually going pretty fast for what's aiming to be an industry standard codec. One little bug in the encoder that goes into the bitstream and then the decoder assumes can break clean-room optimizations and bake in non-optimal behaviors for a decade.

There are plenty of little weird things in the VPx history where a symmetrical bug in the encoder and decoder caused strange and painful limitations for 3rd party implementations. And anything like that in AV1 couldn't be fixed until AV2, because once you have decoders shipping in hardware, you need to stay compatible with them FOREVER. There are 10+ year old H.264 Baseline Profile decoders that modern encoders can make perfectly compatible streams for.

If a codec is just running as software in web browsers, things can be a lot more fluid. But not if it's going into fixed-function hardware! Or on any device that doesn't reliably get automatic firmware updates.


On that regards im pretty eager to see if we currently stand in the middle of a transition @ Intel and AMD to FPGA IP Cores for the Video Decoding/Encoding ;)

It looks like this could happen in the not so distant future ;)

After all the Hardware (extension) activation/upgrade tests in the past.

[Jamaika]

Problem with playing and converting video to YUV 10bit.
daalaenc.exe --b-frames 4 --video-quality 25 --complexity 3 --output "daala+1660_comp3_q25.ogg" -
https://www.sendspace.com/file/iknrja

[iwod]

I still hope one day we gonna see those results from Real coming back for now all the NGV Results are buried somewhere deep in some Intel Restroom, though Intel is AOM member as well so who knows ;)

Sure Intel, AMD and Nvidia are mostly only there for getting their Hardware Decoding ready to go but they also have valuable R&D in different parts that might become interesting if they decide to share them :)

So there might be a possibility we gonna see Intel contributing some NGV IP there would be actually no better time then now for it instead of leaving everything taking dust in the Restroom :D

As per your quoted post. OMG. I was so afraid of admitting my love with RMVB these days. Good memories with Karl on Doom9. ( Where is he now ? )

What is NGV? Was it not the codename for RV40 aka RMVB? If not is it suppose to be after RV40? Which i remembered the open it up as Helix.
And what is NGV suppose to do with Intel?

I really wish Real could truly open up RMVB.

[CruNcher]

Not only you :)

NGV (RealVideo 11) was the Next Generation Video Codec developed at Real after their H.264 contribution (RV10) then it was stopped and complete ip and NGV Team transfered to Intel ;)

Pretty much Real Networks History as active Codec Developer ended @ that time.

Karl was not among them he stayed at Real and still is there worked on some Cloud Sureplay seemless Device Transcoding and Player parts it seems :)

2014-16: RealTimes for Mac

Though the Chinese (Asian) arm of Real still seems to actively working on the Content Creation part and also update it most probably based on the older code path (RV10) :)

http://www.realnetworks.com.cn/en/en/RealMedia%20HD
http://www.realplayer.cn/software/ReleaseDoc/RealProducerHD_Release_Notes.pdf

RealProducer HD for Windows enables consumers to create videos in HD at faster speeds than H.265 with comparable image quality. It comes with a smart, intuitive user interface and enables substantially faster encoding and uploading HD video content to the web and the cloud.

Users enjoy

Shorter cache/download time with reduced data costs versus H.264

Higher image quality with lower storage needs versus H.264

Lower battery consumption for longer viewing time versus H.265


Most probably though in the comparison range of VP9 at best or a weak GPU IHV H.265 Encoder :)

[iwod]

Not only you :)

NGV (RealVideo 11) was the Next Generation Video Codec developed at Real after their H.264 contribution (RV10) then it was stopped and complete ip and NGV Team transfered to Intel ;)

Pretty much Real Networks History as active Codec Developer ended @ that time.

Karl was not among them he stayed at Real and still is there worked on some Cloud Sureplay seemless Device Transcoding and Player parts it seems :)

2014-16: RealTimes for Mac

Though the Chinese (Asian) arm of Real still seems to actively working on the Content Creation part and also update it most probably based on the older code path (RV10) :)

http://www.realnetworks.com.cn/en/en/RealMedia%20HD
http://www.realplayer.cn/software/ReleaseDoc/RealProducerHD_Release_Notes.pdf





Most probably though in the comparison range of VP9 at best or a weak GPU IHV H.265 Encoder :)

Sorry if this is going to be off Daala's topic a little.

ARH!. Yes, That NGV.
WHY THE HECK did Intel decide to invest in RV11 aka NGV? And then not release anything and Kill it?

I think ( not sure now ), Real Producer, or the rmvb encoder itself has some of the best default Pre and Post Processing settings, you get very decent results without any tweaking or parameters. RM was crap. RMVB totally changes the game. It goes from amazing in Anime and very decent in other categories. It doesn't preserve any grain in movies, so it never did well in high quality Rips.

And it is for this very reason, I never liked VP8, VP9, or VP10. Even after the acquisition of Google, they still smells of On2.

[Gravitator]

http://wyohknott.github.io/image-formats-comparison/#mascot*3:1&ogv=m&bpg=m
At the edges of the red strip is present comb.

[CruNcher]

Those are the Chroma issues still left we talk about a lot and they also showup in AV1 as well.

you can see them everywhere not only that sample

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&ogv=m&bpg=m
http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&webm=m&bpg=m

[IgorC]

There was an interesting comparison of image formats in 2016.

HEVC and Daala are on first place. Daala(or AV1 at this moment) already does better in these days

https://jpeg.org/items/20161026_press.html
https://jpeg.org/downloads/aic/wg1n73041_icip_2016_grand_challenge.pdf

[benwaggoner]

There was an interesting comparison of image formats in 2016.

HEVC and Daala are on first place. Daala(or AV1 at this moment) already does better in these days

https://jpeg.org/items/20161026_press.html
https://jpeg.org/downloads/aic/wg1n73041_icip_2016_grand_challenge.pdf
AV1 does better than it did, or better than HEVC and Daala do?

I can see a royalty-free AV1 as being an excellent still image codec, and potentially, finally, something that could replace JPEG on the web for continuous tone images.

[IgorC]

AV1 does better than it did, or better than HEVC and Daala do?

Both statements are fine (in the context of that JPEG comparison)

[mzso]

I can see a royalty-free AV1 as being an excellent still image codec, and potentially, finally, something that could replace JPEG on the web for continuous tone images.

Don't get your hopes up. Jpeg is rather resilient. Even google couldn't popularize webp. An there were a bunch of other formats that didn't gain any traction.
To me FLIF looks interesting for images, and it's a finished format. But I don't have high hopes that I'll be seeing anything new in the browser.

[IgorC]

It's different. WebP was only Google's project. Even Mozilla haven't support it, heh. Nor Microsoft...
While AV1 is supported/promoted by many big players http://aomedia.org/about-us/
WebP is barely better than JPEG (~15-20%) while AV1, HEVC or Daala are considerably better than that.

Also JPEG is damn good image format. There is still no other image format with 2x better compression than JPEG.
While H.264 and HEVC already outperform MPEG-2 by more than 2x on wide range of bitrates.

[Jamaika]

WebP is barely better than JPEG (~15-20%) while AV1, HEVC or Daala are considerably better than that.
The webp format didn't win with the whole jpeg family. The codec is also not a 16 bit. The codec AV1/Daala wasn't implemented to webp.
Apparently there is no need to do so.
Also JPEG is damn good image format. There is still no other image format with 2x better compression than JPEG.
Waiting for JPEG XS

[mzso]

It's different. WebP was only Google's project. Even Mozilla haven't support it, heh. Nor Microsoft...
While AV1 is supported/promoted by many big players http://aomedia.org/about-us/
WebP is barely better than JPEG (~15-20%) while AV1, HEVC or Daala are considerably better than that.
You mean Google's project like Webm, and VP9? Those didn't get any input from others either, yet all relevant browsers support them now.
The only difference is that there's no JPEG in video formats, which is supported by everything anywhere.


Also JPEG is damn good image format. There is still no other image format with 2x better compression than JPEG.
While H.264 and HEVC already outperform MPEG-2 by more than 2x on wide range of bitrates.
Good my *ss, people just got used to it's many artifacts.

[LigH]

@ IgorC:

Obviously you don't understand the main difference between still image compression and video compression.

Motion prediction and inter-frame encoding.

One single image has no motion. No surprise there is less redundancy to spare. If you compared I-frame only MPEG-2 with I-frame only HEVC, the ratio would be similarly disappointing.

[IgorC]

@ IgorC:

Obviously you don't understand
Sorry to dissapoint you but I do have concept of intra-/inter- prediction. I'm not new to Doom9 and image/video/audio compression.

So keep your speech for newbies.

[LigH]

:o Okay ... sorry for my bold expressions.

But expecting a 1:2 breakthrough in lossy still image compression sounds like a miracle to me, if I do not even expect that to happen in video compression.

Even more than the "revolutions" (e.g. something else than DCT windows) which happened from MP3 over VQF and Vorbis towards Opus in the audio world.

Something that might come at least close was V-Nova, the "noise modelling" in video compression, similar to mp3Pro and HE-AAC.
_

P.S.:

Wavelets instead of DCT was most probably not the expected miracle. At least not on its own...

[IgorC]

You mean Google's project like Webm, and VP9?.
Well, VP9 is considerably better than H.264 and VP8 at least on Youtube's bitrates (1080p ~1.7-2 Mbps)

While WebP is just somewhat better than JPEG.


Good my *ss, people just got used to it's many artifacts

If it was that bad there would multiple articles about how bad JPEG was.
And it's not the case.

[IgorC]

But expecting a 1:2 breakthrough in lossy still image compression sounds like a miracle to me, if I do not even expect that to happen in video compression.

Even more than the "revolutions" (e.g. something else than DCT windows) which happened from MP3 over VQF and Vorbis towards Opus in the audio world.

Something that might come at least close was V-Nova, the "noise modelling" in video compression, similar to mp3Pro and HE-AAC.
Yes, 2x ratio is hard to achieve.

Considering that JPEG comparison (subjective MOS), Daala/HEVC were already approx ~1.6-1.7x of JPEG efficiency at MOS 4(perceptible but not annoying). And the efficiency is 1.2-1.4x at MOS 4.5

If AV1 will have ~10%(?) of better intra prediction then it will be ~1.8x of JPEG efficiency at MOS 4. Rough numbers.


As of audio, Opus, xHE-AAC(USAC) 80 kbps are on par with MP3 128 kbps in my experience. That's 1.6x
And a recent audio standard 3DA apparently will need ~64-72 kbps. That's 1.75-2x.

[Gravitator]

http://i91.fastpic.ru/big/2017/0930/10/86bcf6efda795961068f393d0b07e710.jpg (http://fastpic.ru/)
http://wyohknott.github.io/image-formats-comparison/#koln-night&ogv=s&webm=s

Daala in dark areas can more effectively save small details :) AV1 smears.

[benwaggoner]

Daala in dark areas can more effectively save small details :) AV1 smears.
Do you know that this is due to bitstream differences versus encoder differences? The libvpx series was always tuned for PSNR which can result in this kind of issue.

[LigH]

New release (sporadically from now on): AOM v0.1.0-7288-gbddba0a08 (MABS: MSYS2/MinGW, GCC 7.2.0)

See MediaFire shares in my signature

[Jamaika]

I will ask this controversial question.
What about the Daala project? Is it closed, will it be resumed?
https://github.com/xiph/daala/commits/master

[oibaf]

I will ask this controversial question.
What about the Daala project? Is it closed, will it be resumed?
https://github.com/xiph/daala/commits/master

Daala code that proved to be useful was merged into AV1, also the developers moved to AV1.
For some background see here: https://en.wikipedia.org/wiki/AOMedia_Video_1

[Quikee]

Daala is likely to be continued after AV1 as an experimental codec. It achieved near HEVC quality levels without even nearly being finished (it doesn't even have B-Frames yet) and compared to AV1 it is much less complex. So let's see...

[MoSal]

Even if Daala does not develop into a competitive next-gen Internet codec. I think it has real potential to at least fill some niches:

* Still images!
* Broadcasting internal usage (replace Dirac, VC-2).
* Intermediate codec (replace ProRes).

Unfortunately, I don't see Mozilla diverting resources away from AV1 (and Opus) anytime soon.