Genymobile / scrcpy

Display and control your Android device
Apache License 2.0
108.77k stars 10.47k forks source link

Quality #2367

Open InterestingInterest opened 3 years ago

InterestingInterest commented 3 years ago

Hey there, sorry to bother you with this. I was just wondering, is scrcpy suited to watching video playback from a mobile device or is it not really for that?

I tried to play a stream through a Live Sports app on my phone, so I can view it on my laptop screen using scrcpy. The stream is set to HD, though my device resolution is 720x1280. When watching back, it's not as smooth as it should be, but worse than that, the quality is a bit poor. It doesn't really look 720p to me. I've got a screenshot to help show this.

https://i.postimg.cc/g07DLr9f/720.png

I have tried increasing the bitrate using scrcpy -b20M and tried changing the renderer to openGL. Could the issue just be on my end, or is my use case not what scrcpy is for?

Thanks!

Environment

rom1v commented 3 years ago

is scrcpy suited to watching video playback from a mobile device or is it not really for that?

Yes, it can. In practice, it's not often useful, since it does not forward sound though :)

I tried to play a stream through a Live Sports app on my phone, so I can view it on my laptop screen using scrcpy. The stream is set to HD, though my device resolution is 720x1280. When watching back, it's not as smooth as it should be, but worse than that, the quality is a bit poor. It doesn't really look 720p to me. I've got a screenshot to help show this.

What is the quality if you just record (without streaming)?

scrcpy -b20M --record file.mp4

If the resulting quality is good, then the streaming quality is the culprit (try to adjust the settings of your streaming software).

InterestingInterest commented 3 years ago

is scrcpy suited to watching video playback from a mobile device or is it not really for that?

Yes, it can. In practice, it's not often useful, since it does not forward sound though :)

I tried to play a stream through a Live Sports app on my phone, so I can view it on my laptop screen using scrcpy. The stream is set to HD, though my device resolution is 720x1280. When watching back, it's not as smooth as it should be, but worse than that, the quality is a bit poor. It doesn't really look 720p to me. I've got a screenshot to help show this.

What is the quality if you just record (without streaming)?

scrcpy -b20M --record file.mp4

If the resulting quality is good, then the streaming quality is the culprit (try to adjust the settings of your streaming software).

Thanks for this response, very helpful. I did some further tests, I played a Youtube video and that seemed absolutely fine, so I went back to the live app. I tried the other player they have which I don't usually use, let it buffer, and it actually seemed to be fine too. I wasn't streaming anything live this time, so I'll have to test it again when sports are on, but it might be that the key is the player on the phone.

One thing I did notice however, is that the recorded playback file is smoother than how it appears when I'm using it in real time. Sorry, I'm not good at explaining it, but in the recorded file there's a smoothness to the action, whereas in the playback, it's slightly jittery. Think of it like an FPS drop, it kind of looks like that. It's very slight, but I do notice it. The recorded file is OK, but when it's being streamed in real time, it isn't

Also, I actually had no idea scrcpy could record, that's fantastic!

rom1v commented 3 years ago

One thing I did notice however, is that the recorded playback file is smoother than how it appears when I'm using it in real time.

You mean when opening scrcpy only (without streaming)? Is it over USB?

Think of it like an FPS drop, it kind of looks like that. It's very slight, but I do notice it.

Is there any FPS drop? Enable FPS logging by pressing Alt+i in the scrcpy window, it will print framerate every second in the terminal. Are there lines with skipped frames?

InterestingInterest commented 3 years ago

You mean when opening scrcpy only (without streaming)? Is it over USB?

Sorry, I'm a bit unsure what you mean by without streaming? You mean streaming the video? And yes I do use USB-C

Is there any FPS drop? Enable FPS logging by pressing Alt+i in the scrcpy window, it will print framerate every second in the terminal. Are there lines with skipped frames?

There are a few, yeah. It seems pretty consistent though. https://i.postimg.cc/9FgHbBYq/frames.png

INFO: 51 fps
INFO: 54 fps (+1 frames skipped)
INFO: 56 fps
INFO: 55 fps
INFO: 56 fps
INFO: 55 fps (+1 frames skipped)
INFO: 55 fps
INFO: 51 fps
INFO: 52 fps
INFO: 51 fps
INFO: 51 fps
INFO: 53 fps (+1 frames skipped)
INFO: 53 fps
INFO: 51 fps
INFO: 50 fps
INFO: 52 fps
INFO: 54 fps
INFO: 54 fps
INFO: 55 fps
INFO: 56 fps
INFO: 55 fps
INFO: 54 fps
INFO: 54 fps (+1 frames skipped)
INFO: 55 fps
INFO: 55 fps
INFO: 55 fps
INFO: 56 fps
INFO: 55 fps
INFO: 52 fps
INFO: 54 fps

I tried to take a video to show this but I don't think the screen recording on my laptop is good enough to really show what I mean.

rom1v commented 3 years ago

Sorry, I'm a bit unsure what you mean by without streaming?

