opentok-react-native icon indicating copy to clipboard operation
opentok-react-native copied to clipboard

Lost reference to publisher camera

Open Carlosp16 opened this issue 7 years ago • 34 comments

After a time using the app in background or sometimes after a reconnect the publisher loss the reference to the camera. The audio still work for the publisher but the video is lost(Black screen). We don't received any errors in console. Any ideas to fix it?

Carlosp16 avatar Aug 09 '18 18:08 Carlosp16

@Carlosp16 This seems like a duplicate of the following: https://github.com/opentok/opentok-react-native/issues/141

Could you please check out the solution mentioned in the issue?

msach22 avatar Aug 13 '18 21:08 msach22

I think this is distinct from #141

We have an issue that is somewhat difficult to reproduce where a user may put the app in the background for some time, then restore the app to foreground, but their video is gone. It doesn't happen every time, sometimes the video comes back as expected. When it does disappear, toggling the video on/off doesn't have any effect - both users just see a black feed.

I should note that it's not only moving the app to the background. This happens occasionally while the users are in a session - but it has seemed to happen more frequently in the cases where one user leaves the app, then returns.

We've focused primarily on iOS - not sure about behavior on Android.

evillemez avatar Aug 14 '18 18:08 evillemez

@msach22 Ticket #141 is not related to this issue, because I have "Background Mode" capability activated on Xcode. While you are on a call and App goes into background mode the session is not being destroyed, the real problem is when the App comes into foreground again, for some reason the publisher video feed is gone (black screen), I tried forcing the publisher component to render again based on the AppState(Active, Inactive, Background) but no luck, once the app goes to background you lose the publisher video feed.

cmedinadeveloper avatar Aug 17 '18 15:08 cmedinadeveloper

@msach22 Any pointers on where we could look? Still haven't been able to figure this one out...

evillemez avatar Aug 30 '18 17:08 evillemez

@evillemez @cmedinadeveloper Apologies for the delay on this, will check this out and report my findings in the next few days!

msach22 avatar Sep 03 '18 02:09 msach22

@msach22 Cool man - thanks for taking a look. If there's any more info we can provide, let us know and we'll do what we can.

evillemez avatar Sep 03 '18 13:09 evillemez

@msach22 Hey, just checking in. Did you have any luck uncovering anything related to this? If there's any information we can provide, or something you would like us to try - please let us know and we'll do what we can.

evillemez avatar Sep 17 '18 16:09 evillemez

@evillemez Sorry for the delay, here's what I did and I'm still unable to see this issue:

  • Created a new RN project
  • Added this library
  • Added the code from https://github.com/opentok/opentok-react-native-samples/tree/master/BasicVideoChat
  • Ran it on my iPhone 7 device
  • Went into background and foreground many times and the SDK was able to reclaim the camera each time.

Is there any other information that might help dig deeper?

  • iOS version
  • iPhone version

Edit: When this does happen, how long has the app been in background mode? Are you still transmitting audio in the session or are you completely disconnected?

msach22 avatar Sep 19 '18 01:09 msach22

@evillemez Could you please email me at [email protected] with a recent sessionId where this happens? This will allow me to see if you are still sending video packets or not. I'm trying to see if the camera gets reclaimed but somehow it doesn't bubble up to the RN view.

You can also use Inspector to check out the video packets information

msach22 avatar Sep 19 '18 15:09 msach22

@msach22 Yeah - we can create a session to reproduce and reach out to you over email. Thanks so much!

evillemez avatar Sep 19 '18 17:09 evillemez

@evillemez Awesome, looking forward to it!

msach22 avatar Sep 19 '18 18:09 msach22

Any luck with this issue? Im facing the same one in SWIFT SDK for opentok. The publisher feed goes black sometimes when the app comes back to foreground.

devsujith avatar Sep 28 '18 12:09 devsujith

@devsujith No luck, this is still happening to us, we are not able to find a workaround

cmedinadeveloper avatar Sep 28 '18 13:09 cmedinadeveloper

Are you facing this issue each time the app is backgrounded and comes back to foreground? Or is it the scenario when the session window is reconnected once and then followed by background and resume?

devsujith avatar Sep 28 '18 14:09 devsujith

@devsujith This is happening to us on both cases

cmedinadeveloper avatar Sep 28 '18 19:09 cmedinadeveloper

Just a note that, for us, this seems to be an iOS only issue. On Android the video continues if the app is in the background. So switching back and forth doesn't seem to cause a problem.

evillemez avatar Oct 29 '18 14:10 evillemez

@msach22 Based on recent conversations, I started thinking about this again. Would force unmounting/remounting the publisher be an approach we should try if we can detect that video has been lost?

evillemez avatar Nov 03 '18 19:11 evillemez

@evillemez Yes, if you unmount and remount a publisher component, you will essentially remove the old publisher and create a new publisher.

