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.15k stars 1.68k forks source link

Uncontrolled buffering while switching to highest bitrate within an Audio Adaptation Set #124

Closed bherrmann-iis closed 9 years ago

bherrmann-iis commented 10 years ago

Hi,

I've encountered an issue while switching within an audio adaptation set containing multiple audio representations with different bitrates. To be exact: The issue only appears if switching to the highest bitrate of the is set triggered. Video switching behaviour was not tested! After this is done, the audio and video buffer is rapidly filled with segments until the end of the file preventing anymore switching after that.

The facts:

How can it be reproduced?

1) Use this mpd: http://dash.edgesuite.net/dash264/TestCases/3b/fraunhofer/heaac_stereo_with_video/Sintel/sintel_480p_heaac_stereo_sidx.mpd 2) Disable ABR-Mode (just to be able to see the exact problem). 3) Load the mpd and switch your way up to the highest audio bitrate (5 total representations) 4) Everything is fine and smooth till a switching event from any bitrate to the highest is triggered. 5) Look at the audio/video buffers. The are increasing rapidly and uncontrolled 6) Stalled swiching capability, because file gets fully pre-loaded in seconds.

How should it behave?

Swtching between all representations in an adaptation set must not brake the upper pre-buffer limit of the player.

Which player, version, os showed the problem?

I tested: Chrome 32.0.1700.107 (Linux), Chrome 32.0.1700.77 (Mac), Chrome 33.0.1750.117m (Windows) and IE11 - 11.0.9600.16518 (Windows 8.1) The issue could be observed within every test.

Additionaly information:

Enabled ABR-Mode shows the same issue, but there it depends when the player will switch to the highest bitrate. I checked wireshark ouput to see, if it fetches the right representations when switching. The fact that the player won't switch anymore after triggering the bug and fetching the whole content, can also be seen with wireshark (the player still shows, that he switched to another bitrate in the overlay!)

Best regards, Bernd

kirkshoop commented 10 years ago

This behavior seems intentional. A change was contributed that detects when the highest representation is selected for an mpd with a duration longer than 10min and sets the required buffer to 300sec.

If the bandwidth to the server was unable to provide the segments before the player needed to play them then the rule should still switch down. If you are seeing the player immediately buffer to the end then there must be enough bandwidth to prevent the switch.

bherrmann-iis commented 10 years ago

Thanks for clarification. I wasn't aware that there were changes regarding the upper buffer limit implemented. Since this behavior is intentional, this issue can be close.

kirkshoop commented 10 years ago

Also, look at player.setBufferMax() for some limited control over buffer length. "required" - the default policy "min" - just use a fixed value calculated from the minBufferTime and duration values in the mpd "infinity" - the buffer length is the duration from the mpd. this is very aggressive.

dsparacio commented 9 years ago

closing issue based on comment berndherrmann commented on Mar 26, 2014