It's a per-slice quantity constructed when parsing the slice header.

CC: libav-stable@libav.org

It's the output_window that is applied to the output frame, not
pic_conf_win

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

It drops everything that cannot be used for re-encoding and/or
streamcopy.

According to the WebP Lossless Bitstream Specification
"each transform is allowed to be used only once".

If a transform is more than once this can lead to memory
corruption.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Since the duration is compared to the tfra durations/intervals which
are expressed in pts, calculate that here as well.
Signed-off-by: Martin Storsjö <martin@martin.st>

For strict CFR, they should be pretty much equal, but if the stream
is VFR, there can be a sometimes significant difference.

Calculate the pts duration separately, used in sidx atoms and for
tfrf/tfxd boxes in smooth streaming ismv files.

Also make sure to reduce the duration of sidx entries according to
edit lists.
Signed-off-by: Martin Storsjö <martin@martin.st>

When reading these values from track->frag_info, the same adjustment
has already been done.
Signed-off-by: Martin Storsjö <martin@martin.st>

Adjusting it is only necessary when a sidx/tfrf/tfxd atom already has
been written for the previous fragment (since the sidx/tfrf/tfxd atoms
include the duration between the first pts of the previous fragment, to
the first pts of the new fragment).
Signed-off-by: Martin Storsjö <martin@martin.st>