> On 15 Jan 2018, at 09:14, Tobias Rapp <t.r...@noa-archive.com> wrote: > > On 13.01.2018 23:52, Дмитрий Гуменюк wrote: >> Hi, >>> On 13 Jan 2018, at 01:37, Дмитрий Гуменюк <dmitry.gumen...@gmail.com> wrote: >>> >>> Hi >>> >>>> On 12 Jan 2018, at 13:32, Дмитрий Гуменюк <dmitry.gumen...@gmail.com> >>>> wrote: >>>> >>>>> On 12 Jan 2018, at 13:17, Tobias Rapp <t.r...@noa-archive.com> wrote: >>>>> >>>>> On 12.01.2018 12:16, Дмитрий Гуменюк wrote: >>>>>> Hi >>>>>>> On 11 Jan 2018, at 09:20, Tobias Rapp <t.r...@noa-archive.com> wrote: >>>>>>> >>>>>>> On 10.01.2018 18:18, Kyle Swanson wrote: >>>>>>>> Hi, >>>>>>>> For this to be a part of libavfilter the output needs to be more >>>>>>>> generic >>>>>>>> than the just the Soundcloud format. If we want this to be generally >>>>>>>> useful >>>>>>>> it should probably just output an array of floats between 0.0 and 1.0. >>>>>>>> The >>>>>>>> consumer of this data (JS library, or whatever) can use this in >>>>>>>> whatever >>>>>>>> way it wants. >>>>>>> >>>>>>> I agree. If the BWF Peak Envelope output which was suggested in the >>>>>>> other thread does not match your demands and filter implementation is >>>>>>> actually necessary I would prefer if the filter would attach the RMS >>>>>>> value(s) as frame metadata instead of directly dumping to file. Frame >>>>>>> metadata can then be re- >>>>>> RMS values may be counted for several frames or only for a half of a >>>>>> frame >>>>>>> used by other filters or dumped into file by using the existing >>>>>>> "ametadata" filter. >>>>>>> >>>>>>> This would be similar to: >>>>>>> >>>>>>> ffmpeg -i input-file -f null -filter:a >>>>>>> "asetnsamples=22050,astats=metadata=on,ametadata=print:file=stats-file.dat" >>>>>>> /dev/null >>>>>> I like this idea, but won’t asetnsamples affect performance by creating >>>>>> fifo queue? And it may require some effort to parse long output >>>>> >>>>> I added asetnsamples to define the audio frame size (interval of values >>>>> from astats). You can reduce the number of lines printed by ametadata by >>>>> using the "key=lavfi.astats.foo" option. >>>> I used asetnsamples as well, and I measured performance while transcoding >>>> - it appears to be slight slower >>> I think output is now more generic and I got rid of long switch/case, >>> thanks for support >> Here is most recent patch, seems like all comments are addressed, did I miss >> something? > > I still would prefer to have the value attached as frame metadata, then > dumped into file via the existing "ametadata" filter. Even better would be to > integrate the statistic value (if missing) into the "astats" filter. > > If your concern is the output format of "ametadata" then some output format > extension (CSV/JSON) needs to be discussed for ametadata/metadata. > > If your concern is performance then please add some numbers. In my tests > using an approx. 5 minutes input WAV file (48kHz, stereo) the run with > "asetnsamples" was considerably faster than the run without (1.7s vs. 13.9s) Hi As I mentioned previously adding metadata to each frame is not possible as value may be counted for several frames or only for a half of a frame
I used 2 hours long 48kHz mp3 https://s3-eu-west-1.amazonaws.com/balamii/SynthSystemSystersJAN2018.mp3 For this purposes I set up CentOS AWS EC2 nano instance Then I transcoded it while filtering like following (just to recreate real situation): 1. -filter:a "asetnsamples=192197,astats=metadata=on,ametadata=print:file=stats-file.dat" out.mp3 2. -filter:a "dumpwave=n=192197:f=-" out.mp3 Results: 1. 244810550046 nanoseconds 2. 87494286740 nanoseconds One of the possible use cases - to set up 2 chains of asetnsamples->metadata - for example: "asetnsamples=192197,astats=metadata=on,ametadata=print:file=stats-file.dat,asetnsamples=22050,astats=metadata=on,ametadata=print:file=stats-file1.dat” for sure it will affect performance Comparing with "dumpwave=n=192197:f=out1,dumpwave=n= 22050:f=out2" > Regards, > Tobias > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
