No video transmitted/recorded due to very low bitrate

[q-kit]

• I have verified that the issue occurs with the latest twilio-video.js release and is not marked as a known issue in the CHANGELOG.md.
• I reviewed the Common Issues and open GitHub issues and verified that this report represents a potentially new issue.
• I verified that the Quickstart application works in my environment.
• I am not sharing any Personally Identifiable Information (PII)
  or sensitive account information (API keys, credentials, etc.) when reporting this issue.

Expected behavior:

Both video and audio should be properly transmitted and recorded.

Actual behavior:

One of our users joined a group room from an iOS 15.3.1 device. His audio sounds OK, while his video turned out to be a black screen, and the video record is also all black screen. As far as I can see from the video troubleshoot, the bitrate of his audio track is about 20kbps while that of his video track is less than 10kbps. Can anyone help with identifying the issue? I can provide the room SIDs if needed. Thanks!

Software versions:

• Browser(s): Safari
• Operating System: iOS 15.3.1
• twilio-video.js: 2.18.1
• Third-party libraries (e.g., Angular, React, etc.): vue.js

[PikaJoyce]

Hi @q-kit,

Thanks for opening this issue with us. Could you please provide some room sids for us to investigate further?

Best,
Joyce

[q-kit]

Hi @q-kit,

Thanks for opening this issue with us. Could you please provide some room sids for us to investigate further?

Best, Joyce

Hello Joyce,

Thanks for looking into this issue! Below are the room SIDs. Please let me know if anything else is needed from my end.

RMdc540de9c9d3a6eb6983c01362daee18
RM282c09b749f2014b6413ce2650513423
RM4b8fe4ddf4bc6aade62c55ab1564042b
RM2039613f994834ff363f0002e907d94f

Thanks!

Q

[PikaJoyce]

Hi @q-kit,

Thanks for getting back to me with all of the room sids. I've checked them out and it seems that the iOS user gets a 53002 error in every room also as a result of potentially unstable network. This could be a result of our trackSwitchOff API. You can read more about it here.

Does this sound like what you may be encountering?

Best,
Joyce

[q-kit]

Hello Joyce,

Thanks for the investigation!

While troubleshooting those rooms, all I can rely on is the Insights/Troubleshoot tool under the console, which didn't show any error like the 53002 one. Is there any other tool that provides more detailed logs like what you checked?

Thanks!

Q

[PikaJoyce]

Hi @q-kit,

No worries! There sure is! It's called the Video Insights. You can implement the Room Monitor directly in your app as well to do some real time debugging. Hopefully it'll be useful to you. With that being said, it should be detected within insights and accessible from within the dashboard.

Please let me know if your issue is a result of trackSwitchOff as well!

Thanks,
Joyce

[q-kit]

Hello Joyce,

Thanks for the info!

I was actually looking at the Video Insights of the 4 rooms listed above, but I didn't see any issue reported there, so I was wondering from where you were able to get the 53002 error code, and if that kind of detailed log is accessible to me.

Thanks for introducing Room Monitor! I'll integrate it to my app.

For now, I'm not quite sure if the issue is due to trackSwitchOff, will dive deeper and then get back to you later.

Thanks!

Q

[q-kit]

Hello Joyce,

I've gone through the doc on trackSwitchOffMode, and learnt that it watches the downlink and switches off video tracks when the downlink bandwidth is predicted to be insufficient.

To my understanding, this may not be the root cause of my issue. Our use case is like a presentation. There is a presenter publishing webcam video, audio and data track, and multiple subscribers publishing only data track for most of the time. The issue is that the video published by the presenter had very low bitrate, and I can replicate it as the presenter with throttled uplink bandwidth. I tried changing the bandwidth profile of the presenter to presentation mode, and made the presenter the dominant speaker. It did make some difference. Before the change, when the uplink bandwidth of the presenter is limited to 400kbps, then subscribers got no video from the presenter, while after the change, the subscribers can see the presenter video in lower quality. So, I guess that the bandwidthProfile.mode rather than the trackSwitchOffMode is the key to this issue.

Please let me know your thoughts. Thanks!

Q

[q-kit]

@PikaJoyce ^^

[PikaJoyce]

Hi @q-kit,

Apologies for the delayed response. Thank you for looking into the documentation.

Please correct me if I'm wrong, so the issue here is that the user facing issues is experiencing low uplink bandwidth?
Is this also an issue that is only experienced by the iOS user?

It also seems like using presentation mode is a perfect fit for your particular issue. Are you still experiencing issues while using presentation mode?

With all of that being said, are you looking for high quality video with low uplink bandwidth on a mobile device?

Here is some extra documentation on enhancing the quality of your application that may be useful as well!

Thanks,
Joyce

[q-kit]

Hello @PikaJoyce ,

No worries and thanks for the reply! I should have @ you in my last reply.

I think that the issue has something to do with the uplink bandwidth since the video track published by the user had very low bitrate. So far, this issue has happened to 2 or 3 users, and all of them are iOS users, but I'm not 100% sure if it only happens to iOS users.

Switching to presentation mode seems to be working so far. I'll keep an eye on it, and will get back to you in case this issue happens again.

Thanks for sharing the extra document! That's actually where I found the presentation solution.

Q

[PikaJoyce]

