Add EIA-608 (CEA-608) Closed Captioning support for HLS #68
Merge remote-tracking branch 'upstream/dev-hls' into dev-hls
MediaCodecAudioTrackRenderer: Fix AV sync drift, change time anchor

MediaCodecAudioTrackRenderer has a fundamental issue; it only reads the incoming
media timestamp at the start of playback and then reports current position based
on the number of samples written to AudioTrack plus recorded media start
timestamp. Variations in incoming media timestamps are not considered until they
become really big, 200 ms. 200ms is pretty bad AV sync. Just reducing the hard
coded 200 ms gets messy as the existing logic doesn't take input sample length
into account.
Existing code also makes the assumption that a media timestamp corresponds to
the end of a buffer, and it calculates a bufferStartTime as timestamp -
buffer_duration. At the start of streams this often becomes negative, a fact
that's swept under the rug with
audioTrackStartMediaTimeUs = Math.max(0, bufferStartTime);
So audioTrackStartMediaTimeUs is often wrong and doesn't correct itself.

MediaCodecAudioTrackRenderer is a clock source, and other renderers (eg video)
relies on the reported position for sync. For consistent AV sync it's important
that the position reported is properly anchored in the media timestamps,
extracted upstream from the container, and not in AudioTrack. AudioTrack is just
a dump sample sink, not a clock source.

A problematic example is HLS. After discont (eg stream switch) a new TsExtractor
is created with base time taken from the manifest. There can be a slight delta
between the last timestamp in the previous HLS chunk and the new one (with new
base time). These differences add up and AV sync start to drift.

Record the timestamp and frame number for every incoming media buffer and
calculate the corresponding media time in getCurrentPositionUs.

Signed-off-by: Jonas Larsson <jonas@hallerud.se>
Speculative fix for behind live window triggered 404s

If we were too slow to load a segment, maybe retried a couple of
times, the segment may be deleted from the server. We're behind
the live window. In this case the player will simply error out,
which isn't very user friendly (or how iOS does it).

This is a speculative fix:
- Make sure playlist is up to date in HlsChunkSource, not having
  reached the end of our current copy doesn't mean we shouldn't
  refresh it.
- If we get a 404 for a TsChunk in a live stream, try to reset
  state to trigger selection of a more recent chunk.

This needs testing, has not been confirmed to fix the problem yet.

Signed-off-by: Jonas Larsson <jonas@hallerud.se>