msach22 avatar Nov 12 '18 16:11 msach22

@evillemez Is there a way to detect if video is lost. On android if camera is taken away by any other app like whatsapp video call, video stream freezes for me too

mmubasher avatar Nov 30 '18 18:11 mmubasher

Eh, that's tricky... my first guess would be to hook into Subscriber.videoNetworkStats and Subscriber.audioNetworkStats - you can see if the a/v bytes received stop changing, or go to zero. But, you also have to check if that was intentional or not, if your app allows users to disable their video.

evillemez avatar Dec 04 '18 15:12 evillemez

@evillemez Have you tried using AppState and unmounting and remounting the OTPublisher component?

If you can see that the publisher changed from background mode to foreground and they are not sending any videoNetworkStats, you can unmount and remount to create a new publisher instance

One more question, is this happening on all iOS devices or just specific ones?

msach22 avatar Dec 11 '18 19:12 msach22

@msach22 @cmedinadeveloper

I'm not sure if we've tried remounting the Publisher in the case of an app state change. I think we did, but it's been a while, my memory is fuzzy on this now... @cmedinadeveloper do you remember?

As far as I'm aware it's all iOS devices. We had shift our focus on to something else for a bit, but are coming back to this soon.

evillemez avatar Jan 23 '19 17:01 evillemez

@msach22 Hi everyone! Also face with this issue, when sometimes subscriber looks on black screen, but audio is still available. In my case this issue is reproducing even the publisher just publish the stream and rotate the device.

[In publish mode]: I was reproduce black screen when start stream with device portrait orientation, then put the device on leftLanscape mode, then put the device on the table to change device orientation to faceUp. The record orientation is portrait. switch recordOrientation { case .portrait: return .left case .portraitUpsideDown: return .right case .landscapeLeft, .faceUp, .faceDown: return .up case .landscapeRight: return .down case .unknown: return .up }

Also i have enabled publisher.audioFallbackEnabled = true And the screen of the network monitor when the stream freeze. PS. I use image buffer delegate and consume frames. Each frame from publisher is correct, not black. I think there is a problem with network or breaking of orientation?

<img width="1160" alt="screenshot 2019-02-01 at 13 19 22" src="https://user-images.githubusercontent.com/8685210/52117531-00c3fb00-2625-11e9-8983-ed4785ce1c65.png"

The last session where issue was reproduced "sessionId": "1_MX40NjE3NjQ5Mn5-MTU0OTAxODU1Nzc2N344RTF4SUpmd09QYjhHNWhPanBVTUtZWlB-fg" "archiveId": "a2d49121-988e-40b5-bc4a-b336013a5c89", "streamId": "C04E2079-F807-48BA-B1CC-D0F0B7BA950C", iOS 11.01(15A402) iPhone 6+

Rjayone avatar Feb 01 '19 10:02 Rjayone

For what it's worth, I'm still having this issue on iOS in the latest version, but I also still haven't been able to figure out a consistent way to reproduce it.

What I do know is that when this does happen the remote side still thinks the received stream has video.

evillemez avatar May 05 '19 01:05 evillemez

@evillemez I resolved my issue with black frames. The last steps i've made is add didDrop sampleBuffer: and reconfigure session with another preset.

https://paste.ofcode.org/VhwY9YEmnxqEqFbkepSb2N CameraController - the object that configure and manages AVCaptureSession

Rjayone avatar May 05 '19 10:05 Rjayone

@Rjayone - Link is broken. Can you share it again.

@msach22 - This issue is still happening. Checking on iPhone and iPad - iOS version- 12.1.4 - XCode 10.2. Any updates for the resolution?

@evillemez - Have you figured out any solution on this?

nagenderpratapqss avatar May 28 '19 06:05 nagenderpratapqss

@nagenderpratapqss We still don't have a solution, but we also still can't reliably reproduce the problem. It's odd, when it does happen, it happens consistently, but I still don't know what the initial trigger is.

evillemez avatar Jun 04 '19 15:06 evillemez

@evillemez Have you check if this issue happens also in a native iOS app using the latest Opentok SDK? Just wondering if it's related to opentok-react-native or it's a bug on the iOS SDK.

ggoldens avatar Aug 05 '19 14:08 ggoldens

@ggoldens I haven't tried this in a native iOS app, so I'm not sure.

We have seen (very rare) cases of this happening on Android also... but it was a while ago, with older versions of the lib, on old Android devices with other issues, so I'm honestly not sure it's relevant.

I wish I could reproduce this issue consistently, but still no luck.

evillemez avatar Aug 09 '19 18:08 evillemez

Here is a code i used. Hope its would be helpful :)

CaptureSettings.swift.zip

Rjayone avatar Sep 05 '19 15:09 Rjayone