Screen recording problem

[Gapplay]

The new video files (v1.10) now crash Adobe Premiere. The videos reproduce correctly on vlc, however Movies (windows 10 video player) presents some small freezing.
I've fixed the files by transcoding them with Handbrake. The transcoded videos work normally on all programs.

[rom1v]

Thank you for your report.

Does the problem occur on both mkv and mp4 files?

[rom1v]

Could you test if 8d75422 fixes the problem, please?

Here is a win64 binary (to replace in your v1.10): scrcpy.exe
SHA256: 8d79bd1062bd7a78b7bc9238052d17e5b8db099e8838d8462479f53cf8b98a50

[Gapplay]

[8d75422] scrcpy.exe still presents the same problems.
I haven't tested mkv files yet. I'll report later.

[rom1v]

And if you retry v1.9 now, it works correctly?

[Gapplay]

yes, v1.9 records correctly.

[rom1v]

Oh, in v1.10, I upgraded FFmpeg. Could you just replace av*.dll and sw*.dll from those in v1.9?

[Gapplay]

same issues after replacing dlls. It could be something to do with asynchronous recording?

[rom1v]

same issues after replacing dlls

Let's do the reverse: take v1.9, and replace the dll by those from v1.10. Does it still work?

It could be something to do with asynchronous recording?

Once we eliminate all others possibilities… but for now, I don't know how asynchronous recording could produce this bug: the file is expected to be the same.

[rom1v]

How do you stop recording? By closing the window? Does it say that the recording is complete in the logs?

[Gapplay]

How do you stop recording? By closing the window? Does it say that the recording is complete in the logs?

I close the window, here is the log:

INFO: scrcpy 1.10 https://github.com/Genymobile/scrcpy
f:\scrcpy\src\scrcpy-server.jar: 1 file pushed. 1.4 MB/s (22546 bytes in 0.016s)
INFO: Recording started to mp4 file: ..\raw.mp4
INFO: Initial texture: 1080x1920
INFO: Finishing recording...
INFO: Recording complete to mp4 file: ..\raw.mp4

[Gapplay]

Let's do the reverse: take v1.9, and replace the dll by those from v1.10. Does it still work?

Yes, it works.

I've found a quick fix by copying with FFmpeg.
ffmpeg -i raw.mp4 -c:v copy res.mp4
It could be related to https://github.com/Genymobile/scrcpy/issues/351###

[rom1v]

Let's bisect manually (if you know how to build, you could do it faster on your side).

Here is a binary for 63af7fb: scrcpy.exe
SHA256: b78e72e10289f5c9b5ca25b82a6844eea2b56ff1e04b05513295c9c6c130d7a6

And for 35d9185: scrcpy.exe
SHA256: fa577f14df8a1e55f50280ec67a166b44775b66b5965c37575b1bbe2c3b23fca

[Gapplay]

Sorry I don't know how to build. I'll try those scrcpy.exe. Thanks!

v1.10 (test.mp4) doesn't have framerate mode metadata (the programs may think that it has constant framerate), v1.9 (raw.mp4) does.

[Gapplay]

Here is a binary for 63af7fb: scrcpy.exe
SHA256: b78e72e10289f5c9b5ca25b82a6844eea2b56ff1e04b05513295c9c6c130d7a6
And for 35d9185: scrcpy.exe
SHA256: fa577f14df8a1e55f50280ec67a166b44775b66b5965c37575b1bbe2c3b23fca

They don't work

[Gapplay]

ffmpeg -i raw.mp4 -c:v copy res.mp4
I've compared those two files, the difference is only a few lines at the end so probably it's the metadata.

[rom1v]

Thank you for the details.

Could you test with this patch, please (of course I will not commit it as is):

diff --git a/app/src/recorder.c b/app/src/recorder.c
index 402f253..e14599c 100644
--- a/app/src/recorder.c
+++ b/app/src/recorder.c
@@ -237,6 +237,7 @@ recorder_write(struct recorder *recorder, AVPacket *packet) {
         return true;
     }
 
+    packet->duration = 96000;
     recorder_rescale_packet(recorder, packet);
     return av_write_frame(recorder->ctx, packet) >= 0;
 }

Here is a binary: scrcpy.exe
SHA256: a713b5d620b2c506a35d96e22cd7f2b793639a46138ac551feebfd70ad61d0c1

[rom1v]

And if it works, here is a proper fix: 8507fea (not merged yet)

Here is a binary: scrcpy.exe
SHA256: 5eccf73a4077160cda5f351be0efc4d226ec81d283785a521353a2a8be321ab5

[Gapplay]

And if it works, here is a proper fix: 8507fea (not merged yet)

Here is a binary: scrcpy.exe
SHA256: 5eccf73a4077160cda5f351be0efc4d226ec81d283785a521353a2a8be321ab5

I've just tried this binary and it's working great! Thank you!

[rom1v]

Cool, thank you for the report and the tests. I just merged it in master.