Weak dependencies on external libraries do not obviate having to
explicitly enable these libraries, so the weak dependency does not
simplify the configure command line nor have any real effect.

No deprecation guards, because the old decode API (for which this field
is needed) doesn't have any either.

This field should be removed together with the old decode calls.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Copied and modified from hwcontext_qsv.c.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

In this mode it tells the muxer about the bitrate of the input stream.

The code relies on their validity and otherwise can try to access a NULL
object->rle pointer, causing segmentation faults.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>

The string codec name need not be as long as the value we are
comparing it to, so memcmp may make decisions derived from
uninitialised data that valgrind then complains about (though the
overall result of the function will always be the same).  Use
strncmp instead, which will stop at the first zero byte and
therefore not encounter this issue.

Only do this when building for a recent VAAPI version - initial
driver implementations were confused about the interpretation of the
framerate field, but hopefully this will be consistent everywhere
once 0.40.0 is released.

Default to using VBR when a target bitrate is set, unless the max rate
is also set and matches the target.  Changes to the Intel driver mean
that min_qp is also respected in this case, so set a codec default to
unset the value rather than using the current default inherited from
the MPEG-4 part 2 encoder.

This includes a backward-compatibility hack to choose CBR anyway on
old drivers which have no CBR support, so that existing programs will
continue to work their options now map to VBR.

Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

Use webm muxer for VP8, VP9 and Opus codec, mp4 muxer otherwise.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

The dash_write function drops data, if no IOContext is initialized.

Since the mp4 muxer is used in "frag_custom" mode, data is only
written when calling av_write_frame(NULL) explicitly and thus
there will be no data loss.

To add support for webm as subordinate muxer, which doesn't have
such a mode, a dynamic buffer is required to provide an always
initialized IOContext.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

Previously all mapped streams of a media type (video, audio) where assigned
to a single AdaptationSet. Using the DASH live profile it is mandatory, that
the segments of all representations are aligned, which is currently not
enforced. This leads to problems when using video streams with different
key frame intervals. So to play safe, default to one AdaptationSet per stream,
unless overwritten by explicit assignment.

To get the old assignment scheme, use

  -adaptation_sets "id=0,streams=v id=1,streams=a"
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

Using the characters "v" or "a" instead of stream index numbers for assigning
streams in the adaption_set option, all streams matching that given type will
be added to the AdaptationSet.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

Also makes sure all streams are assigned to exactly one AdaptationSet.

This patch is originally based partially on code by Vignesh Venkatasubramanian.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

Bandwidth information is required in the manifest, but not always
provided by the demuxer. In that case calculate the bandwith based
on the size and duration of the first segment.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

The current implementation creates new segments comparing

  pkt->pts - first_pts > nb_segs * min_seg_duration

This works fine, but if the keyframe interval is smaller than "min_seg_duration"
segments shorter than the minimum segment duration are created.

Example: keyint=50, min_seg_duration=3000000
 segment 1 contains keyframe 1 (duration=2s <  total_duration=3s)
                and keyframe 2 (duration=4s >= total_duration=3s)
 segment 2 contains keyframe 3 (duration=6s >= total_duration=6s)
 segment 3 contains keyframe 4 (duration=8s <  total_duration=9s)
                and keyframe 5 (duration=10s >= total_duration=9s)
 ...

Segment 2 is only 2s long, shorter than min_seg_duration = 3s.

To fix this, new segments are created based on the actual written duration.
Otherwise the option name "min_seg_duration" is misleading.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

If set, adds a UTCTiming tag in the manifest.

This is part of the recommendations listed in the "Guidelines for
Implementations: DASH-IF Interoperability Points" [1][2]
Section 4.7 describes means for the Availability Time Synchronization.

A usable default is "https://time.akamai.com/?iso"

[1] http://dashif.org/guidelines/
[2] http://dashif.org/wp-content/uploads/2016/12/DASH-IF-IOP-v4.0-clean.pdf
    (current version as of writing)
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>

Place all temporary files within a single, quasi-atomically created
temporary directory rather than relying on unsafe 'mktemp -u'. This
prevents possible race conditions in case two parallel 'mktemp -u' calls
returned the same path. Additionally, it reduces TMPDIR pollution by
keeping all test files in a single subdirectory.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Servers seem to be happy to receive the wrapped-around value as long
as they receive a report, otherwise they timeout.

Initially reported and analyzed by Thomas Bernhard.