Hi Reimar, On Thu, Sep 18, 2014 at 9:33 AM, Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> On 18.09.2014, at 08:45, Pascal Massimino <pascal.massim...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
