Opened 3 years ago

Last modified 3 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)

ffmpeg-hit-100cpu.png (129.7 KB ) - added by Dashan Chang 3 years ago.
output1.txt (61.2 KB ) - added by Dashan Chang 3 years ago.
output2.txt (29.8 KB ) - added by Dashan Chang 3 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 by Timo R., 3 years ago

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.

comment:2 by Dashan Chang, 3 years ago

Summary: CPU hit 100% when two or three ffmpeg instances transcods webm/vp8mpegCPU hit 100% when two or three ffmpeg instances transcods webm/vp8

comment:3 by Dashan Chang, 3 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 Carl Eugen Hoyos, 3 years ago

Component: ffmpegundetermined
Version: 4.2git-master

Is the issue reproducible without network input?

comment:5 by Timo R., 3 years ago

Component: undeterminedffmpeg
Version: git-master4.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 Timo R., 3 years ago

Component: ffmpegundetermined
Version: 4.2git-master

comment:7 by Dashan Chang, 3 years ago

Version: git-master4.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 Dashan Chang, 3 years ago

who can help please remove the screenshot attachment as I missed removing my username and password. Thank you very much.

by Dashan Chang, 3 years ago

Attachment: ffmpeg-hit-100cpu.png added

comment:9 by Carl Eugen Hoyos, 3 years ago

Version: 4.2git-master

comment:10 by Carl Eugen Hoyos, 3 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 Dashan Chang, 3 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 Dashan Chang, 3 years ago

Attachment: output1.txt added

by Dashan Chang, 3 years ago

Attachment: output2.txt added

comment:12 by Carl Eugen Hoyos, 3 years ago

Then please run git bisect to find the change introducing the regression.

Note: See TracTickets for help on using tickets.