- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 May 2021 17:56:35 +0000
- To: public-webrtc-logs@w3.org
I ran a test with Firefox, Safari and Chrome to see how they're handling this nowadays. The test consists in the following steps: 1. Assign a MediaStream with an audio track and no video track to a video element. 2. Add a video track to the MediaStream assigned in step 1. 3. Remove the video track from the MediaStream assigned in step 1. 4. Add the same video track again to the MediaStream assigned in step 1. Firefox and Chrome behave the same. They don't run the full load algorithm and fire the "resize", "canplay" and "playing" events on step 2. They don't fire any events on step 3 and 4. If the track added in step 4 has a different size, "resize" is fired. Safari fires "resize", "loadedmetadata" and "canplay" on step 2; fires "resize" on step 3; and fires "resize", "loadedmetadata" and "canplay" again on step 4. I guess the reason for the resize events in step 3 and 4 for Safari is that it internally changes the size on track removal while Chrome and Firefox do not. Given that Firefox and Chrome coincide and that seems to match the media element spec, I think we should considered that behavior as correct. Not sure if that requires changes to the latest version of the spec. -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/453#issuecomment-837051373 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 May 2021 17:56:37 UTC