NEW 221192
"A MediaStreamTrack ended due to a capture failure" occurs in 30 seconds after peer connection establishes
https://bugs.webkit.org/show_bug.cgi?id=221192
Summary "A MediaStreamTrack ended due to a capture failure" occurs in 30 seconds afte...
Vicky Cen
Reported 2021-01-31 17:18:12 PST
"A MediaStreamTrack ended due to a capture failure" error occurs on Safari in around 30 seconds after peer connection establishes. This error can be observed most likely in Safari on BigSur 11.1 and 11.0.1, especially when multiple callers in a call. When this error occurs, safari caller will see self video tile as black, but remote callers can still see and hear safari caller well. But it does not on every device. If on 1 device it happens, it's likely to happen every time, and if on another device it does not happen, it's not likely to happen on that device. Seems it's same issue with more details has been reported in this thread: https://github.com/twilio/twilio-video.js/issues/1281
Attachments
sysdiagnose (251.70 MB, application/x-gzip)
2023-01-30 19:37 PST, rychouwei
no flags
sysdiag file from IPhone 14 (312.95 MB, application/gzip)
2024-09-27 05:47 PDT, development
no flags
youenn fablet
Comment 1 2021-02-01 00:01:09 PST
Hi Vicky, Can you reproduce with STP? If you can reproduce it, would you be able to take a sysdiagnose and send it to me (youenn@apple.com)? (In reply to Vicky Cen from comment #0) > "A MediaStreamTrack ended due to a capture failure" error occurs on Safari > in around 30 seconds after peer connection establishes. This error can be > observed most likely in Safari on BigSur 11.1 and 11.0.1, especially when > multiple callers in a call. When this error occurs, safari caller will see > self video tile as black, but remote callers can still see and hear safari > caller well. If a local capture track gets ended, it seems strange that remote callers could still see the corresponding remote track. > Seems it's same issue with more details has been reported in this thread: > https://github.com/twilio/twilio-video.js/issues/1281 According the thread, this seems fixed in iOS 14.2
Vicky Cen
Comment 2 2021-02-02 21:50:17 PST
Hi Youenn, I can reproduce with STP and sent you the sysdiagnose. However, it seems on STP when the error shows, safari caller will get black self video tile and remote caller can't see the track, but still can hear. (sysdiagnose attached and send to your email) On Safari 14.0.2, I did see when the error shows, safari caller will get black self video tile but remote caller can both see and hear the safari user.
youenn fablet
Comment 3 2021-02-03 00:48:19 PST
Looking at sysdiagnose, some H264 encoding failures happen before capture starts failing.
Radar WebKit Bug Importer
Comment 4 2021-02-03 00:49:05 PST
youenn fablet
Comment 5 2021-02-08 00:55:12 PST
*** Bug 220998 has been marked as a duplicate of this bug. ***
youenn fablet
Comment 6 2021-10-19 00:35:27 PDT
Vicky, can you still reproduce this issue on recent Safaris?
Vicky Cen
Comment 7 2021-10-24 21:59:11 PDT
Hi youenn, my colleagues and I have very limited number of testing on the latest Safari (Safari 15). We haven't seen this issue on Safari 15 so far.
James Hall
Comment 8 2022-01-05 07:11:39 PST
Seeing it on Safari 15.(In reply to Vicky Cen from comment #7) > Hi youenn, my colleagues and I have very limited number of testing on the > latest Safari (Safari 15). We haven't seen this issue on Safari 15 so far.
Charlie
Comment 9 2022-10-21 10:58:40 PDT
Hi Youenn, We are seeing this on iPhone 14/iOS 16. Same reproduction steps. Do you have any updates on this? Thank you.
Brian Liu
Comment 10 2022-11-15 16:51:44 PST
Ya, we are seeing the same issue on iPhone 14/iOS 16.0 and 16.0.1, simply create a video & audio streams and attach to MediaRecorder, record a video then destroy the stream tracks, repeating create streams and destroy tracks few times trigger the error function stopStream(stream) { if (stream) { stream.getTracks().forEach((track) => { track.stop(); stream.removeTrack(track); }); } }
Dag-Inge Aas
Comment 11 2022-11-25 06:29:33 PST
Is it safe to assume this issue can be closed by this commit? https://github.com/WebKit/WebKit/commit/b818b253da1d92e9e5f802dea4a735b8adeb1994
youenn fablet
Comment 12 2023-01-20 02:17:42 PST
(In reply to daginge from comment #11) > Is it safe to assume this issue can be closed by this commit? > https://github.com/WebKit/WebKit/commit/ > b818b253da1d92e9e5f802dea4a735b8adeb1994 Not really, this issue is related to camera video tracks.
youenn fablet
Comment 13 2023-01-20 02:21:15 PST
(In reply to Charlie from comment #9) > Hi Youenn, > We are seeing this on iPhone 14/iOS 16. Same reproduction steps. Do you have > any updates on this? > > Thank you. @Charlie, can you give more precise repro steps? Is it the same as https://bugs.webkit.org/show_bug.cgi?id=247967?
rychouwei
Comment 14 2023-01-29 19:35:39 PST
We have the same issue. The system version is: Intel Mac OS X 10_15_7, Safari 15.4 After about 30s of successful webrtc peerConnection connected, MediaStream audioTrack gives this error: "A MediaStreamTrack ended due to a capture failure". We try to recapture the audioTrack with getUserMedia and use rtpSender.replaceTrack to try to resume the call, but once we call replaceTrack, the recaptured audioTrack comes back with the same error: "A MediaStreamTrack ended due to a capture failure". It only occurs in some devices and looks like it might be related to the system version.
youenn fablet
Comment 15 2023-01-29 23:01:13 PST
(In reply to rychouwei from comment #14) > We have the same issue. > > The system version is: Intel Mac OS X 10_15_7, Safari 15.4 > > After about 30s of successful webrtc peerConnection connected, MediaStream > audioTrack gives this error: "A MediaStreamTrack ended due to a capture > failure". > > We try to recapture the audioTrack with getUserMedia and use > rtpSender.replaceTrack to try to resume the call, but once we call > replaceTrack, the recaptured audioTrack comes back with the same error: "A > MediaStreamTrack ended due to a capture failure". > > It only occurs in some devices and looks like it might be related to the > system version. @rychouwei, can you send me a sysdiagnose (youenn@apple.com)? Are you able to reproduce the issue reliably with some steps or specific setups?
rychouwei
Comment 16 2023-01-30 19:00:27 PST
@youenn Is the guide in this link to get sysdiagnose? http://adcdownload.apple.com/OS_X/OS_X_Logs/sysdiagnose_Logging_Instructions.pdf I'll try.
rychouwei
Comment 17 2023-01-30 19:37:20 PST
Created attachment 464772 [details] sysdiagnose 1. At 11:08:28:203, MediaStream audioTrack is ended. 2. At 11:08:29:009, try getUserMedia to capture a new audioTrack. 3. At 11:08:30:505, try rtpSender.replaceTrack to replace the recaptured audioTrack. 4. At 11:08:30:511, the recaptured audioTrack is ended again.
rychouwei
Comment 18 2023-01-30 19:41:54 PST
@youenn The sysdiagnose is provided. please check! "Are you able to reproduce the issue reliably with some steps or specific setups?" One of our customer's Intel Mac OS X 10_15_7, Safari 15.4 can reproduce the issue reliably, from the process is the most basic webrtc communication process, no specific steps found for now.
Michalis
Comment 19 2024-06-21 11:05:38 PDT
I am able to reproduce this when having the default built-in Macbook pro M2 microphone selected in web-rtc enabled apps. For some reason it only happens with the default microphone only (e.g. other vendors are ok).
development
Comment 20 2024-09-27 05:42:14 PDT
Having the same issue "A MediaStreamTrack ended due to a capture failure" in our app for voice communication (IPhone 14 (pro also) IOS ver 17.7 on Safari/Chrome browsers, DuckDuckGo is ok). Older versions of IOS (15-16) on IPhone's 7-8 is ok with Safari. The issue happens only for second end next tries of voice recodring using MediaRecorder API. All desktop versions on Mac and other platforms (Windows, Linux) works ok. During second and next tries the stream generates zero-sized data blobs.
development
Comment 21 2024-09-27 05:47:29 PDT
Created attachment 472703 [details] sysdiag file from IPhone 14 This is an attachment for Comment #20
Note You need to log in before you can comment on or make changes to this bug.