Xiph & Mozilla's Daala codec

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