[FFmpeg-user] Black screen when capturing Windows desktop with audio (gdigrab, dshow)

[Schönberger Markus]

Dear German,

I tested on my notebook and have had same experience even without audio.
To solve the issue in both I changed the preset to "fast" or "ultrafast"
instead "veryfast".



Markus
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user at ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email ffmpeg-user-request at ffmpeg.org
with subject "unsubscribe".

-----Ursprüngliche Nachricht-----
Von: German Geraskin <german.geraskin at gmail.com> 
Gesendet: 22 January 2023 20:26
An: ffmpeg-user at ffmpeg.org
Betreff: [FFmpeg-user] Black screen when capturing Windows desktop with
audio (gdigrab, dshow)

# Disclaimer
Probably, this message should have been sent as a bug report, but
unfortunately I was not able to post it on trac.ffmpeg.org since there is no
tool to recover forgotten username on that site.


# Versions
The issue that will be discussed below was observed on the following
software.
Operating system: Windows 10 Pro (version: 21H2; build: 19044.2130)
FFmpeg: 4.x.x and 5.x.x versions


# Short Description
"Black screen" appears when I try to capture desktop and record audio with
respective input devices, gdigrab and dshow.


# Detailed Description
The command to capture Windows desktop without sound recording works
flawlessly.

  ffmpeg.exe -f gdigrab -framerate 25 -offset_x 54 -offset_y 114 -video_size
960x540 -show_region 1 -i desktop -pix_fmt yuv420p -r 25 -g 50 -c:v libx264
-preset veryfast -profile:v high -crf 28 -f mp4 -y
gdigrab-without-audio.mp4

Please check the video file produced by this command:
https://0x0.st/ohDQ.mp4/gdigrab-without-audio.mp4

The command to capture Windows desktop AND record audio at the same time
does not work as expected. FFmpeg starts working normally, but when the user
(surprise) clicks the MOUSE button, Windows starts showing a black rectangle
in the capture region and FFmpeg captures it.

  ffmpeg.exe -f gdigrab -framerate 25 -offset_x 54 -offset_y 114 -video_size
960x540 -show_region 1 -i desktop -f dshow -i audio="Microphone (Logitech
USB Headset H540)" -pix_fmt yuv420p -r 25 -g 50 -c:v libx264 -preset
veryfast -profile:v high -crf 28 -c:a aac -b:a 64k -f mp4 -y
gdigrab-dshow-audio-ISSUE.mp4

Please check the video file produced by this command:
https://0x0.st/ohDj.mp4/gdigrab-dshow-audio-ISSUE.mp4
(Sound ON)

I believe that this behavior is common to all versions of FFmpeg.
Here are list of four builds tested with the same result:
* ffmpeg-n5.0-latest-win64-gpl-5.0
* ffmpeg-n4.4-latest-win64-gpl-4.4
* ffmpeg-4.1-win64-static


# Solution
After some research, I guessed that this phenomenon occurs when some
message, that FFmpeg cannot correctly interpret, arrives on FFmpeg standard
input when the mouse button is clicked.

To test this my hunch, I tried to start FFmpeg in a new detached console.
And it worked!

  start ffmpeg.exe -f gdigrab -framerate 25 -offset_x 54 -offset_y 114
-video_size 960x540 -show_region 1 -i desktop -f dshow -i audio="Microphone
(Logitech USB Headset H540)" -pix_fmt yuv420p -r 25 -g 50 -c:v libx264
-preset veryfast -profile:v high -crf 28 -c:a aac -b:a 64k -f mp4 -y
gdigrab-dshow-SOLVED.mp4


# Conclusion
Apparently, the issue described above is a bug of the Windows operating
system itself, but not the FFmpeg.

In conclusion, I would like to note that in this experiment, both the mouse
and the microphone were connected via USB.
Perhaps this is important for reproducing the issue and working on fixing
it.

German
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user at ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email ffmpeg-user-request at ffmpeg.org
with subject "unsubscribe".