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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to