Dash.js: sometimes the PLAYBACK_ENDED event is not triggered

Created on 15 Aug 2017  路  13Comments  路  Source: Dash-Industry-Forum/dash.js

Environment

Steps to reproduce

1. Please provide clear steps to reproduce your problem
Load the mpd on the reference player.
Use the control bar to seek close to the end of the stream.
Allow all remaining segments to be loaded in the buffer, but do not allow the player to reach the end of the video before the next seek below.
Console message "[12345] Stream is complete" is displayed.
Seek to a random position.
Allow some short playback time.
Seek close to the end of the stream.
Allow the player to play out the rest of the video.

  1. If the bug is intermittent, give a rough frequency if possible
    Always reproducible.
Observed behaviour

Describe what the player is doing that is unexpected or undesired behaviour.
The PLAYBACK_ENDED event is not triggered. The reference player does not loop the video to the beginning because it does not receive the event.

Bug

All 13 comments

Related to #1901.

Should we be raising a browser bug if this is browser-specific?

I had this problem with Firefox as well. I'm not sure why the player does not trigger its event, maybe because the end of the last audio segment and the last video segment do not align perfectly. But then again the event is triggered fine if there is no back-and-forth seeking. There was a related issue with multiperiod and there was a workaround in StreamController, #2130 is just an extension of that workaround.

Could we at least get a bug raised with the FF team before we look at hacking around it further?

I'll look into simplifying this to a simple example to isolate the unexpected browser behaviour.

Hi,

I think that I have found the issue. According to me, it's not a browser issue. It's due to an initialize segment that is pushed after the call to endOfStream on the sourceBuffer. So, the browser doesn't send ended event because it's like when a seek command occurs : new media segments are awaited.

I will submit a PR about it...

Nico

@nicosang One of the solutions I had tried was to only append init segments when there was at least one media segment, but that didn't solve the issue.

@spiterikevin could you, please, take a look at my PR?
Thanks,

@nicosang Sorry for the delay, I'll look at it today. Cheers.

Unfortunately it appears the alternative solution given in #2220 does not fully solve the problem, and also has a problem with multi-period.

I didn't have time to look deeper into whether there is a browser issue yet, but intend to work on this in November. In the meantime the workaround in #2130 and the older workaround that fixed multi-period seem to work.

I have found just one caveat for #2130 (related with #2162). If you have a stream with an adaptation having a presentationTimeOffset parameter defined in its MPD that doesn't match with the real one (timestamps in the stream) the stream could be detected as finished right when it starts.

Although is true that the root of the problem is having an mpd with errors, IMHO we have to make dash.js as much resilience as possible (in fact, that is one of the goals of #2130). We can raise warnings notifying about issues in the stream but, whenever is possible, we should avoid impacting playback experience. Open to discussion.

Hi @spiterikevin ,

could you, please, give me more details on how reproduce the problem? Right now, I'm not able to reproduce the issue on PR #2220. Which browser do you use?
When the issue occurs, is there an initialize segment in buffers?

I use Chrome 62.0.3202.62 (64 bits) on Windows 10.

Thanks,
Nico

Fixed in #2220

Was this page helpful?
0 / 5 - 0 ratings