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

MediaStreamTrack does not dispatch "ended" event at Chromium when src of HTMLMediaElement is changed, Firefox does dispatch "ended" event; which implementation is correct? #78

Closed
guest271314 opened this issue Apr 27, 2019 · 8 comments

Comments

@guest271314
Copy link

At Chromium 73 ended event is not dispatched at HTMLVideoElement when src attribute is changed. mute event is dispatched at Chromium 73. Firefox 68 does dispatch ended event when src attribute of HTMLVideoElement is changed. Chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=957340.

Relevant specifications:

https://www.w3.org/TR/mediacapture-fromelement/

A captured MediaStreamTrack ends when playback ends (and the ended event fires) or when the track that it captures is no longer selected or enabled for playback. A track is no longer selected or enabled if the source is changed by setting the src or srcObject attributes of the media element. The steps in MediaStreamTrack.stop() are performed on the MediaStreamTrack when it ends.

https://www.w3.org/TR/mediacapture-streams/

A MediaStreamTrack object is said to end when the source of the track is disconnected or exhausted.

When a MediaStreamTrack track ends for any reason other than the stop() method being invoked, the User Agent MUST queue a task that runs the following steps:

1. If the track's readyState attribute has the value ended already, then abort these steps.

2. Set track's readyState attribute to ended.

3. Notify track's source that track is ended so that the source may be stopped, unless other MediaStreamTrack objects depend on it.

4. Fire a simple event named ended at the object.

Related:

#77

Which implementation of the specifications is correct?

@guidou
Copy link

guidou commented May 9, 2019

This is known bug in Chromium (https://crbug.com/854991).
That said, one of the reasons we haven't fixed it in Chrome is that there some mismatch in how the ended attribute is defined in mediacapture-main and how it is defined in HTML.
In mediacapture-main it is considered an attribute that can be directly set/unset.
In HTML it is not defined as an attribute to be arbitrarily set by the implementation, but instead it is defined in terms of the readyState, current playback position, direction of playback, the loop attribute and direction of playback.
Of course, one way to implement it is to completely ignore the HTML rules when the element is playing a MediaStream, but I would like to see more alignment with the HTML definition.

@guest271314
Copy link
Author

@guidou

but I would like to see more alignment with the HTML definition.

That is the purpose of filing this issue and w3c/mediacapture-main#583. While english is an equivocal language, capable of having differing definitions for the same term, technical specifications should try to avoid ambiguity where possible; e.g., muted at HTML and MediaStreamTrack where the two definitions of the term muted could be adjusted to be consistent with each other.

From perspective here (front-end) when an HTMLMediaElement srcObject is set to a MediaStream instance the muted, ended attributes/properties output should be derived (first) from the MediaStream/MediaStreamTrack, not the HTMLMediaElement - as the media resource is the MediaStreamTrack

@guidou
Copy link

guidou commented May 9, 2019

This issue and the muted attribute issue are completely different.
The ended attribute referred to here is part of HTML media element, so I think mediacapture-main shouldn't override the element definition.

Issue #583 is about attributes with the same name but on different types and I don't see why they should match, especially when a media element can have a mediastream with multiple tracks, some muted and some not muted.

Anyway, I think we should close this bug since the question was which implementation is correct and the answer is that the Firefox implementation matches the spec and Chrome's implementation doesn't. Concerns about the HTML ended attribute can be discussed in other bugs such as #536 and others linked from there.

@guidou
Copy link

guidou commented May 9, 2019

Note that there was a misunderstanding on my part since I thought this bug referred to the ended event and attribute of the HTML element in mediacapture-main, but this is about mediacapture from element. I'll check the issue again and will get back to you.

@guidou
Copy link

guidou commented May 14, 2019

The spec says

A captured MediaStreamTrack ends when playback ends (and the ended event fires) or when the track that it captures is no longer selected or enabled for playback. A track is no longer selected or enabled if the source is changed by setting the src or srcObject attributes of the media element.

So this makes it clear that the Firefox behavior is spec compliant and Chrome's is not.
Since this refers to the track's ended event and not the element's, none of my concerns about the way the element ended event is defined in w3c/mediacapture-main apply.

@guest271314
Copy link
Author

@guidou Just wanted to confirm that Chromium/Chrome implementation of onmute, onunmute and onended is not reliable.

Found another Chromium bug that will file shortly. When a <video> captureStream() method is called before src is set and the captured stream is passed to MediaRecorder the addtrack event is occasionally not dispatched when src of HTMLVideoElement is changed.

@guest271314
Copy link
Author

@guidou MediaStream not dispatching addtrack event https://bugs.chromium.org/p/chromium/issues/detail?id=963018.

If you find the time could you also look into the ongoing issue of Chromium tab crashing when captureStream() is called on a <video> element where src is set to a MediaSource instance (https://bugs.chromium.org/p/chromium/issues/detail?id=820489; https://bugs.chromium.org/p/chromium/issues/detail?id=943484)?

@jan-ivar
Copy link
Member

From #78 (comment) it sounds like Firefox's implementation is the correct one.

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

No branches or pull requests

3 participants