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]

Originally Posted by 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 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 | x64

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.../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]

Originally Posted by LigH

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

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

[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]

Originally Posted by 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.

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]

Originally Posted by 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.

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

[mandarinka]

Originally Posted by mzso

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]

Originally Posted by mandarinka

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]

Originally Posted by mandarinka

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.

Originally Posted by mzso

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]

Originally Posted by captainadamo

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.

Originally Posted by mzso

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.

Originally Posted by mzso

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.