Xiph & Mozilla's Daala codec

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