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

Checks MediaSource.activeSourceBuffers and changes to track state #3182

Conversation

tidoust
Copy link
Contributor

@tidoust tidoust commented Jun 15, 2016

The tests only cover the configurations required by the specification, namely:

  • one SourceBuffer with one audio and/or one video track
  • one SourceBuffer with an audio track and one SourceBuffer with a video track

The tests do not try to create more SourceBuffer objects in particular and do not create text tracks.

The tests should cover all steps in section 2.4.5 "Changes to selected/enabled track state":
https://w3c.github.io/media-source/#active-source-buffer-changes

Note that Edge apparently does not yet support resetting the delaying-the-load-event-flag of the media element, and does not want to reach HAVE_CURRENT_DATA for video-only tracks, unless "endOfStream()" is called. This makes the test harness time out in some cases (because the "load" event is not fired on "window"), even though the underlying test cases actually pass. If needed, I may add calls to "mediaSource.endOfStream()".

…state

The tests only cover the configurations required by the specification, namely:
- one SourceBuffer with one audio and/or one video track
- one SourceBuffer with an audio track and one SourceBuffer with a video track

The tests do not try to create more SourceBuffer objects in particular and do
not create text tracks.

The tests should cover all steps in section 2.4.5 "Changes to selected/enabled
track state":
https://w3c.github.io/media-source/#active-source-buffer-changes
@hoppipolla-critic-bot
Copy link

Critic review: https://critic.hoppipolla.co.uk/r/6628

This is an external review system which you may optionally use for the code review of your pull request.

In order to help critic track your changes, please do not make in-place history rewrites (e.g. via git rebase -i or git commit --amend) when updating this pull request.

@wpt-pr-bot
Copy link
Collaborator

Reviewers for this pull request are: @acolwell, @bit, @shishimaru, @sideshowbarker, and @wolenetz.

@wolenetz
Copy link
Member

I'm reviewing this now. Apologies for delay while I had been working on the MSE spec issue drive-down.

assert_equals(mediaSource.activeSourceBuffers.length, 0,
"activeSourceBuffers is empty to start with");

test.expectEvent(mediaElement, "loadedmetadata");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It shouldn't matter much, but the actual sequence of these events being enqueued is: addsourcebuffer first, then loadedmetadata later once the first init segments across all sourcebuffers has appended and parsed. I'll swap the ordering as part of merging this.

@wolenetz
Copy link
Member

This PR LGTM modulo the comments I added. I'll merge it with commit(s) that address my comments shortly.
@jdsmith3000 Please note @tidoust had an Edge-specific comment, above:

Note that Edge apparently does not yet support resetting the delaying-the-load-event-flag of the media element, and does not want to reach HAVE_CURRENT_DATA for video-only tracks, unless "endOfStream()" is called. This makes the test harness time out in some cases (because the "load" event is not fired on "window"), even though the underlying test cases actually pass. If needed, I may add calls to "mediaSource.endOfStream()".

@wolenetz
Copy link
Member

It looks like tip-of-tree Chrome with --enable-experimental-platform-features is failing the latter two tests because the sourceBuffer.{audio,video}Tracks "change" expectation isn't met. I'll investigate further and fix one or both of these tests and Chrome.

@wolenetz
Copy link
Member

wolenetz commented Aug 19, 2016

Investigating per #3182 (comment), the test looks right, Chrome needs fixing (only HTMLMediaElement.{audio,video}Tracks lists get the 'change' events, not SourceBuffer.{audio,video}Tracks, when selected/enabled track state changes). I've filed https://crbug.com/639151 to get Chrome compliant with 'change' events on SourceBuffer.{audio,video}Tracks.

edit: That same Chrome bug tracks the other implementation issue exposed by this test: MediaSource.activeSourceBuffers needs to get appropriate '{add,remove}sourcebuffer' events when track enable/select state changes require those events per the MSE spec.

I'll merge this PR with additional commit(s) that address my comments shortly.

wolenetz added a commit to wolenetz/web-platform-tests that referenced this pull request Aug 19, 2016
@wolenetz
Copy link
Member

I've addressed all my PR review comments and pushed a PR #3497 (which replaces this PR) which I'll merge shortly.
Thank you, @tidoust, for contributing the bulk of this new test.

@wolenetz wolenetz closed this Aug 19, 2016
wolenetz added a commit that referenced this pull request Aug 19, 2016
…rceBuffers-attribute

@wolenetz completion of @iDoust PR #3182 - Checks MediaSource.activeSourceBuffers and changes to track state
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants