<div dir="ltr"><div><div><div><div><div><div><div><div>Hi Jarek,<br><br></div>Excellent! I hope these efficiency improvements that you are proposing will get adopted, or at least investigated.<br></div><br><div></div>I don't know much about arithmetic coding, but according to Wikipedia, CABAC is considered one of the primary reasons<br></div>for H.264 and H.265 coding efficiency being superior to predecessors. So, using rANS and the other techniques you mention<br></div>should give Daala a distinct advantage. <br><br></div>The only reasons I can think of for them *not* being adopted would be:<br><br></div>1) increased codec complexity (the issue that JPEG 2000 foundered on)<br></div>2) patents (another issue with JPEG 2000)<br></div>3) Not Invented Here Syndrome (TM)<br><div><div><div><div><br></div><div>Kind Regards,<br></div><div>Aaron<br></div><div><div><div><div><br><br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 24, 2016 at 10:43 AM, Jarek Duda <span dir="ltr"><<a href="mailto:dudajar@gmail.com" target="_blank">dudajar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Aaron,<br>
<br>
I had some discussion and analysis regarding their coding part,
and there is a few percents to easily squeeze there (5-10%).<br>
In contrast to nasty CABAC scheme - start with binarization then
try to model these bits, Daala has very nice general scheme: <br>
send to coding part sequence of (ID, symbol),<br>
where symbol is from up to size 16 alphabet,<br>
each ID is statistically modeled as independent random variable -
hence ID itself contains both data type and context (like
neighborhood). <br>
<br>
However, they have a few inefficiencies:<br>
1) start each frame with flat uniform probability distribution
(this is the worst!),<br>
2) use approximated multi-symbol range coder:
<a href="https://people.xiph.org/~tterribe/tmp/StuiverMoffat98-%20Piecewise%20Integer%20Mapping%20for%20Arithmetic%20Coding.pdf" target="_blank">https://people.xiph.org/~tterribe/tmp/StuiverMoffat98-%20Piecewise%20Integer%20Mapping%20for%20Arithmetic%20Coding.pdf</a><br>
the cost of this approximation is 1-3% ratio loss for binary
alphabet: <a href="https://dl.dropboxusercontent.com/u/12405967/Moffat.nb" target="_blank">https://dl.dropboxusercontent.com/u/12405967/Moffat.nb</a><br>
3) use costly every symbol adaptation (mainly to handle the flat
initial distribution problem), but with <br>
freq[s] = count[s] / total<br>
poor type of adaptation: a symbol far in the past has the same
influence on the probability as the most recent symbols,<br>
4) use fixed adaptation rate.<br>
<br>
These can be improved by:<br>
1) Start with a probability distribution characteristic for a
given ID, for example a fixed parametric, eventually modified
somewhere in the file (better behaves in the beginning and allows
for more subtle adaptation),<br>
2) use an accurate entropy coder, like rANS in VP10,<br>
3) use adaptation with exponential forgetting to make recent
symbol more important, like <br>
for (int i = 1; i < m; i++) CDF[i] -= (CDF[i] - mixCDF[i])
>> rate;
<br>
where mixCDF is for the new part, can be tabled for symbol-wise
adaptation such that frequencies of not used symbol will drop to
the minimal nonzero frequency,<br>
4) Allow for varying adaptation rate - for example some ID use
more static probability distribution, for some it is beneficial to
allow encoder to choose one of a few possible adaptation rates.<br>
<br>
Kind regards,<br>
Jarek Duda<div><div class="h5"><br>
<br>
<br>
<br>
On 16/04/24 05:36, Aaron Boxer wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr">
<div>
<div>
<div>Dear Daala-istas,<br>
<br>
</div>
I took a look at the PSNR and PSNR-HVS charts for daala vs
H.264 and H.265.<br>
</div>
May I ask at what PSNR value you would consider Daala to be
competitive with H.265 ? From the graph, it looks like you are
asymptotically matching H.264 quality, but there is still
significant difference with HEVC, and progress is flattening
out. <br>
<br>
</div>
<div>I don't mean to be that guy, but when do you think you will
be able to meet your project goal of meeting or beating HEVC
quality? I am asking because I think this is a great project,
and want to see it beating out the $$-driven competition.<br>
<br>
<br>
</div>
<div>Kind Regards,<br>
</div>
<div>Aaron Boxer<br>
<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><span class=""><pre>_______________________________________________
daala mailing list
<a href="mailto:daala@xiph.org" target="_blank">daala@xiph.org</a>
<a href="http://lists.xiph.org/mailman/listinfo/daala" target="_blank">http://lists.xiph.org/mailman/listinfo/daala</a>
</pre>
</span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
<pre cols="72">--
dr Jarosław Duda
Institute of Computer Science and Computer Mathematics,
Jagiellonian University, Cracow, Poland
<a href="http://th.if.uj.edu.pl/~dudaj/" target="_blank">http://th.if.uj.edu.pl/~dudaj/</a></pre>
</font></span></div>
<br>_______________________________________________<br>
daala mailing list<br>
<a href="mailto:daala@xiph.org">daala@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/daala" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/listinfo/daala</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div>