BehindLiveWindowException when playing HLS #1074
Comments
|
|
|
Note that most often the exception is caused by a combination of the two bullet points above. Repeated client buffering will only cause the exception if the accumulated duration of time spent buffering exceeds the window size minus the duration that the client wants to buffer locally (typically ~30 seconds). So the larger the window size, the less likely this is to occur. I would say that you'd want the window to be at least ~2 minutes. |
|
@ojw28 How to workaround? |
|
@crossle Here's my workaround: ( if (live) {
if (previousTsChunk == null) {
chunkMediaSequence = getLiveStartChunkMediaSequence(nextVariantIndex);
} else {
chunkMediaSequence = switchingVariantSpliced
? previousTsChunk.chunkIndex : previousTsChunk.chunkIndex + 1;
if (chunkMediaSequence < mediaPlaylist.mediaSequence) {
if (allowSkipAhead) {
chunkMediaSequence = getLiveStartChunkMediaSequence(nextVariantIndex);
liveDiscontinuity = true;
} else {
fatalError = new BehindLiveWindowException();
return;
}
}
}
} else {
....
} |
|
Where should I use this code? ;( |
|
You should really just fix the source content as per my initial response. |
|
Am facing the same issue at my end. @ojw28 as per you we have to increase the buffer time from default 10 sec to more then 30 sec and it will solve the problem. But in my case i am using Akamai as my CDN and they don't provide any other option to increase it more then 10 sec, though they provide option to decrease this below 10 (which is not useful). Is there any other alternative option to resolve this. |
|
That doesn't sound right. Are you sure the variable you're looking at isn't the chunk size, for which a 10 second limit would make sense. |
|
I guess we are not sync. I'm consuming AKAMAI HLS Playback URL (.m3u8) as stream URL. I havent found that we may request custom config against stream URL. Also would like to understand the term "window" as I'm referring it as HLS segment(.ts) duration size(default is 10 secs) which can't be changed to 30 secs. |
|
I end up fix this problem with:
|
|
Window refers to (N-1)*(SegmentDuration), where SegmentDuration is 10s in your case, and N is the number of segments that are listed in each HLS playlist at any given point in time. I suspect you'll find that your HLS media playlists only contain 3 or 4 segments at any given point in time. Increasing that would help you to avoid this issue. |
|
@ojw28 Hmm .. consider the fact that I cannot ask/demand customization from server (Akamai) in my case. I just have HLS URL to play though any suggestion to handle it in client side (Player) would be help. |
|
I'd be surprised if Akamai don't allow configuration of the window length. How many segments are listed in your manifests, at any given point in time? |
|
@ojw28 I have checked and find that it provides me 3 ts segment at a particular time. |
|
Right, and that's your problem. It should be possible for you to increase that somehow. |
|
@ojw28 Firstly let me know you that i am working with Live stream (not VOD). I am using Akamai playback url given by end client. So it not possible to update anything from Akamai. Is there any kind of solution for client side to resolve this ? |
|
You should request that the provider resolves the issue. Fundamentally you're trying to play a live stream with a live window of insufficient size. It's a content issue. It can only be properly resolved by the content provider. The best thing that you can do on the client is as @kientux suggested further up this thread, which is to automatically restart the playback each time it fails in this way. This will not be seamless, but it will allow playback to continue once it buffers again. |
|
@ojw28 Ok....but the purposed client side solution is not suitable for me. I have tried the same stream with BrightCove player (Paid Solution) and it works fine but the strange thing is that they are also using ExoPlayer internally. |
|
So get the provider to fix their content. It's simply not a client side problem if content is not provided correctly. |
|
Dear colleagues, |
|
I found another bug still opened and I think that in case of mpegdash we facing BehindLiveWindowException because of it. |
|
Where is the correct place to catch the BehindLiveWindowException? I realize that the provider should fix the content, but until I can get the addressed, what is the best place to catch this exception and restart the player? Here is stack trace: |
|
The correct place is implementation of the |
|
1513 |
|
@huykn , in this case you loose ability to dynamically select variant base on network conditions and you have to control from your client side which variant select in order to provide best user experience. In other words, if the network quality is low you have to detect it by yourself and switch stream into lower variant, otherwise buffering will be more and more frequent and end user experience of your application will be unpredicted. Keep this in mind. |
|
Specifically for HLS, it seems this issue can be caused by non-aligned segment numbers across the different variants, in addition to the other causes mentioned above. Non-aligned segment numbers are permitted by the HLS spec, and therefore failing to correctly handle this case is an ExoPlayer issue. It's kind of tracked by #699, but it would be good to have a bug explicitly tracking this resulting in @huykn - Are you able to provide test content that reproduces this issue? If so, please file a new issue on this tracker providing all of the information requested in the issue template, and we'll use that to track the problem. |
|
Hello, I'm also getting this exception on one of my HLS playbacks. Any chance for a temporary built-in solution until the root cause for this problem will be found? Thanks |
|
@krok55 The root cause was found. As you see in the conversation above, this is problem from content provider, not client. So ExoPlayer might never try to handle this exception. |
|
Note - There are fixes in |
|
Note that Apple's documentation on using HTTP live streaming has 3 segments in it https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html I hardly think this is a content problem |
|
|
I'm still seeing this in 1.5.10 across a variety of HLS Live streams. |
|
I am also facing the same issue with Exoplayer 2.x.x and 1.5.x versions while playing the Live HLS Video. Need resolution of it on client end, guys? |
|
I just experienced this with ExoPlayer 1.5.11 with a live hls stream. Stack trace is the same as aforementioned:
I'm unable to provide a sample stream as they are authenticated, but please let me know if there's any additional information i can provide. |
|
@theBradfo Just wait for some couple of days, new fixed release is about to come for this issue. |
|
@ishantsagar, @ojw28 can you provide any information on this forthcoming release and potentially some detail on how it would fix this issue? |
|
@ishantsagar - Please don't cross post on multiple issues (i.e. this one and #1782), it adds unnecessary noise to the issue tracker. Please continue this discussion on the open issue, which is #1782. |
With latest ExoPlayer library, when playing HLS, sometimes the video hang with
BehindLiveWindowException:But if I just wait for about 3 - 5 seconds (or call
preparePlayer()again) then the video starts playing again with no problem. Sometimes there's alsoSocketTimeoutExceptionofokhttpbefore this exception, I tried to increase timeout inDefaultHttpDataSourceandSocketTimeoutExceptionis gone but this exception persists.So how to get rid of this? Maybe it's because of slow network connection, is there any way to increase timeout other than in
DefaultHttpDataSource?The text was updated successfully, but these errors were encountered: