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

[Michael Niedermayer]

On Fri, Sep 19, 2014 at 08:08:10AM +0200, Reimar Döffinger wrote:
> On 19 September 2014 07:34:11 CEST, Pascal Massimino <pascal.massimino at gmail.com> wrote:
> >Hi Reimar,
> >while i don't necessarily disagree with the above generally speaking
> >[*],
> >let me repeat that
> >this is a pragmatic choice. I'm not going to give up on the speed-up i
> >have
> >right now for
> >some hypothetical decoder later.
> 
> I think we're completely past each other.
> Changing the spec to say these values are invalid does not require changes to any decoder.
> Any decoder that is conformant would still be a confirming decoder.
> Thus it is completely impossible that this would make your decoder slower!!
> If you do understand anything other than that your claim it would make your decoder slower is simply _wrong_ and untrue you are still misunderstanding me.
> On the contrary your spec is the one that requires decoder changes, and at least in theory might cause slowdown.
> But even if you decide to keep the spec changed, it seems like a rather obfuscated way to specify it.
> As far as I can tell you basically changed the codec to only support palette size 256 and non-coded palette entries are opaque black.
> Not to mention that it is a spec change that renders previously compliant implementation non-compliant (as FFmpeg proves) and all that because you don't want to have e.g. a configure option to switch libwebp between a fast and a "thorough compliance check" mode, which would solve the issue without changing the spec or causing slowdown for the fast config.
> With how little consideration such changes are made is what scares the hell out of anyone wanting to implement it or vp* in hardware.
> 
> >(on a tangential side, this change also saves 2-6 bytes for files that
> >actually have 0x00000000
> >color in their palette, somewhat frequent case, because you then don't
> >need
> >to transmit this color)
> 
> I noticed that, however one additional entry is enough for that, leaving any other entries still available for error resilience and future extensions.
> Also, if you want the encoder to actually use it the "should" should be "must" instead.

I think you are correct in several points your raise, but discussing
the webp spec on ffmpeg-devel is probably not optimal. Not sure which
is the appropriate place ...

As is, the spec says out of range values should be transparent black
and thats what the patch changes the decoder to, thus its correct.
if some consensus is found and the spec is changed we can revert or
amend our decoder again

patch applied

thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140919/6d7952b9/attachment.asc>