[daala] Curious about progress of codec

[Aaron Boxer]

Hi Jarek,

Excellent! I hope these efficiency improvements that you are proposing will
get adopted, or at least investigated.

I don't know much about arithmetic coding, but according to Wikipedia,
CABAC is considered one of the primary reasons
for H.264 and H.265 coding efficiency being superior to predecessors. So,
using rANS and the other techniques you mention
should give Daala a distinct advantage.

The only reasons I can think of for them *not* being adopted would be:

1) increased codec complexity (the issue that JPEG 2000 foundered on)
2) patents (another issue with JPEG 2000)
3) Not Invented Here Syndrome (TM)

Kind Regards,
Aaron



On Sun, Apr 24, 2016 at 10:43 AM, Jarek Duda <dudajar at gmail.com> wrote:

> Hi Aaron,
>
> I had some discussion and analysis regarding their coding part, and there
> is a few percents to easily squeeze there (5-10%).
> In contrast to nasty CABAC scheme - start with binarization then try to
> model these bits, Daala has very nice general scheme:
> send to coding part sequence of (ID, symbol),
> where symbol is from up to size 16 alphabet,
> each ID is statistically modeled as independent random variable - hence ID
> itself contains both data type and context (like neighborhood).
>
> However, they have a few inefficiencies:
> 1) start each frame with flat uniform probability distribution (this is
> the worst!),
> 2) use approximated multi-symbol range coder:
> https://people.xiph.org/~tterribe/tmp/StuiverMoffat98-%20Piecewise%20Integer%20Mapping%20for%20Arithmetic%20Coding.pdf
> the cost of this approximation is 1-3% ratio loss for binary alphabet:
> https://dl.dropboxusercontent.com/u/12405967/Moffat.nb
> 3) use costly every symbol adaptation (mainly to handle the flat initial
> distribution problem), but with
> freq[s] = count[s] / total
> poor type of adaptation: a symbol far in the past has the same influence
> on the probability as the most recent symbols,
> 4) use fixed adaptation rate.
>
> These can be improved by:
> 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),
> 2) use an accurate entropy coder, like rANS in VP10,
> 3) use adaptation with exponential forgetting to make recent symbol more
> important, like
> for (int i = 1; i < m; i++) CDF[i] -= (CDF[i] - mixCDF[i]) >> rate;
> 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,
> 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.
>
> Kind regards,
> Jarek Duda
>
>
>
>
> On 16/04/24 05:36, Aaron Boxer wrote:
>
> Dear Daala-istas,
>
> I took a look at the PSNR and PSNR-HVS charts for daala vs H.264 and H.265.
> 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.
>
> 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.
>
>
> Kind Regards,
> Aaron Boxer
>
>
>
>
>
>
>
>
> _______________________________________________
> daala mailing listdaala at xiph.orghttp://lists.xiph.org/mailman/listinfo/daala
>
>
>
> --
> dr Jarosław Duda
> Institute of Computer Science and Computer Mathematics,
> Jagiellonian University, Cracow, Polandhttp://th.if.uj.edu.pl/~dudaj/
>
>
> _______________________________________________
> daala mailing list
> daala at xiph.org
> http://lists.xiph.org/mailman/listinfo/daala
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/daala/attachments/20160424/f1fc4569/attachment.html>