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>

This avoids that the mp4 muxer does a similar heuristic, adjusting
the timestamps in a way that the dash muxer doesn't know the actual
timestamps written to the file in the end. By making sure that the
mp4 muxer internal heuristic isn't applied, we know the exact
timestamps written to file, so that the timestamps in manifest match
the files.
Signed-off-by: Martin Storsjö <martin@martin.st>

Even if this is a guess, it is way better than writing a zero duration
of the last sample in a fragment (because if the duration is zero,
the first sample of the next fragment will have the same timestamp
as the last sample in the previous one).

Since we normally don't require libavformat muxer users to set
the duration field in AVPacket, we probably can't strictly require
it here either, so don't log this as a strict warning, only as info.
Signed-off-by: Martin Storsjö <martin@martin.st>

Add a missing AVClass member, check whether localaddr is null.
(Previously, localaddr was always a local stack buffer, while it
now also can be an avoption string which can be null.)

This fixes crashes when not passing any localaddr parameter, since
66028b7b.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes a crash, when trying to mux h264 into mxf_opatom.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Previous version reviewed-by: tomas.hardin@codemill.se
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Based on patch by Martin Vignali <martin.vignali@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fix Ticket3530

Based-on debuging work by Martin Vignali <martin.vignali@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Now seems to work fine with different combinations of odd/even heights
and odd/even number of threads.