Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmenduration wrong #2940

Closed
PolynomialDivision opened this issue Feb 19, 2019 · 9 comments
Closed

Segmenduration wrong #2940

PolynomialDivision opened this issue Feb 19, 2019 · 9 comments
Milestone

Comments

@PolynomialDivision
Copy link

PolynomialDivision commented Feb 19, 2019

The getQualityForBitrate function has this if statement:

if (latency > fragmentDuration) {

Here the Fragmentduartion is fetched:

const fragmentDuration = voRepresentation.fragmentDuration;

At this line:

representationInfo.fragmentDuration = voRepresentation.segmentDuration || (voRepresentation.segments && voRepresentation.segments.length > 0 ? voRepresentation.segments[0].duration : NaN);

What is this line doing?
I have a MPD file specifying the durations by d='...'.
I think voRepresentation.segmentDuration is always NaN.
And so voRepresentation.segments[0].duration is always taken.
Is this always the first segement? What if my durations varies?
What is exactly this list voRepresentation.segments?
As I understand it, it contains all elements for one Representation?
Why can't I use the element here that I want to fetch?
Is there some way to get the index of the element I want to fetch?


Here is exactly what I mean:

track.segmentDuration = segments[0].duration; //assume all segments have the same duration

I just need to get the duration for the next segment in the list that should be downloaded or checked next... Is there a way to get this segment number?


Furthermore, the segment duration is wrong for the insufficient buffer rule leading to weak download behaviour and stalling.

const fragmentDuration = representationInfo.fragmentDuration;

@epiclabsDASH
Copy link
Contributor

@PolynomialDivision, thanks for reporting. The way we manage some of the objects you reference here (voRepresentation.segments, that keeps the next 10 segments to be played for a given representation) is going to suffer a big change in dash.js v3.0 (to be released shortly). So, the issue you mention that is affecting to ABR is going to be fixed "collaterally". I will double check to be sure of this.

@epiclabsDASH epiclabsDASH added this to the v3.0 milestone Feb 22, 2019
@PolynomialDivision
Copy link
Author

Thanks for your answer.
Can I just checkout the development branch and test it myself? :)

@epiclabsDASH
Copy link
Contributor

Not yet. Still is not published but it will shortly. I will keep you updated.

@PolynomialDivision
Copy link
Author

PolynomialDivision commented May 20, 2019

On the dash.js meeting it was said that there is only getNextSegment() left for the scheduler.
It was not sounding as the segment time regarding the rules will be fixed in dash.js v3. Further, it sounded that just the getNextSegmentByTime(...) will be fixed.

@PolynomialDivision
Copy link
Author

PolynomialDivision commented Jun 27, 2019

There is some interesting Pull Request #3003.
It's written that using SegmentTimeline representation metrics are not correctly reported and top level application could get erroneous "current bitrate" value. I'm not entirely sure, what that means.
is that maybe related to my issue? I'm using SegmentTimeline as well but not for live-streaming. So representation metrics are not correctly reported as well?

@epiclabsDASH
Copy link
Contributor

Not really, it is related with the index of the current level as it is retrieved by the reference player, when playing multiperiod streams.

@epiclabsDASH
Copy link
Contributor

epiclabsDASH commented Jul 4, 2019

I will send a PR in the next few hours fixing this + extra improvements.

@epiclabsDASH
Copy link
Contributor

@PolynomialDivision, already fixed in the PR I am preparing for v3.0.1. Still not published because I am including on it other fixes related with timing. I will let you know once finished.

No later than early next week so it is ready for the code freeze for v3.0.1.

@PolynomialDivision
Copy link
Author

Actually, is this now fixed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants