Also use MediaCodec buffer flag constants instead of those on MediaExtractor.
This is in preparation for merging InputBuffer and SampleHolder.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117810136
This version only supports 16-bit uncompressed PCM. A follow-up CL will
add support for other sample bit depths.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117809475
This is the first version and is still not linked to the WebVTT parser nor
does it support all the intended features, but it was left this way to
ease the review a little bit.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117722492
- Not doing any renaming for now. It'll be easier to wait
until after the extensions themselves are brought across.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117438338
Some devices fail to decode an avc3 stream that doesn't start with an SPS (for
example, if an access unit delimiter appears first). Workaround the issue by
discarding input sample data up to the first SPS on those devices.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117224602
This is needed to support fully demuxed audio in HLS. For the
sample I have the video (only) variant still declares an AAC
stream. I suspect there's at least one toolchain out there that
hardcodes H264 and AAC streams in TS output.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117224224
DTS Express (which is DTS LBR according to http://www.mp4ra.org/codecs.html) is
not supported for passthrough playback currently. Associate a different MIME
type with it so that we don't try to use DTS passthrough for playing DTS
Express.
The MIME type for DTS Express is just vnd.dts.hd, with a profile parameter
indicating that it's DTS Express rather than one of the other formats.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117129583
Notes:
- The way this works is that every time the player needs to
select some tracks it invokes the TrackSelector. When a
track selection is actually activated (i.e. "hits the
screen") it gets passed back to the TrackSelector, which
allows it to expose the current tracks through an API that
it may choose to define. Since playlist support doesn't exist
yet, it's currently the case that the pass-back always occurs
immediately.
- A TrackSelector can invalidate its previous selections if its
selection criteria changes. This will force the player to invoke
it again to make a new selection. If the new selection is the
same as the previous one for a renderer then the player handles
this efficiently (i.e. turns it into a no-op).
- DefaultTrackSelector supports disabling/enabling of renderers.
Separately, it supports overrides to select specific formats.
Since formats may change (playlists/periods), overrides are
specific to not only the renderer but also the set of formats
that are available to it. If the formats available to a renderer
change then the override will no longer apply. If the same set
of formats become available at some point later, it will apply
once more. This will nicely handle cases like ad-insertion where
the ads have different formats, but all segments of main content
use the same set of formats.
- In general, in multi-period or playlist cases, the preferred
way of selecting formats will be via constraints (e.g. "don't play
HD", "prefer higher quality audio") rather than explicit format
selections. The ability to set various constraints on
DefaultTrackSelector is future work.
Note about the demo app:
- I've removed the verbose log toggle. I doubt anyone has
ever used it! I've also removed the background audio option.
Without using a service it can't be considered a reference
implementation, so it's probably best to leave developers to
figure this one out. Finally, listening to AudioCapabilities
has also gone. This will be replaced by having the player
detect and handle the capabilities change internally in a
future CL. This will work by allowing a renderer to invalidate
the track selections when its capabilities change, much like
how a selector is able to invalidate the track selections in
this CL.
- It's now possible to enable ABR with an arbitrary subset of
tracks.
- Unsupported tracks are shown grayed out in the UI. I'm not
showing tracks that aren't associated to any renderer, but we
could optionally add that later.
- Every time the tracks change, there's logcat output showing
all of the tracks and which ones are enabled. Unassociated
tracks are displayed in this output.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117122202
- Format can represent both container and sample formats.
If a container contains a single track (as is true in
DASH and SmoothStreaming) then the container Format can
also contain sufficient information about the samples
to allow for track selection. This avoids the Format to
MediaFormat conversions that we were previously doing in
ChunkSource implementations.
- One important result of this change is that adaptive
format evaluation and static format selection now use the
same format objects, which is a whole lot less confusing
for someone who wants to implement both initial selection
and subsequent adaptation logic. It's not in the V2 doc,
but it may well make sense if the TrackSelector not only
selects the tracks to enable for an adaptive playback, but
also injects a FormatEvaluator when enabling them that will
control the subsequent adaptive selections. That would make
it so that all format selection logic originates from the
same place.
- As part of this change, the adaptiveX variables are removed
from the format object; they don't really correspond to a
single format. This also saves on having to inject the max
video dimensions through a bunch of classes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=114546777
Duration was originally included in MediaFormat to match the
framework class, but it actually doesn't make much sense. In
many containers there's no such thing as per-stream duration,
and in any case we don't really care. Setting the duration on
each format required excessive piping.
This change moves duration into SeekMap instead, which seems
to make a lot more sense because it's at the container level,
and because being able to seek is generally couplied with
knowing how long the stream is.
This change is also a step toward merging Format and MediaFormat
into a single class (because Format doesn't have a duration),
which is coming soon.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=114428500
This change removes the need for SourceBuilders to load their
manifests before building their sources. This is done by pushing
initial manifest loads into the ChunkSource classes. This simplifies
the SourceBuilders a lot, and also DemoPlayer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=113259259
- I think \r and \n are handled the wrong way around?
- We only expect to encounter a BOM sequence at the start of a
file, but it feels fine to automatically discard it in all
cases for simplicity. A BOM sequence doesn't mean anything in
UTF-8. See https://en.wikipedia.org/wiki/Byte_order_mark. Note
that I think the advice not to remove it on that page relates
only to the case where the file is being edited + saved.
Issue #1136
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112143407
Previously, when spectral band replication (SBR) or parametric
stereo (PS) was in use in an MPEG-4 stream, the channel configuration
chosen was likely incorrect. The channel configuration was *always*
incorrect for 7.1 audio (gave 7 channels instead of 8).
