Video freezes when moving the app to background

[andrew.n]

There is a small issue that I have after I start the streaming, If I move the app to background, and open another app etc, when I open the app again, the streaming view is frozen.

I tried to call muteVideo function on applicationWillResignActive, and call again unmuteVideo on applicationDidBecomeActive, but no luck.

But, if I call switchCamera after applicationDidBecomeActive, the video view resumes the streaming...

What is the best approach for this flow? How can I resume the video view without having to call switch camera twice?

 

[Max]

Good day

There is a small issue that I have after I start the streaming, If I move the app to background, and open another app etc, when I open the app again, the streaming view is frozen.

Unfortunately, we cannot reproduce the issue for stream publishing in Two Way Streaming example app: publishing view is not frozen after moving the app to background, opening other app (Safari e.g.) then restoring Two Way Streaming app.
Please check if you enable Background modes for your app, at least:
- Audio, AirPlay and picture in Picture
- Background fetch

 

[andrew.n]

Good day

Unfortunately, we cannot reproduce the issue for stream publishing in Two Way Streaming example app: publishing view is not frozen after moving the app to background, opening other app (Safari e.g.) then restoring Two Way Streaming app.
Please check if you enable Background modes for your app, at least:
- Audio, AirPlay and picture in Picture
- Background fetch

I enabled Background fetch as well (Audio, AirPlay and picture in Picture was already enabled) and I'm facing the same issue.
Regarding the demos, as I see you use RTCEAGLVideoView, I tried to replace with RTCMTLVideoView, but I couldn't make the demo project work.
Can you tell me if you have this issue when using RTCMTLVideoView?

Notes:
- a few weeks ago when I used RTCEAGLVideoView, I remember that I tested this use-case and everything worked fine.
- if I pull the control center menu, the view freezes but after I dismiss it, the video view resumes.. this freeze happen only when I move the app in background...

 

[Max]

We raised internal ticket WCS-2969 to investigate this use case with RTCMTLVideoView.
As workaround, you can use either RTCEAGLVideoView or switchCamera method.

 

[andrew.n]

Hello @Max
I just downloaded SDK version 2.6.6 for iOS and it seems that the app moving to background and foreground is not fixed :|...
Do you have a demo for this new release where I can check that the issue is fixed on your project?

 

[Max]

Good day.
We use TwoWayStreaming example with automatic switching to RTCMTLVideoView to display a video, if device supports this view. Please see details here
In our tests, video freezes when app is moved to background and then continues to play when app is restored to foreground.

 

[andrew.n]

@Max I did several tests today. And I came up with the following conclusion
It happens that on a debug configuration, the video view to unfreeze and works as respected in 1 of 5 cases. In a release configuration, it has like 3 of 5 cases to work properly.
Another thing that I saw is that if I pull the Notifications Center or Control Center, and push it back, the video view resumes without any issue.
This issue happens when I move the app in the background (open another app) and return to my app.

When I pull Notifications Center/Control Center or if I move the app to the background, the app events are calling:
applicationWillResignActive -> applicationDidEnterBackground
applicationWillEnterForeground -> applicationDidBecomeActive

Can you provide me more details about what was there the issue with the SDK in this case?
Do you register for those app events to refresh the view?
What if you can test your SDK in a new project, using XIBs/Storyboards and Swift?

I saw the demos updates on your repo, it looks like you just changed how to check if Metal is available for the device...

Also, when I move the app in the background I see this log:
[Snapshotting] Snapshotting a view (0x109b3b200, UIKeyboardImpl) that has not been rendered at least once requires afterScreenUpdates:YES.
Why this is displayed? Why do you need to snapshot the view before it goes to the background?

 

[Max]

We raised the new ticket WCS-3003 to investigate it.

What if you can test your SDK in a new project, using XIBs/Storyboards and Swift?

We're now testing Swift SDK wrapper in ticket WCS-2853. So we only tested background issues with Objective C SDK.

 

[Max]

I saw the demos updates on your repo, it looks like you just changed how to check if Metal is available for the device...

We've done some changes also in Objective C framework code.
We made some tests on SDK build 2.6.8, and the issue is not reproduced in Two Way Streaming example. Please provide your code sample to reproduce the issue using this private form.