Opened 5 years ago
Last modified 5 years ago
#8402 new defect
CPU hit 100% when two or three ffmpeg instances transcods webm/vp8
Reported by: | Dashan Chang | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | git-master | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
When two (Windows 7) or three (Windows 10) ffmpeg instances independently and simultaneously transcode and output to webm/vp8, the computer would hit 100% CPU.
Killing one would restore another one to its normal CPU usage.
ffmpeg version git-2019-11-22-89aa134
The command line is:
ffmpeg.exe -i rtsp://[url1] -f webm -r 20 -s 640x400 -vcodec vp8 clip1.webm
ffmpeg.exe -i rtsp://[url2] -f webm -r 20 -s 640x400 -vcodec vp8 clip2.webm
Attachments (3)
Change History (15)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
Summary: | CPU hit 100% when two or three ffmpeg instances transcods webm/vp8mpeg → CPU hit 100% when two or three ffmpeg instances transcods webm/vp8 |
---|
comment:3 by , 5 years ago
I am not sure its load causing this. It seems to me that there is something similar to an mutex object locking each others. On Windows 10, when two ffmpeg instances transcode for live view (even though transcoding and CPU looks normal), you would notice that pictures on the two live view moving/stop toggling. This indicates the two instances already started to block each others. Adding the third instance, it may run n normal CPU for a while. Then suddenly all three instances hit CPU to 100%.
comment:4 by , 5 years ago
Component: | ffmpeg → undetermined |
---|---|
Version: | 4.2 → git-master |
Is the issue reproducible without network input?
comment:5 by , 5 years ago
Component: | undetermined → ffmpeg |
---|---|
Version: | git-master → 4.2 |
Your screenshot clearly shows that one of your two processes is going at way faster than realtime, and the other also is slightly faster than x1.00.
It hitting 100% CPU on a quad core with that kinda work is really not surprising in any way.
comment:6 by , 5 years ago
Component: | ffmpeg → undetermined |
---|---|
Version: | 4.2 → git-master |
comment:7 by , 5 years ago
Version: | git-master → 4.2 |
---|
Is the issue reproducible without network input? I am not sure. I did test and transcoded three big H264 files (30 minutes long) to webm/vp8 simultaneously. The phenomenon is that even though CPU hits high but they all proceed without blocking each other and they also finished much faster than with RTSP as inputs.
In my analysis the issue seems in the webm/vp8 encoder because in my use case, I often run more than ten instances of ffmpeg simultaneously on one computer to transcode to other media formats such as H264/mpeg1video and CPU always runs low.
comment:8 by , 5 years ago
who can help please remove the screenshot attachment as I missed removing my username and password. Thank you very much.
by , 5 years ago
Attachment: | ffmpeg-hit-100cpu.png added |
---|
comment:9 by , 5 years ago
Version: | 4.2 → git-master |
---|
comment:10 by , 5 years ago
If no network input is required I am curious how the issue can be reproduced: Please provide command lines and complete, uncut console output.
comment:11 by , 5 years ago
I have tested several major versions one by one. I found the last version that works with no high CPU (actually each only uses 3% CPU) for transcoding to webm/vp8 is ffmpeg-4.0.2-win64-static.zip.
After this version, all would hits high CPU even in one ffmpeg instance transcoding to webm/vp8. With two more instances, it would immediately hit 100%, including the today's release: ffmpeg-20191126-59d264b-win64-static.zip
by , 5 years ago
Attachment: | output1.txt added |
---|
by , 5 years ago
Attachment: | output2.txt added |
---|
comment:12 by , 5 years ago
Then please run git bisect
to find the change introducing the regression.
Sounds like exactly what happens if you put a lot of load on your CPU. Eventually it will hit 100% and stuff will slow down.
Encoding is slow, that's just how it is.