Bug 229251 – [WebAudio/WebM] Incorrect number of frames returned if decoding frame rate doesn't match original

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Audio

[Jean-Yves Avenard [:jya]]

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.

[Radar WebKit Bug Importer]

<rdar://problem/82095650>

[Jean-Yves Avenard [:jya]]

Created attachment 437617 [details]
Patch

[Eric Carlson]

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

[Jean-Yves Avenard [:jya]]

Created attachment 437698 [details]
Patch

[EWS]

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].