we have also reported this weird behaviour before, it appears to be related
to the presence of IDR keyframes, by default the player discards al the
frames (but not the corresponding audio) until it finds an IDR keyframe
then it displays the IDR keyframe and plays all the buffered audio until
it reaches the point in time of the displayed keyframe, then the video
resumes normally, with the allowNonIdrKeyframes option the interval until a
keyframe is found is reduced (in our case we go from 30 seconds to less
than a second) but we think that the right solution is to discard all the
audio buffers prior to the keyframe timestamp.

On Wed, Apr 6, 2016 at 1:58 AM, Yuriy Chernyshov notifications@github.com
wrote:

Dear colleagues,
Another issue discovered and this time I am ready to provide channel
manifest link :-)
Actual result is next:
When start to play provided live channel, audio track plays ahead of video
one for a several seconds (depends on device, could be 5, or 10, or
whatever) while first frame of the video is displaying. Then both channels
starts to play synchronously. Interesting thing is that video starts to
play synch with audio without blinking. From user perspective it seems like
video waits for the audio.
More interesting, if I disable audio track from the code in
DemoPlayer.java (in constructor):
player.setSelectedTrack(TYPE_AUDIO, TRACK_DISABLED);
then video freezes on the first frame and never resumes. As soon as audio
track enables, video starts to play synch with audio.
This behaviour was detected on our application and reproduced on the
ExoPlayer application.
Live channel manifest url is:

http://s91.acdn.quickplay.com/live/ss/9990/s/livech92048/livech92048.isml/manifest.mpd
Content is MPEGDASH, not protected.

It could be content (or server environment) issue as well, the reason to
assume this is that there is the same channel available in our different
server but Widevine protected and it plays well just right from the start.
It is hard for me to determine exact root cause and I am asking for your
assistance.

Thank you in advance.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1416

@tresvecesseis I'm pretty sure your case was applicable to HLS only.
@ChernyshovYuriy If your DASH content is generated such that each segment starts with a keyframe (which they should) and such that each segment contains samples whose timestamps align properly with what the manifest defines, then this shouldn't happen. Unfortunately, it's up to you to debug what's wrong with your content. Given the streams we have from other providers all work correctly, this is most likely to be a content issue.

Actually, I think it might be possible for this behavior to occur in the DASH case (although it's not really the same problem). I'll have a look.

In my case I'm dealing with progressive HTTP streams not adaptive ones
El 6 abr. 2016 12:17 p. m., "ojw28" notifications@github.com escribió:

Actually, I think it might be possible for this behavior to occur in the
DASH case (although it's not really the same problem). I'll have a look.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1416 (comment)

This is fixed for both DASH and SmoothStreaming in dev-v2. I'm not sure about HLS; it would likely depend on how sensibly the chunks are encoded, but closing this issue because the sample provided was a DASH stream.