Open woowe opened 5 years ago
turning off Hardware-accelerated video decode
in chrome://flags took the video buffer time to ~40ms
What make and model Chrome OS device do you have?
On Sat, May 4, 2019, 6:02 PM woowe notifications@github.com wrote:
turning off Hardware-accelerated video decode in chrome://flags took the video buffer time to ~40ms [image: Screenshot 2019-05-04 at 5 02 00 PM] https://user-images.githubusercontent.com/14899481/57185305-5f9c4900-6e8e-11e9-85b3-99aff93ffc2f.png
ā You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/RainwayApp/bug-tracker/issues/331#issuecomment-489369039, or mute the thread https://github.com/notifications/unsubscribe-auth/ABVT472AT5ZIH2RQIGZ7FFTPTYBXFANCNFSM4HKZZWZA .
@BetaLeaf Google Pixelbook IntelĀ® Coreā¢ i5, 8GB RAM, 256GB SSD https://store.google.com/us/config/google_pixelbook
I'm a bit confused. If I understand the description of Shadow correctly, they basically do what Rainway does, but for a PC in the cloud rather than a PC in your home. So why would you want to use Rainway to play games that are installed on a Shadow cloud gaming instance? The Shadow cloud gaming instance already allows you to play those games from, according to their website anyway, all your devices. Seems redundant. Am I missing something?
@apecoraro I absolutely see where you are coming from. It does kinda seem a bit redundant and I wish I didn't have to use another layer in between me and the shadow PC! Unfortunately the shadow pc software really only works well on Windows and while ChromeOS can run Andriod apps, the Shadow PC one doesn't work at all on ChromeOS for me.
So I thought I would give Rainway a try since really it is the peak of convenience for me in terms of remote access of a remote computer, being in a browser.
All that being said a Pixelbook on ChromeOS should be more or less the perfect device for Rainway since Chrome is so optimized for this device and the fact that it is not producing the results that you would expect with a hardware accelerated browser optimized device is interesting at least. So I thought it would be good to submit a bug!
I see, thanks for the explanation. Have you tried lowering the level of detail settings? On the client's Settings tab there are three different settings, Quality, Framerate, and Stream Scaling. If the Shadow PC is having trouble encoding the video fast enough or conversely your client device is having trouble decoding the video fast enough, then lowering Quality and Framerate should help. If the issue is the bandwidth between your Shadow PC and your client device, then all three of those settings will help. Try putting them all at the lowest setting. Hopefully you should be able to get acceptable performance with all settings at the lowest level. Next step would be to figure out which setting is the one that is the bottleneck in the performance.
To do that start by increasing the Stream Scaling one level at time until you get to max level (i.e. no scaling). If messing with the Stream Scaling has no effect on the performance then it is likely that the encoding and/or decoding is taking too long. So in that case, next try increasing the Frame Rate setting separately. Then try Quality separately. Then try tinkering with both at the same time until you find a pair of settings that works for you.
Also for mouse jumpiness, try turning on mouse capture, if you haven't already (Ctrl-Shift-C).
Can you go to "chrome://flags" and enable any flags with "Mojo," especially the Mojo video deocder?
Quality | Framerate | Stream Scaling | Video Buffer | Latency |
---|---|---|---|---|
Low | 30 | 640x480 | 210 | 30 |
Low | 30 | 1280x720 | 205 | 30 |
Low | 30 | 1600x900 | 200 | 40 |
Low | 30 | Disabled | 175 | 40 |
Medium | 30 | 640x480 | 200 | 30 |
Medium | 30 | 1280x720 | 190 | 35 |
Medium | 30 | 1600x900 | 200 | 40 |
Medium | 30 | Disabled | 170 | 35 |
High | 30 | 640x480 | 200 | 40 |
High | 30 | 1280x720 | 205 | 35 |
High | 30 | 1600x900 | 200 | 35 |
High | 30 | Disabled | 180 | 40 |
Low | 60 | 640x480 | 255 | 40 |
Low | 60 | 1280x720 | 265 | 35 |
Low | 60 | 1600x900 | 245 | 40 |
Low | 60 | Disabled | 100 | 40 |
Medium | 60 | 640x480 | 230 | 40 |
Medium | 60 | 1280x720 | 250 | 35 |
Medium | 60 | 1600x900 | 205 | 40 |
Medium | 60 | Disabled | 110 | 40 |
High | 60 | 640x480 | 255 | 40 |
High | 60 | 1280x720 | 235 | 40 |
High | 60 | 1600x900 | 170 | 40 |
High | 60 | Disabled | 100 | 35 |
These were some results that I have put together, reduced the number of stream scales that i did though to keep the permutations down to a reasonable level.
It seems to suggest that the video scaling might have something to do with this. I find it extremely interesting that in terms of video buffer, scaling down the the lowest resolution consistently have me the highest video buffer times.
60 FPS performed seemingly the same as 30 FPS but I was not able to interact with anything like I was with 30 FPS (albeit very lagged). I checked my windows PC running shadow and the cursor was jumping absolutely everywhere. Just another interesting find.
As a bit more exploring I installed rainway on to my windows PC to see if the Shadow PC had anything to do with the experience (doubtful). Alas I was unable to do remote desktop or play a game, but that is out of the scope of this issue i guess. The thing has an intel integrated GPU so I am not too worried about it.
@Codeusa I did find some flags! Out-of-process system UI (mash) -> default In-process window service (SingleProcessMash) -> default Mojo-based IMF to bridge the client and IME -> default Media Session Service -> default
It seemed to me the single process mash and the out-of-process mash would conflict if both are enabled so I avoided it. I tried:
Out-of-process system UI (mash) -> enabled In-process window service (SingleProcessMash) -> default Mojo-based IMF to bridge the client and IME -> default Media Session Service -> enabled
No luck, still same results and then:
Out-of-process system UI (mash) -> default In-process window service (SingleProcessMash) -> enabled Mojo-based IMF to bridge the client and IME -> enabled Media Session Service -> enabled
Still, no luck.
Attached are some logs from my console, from the 2 different rainway hosts i tried shadow-pc-rainway.log local-network-rainway-attempt.log
I forgot to mention that turning off the hardware accelerated video decode in chrome flags gave me a video buffer of about 60ms on high quality, 30 fps, 1920x1080 (no scaling)
A large video buffer indicates that your client is having trouble decoding video fast enough to keep up with the stream (more buffer equals more latency. Also, the fact that the buffer shrinks (indicating the decoding performance is better) is, in our opinion anyway, a bug in Chrome. We've reported it to Google several times in the past.
Pixelbook ChromeOS stable very laggy
Rainway on pixelbook is extremely laggy.
Steps
What happens
Video is extremely laggy, mouse jumps all over the place, huge slow downs almost as if the video is going in slowmotion
What is expected
A bit of input lag but little to no video lag
Host
Browser
Logs
Edit 1 - Also this was tested on stable, beta, and dev channels at the time of this writing