[FFmpeg-devel] [PATCH]: libavcodec/webp

[Pascal Massimino]

Hi Reimar,

On Thu, Sep 18, 2014 at 9:33 AM, Reimar Döffinger <Reimar.Doeffinger at gmx.de>
wrote:

> On 18.09.2014, at 08:45, Pascal Massimino <pascal.massimino at gmail.com>
> wrote:
> > Hi,
> >
> > the webp lossless doc was unclear regarding palette index falling out of
> > range.
> > See issue #206 [1] for the bug report.
> > The solution retained was to treat out-of-range index as color
> 0x00000000,
> > so we could keep the speed-up in libwebp (we use fake extra entries in
> the
> > cmap to handle out-of-bound values without the extra branch).
> >
> > The doc was clarified (along with few other loose ends) in patch #71605
> [2]
> > Attached is the fix for ffmpeg's webp decoder to treat out-of-bound index
> > as transparent-black instead of reporting an error.
>
> The spec now says "should be set". I don't fully understand why we would
> ordinarily expect out-of-range value.
>

corrupt files, for instance. Or just malicious ones.

I also don't understand why the issue talks about speed loss in the
> decoder, when it is the encoder that decides to use out-of-bounds values.
>

I considered both options: making the values forbidden, or defining a
behaviour for out-of-bound.
It turned out (see bug issue text) that introducing the bound-check in an
already tight-loop was slowing down decoding up to 9%.
All things considered, pragmatism indicates that the latter option should
be favored.

Why does the spec not e.g. say "the encoder MUST NOT produce out-of-range
> values. A decoder SHOULD interpret them as black" (in which case our
> decoder should still warn about the file being invalid).
> Also, a branch per pixel is not necessary even if the spec required
> creating an error, you could just or the result of the range check
> together, which could/should come in at maybe 1 cycle/pixel.
>

/skal