How should timestamps be handled for audio discarded during decoding?
Open
@dalecurtis is already working on this.
Since Sep 3, 2026.
agenda
CR Blocking
- Dominant language
- HTML
- Stars
- 1.3k
- Forks
- 194
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 3
Description
While trying to fix the negative timestamp test failures in Chromium:
I've run into a question about how things like Opus pre-skip should be handled. The opus test file in this case has a pre-skip of 312 samples (6500us), which Chromium's decoding system happily discards. To ensure timestamps are accurate we adjust the -42 forward (to 6548us).
As I see it, we have a couple choices:
- AudioDecoder shouldn't discard anything.
- AudioDecoder shouldn't adjust timestamps for discarded audio (not sure how this works when full packets can end up discarded).
- Agree that timestamps should be adjusted for discarded audio.
- Do nothing and switch to a Opus test file with zero pre-skip
@padenot @youennf @tguilbert-google WDYT?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.