Assertion failure: trackEndTime >= tstamp, at src/dom/media/webm/WebMDemuxer.cpp:621
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox65 | --- | wontfix |
firefox66 | --- | wontfix |
firefox67 | --- | fixed |
People
(Reporter: tsmith, Assigned: bryce)
References
(Blocks 1 open bug)
Details
(Keywords: assertion, testcase)
Attachments
(2 files)
Comment hidden (Intermittent Failures Robot) |
Updated•6 years ago
|
Assignee | ||
Comment 2•6 years ago
|
||
Just run into this while looking at bug 1530835. Even created my own test case before realizing we already have a bug and one here.
These WebM's have samples with timestamps greater than the duration specified in the segment header. This shouldn't happen in the sense that muxers shouldn't make such files. However, if muxers are going to misbehave and make such files, there's nothing in our code that prevents this condition firing (as we see in this bug).
I think we should relax the assertion here to instead be a log. We could also take the larger of the segment duration or sample timestamp.
Assignee | ||
Comment 3•6 years ago
|
||
We're able to hit this assertion in the wild due to bad muxers. As such, replace
the assert with a log. If a sample has a time stamp > the segment duration, use
that instead of the duration for calculating our next time stamp. Use an
explicit int64_t type in the signature for our next time stamp calculation
as the logging explicitly expects an int64_t (makes it harder to change the
types involved and footgunning by having a wrong formatter in the logs).
Assignee | ||
Comment 4•6 years ago
|
||
![]() |
||
Comment 6•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Updated•6 years ago
|
Comment hidden (Intermittent Failures Robot) |
Updated•6 years ago
|
Updated•6 years ago
|
Description
•