FS#58619 - [ffmpeg] Ctrl^C / Q doesn't always kill ffmpeg process

Attached to Project: Arch Linux
Opened by Elias (Bleuzen) - Wednesday, 16 May 2018, 11:52 GMT
Last edited by Maxime Gauduin (Alucryd) - Tuesday, 20 August 2019, 16:17 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Maxime Gauduin (Alucryd)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
When I use ffmpeg to record something and want to stop it (with pressing Ctrl^C or Q)
it stops the recording, but the ffmpeg process stays alive.
Not only stays alive, the CPU usage of that process goes up to 100% for one thread / core (12.5% CPU usage in my case).

I have to press Ctrl^C a second time to stop the ffmpeg process.
This should not be needed, as on other distros where I tryed it (Ubuntu and Suse) ffmpeg directly stops when pressing Ctrl^C the first time and it doesn't left over a process which uses one cpu core.
Here I have to press Ctrl^C two times to not left over that stupid ffmpeg process.

Additional info:
* package version: 1:4.0-2


Steps to reproduce:
1. Start a recording with ffmpeg, for example an audio recording:

ffmpeg -f alsa -i pulse -acodec flac "ffrec.flac"

2. Wait some seconds (let it record for at least 5 seconds)

3. Press Ctrl^C

The ffmpeg process should end here usually (it does on other linux distros).
But it stays alive and uses more cpu.
To kill it, you have to press Ctrl^C a second time. But this should not be needed.
This task depends upon

Closed by  Maxime Gauduin (Alucryd)
Tuesday, 20 August 2019, 16:17 GMT
Reason for closing:  Fixed
Additional comments about closing:  4.2
Comment by DrZaius (DrZaius) - Wednesday, 16 May 2018, 20:19 GMT
Workaround is to use "-f pulse -i default" instead.
Comment by Elias (Bleuzen) - Thursday, 17 May 2018, 20:03 GMT
Works for now, thanks
Comment by Maxime Gauduin (Alucryd) - Thursday, 28 June 2018, 12:33 GMT
Does it still happen with 4.0.1? Also, what version did you use on other distros? Ubuntu is still at 3.4, I doubt this is a packaging issue anyway, will probably close as upstream.
Comment by Elias (Bleuzen) - Friday, 29 June 2018, 08:29 GMT
Yes, bug is still there with 1:4.0.1-2.

Tested other distros where it works as it should (today):
- Ubuntu 18.04 with ffmpeg 3.4.2-2
- Solus with ffmpeg 3.4.2-52
I also tested it in the past with OpenSUSE Tumbleweed with ffmpeg 4.0, where it also worked. But I don't have an openSuse install there right now, so I'm not sure if it still works there with 4.0.1.
Comment by DrZaius (DrZaius) - Monday, 10 September 2018, 22:04 GMT
Consider reporting this upstream (https://trac.ffmpeg.org/) if you believe this is a FFmpeg issue. Make sure to test a build from the current git master branch. Simply clone, ./configure (no configure options will be needed for this case), make, then run your command: no need to install or use anything from AUR. Also include your actual command and the complete console output. git bisect points to commit ea93b74074c509f59942c7ed4112ed3d64c3af33 as a possible culprit–on Arch at least (I recommend you mention that). If true it will affect both the 3.4.x and 4.0.x release branches. I did not investigate why you can't duplicate the behavior it on those other distros.

https://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=ea93b74074c509f59942c7ed4112ed3d64c3af33
Comment by DrZaius (DrZaius) - Tuesday, 23 April 2019, 22:11 GMT
Fixed upstream:
https://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=commit;h=f9a061a31c3d2d81b3ec1e1b9b37187a358cdd9e

It has not been backported to the 4.1 release branch but it will be included in the next major release.
Comment by Maxime Gauduin (Alucryd) - Wednesday, 24 April 2019, 07:02 GMT
Awesome, thanks for the heads up!

Loading...