search

vladikoff / chromeos-apk

☢️ Run Android Apps in Chrome OS OR Chrome in OS X, Linux and Windows.
MIT License
7.76k stars 931 forks source link

Limelight Gamestream (RTSP not working) #87

Open dvdmuckle opened 10 years ago

dvdmuckle commented 10 years ago

Limelight, a hack of the Nvidia shield gamestream software, now... kinda works on the Android Chromebook and ARChon runtime. The problem is, the RTSP handshake fails, and I'm pretty sure it's because, according to this screenshot screenshot 2014-10-04 at 1 26 09 pm the protocol is "not available." Is there any way to get RTSP streaming to work with this app or is it a dead end?

vladikoff commented 10 years ago

I spent a bit of time debugging similar connectivity issues. However not much progress yet, I will keep you updated.

cgutman commented 10 years ago

Hi, Limelight developer here.

The RTSP connection is merely a normal TCP connection (using the Java Socket class) that I'm sending RTSP messages over. The only thing possibly different that I'm doing than other apps using sockets is calling Socket.setTcpNoDelay(true) on my socket. Socket.setTcpNoDelay() triggers a call to setsockopt() (the BSD socket API function) to set TCP_NODELAY. ENOPROTOOPT is returned if the protocol doesn't support the option being passed in.

I'm going to try to get a repro on a local machine to confirm that this is what's going on.

Here's a link to the offending code in Limelight-common: https://github.com/limelight-stream/limelight-common/blob/master/src/com/limelight/nvstream/rtsp/RtspConnection.java#L50

Update: confirmed that the setTcpNoDelay() call is what's raising the SocketException as I thought.

dvdmuckle commented 10 years ago

Thank you very much for the help. Judging from cgutman's comment, the app is not compatible with the Chromebook Android Runtime, correct? Or is there anyway to alter the app to work with the Chromebook?

cgutman commented 10 years ago

I've done some testing and there is a real bug here. On Android and Windows/OSX/Linux, calling setTcpNoDelay() on an unconnected socket is perfectly legal. On ARC, it causes a SocketException.

If I call setTcpNoDelay() after connect(), then I'm able to at least establish a connection. It appears that native libraries don't work, even though I have libraries for x86 and x86_64. If I disable audio to avoid the native library issue, the mouse is wonky and gamepad doesn't work so it's not much use.

The good news is that there's apparently an OMX.ARC.H264.Decoder that uses hardware-accelerated decoding.

dvdmuckle commented 10 years ago

From what it sounds like, a version of Limelight would have to be made specifically for Chromebook.

dvdmuckle commented 10 years ago

The ARChon run-time has a folder in which extra files can be added for further app support, correct? Could that be used somehow?

vladikoff commented 9 years ago

@cgutman would you be willing to file an ARC bug at https://code.google.com/p/chromium/issues/list?can=2&q=arc&colspec=ID+Pri+M+Week+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles (Tagged Platform-ARC) regarding setTcpNoDelay(). If that gets fixed then it may be easier to proceed from there.

Olympuserver commented 9 years ago

Any progress on this?

@cgutman were you able to file an ARC bug to avoid the socket exception? Or is that not really needed?