Log in

[modim1425]

Thanks for reading!,

So, I've got a shakey p2p video chat between my Nexus S and Chrome browser test page implementing non-WebRTC OpenTok. I've got it working-ish using the labs Android API. Yes, yes, I realize that you won't have any specific answers about an experimental-phase API but maybe my problem is more with my strategy than with the API. Everything's fine until I go to switch from front camera to back camera at which point it's crashville. Obviously this is because the camera used by the session to create the publisher is no longer the same camera so I've tried disconnecting the Publisher, switching the camera, recreating the publisher using the new camera, then calling publisher.connect(), and again: crashopolis. Okay, so maybe because this is a p2p session and the disappearance and reappearance of the Nexus publisher looks like a 3rd peer trying to join (??).

I am a dim-witted, drooly, lumbering oaf completely capable of missing the bleeding obvious so I'd thought I'd ask you: am I missing something here? If I can make what I need into something solid here, my partner and I are looking to run with it and significantly upgrade our account. I am so so so close but I need to be able to switch cameras back and forth.

Any thoughts? Ideas? Even ruthless ridicule would be appreciated if it were followed by some help.

On a side note, tossing the odd helpful comment here and there on to the Android Hello World code wouldn't have actually brought about anyone's early demise, would it have? Just sayin'...

[charley]

When you mention that you're using a p2p session, does this mean to suggest that you're setting the p2p flag on your call to createSession in the server-side SDK? The p2p flag for Flash uses a Flash-proprietary technology that none of the mobile SDKs will be able to target, so that should be avoided.

Per camera switching, I have not spent enough time testing the unpublish-republish workflows, so if there's a crash there it's news to me and you should make a gist of your logcat. Per the API workflow itself, a Camera instance is immutably bound to the Publisher instance (for now - obviously this could use improvement). Unfortunately, this means that in the short-term you'll have to settle for unpublishing and republishing if your action calls for a camera swap.

[charley]

Oh, also! You bring up a good point about documentation. I committed a few inline notes to Android-Hello-World, but also there's javadoc for the SDK itself if you haven't already come across it:
http://opentok.github.com/opentok-android-sdk/
I generally try to keep this updated with whatever is in the master branch for the SDK.

[modim1425]

Yeah, I can't seem to get my test app on Android to republish with a different camera without crashing. My new thinking is to simply accept that the session from Android to browser is a "video-conferencing"-style session and see if Android can deal with having each camera as it's own publisher and making one or the other visible/active/whatever as needed.

Just one other thing I'm wrestling with right now is latency/lag time. Right now I've approx. 6 seconds of delay. It's enough to make it actually almost impossible for two people to converse. My proof-of-concept models' code is sloppy so I'm sure that some of it is my own fault but what things can I do to speed things up?

[charley]

We'll probably have to work together to get the multi-publisher approach to work. Frankly, I'd rather patch the Camera swap issue rather than force you through such a strange workflow.

Anyway, per latency, I've also started to notice poor latency with Android Publisher --> Flash Subscriber. I think that Flash might be overzealously buffering, because on the same network I can get both iOS and Android subscribers to playback with significantly lower latency. I'll keep drilling on this from my end, but if you're able to isolate conditions that are really bad (certain Android devices, application configurations (#subscribers vs. device CPU, etc.), network conditions, etc), it'll help us out a ton. Things you can do in the meantime:

* Stick to a minimum of widgets -- more stuff running on the device is less time for the media pipeline to process data.
* Hint sessions with your local IP address to get the closest possible media server (see createSession documentation on server-side SDK).
* Experiment with nonflash sessions to see where exactly the latency seems to be coming from.