I think such manifests are invalid, and I haven't seen any examples,
but given it's trivial to fill in the duration if the periods define
durations, it seems worth being robust.
- It's not possible to determine a period's duration just from the
corresponding Period element in a DASH manifest. It's necessary
to look at the start time of the next period (or the duration of the
manifest for the last period) to determine how long a period is. We
don't currently do this in the parser, and hence set duration incorrectly.
We also set period start times incorrectly because we don't set it to
equal to sum of the durations of prior periods in the case where it's
not explicitly defined.
- We're currently propagating these (incorrect) values all over the place
through data-structures that we build when parsing the Period element.
- This CL removes this redundancy, storing only the start time of each
period in Period elements, and not propagating it elsewhere. It's then
used when required in DashChunkSource.
The following sequence was problematic:
1. See start of a cluster having not output a seek map. Decide
to seek for the cues. Enter CUES_STATE_BUILDING state.
2. Error occurs before seek map is output.
3. ExtractorSampleSource isn't prepared yet, so restarts from the
start of the stream.
4. See start of the same cluster having not output a seek map.
This time cuesState is CUES_STATE_BUILDING, so we just carry
on. We then fill the buffer with sample data, despite the
source not being prepared, at which point we get stuck.
It's unclear to me why cuesState needed three states, so I've rm'd
the BUILDING state. Step (4) above will now do the same thing as
in step (1). If the failure repeats, we'll eventually fail, which
is WAI.
These MP3s are unseekable but allow calculating the VBR duration correctly.
Treat streams as live only if they are unseekable and lack a duration.
Issue: #713
- Remove unused method in DashChunkSource.
- Remove inputEncoding parameter for subtitle parsers. We're
ignoring it in all but one of the parsers, and for the one
that does use it, it'll only ever receive null, since that's
all we're passing.
- Make TextTrackRenderer advance to the next subtitle even if
the current one hasn't finished, in the case that they overlap.
This shouldn't ever really happen, but it seems best to trust
the start time of the new sample rather than the last event
time of the previous one.
- Video track is always marked as adaptive, the resolution is
stripped out (since it's otherwise just set to whatever the
resolution of the first selected variant is), and the max
dimensions are set.
Issue #514
This is needed for several use cases:
- ExtractorSampleSource with option to play both embedded and out-of-band
subtitles.
- HLS multi-audio and out-of-band-webvtt.
- Migrate demo app to use new APIs.
- Add multi-track support for ExtractorSampleSource case.
- Add multi-track support for SmoothStreaming use case.
The final step is to add support back for the DASH use case and
delete MultiTrackChunkSource. This is blocked on multi-period support
landing, in order to prevent a horrendous merge conflict. We also
need to update HLS to expose sensible track information.
Issue: #514
When ChunkSource implementations implement multi-track for DASH and SS,
format selection will move inside of ChunkSource. If we, for example, fail
to query the decoder to determine which tracks are playable, we need an
opportunity to fail (i.e. say we're not prepared, so that maybeThrowError
is called, from which we can throw).
This may go away in the future if we remove the distinct preparation step
and treat tracks/formats as things that can change dynamically, but for now
this is what we have.
Issue #514.
Fix reading the first slice flag, which before could cause a read out of bounds
if the NAL unit started at the end of the buffer.
Handle non-VCL NAL units by flushing a pending sample when starting to read one.
multi-track support upstream to the ChunkSource interface.
This change does not yet make use of the newly exposed APIs. This
will come in a subsequent CL.
Issue #514.
- Currently all subtitles we parse contain timestamps relative to the sample
timestamp, however we add the sample timestamp in inconsistent ways (sometimes
in the Subtitle, sometimes in the SubtitleParser). This change converges on
a single approach. It also paves the way for passing absolute offsets to use
instead, and being able to apply them in a consistent way in a single place
(PlayableSubtitle). This functionality will be required for ISO 14496-30 TTML
embedded subtitles.
Issue: #689
- Parse all attributes that may exist in either the AdaptationSet or
in the child Representation elements at both levels.
- Correctly infer TYPE_TEXT for Representation elements whose mimeType
is application/mp4 and whose codecs attribute indicates a known text
codec type.
Issue: #689
Remove MPEG TS stream filtering based on AudioCapabilities.
Pass AudioCapabilities to MediaCodecAudioTrackRenderer so it can choose between
passthrough/raw and decoding for AC-3 tracks.
- Generalize rendererEnabledFlags to be selected track indices through
ExoPlayerImpl/ExoPlayerImplInternal.
- Selecting an out-of-bound track index (e.g. -1) is equivalent to
disabling a renderer prior to the generalization.
- A prepared TrackRenderer that exposes 0 tracks is equivalent to a
TrackRenderer in the STATE_IGNORE state prior to the generalization.
Issue #514.
On NVIDIA Shield, recreated passthrough AudioTracks have incorrect playback head
positions, due to shared state with the previously destroyed passthrough
AudioTrack. Calling AudioTrack.flush() before AudioTrack.release() ensures this
state is cleared.
This is a safe change so I have not made it a device-specific workaround. The
combined time for flush and release is less than 10 ms (with flush normally
taking less than two ms).
Everything I've seen that uses ExoPlayer sets it to true, and
setting it to false is poorly supported / likely to result in
bad initial A/V sync after each seek.
Both FragmentedMp4Extractor and WebmExtractor now invoke seekMap() with
SeekMap.UNSEEKABLE if there isn't an index in the stream, so DASH playbacks
will end up printing this warning every 5 seconds or so. This is obviously
not desirable, so this CL just removes the warning! The alternative would
have been to print a warning if the value is anything other than UNSEEKABLE,
but it doesn't really seem worth it.
This is useful to allow playback of individual segments from a
DASH stream as regular fmp4 files. These segments don't typically
contain a segment index. For playback to start, we need to invoke
seekMap with the UNSEEKABLE index. We do this if we haven't seen
a segment index when we encounter an mdat box (if one were present,
it would have been located earlier than this point).
1. [Cleanup] Remove unused Track types, including TYPE_TIME_CODE.
2. Add subtitle track type, which is different to the existing text type.
3. Set duration on the media formats for text and subtitle tracks. This
was causing the player to report unknown media duration for mp4 files
containing such tracks.
4. Make TextTrackRenderer do the right thing when not started.
Issue: #635
- Make UnrecognizedInputFormatException public so the app can more easily handle
it when it is propagated to onPlayerError.
- Format the description using the simple class names for the extractors.
- Don't retry loading after it's thrown, but just throw immediately.
- ExtractorSampleSource takes an array of extractors to test for suitability.
- Extractors now implement a sniff() method that returns whether they can
extract samples in the input stream's format.
- Switch demo app samples to use format detection.
Issue: #438
1. Fix seeking in test2.mkv by handling non-default timescale
after duration.
2. Fix handling of missing cues in test6.mkv by allowing playback
to continue (but all seeks will reset to t=0).
Issue #631
The ID_SEGMENT can only be read once, as seeing the element a second time is
assumed to indicate that the file contains multiple segment elements (which is
not supported).
This change allows the element to be read twice if it is at the same position,
so that retrying loading from the start can succeed.
1. Workaround for decoders that fail to handle the END_OF_STREAM flag.
2. Revert processing of final output buffer if it's non-empty. This
introduced another bug (#596)
Reverts: b88012f51f
Issue: #417
Issue: #596
SubtitleLayout no longer trigger re-layouts of the view hierarchy.
Instead, the SubtitleLayout just invalidates itself. This is made
possible by making SubtitleLayout a regular View that draws each Cue
directly onto the canvas, rather than having SubtitleLayout be a
ViewGroup with a child View for each Cue.
The SubtitleLayout is now properly aligned with the surface.
This means the subtitles remain on top of the video in portrait
mode, rather than being huge and below it.
Prior to this change, there was a bug where playback would
fail with the following steps:
1. Start playback.
2. Pause playback.
3. Disable all renderers.
4. Enable at least one renderer.
5. Resume playback.
The new logic assumes that an input format change will be
followed by an output format change, but I think this is
pretty much guaranteed. If this weren't to happen then the
new pixel aspect ratio wont be picked up, but I think it's
extremely unlikely (it would require the format to stay
exactly the same except for the pixel aspect ratio, which
would be bizarre).
1. An optional U+FEFF BYTE ORDER MARK (BOM) character.
2. The string "WEBVTT".
3. Optionally, either a U+0020 SPACE character or a U+0009 CHARACTER
TABULATION (tab) character followed by any number of characters that
are not U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters.
4. Exactly one WebVTT line terminators to terminate the line with the file
magic and separate it from the rest of the body.
Issue: #580
Improve Mp4Extractor test.
Add support for Xiph lacing in Matroska files.
Add support for EBML lacing in Matroska files.
Handle the initial sticky intent for HDMI audio plug.
An accumulation of several fixes:
1. Change to HlsExtractorWrapper is just a move + documentating
things that were already true + adding a precondition in the
configureSpliceTo method.
2. Change in HlsSampleSource.readData ensures that configureSpliceTo
and hasSamples aren't called on an extractor that isn't prepared.
3. The other change in HlsSampleSource ensures the correct "previous"
TsChunk is used. If a TsChunk fails to load and is replaced, the
previous chunk should be the one before that whose load completed
successfully.
4. Determine switchingVariantSpliced based on the actual format of the
previous chunk, so it's set correctly in the case of a TsChunk load
failure and subsequent replacement.
This fixes the case where we need to switch from one variant to
another during preparation, having loaded zero samples, because
the first chunk for that variant gave us a 404 error. In this
case the first extractor will have no samples, and there will
be a second extractor that does.
There was a mess where we were indexing into both a list of variants
and a (differently ordered and possibly of differing length) list of
formats. This sanitises everything.
1. Refine the way TtmlNode handles whitespace collapsing when constructing
the output text. Can of worms.
2. Start using SpannableStringBuilder. This will allow attaching of spans
in getText as nodes are encountered, which is how we'll be incorporating
styling information into the result.
1. Remove requirement for TrackRenderer implementations to report
current position, unless they are time sources.
2. Expose whether renderers have media to play. The immediate benefit
of this is to solve the referenced GitHub issue, and also to only
display the appropriate Audio/Video/Text buttons in the demo app
for the media being played. This is also a natural step toward
multi-track support.
Github issue: #541
- Fix bug where duration of initially disabled tracks wasn't correctly
incorporated into the overall duration reported by the player.
- Don't transition to STATE_ENDED unless the position has reached the
duration, if the duration is known. This allows for "playback" to
continue when all renderers are disabled, rather than jumping straight
to STATE_ENDED.
- contentType can be defined on an AdaptationSet.
- language can be defined either in AdaptationSet or in a contained
ContentComponent.
- The id from the AdaptationSet should come from the AdaptationSet.
to if the playlist load fails.
NB - I'm aware the casting is a bit messy, but I don't want a common
interface because I'm hopeful that TsChunk will go away at some point.
Issue: #537
* fix channel number encoding using the AUDIO_SPECIFIC_CONFIG_CHANNEL_COUNT_TABLE
* allocate the correct number of bits (4) int the CodecSpecificDataUtil struct
This makes it so that it's no longer necessary to specify the number
of downstream renderers to HlsSampleSource, FrameworkSampleSource and
ExtractorSampleSource, by forcing the downstream renderers to register
with the SampleSource instances in their constructors. This eliminates
a common source of subtle client bugs where the passed value is incorrect.
ChunkSampleSource had a null check solely for the VTT case,
where DashChunkSource wasn't setting a MediaFormat on VTT
chunks. It's trivial to do so, and is more consistent, so I've
done that and removed the null check. Also done some small
tidying.
This OMX component is listed but can't be instantiated on this device.
According to the GitHub issue, some other devices are also affected, so these
will have to be added too.
Issue: #377
They're current location is annoying, because it creates a dependency
from the dash package to the webvtt package. For apps like Play Movies
where WEBVTT isn't used, it's nice just to delete the whole package at
import time, which requires that this dependency be removed.
- There's definitely potential for more code sharing in these
classes, but deferring for now.
- Also made no-scheme default to file://, and allowed smoothstreaming
URLs to be specified with or without the /Manifest suffix.
Before preparation, and when seeking, Mp3Extractor did not handle retrying:
- synchronizedHeader was set before the header was known to be valid, which
means that after seeing one valid frame header and then failing to read, the
synchronization would be treated as complete.
- The input buffer would keep data loaded during synchronization but on the next
call to synchronize when retrying it was not returned to the mark position to
re-parse the data.
This change fixes these issues.
- Make HlsPlaylistParser treat non-positive dimensions as unknown.
- Make HlsPlaylistParser parse floating point resolutions, because
technically that's how they're spec'd.
- Make VideoFormatSelectorUtil treat non-position dimensions as unknown.
Issue: #461
When I moved the id3Reader instantiation out of the while
loop (below where it is now) it was no longer guarded by
the streamTypes.get(streamType) deduping check. This brings
back an equivalent check.
When a XING header is present but not usable (due to missing fields), CBR
seeking can be used instead. It relies on the bitrate. The bitrate from the
unusable XING header is not correct, which leads to incorrect seeking.
Also fix VBRI seeking by setting the correct offset on the frame to parse. Few
people seem to use that format, but I have found two very short truncated
samples which were falling back to the CBR case before but are using VBRI with
this change.
When a passthrough AudioTrack is replaced (due to seeking) the new one behaves
as if it is still emptying data from the old one, with its playback position
advancing until it runs out of data.
Data written while the 'old' AudioTrack was emptying would be discarded, so
avoid writing to the new AudioTrack while the old one is still emptying.
Also avoid using AudioTrack.getTimestamp with passthrough tracks, as this causes
the playback position to jump to a position that breaks audio/video
synchronization.
This also fixes a technical mistake where HlsChunkSource is fed
seekPositionUs=-1 when obtaining the first chunk. This is wrong,
but the usage of this variable within HlsChunkSource enforces that
the seek must stay within bounds, so we get away with it.
Issue: #385
1. prepare() needs to load a TsChunk to actually prepare the source.
2. Source is prepared, but no tracks are enabled (this is why it's
an edge case - no-one is likely to be doing this!).
3. The TsChunk load completes.
We should not load additional chunks in this case.
