View Bug Details

IDProjectCategoryView StatusLast Update
0000758DCP-o-maticBugspublic2018-10-17 20:16
Reportercarl Assigned Tocarl  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Target Version2.9.0 
Summary0000758: Audio analysis inefficient
Description

As user, I'm just interested on the main level and the peak level, just
to know if I have to adjust it.

The ffmpeg audio filter volumedetect is very fast to calculate the audio
level statistics, maybe there's something to do to optimize the analysis.
(-af volumedetect - f null NULL on windows / -af volumedetect -f null
/dev/null on Linux)

TagsNo tags attached.
Branch
Estimated weeks required
Estimated work requiredAverage

Activities

carl

2015-11-26 09:37

administrator   ~0001008

Lilian: ffmpeg does it at about 2500fps for a compressed video file, about
100fps for a prores or dnxhd.

carl

2015-11-27 19:13

administrator   ~0001014

Lilian: Maybe you should forget about it.
It seems the actual calculation is as fast as FFmpeg does. I tried with a compressed video/audio file.
With a prores/pcm input, both options are more or less the same...

Although it might be slower now with EBUR128...

carl

2016-01-14 10:45

administrator   ~0001104

Markus Raab says:

its not movie depended, it's with all movies.
Here is an example I just used:[LINK] http://we.tl/sB6skQWakG [we.tl] [we.tl]
Attached see screenshots of both Versions, in V1 it takes only 7 secs., in V2 1min24sec.

I tested this before on Win7, now I updated to Win10, but stays the same.

carl

2016-03-02 09:55

administrator   ~0001157

Last edited: 2016-03-02 10:23

Reporter

1.X: 7s
2.X: 84s (12x slower)

Ubuntu 14.04, sintel-2048-surround.mp4

opt 1.79: 8s
deb 9894a46: 28s (3.5x slower)
opt 9894a46: 21s (2.6x slower)
deb 9894a46 no EBUR128: 13s (1.625x slower)
opt 9894a46 no EBUR128: 7s (same speed)

carl

2016-03-02 10:48

administrator   ~0001158

Option to disable EBUR128 added in ca045c71b2e76f86fef1ca99d7e7703a41dfcf33.

carl

2016-03-05 23:44

administrator   ~0001163

Tests on Win7 suggest that turning off EBUR128 is enough to get the speed back to 1.79.0 levels; analysing Sintel:

2.6.3 with EBU 54s
1.79.0 19s
2.6.31 with EBU 59s
2.6.31 no EBU 12s

carl

2016-03-05 23:44

administrator   ~0001164

Need to ask Markus to test.

carl

2016-06-29 21:10

administrator   ~0001320

Last edited: 2016-06-29 21:10

callgrind analysis shows nothing obvious except that EBUR128 is slow and the resampling up to the DCP rate is slow (even with SRC_LINEAR). It doesn't look easy to avoid the resampling altogether though. I believe everything reasonable has been done here.

Bug History

Date Modified Username Field Change
2015-11-25 12:37 carl New Bug
2015-11-25 12:37 carl Target Version => 2.6.0
2015-11-26 09:37 carl Note Added: 0001008
2015-11-27 19:13 carl Note Added: 0001014
2015-11-30 14:58 carl Target Version 2.6.0 => 2.7.0
2016-01-14 10:45 carl Note Added: 0001104
2016-03-02 09:55 carl Note Added: 0001157
2016-03-02 10:05 carl Note Edited: 0001157
2016-03-02 10:20 carl Note Edited: 0001157
2016-03-02 10:23 carl Note Edited: 0001157
2016-03-02 10:48 carl Note Added: 0001158
2016-03-05 23:44 carl Note Added: 0001163
2016-03-05 23:44 carl Note Added: 0001164
2016-03-05 23:44 carl Target Version 2.7.0 => 2.8.0
2016-04-22 15:55 carl Target Version 2.8.0 => 2.9.0
2016-06-29 21:10 carl Note Added: 0001320
2016-06-29 21:10 carl Note Edited: 0001320
2016-06-29 21:10 carl Status new => resolved
2016-06-29 21:10 carl Resolution open => fixed
2016-06-29 21:10 carl Assigned To => carl
2018-10-17 20:16 carl Status resolved => closed