The initial values are not checked against the number of block sizes.
Initializing them to frame_len_bits will result in a block size index of 0
in these cases instead of something that might be out-of-range.

This prevents build errors when compiler and assembler default
targets differ. Ideally each file would declare the highest
level it requires. This is however not easily possible as it
complicates assembling pre-armv6t2 code in Thumb-2 mode.

HAVE_NEON is used as indicator for ARMv7-A since no other
symbol exists for this and NEON is only available in this
variant.

Adding the thread count in frame level multithreading to has_b_frames
as an additional delay causes more problems than it solves.
For example inconsistent behaviour during timestamp calculation in
libavformat.
Thread count and frame level multithreading are both set by the user.
If the additional delay caused by frame level multithreading needs
to be considered in the calling code it has all information to take
it into account.
Should it become necessary to calculate a maximum delay inside
libavcodec it should be exported as its own field and not reusing
an existing field.

The Apple HTTP Live Streaming demuxer's implementation of
seeking searches for the MPEG TS segment which contains the
requested timestamp. In its current implementation it assumes
that the first segment will start from 0.

But, MPEG TS streams do not necessarily start with timestamp
(near) 0, causing seeking to fail for those streams.

This also occurs when using live streaming of HTTP Live Streams.
In this case sliding playlists may be used, which means that in
that case only the last x encoded segments are stored, the earlier
segments get deleted from disk and removed from the playlist.
Because of this, when starting playback of a stream in the middle
of such a broadcast, the initial segment fetched after parsing
the m3u8 playlist will not start from timestamp (near) 0, causing
(the admittedly limited live) seeking to fail.

This patch changes this demuxers seeking implementation to use
the initial DTS as an offset for searching the segments containing
the requested timestamp.

This opens a plain TCP connection through the proxy via the
CONNECT HTTP method. Normally, this is allowed for connections
on port 443, but can in general be used to allow connections
to any port (depending on proxy configuration), and could thus
be used to tunnel any TCP connection via a HTTP proxy.

RTCP timestamps are only necessary to synchronize time between
multiple streams. For a single stream, the RTP packet timestamp
provides more reliable timing. As a result, single-stream RTP
sessions should now have accurate and monotonic PTS.

TLSv1 is compatible with SSLv3, so this doesn't change much
in terms of compatibility. By explicitly using TLSv1, OpenSSL
sends the server name indication (SNI) header, which we
already set using SSL_set_tlsext_host_name (earlier, this
didn't have any effect).

SNI allows servers to serve SSL content for different host
names with separate certificates on one single port (vhosts).

This is useful, since the normal timegm function isn't a standard
function (requiring _BSD_SOURCE or _SVID_SOURCE on glibc to
be visible, and not available on e.g. windows). The widely available
function mktime uses the local time zone, which requires ugly
workarounds to handle UTC time.