This allows the adjustment of timestamps in microseconds along with
TS timestamps. This is useful for containers that include the
timestamps in microseconds format, like fMP4 and WebVTT.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132547521
- This change fixes seeking before the prepare (or more
accurately, before the timeline is set). The fix a minimal
one to fix the behavior. It's inefficient compared to
posting the pending seek onto the playback thread, which
will be the long term solution.
- As of this change, I think we can call V2 "done". There are
some loose ends to tie up, but the API is effectively
finalized and the implementation is in a state where you
can take it, use it and expect it to work.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132468107
Adds a few unused fields to HlsUrl and moves things towards the Hls
reimplementation we are looking for. Also fixes a bug related to
asuming every getNextChunk().loadable == null being related to
reaching the live edge.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132305206
New version hangs when running:
./gradlew :library:assembleAndroidTest --debug
Android Studio "strongly recommends" we upgrade to the
hanging version, but I guess we'll just have to ignore
that until the latest version works again!
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132063280
If the live window has a small duration, we currently
end up setting the default start position to be right
at the start of the window. This increases the chance
of a BehindLiveWindowException.
With this change we impose a minimum 5s gap between
the start of the window and the default start position.
If the window is *really* small (<10s) then doing this
would push the default start position too close to the
end of the window. We don't have much time to play with
in either direction in this case, so we put the default
start position in the middle of the window and hope for
the best.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132054802
Now you can do cool things (if you really want to!) like
play a video twice, then play a second video, then loop
the whole thing, all seamlessly.
new LoopingMediaSource(
new LoopingMediaSource(firstVideoSource, 2),
secondVideoSource));
You can also just loop, which is probably more useful :).
Issue: #490
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132049599
People will inevitably try and do it, and it's pretty
easy to handle properly, so why not...
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132047019
- Don't send a timeline to the listener until all children
have reported their timelines.
- Propagate a proper merge error if merging fails.
- The PlayerActivity hack is necessary due to the way Andorid's
MediaController widget attaches to the window :(. It'll go
away once we get our own player controls.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131958169
This could cause us to "lose" allocations backed by an
initial block, meaning they became unavailable for use
despite still being allocated.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131931465
- Centralise compileSdkVersion, targetSdkVersion and
buildToolsVersion in a single place for gradle.
- Bump compileSdkVersion and targetSdkVersion to 24.
- Bump com.android.tools.build version to re-enable
instant start.
- Bump targetSdkVersion in manifests (needed for
internal builds).
- Use standard expandable_list_item from Android in
the demo app, since ours doesn't look right when
targeting API level 24. We were also setting the
theme on the wrong element in the manifest, so I'm
removing that line.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131929216
