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

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

This allows the application to fall back on another hwaccel or,
more likely, software decoding.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Non-standard compliant libc should be supported on a per-case basis
anyway.

Data and subtitle streams might cause false positive.

It should be more trustworthy than extension matching.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

This is actually defined in the A/52 specification.

Some encoders already use this value even
though it's reserved in the A/52 specification.

CC: libav-stable@libav.org

CC: libav-stable@libav.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Tim Walker <tdskywalker@gmail.com>

This appears to be the intended behavior.

This avoids an unused variable warning on big-endian systems.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

The decoder is float-based and the test needs to allow for some fuzz.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes handling redirects in case the server provided a session
id within the redirect reply.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

The RFC spec draft only specifies the "H265" name - there is no
specification saying how to interpret "HEVC" (if such a packet
format is specified it could be an entirely different format).

Since this is a very new standard (still a draft), there is little
need for compatibility with existing, broken implementations. Therefore
remove the extra alias, to avoid the risk of encouraging incorrect
usage.

Intentionally keeping the ff_hevc_dynamic_handler name for the
handler, to use "hevc" consistently as name for the codec instead
of "h265" within the library internals as long as there only is one
single variant in actual use.
Signed-off-by: Martin Storsjö <martin@martin.st>

In practice this hint is ignored - the rtp muxer always overwrites
the stream time base without taking the hint into account. But as
a general practice this is the correct way to pass a time base hint
on to a chained muxer.

This avoids warnings about using the codec time base as hint
being deprecated.
Signed-off-by: Martin Storsjö <martin@martin.st>

HOSTCPPFLAGS and HOSTCFLAGS are only set in config.mak.
Signed-off-by: Martin Storsjö <martin@martin.st>

The size variable is (correctly) unsigned, but is passed to several functions
which take signed parameters, such as avio_read, sometimes after having
numbers added to it. So ensure that size remains within the bounds that
these functions can handle.

CC: libav-stable@libav.org
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Also avoid an unused variable warning for compilers w/o av_unused support.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

The input file may not have consistent start times, stream durations and
chunk durations. This patch at least removes negative durations that
make chromecast unhappy, and correctly sets starting time on chunks so
that the split (or .ismf) outputs match the manifest.
Signed-off-by: Martin Storsjö <martin@martin.st>

Bug-Id: 661
CC: libav-stable@libav.org

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Previously there was a limit of two cpuflags.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

This makes more sense for future implementations of templates with zmm registers.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>