On Wed, Oct 04, 2017 at 10:33:11AM +0200, Tobias Rapp wrote: > On 30.09.2017 02:48, Michael Niedermayer wrote: > >On Fri, Sep 29, 2017 at 05:08:16PM +0200, Tobias Rapp wrote: > >>Signed-off-by: Tobias Rapp <t.r...@noa-archive.com> > >>--- > >> libavformat/wavenc.c | 5 ++++- > >> tests/ref/lavf/wav_peak_only | 2 +- > >> 2 files changed, 5 insertions(+), 2 deletions(-) > > > >The commit message doest say why this chnage is done > > As I understand the BWF peak envelope chunk definition in EBU Tech > 3285 - Supplement 3 the "dwPosPeakOfPeaks" field contains the > (absolute) byte position of the peak audio sample within the _data_ > chunk: > > """ > The peak-of-peaks is first audio sample whose absolute value is the > maximum value of the entire audio file. > > Rather than storing the peak-of-peaks as a sample value, the > position of the peak of the peaks is stored. In other words, an > audio sample frame index is stored. An application then knows where > to read the peak of the peaks in the audio file. It would be more > difficult to store a value for peak since this is dependant on the > binary format of the audio > samples (integers, floats, double...). > > If the value is 0xFFFFFFFF, then that means that the peak of the > peaks is unknown. > """ > > As a peak-only file doesn't contain a data chunk it would make no > sense to store the data position. > > But when looking at FFmpeg's implementation within wavenc.c I notice > now, that the implementation is using a totally different > interpretation of the spec and stores the peak frame index (position > relative to peak chunk data) instead. > > In my opinion the current implementation of "dwPosPeakOfPeaks" is > wrong and the patch should actually be changed to always write "-1" > unconditionally until the peak-of-peaks feature is implemented > correctly. See attached patch update.
have you confirmed that files not created by ffmpeg mismatch what we do ? If so this is ok but please bump the micro version of libavformat every time this muxer behavior changes. So demuxers can know what they are dealing with [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
