search

Dash-Industry-Forum / dash.js

A reference client implementation for the playback of MPEG DASH via Javascript and compliant browsers.
http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html
Other
5.12k stars 1.68k forks source link

AutoSwitch issue #1751

Closed ThiagoMiranda closed 7 years ago

ThiagoMiranda commented 7 years ago

Hi.. I've been using Dash.js with my own Player to play Dash and DashDRM streams. I've noticed something odd that only happens in some videos ( unfortunately I'm in production with my Player and some of my clients did notice it too ). When the AutoSwitch is enabled the player freezes when trying to switch it ( if I seek it the video returns to playing ). When the AutoSwitch is false, it plays nicely. I've tried to identify the moment that it occurs but it doesn't fire an error event or nothing ( at least in my tests ) that I could use to identify the freeze and perhaps seek the video to the next second. Can you help me? Thanks I've tested on the reference page and the same issue happens.

Environment
Steps to reproduce
  1. Just play the video until second ˜00:10 and it will freeze when trying to change the output automatically
Observed behaviour

The image freezes, the sound plays for a while ( two-three seconds ) and freezes too. If I seek the video it restarts to play nicely.

Console output
[11523] Prior to making a request for time, NextFragmentRequestRule is aligning index handler's currentTime with bufferedRange.end. 40  was changed to  40.8 
fp.dash.js:3 [11524] Getting the request for video time : 40.8 
fp.dash.js:3 [11524] Index for video time 40.8 is 3 
fp.dash.js:3 [11524] SegmentList: 30 / 90.048 
fp.dash.js:3 [11524] Getting the next request at index: 4 
fp.dash.js:3 [11525] SegmentList: 40 / 90.048 
fp.dash.js:3 [11535] Buffered Range for type: audio : 0  -  49.898 
fp.dash.js:3 [11833] Buffered Range for type: video : 0  -  10.72 
fp.dash.js:3 [11833] Buffered Range for type: video : 10.8  -  49.88 
sb.logger.js:43 Added bw kbps metric: 30

Edit: This is a .mpd file from my same server/encoder that works: http://svbps-sambavideos.akamaized.net/vod/_definst_/amlst%3Astg%3B219%2C6004%2Cc6a518204bc3a1ba5b5a4a107f77de77%3Bhidden32np%3B3WUIAZCQWMAH2AUB4UWWQS5LQMBO4NC4LFL5YSHBCUIBQJWYNEKHNU2UOFCDQNEPOU5TL2VCOMAK2NPU2WKHD2XQCEBUQE3SYTZYPEMGTMG7MFPTYS5IR32QT5ZCJW7GTBOZRFTHP4WYLJSPW6W74K2PEQ6ZNTSJA5ZMVUTVZM2EIW65MQYTBB6KAOGTRZFFBS3A33O3HAGCMEKM6DRXHCMZD6EAHYU7MJAKJNLZNQVKQRMTTQEKQRIWI45CUL5PD5BIOY3CJF4MPM5W7BHLEJMCRLM3EFLQPR46HLRDT6555IYFN66IICJ46VWKC6NV66FUTHEDEPP5WIBINSFL5HC3NMZN3RDXBTZ2PDEFMYXW4GY%21/manifest_mvlist.mpd

davemevans commented 7 years ago

Your console log already explains the problem - there's no media for the time between 10.72s and 10.8s, so playback stalls.

fp.dash.js:3 [11833] Buffered Range for type: video : 0  -  10.72 
fp.dash.js:3 [11833] Buffered Range for type: video : 10.8  -  49.88

You need to ensure that the segments accross all representations are the same length, which is not the case here. The manifest describes the segments as being ten seconds but in reality they seem to vary quite a bit.

ThiagoMiranda commented 7 years ago

@bbcrddave Is there any way to detect this gap? For now I'm seeking the video if I detect, for 3 seconds, that the media is stalled but keeps it's status as "playing". I'm not sure if this is the best approach. Do you have any thoughts? Thanks for the response =)

ThiagoMiranda commented 7 years ago

@bbcrddave I'm trying to set the AutoSwitch to false ( setAutoSwitchQualityFor('video', false) ) when the error occurs but it isn't working. Eventually the player tries to change the quality for it's own. Is there a bug for that?

davemevans commented 7 years ago

I don't know of any current issue with that API, but it will be too late by the time the error has occurred since there will already be a gap in the media timeline.

Your best bet is to get your media sorted such that the switch points are aligned rather than hacking around the problem in your application.

ThiagoMiranda commented 7 years ago

@bbcrddave We are trying to get with ZenCoder ( our encoding solution ) and Wowza ( our streaming solution ) a good solution for that but unfortunately the videos already uploaded by the user wouldn't be affected so I'm trying to get around with it like Bitmovin ( for example ) seems to deal as their player plays our videos even with this sync error. Either way, your tip about the track sync error was very helpful. Thanks :)

