![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
xiphmont
Xiph.Org has been working on Daala, a new video codec for some time now, though Opus work had overshadowed it until just recently. With Opus finalized and much of the mop-up work well in hand, Daala development has taken center stage.
I've started work on 'demo' pages for Daala, just like I've done demos of other Xiph development projects. Daala aims to be rather different from other video codecs (and it's the first from-scratch design attempt in a while), so the first few demo pages are going to be mostly concerned with what's new and different in Daala.
I've finished the first 'demo' page (about Daala's lapped transforms), so if you're interested in video coding technology, go have a look!
no subject
Date: 2013-06-21 07:31 am (UTC)Objection! DFT is circular, not DCT!
no subject
Date: 2013-06-24 01:14 pm (UTC)no subject
Date: 2013-06-21 08:11 am (UTC)Why lapped transforms are compared to plain DCT without intra prediction (and maybe ADST), if this is supposed to be better than H.265?
I am disappointed with amount of bullshit in this demo. It's worse than all previous ones. I'll have to ascribe it to Mozillain corporate influence I guess.
no subject
Date: 2013-06-24 01:20 pm (UTC)I don't compare with prediction, block filtering, adaptive quant, motion compensation, or anything else because I'm comparing _only_ the transforms. The demo page is an illustration of what a lapped transform is, and why you might want to use it. It's not a comparison of a finished Daala coder vs any other coder.
>I am disappointed with amount of bullshit in this demo
Well, now I'm sorry I bothered replying :-(
Lapped comparison
Date: 2013-06-22 08:10 pm (UTC)Re: Lapped comparison
Date: 2013-06-24 01:27 pm (UTC)The DCT-only and lapped transforms had the same scales. Both were producing coefficients in the range of roughly +/-1500 quantized to a range of +/-48. The summed log-energy after quantization was the same for both. They were on entirely equal footing (otherwise it would have been misleading, just as you worried). And again-- I was illustrating only the relative performance of the naked transforms.
> I'd rather see the results at the same bitrate and not with the same quantization.
That's the entire problem-- then you're not measuring the transform, you're measuring the entire encoder. If you simply drop a lapped transform into an existing format (like h.264 or VP8) it performs rather poorly-- those formats are not designed to exploit it. Similarly, when we drop the lapped transform in Daala and just replace it with the DCT, the performance takes a similar hit. And none of the above would illustrate the differences in the transform itself.
There will be complete end-to-end codec comparisons in due course, but Daala is not complete enough to do that yet. For now, one variable at a time.
Re: Lapped comparison
Date: 2013-06-24 07:13 pm (UTC)That said, that particular example uses very high quantization, and from what I've heard the problem with lapping is that while it helps at low rates it hurts at higher ones. Some formats that use it turn it off for low quantizers (WMV9 certainly does this, and I think JPEG XR does too). Apparently the issue is that they spread detail across more coefficients, so the end result is more expensive to code - hence my original question.
Re: Lapped comparison
Date: 2013-06-25 02:34 am (UTC)Perhaps you're right. I was trying to err on the side of not going down too many technical ratholes, but I might have kept it too simple there. What I was worried about: the figure is dominated by the DC components, and so that quickly devolves into other questions about 'why no DC prediction?' or 'why didn't you leave the DC out of the figure, since it's the AC behavior that's interesting?' and so on.
>That said, that particular example uses very high quantization, and from what I've heard the problem with lapping is that while it helps at low rates it hurts at higher ones.
We've gotten far enough to see that it helps with both, at least in Daala. You can find a number of researchers on the net who say 'lapped transforms don't really help' but not much documentation of what they tried that didn't work... Tim mentions a bit of this in his slide deck.
>Apparently the issue is that they spread detail across more coefficients, so the end result is more expensive to code - hence my original question.
I would think the problem is not that they spread detail across more coefficients in a block (this is the problem with wavelets), but that they duplicate edge detail into multiple blocks because blocks overlap. Perhaps we're winning because our predictors are able to account for that.
Another potential drawback is that lapping is going to spread ringing farther; an 8x8 lapped transform operating with 16x16 support is going to have ringing somewhere between an 8x8 and 16x16 DCT. That said, a 4x4 or 8x8 lapped transform is going to have as much coding gain as an 8x8 or 16x16 unlapped DCT, so we still theoretically come out ahead. Of course, you have to use a transform coefficient set that actually delivers that much coding gain, and we've spent quite a lot to time looking for them.
Re: Lapped comparison
Date: 2013-06-25 06:40 pm (UTC)I don't understand this. Isn't the goal to find coefficients which give best perceptual quality? Otherwise it's tuning for PSNR again. I hope it was done on real images at least.
(Yes I know that you're not finished yet. Still, I don't understand why do you expect tuning isolated pieces to perceptually dubious metrics will yeild a good result.)
Re: Lapped comparison
Date: 2013-06-25 07:31 pm (UTC)In general for a transform, the higher the coding gain and the more coherent the coefficient grouping, the better the end quality will be. It's a direct [if simplistic] measure of how many bits you save when you code the image to a given precision using that transform.
That said, the transform does not exist in isolation. We want to have a transform that both doesn't inherently 'look bad' when it loses precision, and interacts well with other parts of the system design. You'd be right to point out that, eg, wavelets have high-ish coding gain but don't perform well on either count.
There are _many_ possible lapped transforms. Restricting things to just our structure and six-bit dyadic coefficients with a denominator of 64, that's IIRC 442 possibilities for 4x4, tens of millions for 8x8 and TNTC for 16x16. Some of those transforms have high coding gain and look bad. Some look good [in isolation] but have poor coding gain. Some have high coding gain _and_ look like what we want. We're looking for those.
> Otherwise it's tuning for PSNR again.
heh. PSNR has some valid uses when comparing a codec _to itself_. You can't use it to compare different codecs or different techniques directly.
>I hope it was done on real images at least.
Yes, we're hoping to establish these as standard testing sets:
https://people.xiph.org/~tterribe/daala/subset1-y4m.tar.gz
https://people.xiph.org/~tterribe/daala/subset3-y4m.tar.gz
PNG versions of the same images:
https://people.xiph.org/~tterribe/daala/subset1-8bit.tar.gz
https://people.xiph.org/~tterribe/daala/subset3-8bit.tar.gz
Nice!
Just a complaint... it seems that theora and vorbis are no longer actively developed. It would be nice to release a last theora release with all improvements in svn (IIRC Firefox is already shipping theora from svn) and finally merge aoTuV in xiph vorbis. Linux distro usually ship the official xiph release which miss all those improvements.
Thanks!
Re: Nice!
Date: 2013-06-24 01:28 pm (UTC)no subject
Date: 2013-06-24 11:27 am (UTC)no subject
Date: 2013-06-24 01:30 pm (UTC)no subject
Date: 2013-07-05 03:17 pm (UTC)no subject
Date: 2013-10-27 01:58 am (UTC)no subject
Date: 2013-07-07 04:23 pm (UTC)no subject
Date: 2013-10-27 02:00 am (UTC)Or do you mean for Daala? It's in Xiph Git: http://git.xiph.org/?p=daala.git;a=summary
Lossless helps with automated testing?
Date: 2013-06-25 10:19 am (UTC)Re: Lossless helps with automated testing?
Date: 2013-06-25 07:33 pm (UTC)Short answer is yes, though the testing isn't usually randomized unless it's fuzzing.
Greetings and Thanks
Date: 2013-07-04 01:32 am (UTC)Many thanks to xiph.org team for creating these patent-free codecs. You're on the right track aiming for the best quality. This is what Free/Open Source is all about, the next best (or next-next best in this case) thing by the community. FOSS must set the quality standard, not software patent trolls.
Cheers! d^_^b (2 thumbs up)
From an English non-speaker
Date: 2013-08-03 06:30 pm (UTC)Re: From an English non-speaker
Date: 2013-10-27 02:00 am (UTC)no subject
Date: 2015-05-27 06:11 pm (UTC)Kondiloma akuminata atau yang sering disebut sebagai kutil kelamin, merupakan salah satu penyakit seksual menular (PMS) yang disebabkan oleh virus yang bernama Humanpapilloma virus (HPV). Terdapat lebih dari 40 jenis HPV yang dapat menginfeksi daerah kelamin laki-laki dan perempuan. Jenis HPV ini juga dapat menginfeksi mulut dan tenggorokan. Kebanyakan orang yang terinfeksi dengan HPV bahkan tidak tahu mereka memilikinya. HPV tidak sama dengan herpes atau HIV (AIDS).