Xiph & Mozilla's Daala codec

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