> On 18 Jan 2018, at 17:32, Dmytro Humeniuk <dmitry.gumen...@gmail.com> wrote: > >> >> On 18 Jan 2018, at 08:56, Tobias Rapp <t.r...@noa-archive.com> wrote: >> >> On 15.01.2018 13:48, Dmytro Humeniuk wrote: >>>> 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" >> >> Sorry, I misunderstood your concerns regarding asetnsamples filter >> performance. The numbers I provided have been for >> >> "asetnsamples=22050,astats=metadata=on,ametadata=print:file=stats-file.dat" >> >> versus >> >> "astats=metadata=on,ametadata=print:file=stats-file.dat" >> >> When comparing astats+ametadata versus dumpwave it is obvious that a >> specialized filter which only calculates one statistic value is faster than >> a filter that calculates multiple statistics. But still my opinion is that >> if the dumpwave filter is to be added to the codebase it should be more >> generic (i.e. output frame metadata similar to the psnr/ssim filters for >> video). > > Actually current output(normalised float values in range 0...1) was proposed > by Kyle as more generic. Ping >> >> 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
