This is a (minor) bitstream change: if the 'color_space' bit is set to '1'
(which is normally an undefined/invalid behaviour), we add extra data at the
end of partition #0 (so-called 'extensions')
Namely, we add the size of the extension data as 3 bytes (little-endian),
followed by a set of bits telling which extensions we're incorporating.
The data then _preceeds_ this trailing tags.
This is all experimental, and you'll need to have
'#define WEBP_EXPERIMENTAL_FEATURES' in webp/types.h to enable this code
(at your own risk! :))
Still, this hack produces almost-valid WebP file for decoders that don't
check this color_space bit. In particular, previous 'dwebp' (and for instance
Chrome) will recognize this files and decode them, but without the alpha
of course. Other decoder will just see random extra stuff at the end of
partition #0.
To experiment with the alpha-channel, you need to compile on Unix platform
and use PNGs for input/output.
If 'alpha.png' is a source with alpha channel, then you can try (on Unix):
cwebp alpha.png -o alpha.webp
dwebp alpha.webp -o test.png
cwebp now has a '-noalpha' flag to ignore any alpha information from the
source, if present.
More hacking and experimenting welcome!
Change-Id: I3c7b1fd8411c9e7a9f77690e898479ad85c52f3e
going down to strict -ansi c89 is quite overkill (no 'inline',
and /* */-style comments).
But with these fixes, the code compiles with the stringent flags:
-Wextra -Wold-style-definition -Wmissing-prototypes
-Wmissing-declarations and -Wdeclaration-after-statement
Change-Id: I36222f8f505bcba3d9d1309ad98b5ccb04ec17e3
The object WebPIDecoder is available to store the
decoding state. The flow is typically:
WebPIDecoder* const idec = WebPINew(mode);
while (has_more_data) {
// ... (get additional data)
status = WebPIAppend(idec, new_data, new_data_size);
if (status != VP8_STATUS_SUSPENDED ||
break;
}
// The above call decodes the current available buffer.
// Part of the image can now be refreshed by calling to
// WebPIDecGetRGB()/WebPIDecGetYUV() etc.
}
WebPIDelete(idec);
Doing so, one can try and decode new macroblocks everytime fresh
bytes are available.
There's two operating modes: either appending fresh bytes, or
updating the whole buffer with additional data in the end.
The latter requires less memcpy()'s
main patch by Somnath Banerjee (somnath at google.com)
Change-Id: Ie81cbd0b50f175743af06b1f964de838b9a10a4a