Hi @q-kit!

Hm, I see. Well, I'm glad presentation mode is working out for you! Unfortunately, I can't reproduce this unless I have unstable network which makes sense why you may have users experiencing this. In cases with network instability, I find that the downlink bandwidth is also affected. For now, I'll be closing this issue and feel free to open a new one if you run into any other issues!

Thank you!

Best,
Joyce

[q-kit]

Hello @PikaJoyce,

Hope you're doing very well.

I see that this issue happened again today to room RM8a3d5c1da84153873362509520cee45f. This time, the user joined in presentation mode as the dominant speaker with standard dominant speaker priority. We have just upgraded the twilio-video.js SDK to the latest version (2.21.1).

Could you please reopen this issue for further investigation? Please let me know if anything is needed from my end.

Thanks!

Q

[PikaJoyce]

Hi @q-kit,

Thanks for commenting and providing a sid, I will begin my investigations shortly. I know we talked about it in the past, but I was wondering if the user in question is on the iOS device?

Best,
Joyce

[q-kit]

Hello @PikaJoyce,

Thanks for the quick response!

Yes, this user is on an iOS 15.4.1 iOS device. I also have another user who had similar issue 2 days ago (before my latest SDK upgrade), RMa34314011567d09137af92fda3662bf8, and he was on an iOS 15.3.1 device and twilio-video.js 2.18.1.

Hope this helps.

Q

[q-kit]

Hello @PikaJoyce,

Just want to share a new clue I found for RM8a3d5c1da84153873362509520cee45f. I listened to the video record (only audio recorded for this case), and heard that the user was saying that he could not see his face on the screen. Maybe something wrong with local video track on iOS device?

Hope this helps.

Q

[PikaJoyce]

Thanks @q-kit for the additional information.

I want to make sure that this is not an issue with bandwidth. By default, it's off. But since you've switched over to using presentation mode I have reason to believe that this might be what you're experiencing.

Another suggestion, going to revisit this again but could you see if this happens if you connect with trackSwitchOffMode: disabled.

Another question, could other participants in the room see the iOS user even if he could not see himself?

Regards,
Joyce

[q-kit]

Thanks @PikaJoyce for the suggestions!

Shall I try switching the dominantSpeakerPriority from standard to high? For the trackSwitchOffMode, I guess that the track was kept on since the bitrate of the video track was around 30kbps through out the session. To compare, the other user on 2.18.1 had video track with low bit rate in the first quarter of his session, and then 0 bitrate. I heard that 2.18.1 had an issue that closed track won't be reopened and this issue has been fixed in 2.21.1. Anyway, I can also try disabling trackSwitchOffMode to see if helps.

To answer the last question, no other participants were able to see the iOS user. In the media record of this user, no video was captured (it shows a black screen), but his voice was properly recorded.

Q

[q-kit]

Hello @PikaJoyce,

Hope that you had a great weekend!

I got some more examples of the low bitrate video as listed below. I'm also including the participant SIDs, all of them should be for a same user on iOS 15.4.1

RM931b1925dcf294a316375516d8e44e6c / PA38ae2678e1fc39bf9333c66bbc0e6599
RMf466251505476d0ada15a898b9e6c8bb / PAaf90f1907ff08d74e35a2f3bbebeb40d
RM90ef7fce375f80e54693aef12a508448 / PA3f821b6779ec4c00a5e9eb7a4e0fc0df
RM7b7ec419df0c0d0435a5836e02ea7a93 / PA63f5cd48683eb8fd3cec1dd22d26b323
RMd5490b8b8d34cb617072fc29a28ff953 / PA4332aee6131e44e948882412aea7f9a6
RMc6a6e743e4acc8a60c090224c0bf00d7 / PAe6851c39258117271cdc5c80070d6559
RM69f0de5acd20461b0b93cfd6d19d868b / PA05dfc95c1daf691b213721e62ff9f793
RM93f3786919f8cc3b92de925f220dca57 / PA0024359f20334dd7b3b761a1727feaaa

Please let me know if more info is needed from my end. Thanks!

Q

[PikaJoyce]

Hi @q-kit,

Thanks for getting back to me I'll inspect the logs when I can. Have you tried out the suggestions discussed earlier as well?

I am assuming that since it only happens to the iOS user and only under limited bandwidth conditions. Is there any possibility that particular user to increase their bandwidth somehow?

On top of that, could you perhaps also try some of the recommendations found on this doc? Namely, reconsidering the capture resolution (lowering this), as well as render dimensions. I am thinking that the solution may be to maximize the bandwidth usage here for the iOS user.

Best,
Joyce

[q-kit]

Hello @PikaJoyce,

I guess that there is no strong evidence for bandwidth limitation.

In our use case, in each room, there is only one presenter, so no one else would take over the bandwidth. In the above cases, the bitrate of the video sent by the presenter is around 30Kbps, which is pretty low, but might still be OK for VP8 video streaming as per this doc. So, if the video track works properly, even if the the bitrate is this much low, we may still be able to see some frozen/robotic frames instead of a black screen.

Based on that the user said he got a black screen for his selfie video, I suspect that the local video track may have some trouble with accessing the camera. Is there any log that may cover the errors in media tracks? Maybe I can also include preflight test in order to see if some error can be caught?

Thanks!

Q