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 > > > BTW: The "astats" filter already provides some RMS values. > >> If you send another patch, just reply to this thread because >> that makes it easier to follow (sending a patch as an attachment is OK). >> Here are some critiques: >> [...] > > Also when sending patches adding an increased version number helps sorting > out which is the latest one (git format-patch -v2 ...). > > 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