Commit 18f24527 accidentally made side data only packets be handled like a
flush request. Fix this regression by effectively ignoring them as was the
original intention.
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int'
Fixes: fate-cover-art-aiff-id3v2-remux, fate-cover-art-mp3-id3v2-remux and fate-mov-cover-image
under ubsan.
Signed-off-by: James Almer <jamrial@gmail.com>

Atkinson according to
https://bisqwit.iki.fi/jutut/kuvat/ordered_dither/error_diffusion.txt:

        *   1   1    / 8
    1   1   1
        1

Burkes according to
https://bisqwit.iki.fi/jutut/kuvat/ordered_dither/error_diffusion.txt:

          *  8  4
    2  4  8  4  2   / 32

Sierra3 according to
https://bisqwit.iki.fi/jutut/kuvat/ordered_dither/error_diffusion.txt:

          *  5  3
    2  4  5  4  2
       2  3  2      / 32

This belongs in another filter.

This is a maintenance pain more than anything. It appears to make the
code slightly faster as a side effect.

It appears faster than the iterative method on my machine (1.06x
faster), so I'm guessing compilers improved over time (the iterative
version was slightly faster in the past).

Impact is more negligible than previous commit but still faster (1.02x).

1.12x faster overall in palettegen on my machine.

Now that the sort function is deterministic, we can rely on the libc
sorting function.

Currently, in case of equality on the first color channel, the order of
the ref colors is defined by the hashing function. This commit makes the
sorting deterministic and improve the hierarchical ordering.

Similar to the change in paletteuse, we rely on a perceptual model to
decide how and where to split the box.

This prevents mixed sign arithmetic (typically because we have signed
color channel differences), which has nasty side effects in C.

This variable is used only for the running weight (used to reach the
target median). The places where we actually need the box weight are
changed to use box->weight.

This is following the results from personal research¹.

¹: https://github.com/ubitux/research/tree/main/color-quantization#results

"Variance" wasn't exactly the correct word; "cut score" is more
agnostic, which will be useful when changing the algorithm in the next
commit.

The variance computation is simple enough now (since we can use the axis
squared errors) that it doesn't need to have a complex lazy computation
logic.

This is following the results from personal research¹.

¹: https://github.com/ubitux/research/tree/main/color-quantization#results

Now the selection of the color is based on a distance built around human
perception of color instead of the unreliable sRGB triplet one.

This is redundant with a != 0xff below.

The equalities in the w{r,g,b} range checks make sure longest is never
0. Even if the alpha ended up being selected in get_next_color() it
would cause underread memory accesses in its caller (colormap_insert).

This change simplifies the code quite a bit and make it consistent with
how it's done in palettegen.

These color management helpers will be shared by palettegen and
paletteuse in the following commits.

Note that it probably makes sense to share at least the sRGB/linear
functions with other filters at some point.

More information on OkLab can be found here: https://bottosson.github.io/posts/oklab/

For the arithmetic integer version, see:
http://blog.pkh.me/p/38-porting-oklab-colorspace-to-integer-arithmetic.html
and https://github.com/ubitux/oklab-int

This reverts commit dea673d0.

This change cannot work for several reasons, the most obvious ones are:

- the alpha is being part of the scoring of the color difference, even
  though we can not interpret the alpha as part of the perception of the
  color (we don't even know if it's premultiplied or postmultiplied)
- the colors are averaged with their alpha value which simply cannot
  work

The command proposed in the original thread of the patch actually
produces a completely broken file:

    ffmpeg -y -loglevel verbose -i fate-suite/apng/o_sample.png -filter_complex "split[split1][split2];[split1]palettegen=max_colors=254:use_alpha=1[pal1];[split2][pal1]paletteuse=use_alpha=1" -frames:v 1 out.png

We can see that many color pixels are off, but more importantly some
colors have a random alpha value: https://imgur.com/eFQ2UK7

I don't see any easy fix for this unfortunately, the approach appears to
be flawed by design.

Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>