Open tobi512 opened 8 years ago
There must be a regression as this was working before. Is the Selfie example app also not worming anymore?
https://github.com/EricssonResearch/openwebrtc-examples/tree/master/ios/Selfie
@stefanalund Selfie can only show the two cameras and not stream them via WebRTC, right? Are we talking about the same meaning of "streaming" here? 😄 What I meant was definitely sending the stream via WebRTC and there were always problems regarding the back camera as far as I can remember...
Any thoughts on my question regarding the camera change during a running stream?
@tobi512 yes, Selfie only shows the camera stream locally but it is using the same API's as for doing a remote WebRTC session. Unless there is a bug (regression) it should be possible to use the same API for setting the camera source also for remote sessions.
Thanks for the quick answer! @stefanalund
I'll check everything again at work tomorrow and come back at you, but I'm pretty sure setVideoCaptureSourceByName
only sets the local source and not the remote...
The local stream should™️ be the basis for the remote stream...
@stefanalund Sorry for the late reply... I just tested with the current NativeDemo and sadly did succeed in even making a video connection using demo.openwebrtc.org:
On Chrome I get OperationError: Error processing ICE candidate OperationError: Failed to set remote offer sdp: Called in wrong state: STATE_SENTOFFER
On Firefox InvalidStateError: Cannot add ICE candidate in state stable
.
Are there any known errors at the moment? Couldn't verify my issue therefore...
I have tested between ios nativedemo and chrome. Unluckily, i get the same error "OperationError: Error processing ICE candidate" in chrome after i press "call" in ios nativedemo. May i ask if there is any solution to tackle this problem? Thx
Hey OWR-Team, we're currently working with OWR in a productive project and therefore investigating on problems with the back camera. On the current state, the back camera cannot be streamed, since
prepare_media_sessions_for_local_sources
has a booleanhave_video
that prevents the seconds video device from being prepared inprepare_media_session_for_source
. If we hardcode the index for the back camera intoprepare_media_sessions_for_local_sources
, so it's being prepared instead of the front camera (which is normally the first device), the video of the back camera is correctly sent to the remote. So, from my perspective, both cameras must be prepared (into 2 different media sessions?!) and the methodsetVideoCaptureSourceByName
should also update the camera that is sent and not only the one thats shown locally. I'm willing to work on a solution for this, if I get support from your side (especially about the basic idea of the fix)! @superdump @stefanalund Are you aware of the problem and do you agree on my solution idea?PS: What steps are necessary for a camera change while the stream is running (new session description etc.?)
Thanks in advance!