Xiph & Mozilla's Daala codec

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

Originally Posted by Clare

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]

Originally Posted by Jamaika

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.

Originally Posted by Jamaika

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.

Originally Posted by Jamaika

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.

Originally Posted by Jamaika

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]

Originally Posted by Clare

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]

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

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]

Originally Posted by LigH

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]

Originally Posted by mzso

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]

Originally Posted by Clare

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/we...+log/nextgenv2

[LigH]

Originally Posted by Clare

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]

Originally Posted by LigH

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]

Originally Posted by Clare

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/com...60f20d7ec5fd3c

[Clare]

Originally Posted by LigH

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.

Originally Posted by LigH

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]

Originally Posted by Clare

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/...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/...nutes-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. This one is actually revisiting all of our previous technology demos to see what worked, what didn't and how things changed.