Sorry, I confused things with other posts (I thought you were streaming the device capture with OBS or something).

One thing I did notice however, is that the recorded playback file is smoother than how it appears when I'm using it in real time. Sorry, I'm not good at explaining it, but in the recorded file there's a smoothness to the action, whereas in the playback, it's slightly jittery. Think of it like an FPS drop, it kind of looks like that. It's very slight, but I do notice it. The recorded file is OK, but when it's being streamed in real time, it isn't

If it's not only when a frame is skipped as printed in the logs (I think it is not), then here is the explanation.

On the device side, scrcpy captures the frames with their timestamp (the date at which they are captured). On the client side, to minimize latency, scrcpy always displays immediately the last frame it received (and decoded), regardless of the timestamps (it works because the capture is real time, if it was from a pre-recorded file, it could not work, the file would be decoded and played as fast as possible).

In practice, we can assume that the delay between the capture on the device and the display on screen is sufficiently stable for the jitter to be barely noticeable (especially over USB). But there is still a small jitter: the encoding/decoding time may vary depending on frame complexity, the transfer varies depending on encoded frame size (in bytes), etc.

But to compensate the jitter (and respect the delay between frames), it would require to delay frames so that they all match the largest (estimated) possible delay, which would make the latency unacceptable.

However, when recording, the scrcpy client takes care of writing the timestamps captured on the device (transmitted by the server), so when played with your video player (like VLC), the delay between frames is correct.

rom1v commented 3 years ago

I'm still surprised that it is noticeable. Since there are frames skipped, I suspect that there is another additional cause.

Could you test running scrcpy for the same device on Linux?

InterestingInterest commented 3 years ago

Thanks for the detailed response. I think I see what you are saying, it's interesting. I don't really know if it is an FPS drop, and it is slight but because I'm watching a fast paced sport, it's more noticeable than it otherwise would be I think. It's just slightly jittery. When I playback the recording, I do so in VLC, but obviously when scrcpy is active, it's viewed on the window client. I actually wouldn't mind increased latency if it meant smoother playback, but I do understand for most this is far less desirable.

Could you test running scrcpy for the same devixe on Linux?

Unfortunately I can't as I don't have a Linux device.

rom1v commented 3 years ago

Unfortunately I can't as I don't have a Linux device.

Any computer is a Linux device :trollface:

You could run a LiveCD/LiveUSB (Ubuntu for example) on your computer.

InterestingInterest commented 3 years ago

Unfortunately I can't as I don't have a Linux device.

Any computer is a Linux device :trollface:

You could run a LiveCD/LiveUSB (Ubuntu for example) on your computer.

Perhaps one day, unfortunately it's not something I want to mess with right now

rom1v commented 3 years ago

OK, so it's currently not an InterestingInterest for you :trollface:

rom1v commented 3 years ago

in the recorded file there's a smoothness to the action, whereas in the playback, it's slightly jittery

Please check #2464.

InterestingInterest commented 3 years ago

in the recorded file there's a smoothness to the action, whereas in the playback, it's slightly jittery

Please check #2464.

Wow, thanks. Will this be available in scrcpy v1.19?

rom1v commented 3 years ago

Yes. But you can try it now by building the dev branch.

rom1v commented 3 years ago

I added a binary at the end of the post on #2464.

I'd appreciate feedbacks if you could test :)

InterestingInterest commented 3 years ago

I added a binary at the end of the post on #2464.

I'd appreciate feedbacks if you could test :)

Hey there, thanks for this! I did a quick test just now, it's not conclusive but I tried scrcpy --display-buffer=50 And I'm not completely sure it fixed the issue. I'd have to do the recording thing again to test it thoroughly, but it still seemed a bit jittery. It could be because I'm comparing it to my phone which is a smaller screen so it looks smoother there scrcpy --v4l2-buffer=500. I couldn't test this unfortunately since I don't have a Linux device

rom1v commented 3 years ago

it still seemed a bit jittery

OK, so that was probably not the cause in your case (which is also suggested by the "skipped frames" you get).

You could try with a bigger buffering delay, but I think it will not fix the problem for you:

scrcpy --display-buffer=500
InterestingInterest commented 2 years ago

it still seemed a bit jittery

OK, so that was probably not the cause in your case (which is also suggested by the "skipped frames" you get).

You could try with a bigger buffering delay, but I think it will not fix the problem for you:

scrcpy --display-buffer=500

Yeah, thanks a bunch for the help, but unfortunately it still hasn't fixed it. It's just as if it's running in a lower frame rate, it's still watchable, but since some sports are fast paced, it can be noticeable. Regardless this is still an awesome piece of software

rom1v commented 2 years ago

On the recorded file (scrcpy --record file.mp4), it's not noticeable at all, correct?

Does it happen with another device? Another computer? If in the future you decide to try Linux, please let me know if it's better :wink:

Did you try with scrcpy --render-driver=opengl? (although on Windows it will probably make things worse).