On 19 September 2014 07:34:11 CEST, Pascal Massimino <pascal.massim...@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. >[*] just, it sounds like an MPEG-committee discussion! I'd say they've learned the hard way with ASP what a mess you get if you write specs cowboy-style. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
