This implementation does not support TLS listen sockets and loading
CA/Certs from files.

The Windows API does not support loading PEM certs, and would either
require a manual loader or instead be limited to loading Windows PFX
certificates

TLS listen sockets would have to be implemented quite separately, as many
of the APIs are different for server-mode (as opposed to client mode).

Fixes out of array read
Fixes: 3c857d4d90365731524716e6d051e43a/signal_sigsegv_7f4f59bcc29e_1386_20abd2c8e655cb9c75b24368e65fe3b1.flv

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes deallocation of corrupted pointer
Fixes: 343dfbe142a38b521ed069dc4ea7c03b/signal_sigsegv_421427_4074_ffb11959610278cd40dbc153464aa254.avi
No releases affected

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes out of array read
Fixes: 20dd01398dee0f6d83d7e5410a2ae8eb/signal_sigsegv_39eeb1f_4001_62efbdf1c60748dabf1ec310b59525fd.mov

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The rationale for this function is reflected in the documentation for
it, and is copied here:

Clip a double value into the long long amin-amax range.
This function is needed because conversion of floating point to integers when
it does not fit in the integer's representation does not necessarily saturate
correctly (usually converted to a cvttsd2si on x86) which saturates numbers
> INT64_MAX to INT64_MIN. The standard marks such conversions as undefined
behavior, allowing this sort of mathematically bogus conversions. This provides
a safe alternative that is slower obviously but assures safety and better
mathematical behavior.
API:
@param a value to clip
@param amin minimum value of the clip range
@param amax maximum value of the clip range
@return clipped value

Note that a priori if one can guarantee from the calling side that the
double is in range, it is safe to simply do an explicit/implicit cast,
and that will be far faster. However, otherwise this function should be
used.

avutil minor version is bumped.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Fixes integer overflow
Fixes: 1e32c6c591d940337c20b197ec1c4d3d/asan_heap-oob_4a52e5_8946_0bb0d9e863def56005e49f1d89bdc94d.avi

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes integer overflow
Fixes: 0c2625f236ced104d402b4a03c0d65c7/asan_generic_274e1ce_5990_9314e7a67c26aecf011b178ade9f217c.avi

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: 0231a17345734228011c6f35a64e4594/asan_heap-oob_1d92a72_3218_1213809a9e3affec77e4c191fdfdc0a9.mov

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

When async issues its inner seek via ffurl_seek, it treats failures as
EOF being reached. This is not consistent with the behavior of other
protocols (e.g. http, cache) which continue to tolerate reads after
failed seeks, and therefore does not interact correctly with them.

A common pattern where this manifests itself is where avio_seek is
called with pos to be the end-of-file - the http range-request would
fail here, and async would set io_eof_reached to 1. The background
thread would then refuse to read more bytes, and subsequent reads would
only empty the fifo and end in an error.

Presumably the code may have expected subsequent seeks to unset the
io_eof_reached but this is not guaranteed to be true - a subsequent seek
that lands in the AVIOContext's buffer (the fact that the
previously-failed avio_seek leaves the AVIOContext's buffer intact also
suggests that follow-up reads are expected to be tolerated) would not be
issued to the async_seek function, and when that buffer is drained only
async_read calls would follow, leading to the same error just described.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Just realized my previous patch doesn't work quite right.  I uploaded a better
sample file that actually has visible captions to /incoming/hevc_cc.ts.  I
tested with that file doing hevc->x264 and it works.

This is basically an exact copy of the existing h264 logic.
Signed-off-by: Will Kelleher <wkelleher@gogoair.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Matt Oliver <protogonoi@gmail.com>

This adds msvc optimisations as well as fixing an error in icl whereby it will generate invalid code otherwise.
Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Reviewed-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

A too small buffer will cause segfaults somewhere below
decompress_texture_thread.
Reviewed-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

If it is too small av_image_copy_plane segfaults.
Reviewed-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

This prevents various values from getting an insanely huge exponent.
If someone knows a cleaner solution, thats welcome!

This is similar to commit 8978c743 for aacsbr.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

This fixes a null pointer dereference from the recently introduced
AVStream->internal
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Since de0e219a cur_dts is sometimes invalid

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

I didnt find any case that triggers this but if it gets triggered it needs to be
investigated
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

a set ost->frame_rate does not imply CFR in ffmpeg

The changed fate tests had all wrong packet durations
(like 1/1000 or 1/90000)

There might be more cases in which is_cfr could be set
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

* commit '8ad5124b':
  movenc: Automatically flush after writing the initial moov
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'db9b7321':
  vsrc_color: implement frame rate
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '1339009c':
  vf_showinfo: show timebase & framerate too
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '11f87ca7':
  vf_frei0r: also set AVFilterLink.frame_rate
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '7d12cba9':
  vf_framepack: Check and update frame_rate
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '65e73bc6':
  vf_interlace: implement frame rate
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '018bdaed':
  setpts: add FRAME_RATE constant
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '5e91a5c5':
  testsrc: set output framerate
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '9df477e0':
  yadif: update frame rate
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '1062880d':
  vf_fps: set frame_rate.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '61fb67dc':
  buffersrc: accept the frame rate as argument.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '48ff6683':
  lavfi: add a frame_rate field to AVFilterLink.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '79f5347a':
  avcodec: fix doxy placement
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '8de1ee9f':
  lavf: deprecate compute_pkt_fields2
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

This matches the Libav signature and simplifies merging future changes.