On Mon, 21 Dec 2020, Zhiyi Zhang wrote: [...]
- Write or find a Windows tool to automatically take a screenshot every few seconds and deduplicate identical screenshots. The requirements are:
I can help out with this one. I had been debugging some screenshot problems on Wine and already have a few code snippets to do screenshots and save them.
That's great.
For this tool, I'm thinking doing it generally the following way:
- Capture the whole virtual screen and save it in a png in memory.
- Compare the png in 1, if it's not equal to the previous screenshot,
save it to disk in a folder.
Yes, that sounds good.
[...]
I wonder if it would be better if we do video capture instead? If we don't plan on keeping the video forever, I think a 2 mins video shouldn't be too large. A few megabytes I think, depending on the video format.
Video would obviously be nice but the VMs typically don't have access to a graphics card to offload the video compression. So I worry that the CPU usage would be too high and/or interfere with the tests. Also compression would have to happen in real time because we don't want the VM to be stuck compressing the video for 5 minutes after the test is done.
That pretty much means MJPEG [1] but then you either get large files or bad quality. Maybe it could work if we put a frontend detecting duplicate frames but then I don't know how we could preserve the frame interval in the MJPEG file [2].
Disk usage could also be an issue though a video encoder should allow us to solve that by lowering the bitrate, assuming we can still get a reasonable quality. Bandwidth usage may be more of an issue, both in terms of billing, and in terms of transfer time (from the VM hosts to the offsite TestBot server).
But maybe I'm overestimating the challenges of video encoding.
Currently my plan would be to do tests and then set the screenshot interval between 1 and 10 seconds based on the results.
[1] Some internet forums suggest huffyuv or lagarith but neither provides interframe compression which I think would be very beneficial in our case (even if it's very basic like doing a simple diff). The other issue as soon as one strays away from the 'mainstream encoders' is browser support.
[2] It seems like variable rate 'mjpeg' should be possible with a 'modern container' like mkv and mp4 (the latter being probably more compatible with browsers).