cmcguirk
commented
5 years ago I was able to modify the client code and add logging statements, and I was able to determine that even though I still see the visual issue where periodically an image that would have been appropriate a fraction of a second earlier is briefly displayed, all of the PTS (Presentation Timestamp) values are being received in ascending order as they are read from the socket, and the AvPackets are processed in that same order. The bytes remaining read from the meta header for each frame matches the size of each AvPacket as it's being processed too. So I have to suspect that the problem is somewhere in the phone side; it seems to be producing the PTS values in ascending order, and without any excessive gaps in PTS value, so probably it's periodically putting out incorrect video data for some of the frames it's choosing to put out.
It might be worth noting that I've tried recording this phone screen with a couple phone apps, such as APowerRec and AZ Screen Record, and they seem to produce MP4 recordings with what looks like the same kind of visual issue. And my phone's Android version is 6.0.1.
rom1v
null-dev
sshock
I downloaded scrcpy 1.9 on 7/24/2019 with the goal of recording video from my Droid Turbo onto my Windows 7 x64 PC. When I connect with USB and run scrcpy and have it display to my screen, and the video from the phone has a lot of motion, it's common for the display from scrcpy to periodically appear to show maybe 1 frame that probably would have been the correct frame to display about 1/10 of a second ago. So whatever motion was happening appears to jump backwards to where it would have been maybe 1/10th of a second ago for just one frame and then jump back to what the phone is currently displaying; it's a very jarring appearance. Depending on the size I am displaying with scrcpy, these frame jumps may happen as frequently as once a second. If I reduce the display size very small like scrcpy --max-size 400, the frame jumps are less frequent, but they still happen occasionally, maybe a few times every 10 seconds.
I have had my phone display its CPU and memory usage while running this, and it seems to display around 15.00/14.00/14.00 as the CPU usage and the bar only seems to go around 15% across the screen so I interpret that as 15% CPU usage. The phone memory remains with over 1 GB free while this happens. My PC CPU usage is only around 5% while it happens, and only 4 out of 8 GB of memory are in use; these are when I'm running scrcpy --max-size 1920.
I also tried having scrcpy do the file recording. I ran one with mp4 and one with mkv, with the --no-display option so it wouldn't need to do double work, but the mp4 and mkv files it created still have the same kinds of frame jumps I would see in the live display. I play the files in VLC, and I've checked that I'm not just getting some kind of playback issue with the mp4 and mkv files by advancing individual frames in VLC and I can still see the motion get jumped backwards for a frame.
I do not usually run it with --render-expired-frames, and when I've tried it, the frame jumps seem just as frequent, possibly more frequent. When I use ctrl+i, I often see skipped frames, but I am fairly certain I have observed these frame jumps in the display even during periods where no skipped frames are logged. The display on the phone itself always looks perfect during the whole thing, and the game doesn't feel any less responsive than it would while scrcpy was not running.
Do you have any suggestions to get it where it doesn't end up displaying or recording an older frame after it has already displayed/recorded a newer frame? I can probably share the mp4 and mkv file with google drive or something later if that would help.