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: NStefano Sabatini <stefasab@gmail.com>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fixes Ticket4227
Signed-off-by: NMichael 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: NAndreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: NAnton Khirnov <anton@khirnov.net>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

See: aefed6caMerged-by: NMichael 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: NMartin 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: NMartin Storsjö <martin@martin.st>

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

This matches what we write in tfra and tfrf since 9cbf70fa.
Signed-off-by: NMartin 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: NMartin Storsjö <martin@martin.st>