google / ExoPlayer

This project is deprecated and stale. The latest ExoPlayer code is available in https://github.com/androidx/media
https://developer.android.com/media/media3/exoplayer
Apache License 2.0
21.74k stars 6.03k forks source link

DASH/SmoothStreaming/HLS - Live channel audio plays ahead of video #1416

Closed ChernyshovYuriy closed 8 years ago

ChernyshovYuriy commented 8 years ago

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.

tresvecesseis commented 8 years ago

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 https://github.com/google/ExoPlayer/issues/1416

ojw28 commented 8 years ago

@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.

ojw28 commented 8 years ago

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.

tresvecesseis commented 8 years ago

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 https://github.com/google/ExoPlayer/issues/1416#issuecomment-206290175

ojw28 commented 8 years ago

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.