Le septidi 27 messidor, an CCXXI, Jan Ehrhardt a écrit :
OK, you've got some points for using volumedetect. The question is if you still get those differences, taken into account that disk speed might be a limiting factor.
I have no idea, and "profile, don't speculate".
As there is no user-interaction at all, I will have to find a way to pass the outcome of the volumedetect to a second FFMpeg-commandline for the second pass.
That is not difficult at all.
As far as I know now, this can only be done by parsing the screen output of the first pass
It is true that the results of volumedetect go only in ffmpeg's log, but it is specifically designed to be easily parsable. We still need a clean solution for filters that want to communicate out-of-band information. Also, calling it "screen output" shows a deep misunderstanding of how things work.
Would it be possible to insert the momentary value for volumedetect in the metadata and use that as input in af_volume.c? One pass normalization based on volumedetect should be faster than what we have now.
The reason volumedetect is fast is because it does not do all this stuff that, done properly, is expensive, and done improperly is worse than useless.
I did a little test on a 2GB Sony MPEG recording. Transcoding using the R128 input took (on my i5) 178 seconds. Volumedetection on the same file only took 8 seconds and when I applied a volume=-6dB on the source file I was 166 seconds further. Net difference: 8 + 166 = 174 versus 178 is little bit more than a 2% speed gain.
Since you do not explain what is being measured (I suspect it includes video transcoding), this information is mostly useless.
I have now expanded that commandline with volume normalization for both the [a0] and [a1] audio tracks. Breaking it up for two pass encoding would in fact mean three pass in that case: (1) voldetect a0, (2) voldetect a1, (3) the transcoding.
I believe you are wrong, volumedetect should be ran on the whole concatenated audio. Regards, -- Nicolas George