- Use native frame release timing in video renderer for
smoother video playback.
- Avoid unnecessary memory copy steps in audio renderer.
- Use non-blocking AudioTrack API.
Previously we'd end up blocking forever in this case, which
is the worst thing we could do :). We could either throw an
exception or just print a warning. Printing a warning is more
in line with what other methods do (Handler prints a "sending
message to dead thread" warning).
This allows ManifestFetcher to both execute the initial
manifest load and be plugged into an ExoPlayer ChunkSource,
where it can be used for repeated manfiest refreshes during
live playback.
This API wasn't particularly nice. Best to remove it whilst
hopefully no-one is using it. Leaving the ReadHead abstraction
in place, since it might well prove useful in the future.
2. Common interface for manifest parsers.
- This effectively moves the common interface from the Fetcher level
(i.e. ManifestFetcher) to the Parser level (i.e. ManifestParser).
- The motivation here is to allow the implementation of components that
can work with a generic ManifestParser implementation.
- Skips unrecognized elements rather than crashing.
- FourCC treated as required for video and optional elsewhere,
as per the SmoothStreaming spec.
- Only parse initData text when we're actually in the ProtectionHeader element
This means that after a decoder flush, the renderer will avoid
feeding non-keyframes into the decoder until it has received and
fed the first keyframe. The decoder has no way of correctly
decoding non-keyframes that arrive before a keyframe.
It looks like for the case of self-contained media segments,
it's possible to get stuck without failure in the case that
the load fails having loaded less than the length of the init
data.
Since we have a Format class as well, it's very confusing that
FormatHolder actually holds a MediaFormat. I think it's quite
likely that Format will need promoting into the root package as
part of the HLS work, which will make this even more confusing
(although it is possible that for HLS we'll define yet another
Format class, if it turns out we need significantly different
fields).
Note - I deliberately avoided renaming the formatHolder
args/params, because they're not particularly ambiguous and
because it introduces some ugly line breaks.
- Bring back requirement for the first video frame to be rendered
before isReady returns true, *unless* we've deduced that the
upstream source is serving multiple renderers.
- Ditto for requiring that the audio track has some buffered data.
- cache ref didn't work because it referred to a private variable
(which isn't documented) from a public interface definition
(which is). Meaning the Javadoc generator was trying to link
to documentation that didn't exist.
The equals check we perform needs to ignore the max dimensions.
This tended to work in practice because formats would be the
same object, but in the case where different format objects
are used, things can break.
