[FFmpeg-devel] [PATCH] add dumpwave filter

[Dmytro Humeniuk]

> On 15 Jan 2018, at 09:14, Tobias Rapp <t.rapp at noa-archive.com> wrote:
> 
> On 13.01.2018 23:52, Дмитрий Гуменюк wrote:
>> Hi,
>>> On 13 Jan 2018, at 01:37, Дмитрий Гуменюк <dmitry.gumenyuk at gmail.com> wrote:
>>> 
>>> Hi
>>> 
>>>> On 12 Jan 2018, at 13:32, Дмитрий Гуменюк <dmitry.gumenyuk at gmail.com> wrote:
>>>> 
>>>>> On 12 Jan 2018, at 13:17, Tobias Rapp <t.rapp at noa-archive.com> wrote:
>>>>> 
>>>>> On 12.01.2018 12:16, Дмитрий Гуменюк wrote:
>>>>>> Hi
>>>>>>> On 11 Jan 2018, at 09:20, Tobias Rapp <t.rapp at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3872 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180115/c3159cde/attachment.bin>