ThiagoMiranda commented 7 years ago

@bbcrddave We are investigating on the mvlist.mpd generated by the Wowza server. Is there any issues related to it on DashJs?

Either way, I've found some chunks with NaN values on it. Could it be the problem? screen shot 2017-01-25 at 10 25 18

Thanks =)

davemevans commented 7 years ago

No, that is normal - Initialization Segments contain no media, only metadata so it is expected that they have no timing associated with them.

Static SegmentList manifests generated by Wowza should work - there is one in the reference player example streams which plays correctly as far as I can tell.

ThiagoMiranda commented 7 years ago

@bbcrddave Thanks. I'll try to reproduce the same configuration of that reference link.

One thing that concerned me was this:

_Playback issues with MPEG-DASH streams

When using the DASH-IF reference player (dash.js) and the Google Chrome browser, DASH streams may play for a while and then start looping on a single media segment.

If you're running Wowza Streaming Engine software version 4.2.0 and earlier, and if you use the MPEG-DASH test player in Wowza Streaming Engine Manager or the MPEGDASHPlayer examples included with your Wowza Streaming Engine software installation to play a DASH steam, the stream may not start. These players are based on an older dash.js version.

Solution

We recommend that you use either the Google Shaka player or the Bitmovin Adaptive Streaming Player to play DASH streams. These players seem to have better compatibility with Wowza Streaming Engine MPEG-DASH streams.

If you want to use the MPEG-DASH test player in Wowza Streaming Engine Manager or the MPEGDASHPlayer examples in Wowza Streaming Engine software, be sure to use Wowza Streaming Engine 4.3.0 or later. The players in this software are based on the open source Shaka Player project, and should give better playback results.

ref: https://www.wowza.com/forums/content.php?843-Important-stream-playback-issues-that-affect-Wowza-Streaming-Engine-software#playback5_

ThiagoMiranda commented 7 years ago

@bbcrddave sorry for so many questions but can you answer me a last one? Is there any way to get the MediaSource object from a current dashjs.MediaPlayer() ( or any other object )? I was wondering how can I reach the appendBuffer and remove functions. I've tried to use the FactoryMaker but I have to admit that I couldn't figure it out how to use it ( as for get MediaSource object or others like the EventBus )

Thanks!

dsparacio commented 7 years ago

@ThiagoMiranda You're not really meant to get access to these items but rather interact with them with API. What is the reason you need to get to EventBus or MediaSource or SourceBuffer? Maybe if I can understand the use case better than I can come up with a solution for you.

dsparacio commented 7 years ago

We do need to do a better job with Wowzer. I will try to reach out to them and see if we can not come up with a plan to better support their DASH output.

ThiagoMiranda commented 7 years ago

Hi @AkamaiDASH I'm experiencing some problems in the Dashif with Wowza but unfortunately our clients already have a "legacy" of misaligned videos ( actually more than 5 thousand medias ). I've made some modifications on my Zencoder Job and Wowza plugin so I think that I've solved the issue. But, as I've said, we have this legacy.

My first goal on the player side was not to modify your 2.4.0 version ( would be a little difficult to track some new versions and improvements ) so I've made a little "hack" where I can detect a possible "misalignent" ( the misaligned medias's mediaPlayer.getVideoElement().buffered has 2 time ranges when the medias that I don't have the problem has only one ) so I can seek to the "last" time range buffered start time. I was wondering If I can remove the "first time range" when this occurs.

Another issue is the chunk request looping. For some reason that I've still couldn't figure it out ( it's a inconstant behavior ) the browser starts to download several chunks at the same time. Looks like a problem with the schedule function on the ScheduleController.js. I don't know if its related with the first one but it also happens when the auto switch is turned off.

Thanks in advance for the attention. And I'm sorry for so many questions but it's huge client and we are having a little pressure to, at least, minify their client's playback issues.

LloydW93 commented 7 years ago

I have an email thread with Wowza from some time back with some test streams to work with, but then ran out of time to investigate further - can send them on if needed.

ThiagoMiranda commented 7 years ago

@LloydW93 I've tried to reach them too and they've sent me a link describing on the comment https://github.com/Dash-Industry-Forum/dash.js/issues/1751#issuecomment-275125271. I've tested on the Shaka Player but the problem still happens but in Bitmovin it doesn't. The problem is that use the last one would be virtually impossible technically and financially in such a short time. I was wondering if I could make something like I've made on my Flash Player ( I had similar problems with HLS delivery ). If I detect that the next chunk starts after the end of the current one I download another chunk of the current track and then change to the next track in the middle of the chunk playback instead of the end of it. I'm gonna see if I can do this here.

Anyway, thanks a lot for the attention! You've been very helpful.

dsparacio commented 7 years ago

Closing due to inactivity. Please reopen with new info if it is still an issue.