Deal with timecode error episilon when handling time ranges

RESOLVED WORKSFORME

Status

()

Core
Audio/Video
P5
normal
RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: kinetik, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
This is related to bug 1062657.  We need to consider the same issue when dealing with time ranges in other instances, specifically:

- Any handling related to computing GetBuffered
- Switch{Audio,Video}Readers to avoid becoming stuck on an exhausted decoder
  (currently this is somewhat hacked around by checking the decoder's {Audio,Video}Queue for EOS)
- Other places I've forgotten?
(Reporter)

Updated

4 years ago
Blocks: 778617
(Reporter)

Comment 1

4 years ago
Converting MSE's internal timestamp handling to use int64_t/microseconds (as the rest of the media code does) will also make this less painful.  It's currently using doubles/seconds because that's what flows in via the API and what's available in the existing TimeRanges, so it was the path of least resistance until there was sufficient time to make the necessary changes elsewhere in the codebase.
(Reporter)

Updated

4 years ago
See Also: → bug 1065218
Priority: -- → P5
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.