Add SkWebpCodec, for decoding .webp images.

src/codec/SkWebpCodec.cpp

+/*
+ * Copyright 2015 Google Inc.
+ *
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+#include "SkWebpCodec.h"
+#include "SkImageGenerator.h"
+#include "SkTemplates.h"
+
+// A WebP decoder on top of (subset of) libwebp
+// For more information on WebP image format, and libwebp library, see:
+//   http://code.google.com/speed/webp/
+//   http://www.webmproject.org/code/#libwebp_webp_image_decoder_library

[jzern, 2015/04/03 19:15:48]

#libwebp-webp-image-library

[scroggo, 2015/04/03 20:00:19]

Done.

+//   http://review.webmproject.org/gitweb?p=libwebp.git

[jzern, 2015/04/03 19:15:49]

long dead. review is on gerrit.chromium, but
https://chromium.googlesource.com/webm/libwebp
will work

[scroggo, 2015/04/03 20:00:19]

Done.

+
+extern "C" {

[jzern, 2015/04/03 19:15:49]

I don't think this was ever necessary with the public headers, they should have
this within them.

[scroggo, 2015/04/03 20:00:19]

Done.

+// If moving libwebp out of skia source tree, path for webp headers must be
+// updated accordingly. Here, we enforce using local copy in webp sub-directory.
+#include "webp/decode.h"
+#include "webp/encode.h"
+}
+
+bool SkWebpCodec::IsWebp(SkStream* stream) {
+    // WEBP starts with the following:
+    // RIFFXXXXWEBPVP
+    // Where XXXX is unspecified.
+    const char LENGTH = 14;
+    char bytes[LENGTH];
+    if (stream->read(&bytes, LENGTH) != LENGTH) {
+        return false;
+    }
+    return !memcmp(bytes, "RIFF", 4) && !memcmp(&bytes[8], "WEBPVP", 6);
+}
+
+static const size_t WEBP_VP8_HEADER_SIZE = 64;

[jzern, 2015/04/03 19:15:48]

note we use 30 in blink to ensure a partial demux will succeed. that's large
enough for a VP8X chunk + header to allow width / height info to be returned

[scroggo, 2015/04/03 20:00:19]

Done.

+
+// Parse headers of RIFF container, and check for valid Webp (VP8) content.
+// NOTE: This calls peek instead of read, since onGetPixels will need these
+// bytes again.
+static bool webp_parse_header(SkStream* stream, SkImageInfo* info) {
+    unsigned char buffer[WEBP_VP8_HEADER_SIZE];
+    if (!stream->peek(buffer, WEBP_VP8_HEADER_SIZE)) {
+        return false;
+    }
+
+    WebPBitstreamFeatures features;
+    VP8StatusCode status = WebPGetFeatures(buffer, WEBP_VP8_HEADER_SIZE, &features);
+    if (VP8_STATUS_OK != status) {
+        return false; // Invalid WebP file.
+    }
+
+    // sanity check for image size that's about to be decoded.

[jzern, 2015/04/03 19:15:48]

this is OK, we have lib protection for this too

+    {
+        const int64_t size = sk_64_mul(features.width, features.height);
+        if (!sk_64_isS32(size)) {
+            return false;
+        }
+        // now check that if we are 4-bytes per pixel, we also don't overflow
+        if (sk_64_asS32(size) > (0x7FFFFFFF >> 2)) {
+            return false;
+        }
+    }
+
+    if (info) {
+        // FIXME: Is N32 the right type?
+        // Is unpremul the right type? Clients of SkImageGenerator may assume it's the
+        // best type, when Skia currently cannot draw unpremul (and raster is faster
+        // with premul).
+        *info = SkImageInfo::Make(features.width, features.height, kN32_SkColorType,
+                                  SkToBool(features.has_alpha) ? kUnpremul_SkAlphaType
+                                                              : kOpaque_SkAlphaType);
+    }
+    return true;
+}
+
+SkCodec* SkWebpCodec::NewFromStream(SkStream* stream) {
+    SkAutoTDelete<SkStream> streamDeleter(stream);
+    SkImageInfo info;
+    if (webp_parse_header(stream, &info)) {
+        return SkNEW_ARGS(SkWebpCodec, (info, streamDeleter.detach()));
+    }
+    return NULL;
+}
+
+static bool conversion_possible(const SkImageInfo& dst, const SkImageInfo& src) {
+    // FIXME: Do we want to support 565?

[scroggo, 2015/04/02 21:31:55]

The plan is to not downscale to 565, but if the data were natively 565, we could
return it. Is that ever the case?

[jzern, 2015/04/03 19:15:48]

No. The format is natively yuv420 for lossy or 32-bit rgba for lossless. 565 can
be imported but it's converted before processing, so that information is lost.

[scroggo, 2015/04/03 20:00:19]

Good to know. Thanks!

+    switch (dst.colorType()) {
+        // Both byte orders are supported.
+        case kBGRA_8888_SkColorType:
+        case kRGBA_8888_SkColorType:
+            break;
+        default:
+            return false;
+    }
+    if (dst.profileType() != src.profileType()) {
+        return false;
+    }
+    if (dst.alphaType() == src.alphaType()) {
+        return true;
+    }
+    return kPremul_SkAlphaType == dst.alphaType() &&
+            kUnpremul_SkAlphaType == src.alphaType();
+}
+
+SkISize SkWebpCodec::onGetScaledDimensions(float desiredScale) const {
+    SkISize dim = this->getInfo().dimensions();
+    dim.fWidth *= desiredScale;
+    dim.fHeight *= desiredScale;
+    return dim;
+}
+
+static WEBP_CSP_MODE webp_decode_mode(SkColorType ct, bool premultiply) {
+    switch (ct) {
+        case kBGRA_8888_SkColorType:
+            return premultiply ? MODE_bgrA : MODE_BGRA;

[jzern, 2015/04/03 19:15:48]

note this is memory layout and isn't affected by endianness, not sure if that's
true for skia or whether you'd like to treat this as a uint32

[scroggo, 2015/04/03 20:00:19]

The difference between kBGRA_8888_SkColorType and kRGBA_888_SkColorType is
endianness (unless configured otherwise by someone building Skia using a
different #define for SK_PMCOLOR_BYTE_ORDER). I think this is what we want.

(The old code, in SkImageDecoder_libwebp.cpp:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/skia/s...
, chooses MODE_BGRA or MODE_RGBA (or their premultiplied counterparts) based on
SK_PMCOLOR_BYTE_ORDER, which is the same check we use to determine which
SkColorType kN32 (used in the old code) maps to.)

+        case kRGBA_8888_SkColorType:
+            return premultiply ? MODE_rgbA : MODE_RGBA;
+        default:
+            return MODE_LAST;
+    }
+}
+
+// The WebP decoding API allows us to incrementally pass chunks of bytes as we receive them to the
+// decoder with WebPIAppend. In order to do so, we need to read chunks from the SkStream. This size
+// is arbitrary.
+static const size_t BUFFER_SIZE = 4096;
+
+SkImageGenerator::Result SkWebpCodec::onGetPixels(const SkImageInfo& dstInfo, void* dst,
+                                                  size_t rowBytes, const Options&, SkPMColor*,
+                                                  int*) {
+    switch (this->rewindIfNeeded()) {
+        case kCouldNotRewind_RewindState:
+            return kCouldNotRewind;
+        case kRewound_RewindState:
+            // Rewound to the beginning. Since creation only does a peek, the stream is at the
+            // correct position.
+            break;
+        case kNoRewindNecessary_RewindState:
+            // Already at the right spot for decoding.
+            break;
+    }
+
+    if (!conversion_possible(dstInfo, this->getInfo())) {
+        return kInvalidConversion;
+    }
+
+    WebPDecoderConfig config;
+    if (0 == WebPInitDecoderConfig(&config)) {
+        // Wait, this seems like an error in the decoder?

[jzern, 2015/04/03 19:15:49]

would indicate an abi mismatch

[scroggo, 2015/04/03 20:00:19]

Acknowledged.

+        return kInvalidInput;
+    }
+
+    // Free any memory associated with the buffer. Must be called last, so we declare it first.
+    SkAutoTCallVProc<WebPDecBuffer, WebPFreeDecBuffer> autoFree(&(config.output));
+
+    SkISize dimensions = dstInfo.dimensions();
+    if (this->getInfo().dimensions() != dimensions) {
+        // Caller is requesting scaling.
+        config.options.use_scaling = 1;
+        config.options.scaled_width = dimensions.width();
+        config.options.scaled_height = dimensions.height();
+    }
+
+    config.output.colorspace = webp_decode_mode(dstInfo.colorType(),
+            dstInfo.alphaType() == kPremul_SkAlphaType);
+    config.output.u.RGBA.rgba = (uint8_t*) dst;

[msarett, 2015/04/03 12:28:13]

Does this mean we always convert to RGBA?  It looks like we indicate that we
also support BGRA?

Is the reason that it is important to specify because we are not using the skia
swizzler which handles both as kN32?

[scroggo, 2015/04/03 14:14:12]

jzern@ can confirm, but if I understand correctly, this is used whether you
choose BGRA or RGBA. The only other option (looking at the header we have in
third_party) is YUVA.
That is correct.
We are not using the SkSwizzler because libwebp appears to be able to handle the
swizzling for us.

The SkSwizzler *should* handle both versions, but that code has not been written
yet.

+    config.output.u.RGBA.stride = (int) rowBytes;
+    config.output.u.RGBA.size = dstInfo.getSafeSize(rowBytes);
+    config.output.is_external_memory = 1;
+
+    SkAutoTCallVProc<WebPIDecoder, WebPIDelete> idec(WebPIDecode(NULL, 0, &config));
+    if (!idec) {
+        return kInvalidInput;
+    }
+
+    SkAutoMalloc storage(BUFFER_SIZE);
+    uint8_t* buffer = static_cast<uint8_t*>(storage.get());
+    while (true) {
+        const size_t bytesRead = stream()->read(buffer, BUFFER_SIZE);
+        if (0 == bytesRead) {
+            return kInvalidInput;   // Or incomplete?

[msarett, 2015/04/03 12:28:13]

I'm not familiar with webp format, but in this type of situation, I've been
filling the remainder of the image with some default value and then returning
kIncompleteInput.

[scroggo, 2015/04/03 14:14:12]

Yeah, I'm a little torn about what to do in this situation in general. If we're
missing the last couple of lines, for example, I think we should return
kIncompleteInput. If we failed initially, maybe that should be a straight
failure? In order to treat those situations differently, we'd need to know how
far we are into the image. We also need to know that so we can know how many
lines we need to fill. jzern@, is there a way to know what lines were decoded
successfully?

On the other hand, maybe it's up to the caller to decide whether we decoded
enough for them? Unfortunately we do not provide a way for them to know how much
of the image was decoded. With kIncompleteInput they can just decide to take
what we give them or treat it as a failure.

[jzern, 2015/04/03 19:21:34]

yes this is how we handle incremental decoding in blink for instance. you can
use WebPIDecGetRGB / WebPIDecGetYUVA to retrieve the line count. it seems we're
missing a concrete example in the decode guide [1], but the function is simple
enough:

WEBP_EXTERN(uint8_t*) WebPIDecGetRGB(
    const WebPIDecoder* idec, int* last_y,
    int* width, int* height, int* stride);


[1]
https://developers.google.com/speed/webp/docs/api#advanced_decoding_api

+        }
+
+        switch (WebPIAppend(idec, buffer, bytesRead)) {
+            case VP8_STATUS_OK:
+                return kSuccess;
+            case VP8_STATUS_SUSPENDED:
+                // Break out of the switch statement. Continue the loop.
+                break;
+            default:
+                return kInvalidInput;
+        }
+    }
+}
+
+SkWebpCodec::SkWebpCodec(const SkImageInfo& info, SkStream* stream)
+    : INHERITED(info, stream) {}