Opened 10 months ago
Closed 8 months ago
#10504 closed defect (fixed)
Regression: Unable to use dshow devices with gdigrab/ddagrab anymore
Reported by: | Jaex | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | ffmpeg |
Version: | git-master | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description (last modified by )
Utilizing dshow audio devices in conjunction with gdigrab or ddagrab results in a "Conversion failed!" error message with exit code -11 after stopping the recording.
I had been successfully using gdigrab with dshow audio devices together for the past 10 years without any issues. However, after upgrading FFmpeg to version 6.0, this problem emerged. Upgrading FFmpeg to 6.0 is essential for me due to the inclusion of ddagrab support.
Here are example arguments to reproduce the issue:
ffmpeg -f gdigrab -framerate 30 -offset_x 0 -offset_y 0 -video_size 1920x1080 -draw_mouse 1 -i desktop -f dshow -i audio="virtual-audio-capturer" -c:v libx264 -r 30 -preset ultrafast -tune zerolatency -b:v 3000k -c:a aac -ac 2 -b:a 128k -y "output.mp4"
These arguments works fine with FFmpeg 5.1 or older versions but fails with FFmpeg master latest win64 (2023-08-29).
Please refer to the attached files for the debug output logs of FFmpeg master latest and FFmpeg 5.1.
Attachments (5)
Change History (13)
by , 10 months ago
Attachment: | ffmpeg-master-latest-20230805-031639.log added |
---|
comment:1 by , 9 months ago
Description: | modified (diff) |
---|---|
Priority: | important → critical |
comment:2 by , 9 months ago
Priority: | critical → normal |
---|
comment:3 by , 9 months ago
Summary: | Unable to use dshow devices with gdigrab/ddagrab anymore → Regression: Unable to use dshow devices with gdigrab/ddagrab anymore |
---|
comment:4 by , 9 months ago
Further testing:
ffmpeg -f gdigrab -framerate 30 -offset_x 0 -offset_y 0 -video_size 1920x1080 -draw_mouse 1 -i desktop -f dshow -i audio="virtual-audio-capturer" -f null -
Working fine (2023-05-04):
https://github.com/GyanD/codexffmpeg/releases/tag/2023-05-04-git-4006c71d19
Regression (2023-05-08):
https://github.com/GyanD/codexffmpeg/releases/tag/2023-05-08-git-2d43c23b81
So regression happened between 2023-05-04 and 2023-05-08:
https://github.com/FFmpeg/FFmpeg/compare/4006c71d19...2d43c23b81
comment:5 by , 9 months ago
Regression happened at this commit:
https://github.com/FFmpeg/FFmpeg/commit/f5cfb2c5dfbc949a7ed2227f868f55834d20c28b
cc: @elenril
by , 9 months ago
Attachment: | 0001-fftools-ffmpeg-do-not-fail-on-AVERROR-EAGAIN-from-ch.patch added |
---|
by , 8 months ago
Attachment: | ffmpeg-patched.log added |
---|
by , 8 months ago
Attachment: | ffmpeg-unpatched.log added |
---|
comment:7 by , 8 months ago
Replying to elenril:
Please test the attached patch.
I've carried out the tests based on the provided ".patch" file. Here's a detailed rundown of the steps I took, along with my observations:
- Cloned the latest version of the repository:
Commit 6434e440039910f12f7c08072b7db3c5e99c3025 (HEAD -> master, origin/master, origin/HEAD)
- Applied the patch "0001-fftools-ffmpeg-do-not-fail-on-AVERROR-EAGAIN-from-ch.patch".
- To set up a build environment that would compile immediately, I used the following flags:
./configure --enable-cross-compile --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --pkg-config=pkg-config --disable-everything --enable-ffmpeg --disable-ffplay --disable-ffprobe --disable-shared --enable-static --enable-indev=gdigrab --enable-indev=dshow --enable-filter=null --enable-encoder='wrapped_avframe,pcm_s16le' --enable-decoder=pcm_s16le --enable-muxer='null'
- Once the compilation with the patch applied was completed, I ran FFmpeg using the following options:
.\ffmpeg.exe -f gdigrab -framerate 30 -offset_x 0 -offset_y 0 -video_size 1920x1080 -draw_mouse 1 -i desktop -f dshow -i audio="virtual-audio-capturer" -loglevel debug -f null -
- I can no longer observe "Conversion failed!" error message after hitting the "q" key to exit. Additionally, the exit code returned was "0".
For the sake of comparison and to ensure a thorough test, I also compiled the latest version without applying the patch. When I ran FFmpeg with identical options as mentioned earlier, the "Conversion failed!" error message did appear right after I pressed the "q" key to exit, and the exit code returned was "-11".
To give you a clearer picture, I've attached the log files for your review: ffmpeg-patched.log which represents the patched version, and ffmpeg-unpatched.log for the version without the patch.
I hope this information helps. Let me know if you require any further details or tests to be conducted.
comment:8 by , 8 months ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Should be fixed in ced62a0c010f74a713fa7f93c115e2284e22f96c
FFmpeg master latest output