L'octidi 28 messidor, an CCXXI, Jan Ehrhardt a écrit :
No, that is no deep misunderstanding. On a SD card, you really do not want to use FFMpeg's logs, because they slow down things terribly. For instance, volume detection on a concatenated stream of 2 2GB Sony Camcorder files takes 17 seconds with no logging and 27 seconds with logging. Redirecting the screen output (stderr) to a file is 40% faster than using the log.
It seems clear to me your problem here is of system programming: establishing pipes with auxiliary processes to get their output without writing to a temporary file nor using "screen output" (and slightly more subtle: get two output streams from the same program without blocking).
I thought that would be obvious.
I thought it would be obvious that, to measure the speed of a process, you try to isolate this process as much as possible, not drown within unrelated work.
Sometimes you do want volumedetect on concatenated audio, sometimes you do not. In my case, the first recording is often a short intro on what the interview with the client will be about. It is very often taken under different sound conditions than the remainder of the recording(s). I have seen people recording the introduction inside a car before entering a house et cetera.
That is reasonable, but I do not see that it creates additional difficulty.
PS. With respect to the slowness of writing to SD cards see this patch: https://github.com/FFmpeg/FFmpeg/commit/f4d9148fe282879b9fcc755767c9c04de9dd... By simply increasing the copy-buffer from 1K to 32K qt-faststart became 400 times as fast.
It seems to me this is a sign of a crappy (or badly configured) operating system, but it is completely unrelated to the problem at hand since there is absolutely nothing to write in any permanent file until the final phase. Regards, -- Nicolas George