This fixes depending on implementation defined behavior
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

unsigned overflows are well defined in C and used for example in crypto
and various other places.
None of the affected warnings currently shown points to an actual defect

untested
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

In particular, add support for t, pos, n, r parameters, and add an eval
mode option.

Also, partially reword option documentation.

With several major edit by Stefano Sabatini.
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>

Should fix compilation on compilers with less-than-ideal dead code elimination
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* commit '30e6abd1':
  webp: ensure that each transform is only used once

See: c089e720Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'cf18e777':
  movenc: write the display transform matrix

Conflicts:
	libavformat/movenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes Ticket4227
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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>

Fixes 256Gb limit
Fixes Ticket4225
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* commit '30a04188':
  ismindex: Calculate the pts duration of trun atoms, not the dts duration
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '67a29123':
  movenc: Don't assume that fragment durations in pts is equal to duration in dts
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '5c337353':
  movenc: Move sidx edit list timestamp adjustment into a block
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'eee13d65':
  movenc: Only adjust the cts offset at the start of fragments if necessary
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '5cf892d6':
  movenc: Write pts timestamps in tfxd, instead of dts timestamps
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'b81b0cc2':
  movenc: Set the last packet duration based on the next packet when autoflushing
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '30411836':
  dashenc: Heuristically fill in the duration of packets that need it
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '2889c5e1':
  movenc: Heuristically set the duration of the last sample in a fragment if not set
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '8dc72eea':
  udp: Fix crashes after adding AVOptions

See: aefed6caMerged-by: Michael Niedermayer <michaelni@gmx.at>

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>

This matches what we write in tfra and tfrf since 9cbf70fa.
Signed-off-by: Martin Storsjö <martin@martin.st>

When automatically flushing fragments based on set conditions
(fragmentation on keyframes, after some interval or byte size),
we already have the next packet for one stream - use this for setting
the duration of the last packet in the flushed fragment correctly.

This avoids having to adjust the timestamp of the first packet in
the new fragment since the last duration was unknown.

Unfortunately, this only works for automatic flushing (not for
caller-triggered flushing, like in the dash muxer), and only for the
one single track that triggered the flushing. The duration of the
last sample in all other tracks still is dependent on AVPacket
duration (or heuristics).
Signed-off-by: Martin Storsjö <martin@martin.st>