the interpretation of a 0 duration depends on the implementation;
merging of multiple frames isn't guaranteed, some may enforce a minimum
duration.
BUG=webp:380
Change-Id: Idf592049d2092e4cc5cfb2e4c59ddbc91bd52f9c
partially normalize indent, vertical whitespace and capitalization with
the copy used on developers.google.com/speed/webp
Change-Id: I8044418eeb9eaf5bd5c799675c74f6f845d503d6
at the beginning of the loop there's an implicit clear of the entire
canvas to the background (or application defined) color. this avoids
adding the final composited frame to the first.
Change-Id: Ia3a52cf4482c6176334a5c9c99a0ddd07d1776e7
Marking certain frames as "do not blend" helps avoiding alpha-blending
at decode/render time.
It also helps inserting I-frames (frames which can be independently
decoded) into the animation.
Change-Id: Iaa222805db88d2f1c81104ce9d882e7c7ff8cfdb
- Add a note that disposal only applies to the frame rectangle
- Add the formula for alpha-blending.
- Note that alpha-blending would occur for the common rectangle
- Also note the case when both color profile and disposal are
present.
Change-Id: I214787dd64453edf3b0cdaff3951015281a32ee4
- Escape brackets for which kramdown was generating a warning.
Note: This only changes this source file; output HTML would look exactly
the same.
- Also write '5' in words ('five').
Change-Id: I472a03c090a12eb7520719ea463469b36a2736b9
- Clarify the BNF using 'Huffman code groups' and 'Huffman code group'.
- Introduce same terminology in 'Interpretation of meta Huffman codes'.
- Make explicit mention of what is the number of Huffman code groups,
number of Huffman codes and the relation between the two.
Change-Id: I07aa9b62c1d464cd25dc02ac1a68d338b575bdc2
- Rectify a few BNF descriptions
- Corrections in "Decoding Flow of Image Data" section:
1. The sequence in case of "S < 256" should be green, red, blue, alpha.
2. In case of "S >= 256 + 24", the index should be "S - (256 + 24)".
- Provide more description to clarify "Decoding Flow of Image Data" section.
- Some cosmetics: use '1's instead of '1, 2, 3...' sequence, as kramdown takes
care of sequencing.
Change-Id: I2b76caf72f67aae813522dc1a4115f8ec8ea6db7
The color transform block size is stored as 3 bits, not 4.
Fixed the description. The code snippet is already correct.
Change-Id: I830d848b54c121cb5426ca06853a3f1184fd9a31
The prediction block size is stored as 3 bits, not 4.
Fixed the description. The code snippet is already correct.
Change-Id: Iaa66a7e9817b58a2557c9a71c2231cc400b6ae4d
- provide anchor links to the bitstream chunks referenced in the
extended format section
- remove some unnecessary parenthetical notation and add some
consistency to various chunk element definitions
Change-Id: Ifd946fee81b36e4e555399555a2a58c853fdc3b7
- Add details about the VP8L chunk support.
- Also add new example bitsteams containing VP8L chunk.
- Add back a section describing the VP8 chunk.
- Restrict some fields to 16 or 24 bits instead of 32 bits.
- Fields whose values are always positive are stored 1-based
instead of 0-based.
- Unknown chunks can only occur at certain places in the file.
- Remove the restriction for some fields to be divisible by 32 or 16.
Instead they are restricted to be even.
- Add a restriction for (canvas_width * canvas_height) product.
- Add 3 bits for rotation & symmetry in VP8X flags.
- Add some new example layouts.
- Add/clarify some nitty-gritties throughout the doc.
- Use the terms frame/tile more consistently and logically.
- Update related TODOs.
Change-Id: I611c1f58ecc3ee87546ca31bad1609376fad251e
Example kramdown command line to apply syntax highlighting requires
kramdown latest. Command is slightly different for earlier versions.
modified: doc/README
Change-Id: Icda1197436b5c5ed936ceff53c1dc51aa4ce409b
Substantial edit, though less than 100% thorough. This
makes changes that are clearly safe, but avoids others
where my domain knowledge is incomplete and accuracy
might be compromised.
modified: doc/webp-lossless-bitstream-spec.txt
Change-Id: I89361a2e1157b8d2e44a8b4f4603f65833f0c1e6
