1588840 - Add WPT for HTMLMediaElement ending as its MediaStream becomes inactive/inaudible

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, task, P3)

Description

[Andreas Pehrson [:pehrsons]]

I don't see WPT for this in the mediacapture-streams suite. We should add some.

Comment 1

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1588840 - Add WPT for when HTMLMediaElement with a MediaStream should report and fire ended. r?jib

This adds four test cases:

• HTMLVideoElement playing a video track, ending through the track ending.
• HTMLAudioElement playing an audio and a video track, ending through the audio
  track ending.
• HTMLVideoElement playing a video track, ending through the track being
  removed.
• HTMLAudioElement playing an audio track and a video track, ending through the
  audio track being removed.

All test cases test the timing of when the HTMLMediaElement starts reporting
true for its ended attribute, and the timing of the ended event.

Comment 2

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1588840 - Make ended return true after reaching the event loop's step 1 when playing a MediaStream. r?jib

This is especially important for media elements playing MediaStreams, since the
streams can be manipulated to end playback of the elements synchronously by
either stopping or removing their tracks.

Depends on D49384

Comment 3

[Andreas Pehrson [:pehrsons]]

This is blocked on clarifying the details of how a HTMLMediaElement with a MediaStream should fire ended, and when to start returning true for its ended attribute. We already have a spec bug on file for this.

Comment 4

[Andreas Pehrson [:pehrsons]]

The patches reflect what I think is the right behavior, given the HTMLMediaElement spec and my interpreted intent of the mediacapture-streams spec.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/28ed0836d698
Add WPT for when HTMLMediaElement with a MediaStream should report and fire ended. r=jib
https://hg.mozilla.org/integration/autoland/rev/0efd3fc716c4
Make ended return true after reaching the event loop's step 1 when playing a MediaStream. r=jib

Comment 6

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/20124 for changes under testing/web-platform/tests

Comment 7

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 8

[guest271314]

Attachment: CanvasCaptureMediaStreamTrack, muted, timeupdate

@Pehrson

Are you also investigating the case of a `CanvasCaptureMediaStream` set as `srcObject` to an `HTMLVideoElement` where `mute` should be fired?

Consider

Comment 9

[guest271314]

@Pehrson

Are you also investigating the case of a CanvasCaptureMediaStream set as srcObject to an HTMLVideoElement where mute should be fired?

Consider the attached file "CanvasCaptureMediaStreamTrack, muted, timeupdate" where only 1 frame is drawn onto the <canvas>. Chromium fires mute event on the CanvasCaptureMediaStreamTrack after several seconds. Firefox continues playback, firing timeupdate event even though no frames are being drawn onto the <canvas>. Which implementation is correct per specification(s)?

Comment 10

[Andreas Pehrson [:pehrsons]]

Firefox is correct. Feel free to file a spec bug for clarification. I'll hide these comments now as they're off topic.

Comment 11

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/28ed0836d698
https://hg.mozilla.org/mozilla-central/rev/0efd3fc716c4

Comment 12

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot