Known errors

This is a list of errors that I know of / expect, but trust the user to avoid. Some of them can also be safely ignore.

Audio filters and stream copying:

The script will try to copy the input audio stream if three requirements are met:

• Has the same codec (Vorbis or Opus, based on the -n flag)
• The audio bitrate is less or equal the one being chosen by the script
• Trim mode is inactive

If you want to apply audio filters via the -f flag, while the script tries to copy the input audio stream, then ffmpeg will throw an error (as you can't apply filters without encoding). To avoid this error use the trim mode for such files and simply hit enter, when asked for further input.

VP9 and -tune ssim:

The -tune ssim option leads to better results while using VP8. VP9 doesn't offer this option (despite ffmpeg's internal documentation saying the opposite), so you'll see an error message when using VP9 (Failed to set VP8E_SET_TUNING codec control: Invalid parameter. Additional information: Option --tune=ssim is not currently supported in VP9.). This message however can be safely ignored, as ffmpeg ignores the -tune option and continues as usual.

Pictures with transparency:

VP8 (and perhaps VP9, haven't tested it yet) is unable to handle input images with transparency (e.g. RGBA png files). It seems like there is a bug that prevents those pictures to work with the alternate reference frame. Since I can't think of a way to detect those pictures with ffprobe and the script uses the alternate reference frame for all 2-pass encodes, I'll leave it to the user to make sure, that no input picture has an alpha channel.

Gifs are the exception for this problem. The script gives them their own ffmpeg commands.

Wrong color matrix:

When using input videos with a BT.709 color matrix, converting them to VP8 or SD VP9 webms will lead to the colors being slightly off. The reason is that the encoder switches to the BT.601 color matrix. For VP8 that's always the case as it doesn't support any other color matrix. VP9 uses BT.709 for HD, BT.601 for SD footage (that's pretty much the norm nowadays). I'm currently working on detecting those videos automatically with ffprobe. Until then apply the filter colormatrix=bt709:bt601 , but be certain that your input really has the BT.709 color matrix. Using this filter for a BT.601 input, will also lead to wrong colors.

Fast encoding mode and time based filters:

During the fast encoding mode the initial video gets split into several parts, which then get encoded separately but at the same time. In general this has no influence on the applied filters. If you e.g. use crop=400:400:0:50, it'll get applied to all individual clips. However, it gets problematic if a filter has a time based setting.

fade=t=out:st=60:d=5

This filter is supposed to fade the video to black after 60 seconds over the course of 5 seconds. But now here's the problem: This filter gets applied to every individual clip, not the combined video. So you either have no fade at all (if the clips are less than 60 seconds long) or you have a fade to black during each clip until the next one begins.

I don't see any solution to this problem. Such a filter can only be applied if you encode the webm in one go.
So remember: If you have to specify a time code for a filter, don't use the fast encoding mode.