ffmpeg's native WebP muxer always sets ALPHA_FLAG to be true in VP8X chunk

[triune]

Summary of the bug:

Looks like ffmpeg's native WebP muxer always sets ALPHA_FLAG to be true in VP8X chunk even for a completely opaque image: e.g. an animated image where none of the frames have transparency info: ​https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/webpenc.c#L110

But according to the WebP container spec:
​https://developers.google.com/speed/webp/docs/riff_container?hl=en#extended_file_format

<Quote>
Alpha (L): 1 bit
Set if any of the frames of the image contain transparency information
("alpha").
<Unquote>

Bug information aggregated from:
​http://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/179955.html
​https://bugs.chromium.org/p/webp/issues/detail?id=266

How to reproduce:

% ffmpeg -i video.mp4 -c:v libwebp -loop 0 anime.webp

ffmpeg version N-79190-ga5f5b8b Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.1)
  configuration: --enable-libopus --enable-libvpx --enable-gpl --enable-libx264 --extra-libs=-ldl --enable-libmp3lame --disable-yasm --enable-libfdk_aac --enable-nonfree --enable-libwebp --enable-filter=drawtext --enable-libfreetype
  libavutil      55. 19.100 / 55. 19.100
  libavcodec     57. 33.100 / 57. 33.100
  libavformat    57. 29.101 / 57. 29.101
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 40.102 /  6. 40.102
  libswscale      4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100

animated webp images generated by ffmpeg with this defect present are linked here:
​https://storage.googleapis.com/bucketami/00245%3D07576%3D07576%3D07576.webp
​https://storage.googleapis.com/bucketami/00247%3D06534%3D06534%3D06534.webp
​https://storage.googleapis.com/bucketami/femto.webp
​https://storage.googleapis.com/bucketami/VFP3.webp

[Carl Eugen Hoyos]

Is a specific input file necessary to reproduce the issue or is it reproducible with -f lavfi -i color?
Please provide an (as simple as possible) command line together with the complete, uncut console output to make this a valid ticket.

Note that the quote you put in the description would indicate that it is correct to set the flag if you don't know in advance if a transparent frame may appear later.

[Carl Eugen Hoyos]

Could you test this patch?
​http://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192987.html