Video only (i.e. no audio) live streams don't start playing when not starting at t=0. #758
Labels
Comments
|
Yes, this is a known issue. We should fix it. |
ojw28
changed the title
|
any updates on this issue? |
ojw28
added a commit
that referenced
this issue
Jun 15, 2016
- Code is simpler. We only ever reset all tracks. - Allows the standalone media clock to be updated properly. This allows simpler recovery for live streams in ExtractorSampleSource. - Fixes #1285 and paves the way for a fix for #758. Issue: #1285 Issue: #758 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=120530682
|
This is fixed in 2.x. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
For pure live video content (i.e. without audio track), playback starts with a long buffering interval. This is caused by the difference in media time of the StandaloneMediaClock (always 0 initially) and the (much higher) media time of the incoming video content.
Somehow, the media start time of the video content is not propagated into the StandaloneMediaClock: its member "setPositionUs" is only called once in the demo app, caused by the call "player.seekTo(playerPosition);" in the "preparePlayer" function in the PlayerActivity, with the initial playerPosition 0.
This effect can also be observed with static content, if the media start time is much higher than 0.
I have a hard time thinking of a way to easily fix this. Will this issue be resolved? If not, i would be happy about some guidance where to start.
I only tested this behavior for DASH+MP4+AVC, if that is relevant.
The text was updated successfully, but these errors were encountered: