Nicolas George in gmane.comp.video.ffmpeg.devel (Sun, 14 Jul 2013 23:14:59 +0200):
Le sextidi 26 messidor, an CCXXI, Jan Ehrhardt a écrit :
Simple, speed.
I am in no way bound to EBU recommendations
Then use two passes and volumedetect.
If I take the decoding time for audio (Vorbis -q 4) as measurement unit, -af ebur128 costs about 4 while -af volumedetect costs about 0.4 (and -af volume 0.04). Therefore, two decoding for two passes plus volumedetect cost ~2.5 while one pass with ebur128 costs ~5.
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. Our recordings are on a SD card and should stay there. Any one-pass scheme has the definite advantage that the disk has to be accessed only once for reading the input file (and, no, SD cards do not normally have a disk cache). Besides that, using two passes is not easy, as I will explain below.
If you have enough RAM, you can save the PCM while running volumedetect and avoid the second decoding too.
I do not control the user environment at all. The only thing I know is that the host PC has at least Windows XP. For my users it is a one click experience: they connect a SD card with a Camcorder recording through USB to their computer, start our software which is on the same SD card, review if the right video is there and click on 'Yes, upload this for me'. Then, behind the scenes, MEncoder or FFMpeg starts compressing the recording, saves the resulting video on the SD card (I am not allowed to use the HD of the host PC) and LFTP starts uploading the compressed file over a SFTP-connection to our server. Sometimes hours after the one-click the video is online. 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. As far as I know now, this can only be done by parsing the screen output of the first pass, extract the volume level and use that for composing the second command line. I would rather not do that, even if it delivers another 5% (or something like that) speed increase. Everything that breaks the process into more steps is bound to lead to errors. 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. How would we achieve that? Jan