Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upImprove implementation of media resource fetch algorithm #22433
Merged
Conversation
highfive
commented
Dec 12, 2018
|
Heads up! This PR modifies the following files:
|
highfive
commented
Dec 12, 2018
|
|
|
I filed #22434 for setting the EOS back |
|
r? @ceyusa |
|
@bors-servo try=wpt |
bors-servo
added a commit
that referenced
this pull request
Dec 12, 2018
Do not set player EOS. Set correct input size and only if it changes I have been observing inconsistent behaviors with my local tests depending of the media asset being played. I figured that we had two issues: - We were setting the player EOS as soon as we got the first [process_response_eof](https://github.com/servo/servo/blob/1046ae58a155d3f1ab4d011242a03a81a712f3c4/components/script/dom/htmlmediaelement.rs#L1596). This is fine only if there is a single request. But that's not the case for multiple range requests or for seeks. Setting the player EOS makes the player appsrc reject any new buffers, and that breaks playback. Figuring out when is the right time to set the player EOS won't be a straight forward task, so my suggested fix for now is to simply not set it for now. It is a cleanup step that it would be nice to have but it is not mandatory. - We were setting the input size more than once for multiple range requests and with the incorrect value. The fix uses the `content-length` or the `content-range` headers for single and range requests respectively. - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22433) <!-- Reviewable:end -->
|
r+ |
|
|
|
@bors-servo try=wpt |
bors-servo
added a commit
that referenced
this pull request
Dec 12, 2018
Do not set player EOS. Set correct input size and only if it changes I have been observing inconsistent behaviors with my local tests depending of the media asset being played. I figured that we had two issues: - We were setting the player EOS as soon as we got the first [process_response_eof](https://github.com/servo/servo/blob/1046ae58a155d3f1ab4d011242a03a81a712f3c4/components/script/dom/htmlmediaelement.rs#L1596). This is fine only if there is a single request. But that's not the case for multiple range requests or for seeks. Setting the player EOS makes the player appsrc reject any new buffers, and that breaks playback. Figuring out when is the right time to set the player EOS won't be a straight forward task, so my suggested fix for now is to simply not set it for now. It is a cleanup step that it would be nice to have but it is not mandatory. - We were setting the input size more than once for multiple range requests and with the incorrect value. The fix uses the `content-length` or the `content-range` headers for single and range requests respectively. - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22433) <!-- Reviewable:end -->
|
r+ \o/ |
ferjm
changed the title
…the network
|
It seems that try is happy. @bors-servo r=ceyusa |
|
|
bors-servo
added a commit
that referenced
this pull request
Dec 12, 2018
Improve implementation of media resource fetch algorithm I have been observing inconsistent behaviors with my local tests depending of the media asset being played. I figured that we had these issues: - We were setting the player EOS as soon as we got the first [process_response_eof](https://github.com/servo/servo/blob/1046ae58a155d3f1ab4d011242a03a81a712f3c4/components/script/dom/htmlmediaelement.rs#L1596). This is fine only if there is a single request. But that's not the case for multiple range requests or for seeks. Setting the player EOS makes the player appsrc reject any new buffers, and that breaks playback. Figuring out when is the right time to set the player EOS won't be a straight forward task, so my suggested fix for now is to simply not set it for now. It is a cleanup step that it would be nice to have but it is not mandatory. - We were setting the input size more than once for multiple range requests and with the incorrect value. The fix uses the `content-length` or the `content-range` headers for single and range requests respectively. - We were moving to the HaveEnoughData state if a fetch request succeded but no data was fetched from the network. - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22433) <!-- Reviewable:end -->
|
|
|
@bors-servo retry |
bors-servo
added a commit
that referenced
this pull request
Dec 12, 2018
Improve implementation of media resource fetch algorithm I have been observing inconsistent behaviors with my local tests depending of the media asset being played. I figured that we had these issues: - We were setting the player EOS as soon as we got the first [process_response_eof](https://github.com/servo/servo/blob/1046ae58a155d3f1ab4d011242a03a81a712f3c4/components/script/dom/htmlmediaelement.rs#L1596). This is fine only if there is a single request. But that's not the case for multiple range requests or for seeks. Setting the player EOS makes the player appsrc reject any new buffers, and that breaks playback. Figuring out when is the right time to set the player EOS won't be a straight forward task, so my suggested fix for now is to simply not set it for now. It is a cleanup step that it would be nice to have but it is not mandatory. - We were setting the input size more than once for multiple range requests and with the incorrect value. The fix uses the `content-length` or the `content-range` headers for single and range requests respectively. - We were moving to the HaveEnoughData state if a fetch request succeded but no data was fetched from the network. - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/22433) <!-- Reviewable:end -->
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
ferjm commentedDec 12, 2018
•
edited
I have been observing inconsistent behaviors with my local tests depending of the media asset being played. I figured that we had these issues:
We were setting the player EOS as soon as we got the first process_response_eof. This is fine only if there is a single request. But that's not the case for multiple range requests or for seeks. Setting the player EOS makes the player appsrc reject any new buffers, and that breaks playback. Figuring out when is the right time to set the player EOS won't be a straight forward task, so my suggested fix for now is to simply not set it for now. It is a cleanup step that it would be nice to have but it is not mandatory.
We were setting the input size more than once for multiple range requests and with the incorrect value. The fix uses the
content-lengthor thecontent-rangeheaders for single and range requests respectively.We were moving to the HaveEnoughData state if a fetch request succeded but no data was fetched from the network.
./mach build -ddoes not report any errors./mach test-tidydoes not report any errorsThis change is