When calling decodeAudioData with a context where a sampling rate set is different to the original content, the number of frames returned may be incorrect STR: 1- Open https://jyavenard.github.io/htmltests/tests/webaudio/decodeAudioData.html 2- Select opus.webm as the file to use 3- Set the sampling rate to 44100 4- Press play The numbers showing are 88254 frames 2.001224489795918 which indicates that we've returned 88254 frames and that the length of the blob decoded is over 2s This file is originally encoded at 48kHz and is exactly 2s long. When forcing the content to be decoded at 44.1kHz we should be getting 88200 frames and a 2s duration. Something is wrong in the resampling and the trimming.
<rdar://problem/82095650>
Created attachment 437617 [details] Patch
Comment on attachment 437617 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=437617&action=review > Source/WebCore/platform/audio/cocoa/AudioFileReaderCocoa.cpp:339 > + uint32_t leadingTrim = m_webmData->m_track->codecDelay().value_or(MediaTime()).toDouble() * outFormat.mSampleRate; `MediaTime::zeroTime()` should be cheaper than `MediaTime()` > Source/WebCore/platform/audio/cocoa/AudioFileReaderCocoa.cpp:341 > + uint32_t trailingTrim = (m_webmData->m_track->codecDelay().value_or(MediaTime()) + m_webmData->m_track->discardPadding().value_or(MediaTime())).toDouble() * outFormat.mSampleRate - leadingTrim + 0.5; Ditto
Created attachment 437698 [details] Patch
Committed r282196 (241483@main): <https://commits.webkit.org/241483@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 437698 [details].