Possible buffer issues between previous versions

[danrossi]

I'm sorry I am not entirely sure how to report this but there seems to be noticeable buffer issues between specific 2.6 versions.

The latest version will low buffer lengths quickly and rebuffer. Other people have reported this also.

I have made sample players for both versions available.

Is there something a problem or could be done. I have not tried to dig into the code to figure it out yet.

Latest

http://dev.electroteque.org/dash/2.6.0-9757951/

previous known working version although I think the bitrate change is slow.

http://dev.electroteque.org/dash/2.6.0-52470bd/

[jeremco]

Hi

I have tried to find the commit and I think this is due to commit b8c1578 : move throughput/latency estimation out of ThroughputRule, from PR #2003

But I don't know exactly why. Since this commit, throughput rule returns quality 0 for a certain time and then returns highest quality, whereas before this commit, the rules returns the quality highest quality very quickly.

Do you agree with me ?

[danrossi]

I'm not sure. I'm noticing tiny buffers and erratic quality changes. It's starting out with the lowest rate and taking a while to go to a larger rate also. Not sure how else to provide information yet sorry.

[danrossi]

Sometimes the buffer length will grow but then drop off quickly.

[spiterikevin]

The known working version is at commit 52470bd which merges PR 2038. The problem version is at commit 9757951 which merges PR 2042. That narrows down the possible cause to PRs 2029, 2039 and 2042. But I cannot understand why any of those three PRs would cause buffer issues.

@jeremco Commit b8c1578 shouldn't change behavior, it only moves throughput estimation code from one place to another. But I'll look over it again to check if I overlooked some subtle issue that might cause problems.

[jeremco]

@spiterikevin, what i have done is to reset to previous commit in dev branch, and i found the pb has started at commit b8c1578. As I said, i don't understand why.

I have noticed since that commit that when I load the player by removing local storage pref and cache, the quality remains a long time at lowest quality. If you reload the player, quality switch is quicker (because of local storage I think)

But maybe it is not the right way to find the pb, or I misunderstood the pb

[spiterikevin]

@danrossi There was a problem with AbandonRequestRule which was addressed in PR #2066. This might have been causing your issues because AbandonRequestRule is one of the safety features to avoid rebuffering. Incidentally that PR was merged a couple of hours after this issue was opened.

@jeremco I did find a subtle change in behavior inadvertently introduced by #2003. Just opened PR #2087 to fix that problem. I couldn't reproduce the problem before/after commit b8c1578 you had been seeing, but I couldn't find any other significant behavior change. Note: In the before/after tests I attempted I was using the fix from #2015 because otherwise I couldn't get any bitrate change at all.

[danrossi]

I have tried updating. I can see the playhead almost reaches the buffer and then it buffers more. On startup with a low bitrate I receive one rebuffer.

Shouldnt it keep download segments and fill a buffer to a certain limit ? rather than wait until it reaches the buffer length to buffer more ?

Shouldn't it be buffering while paused also ?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because no further activity occurred. If you think this issue is still relevant please reopen it. Thank you for your contributions.