Commit 79377d13 authored by Bryce Van Dyk's avatar Bryce Van Dyk
Browse files

Bug 1504060 - Log instead of asserting that webm samples do not have...

Bug 1504060 - Log instead of asserting that webm samples do not have timestamps > segment druation. r=alwu

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

Differential Revision:

extra : moz-landing-system : lando
parent ce9fbb55
......@@ -556,7 +556,7 @@ nsresult WebMDemuxer::GetNextPacket(TrackInfo::TrackType aType,
int64_t next_tstamp = INT64_MIN;
auto calculateNextTimestamp = [&](auto&& pushPacket, auto&& lastFrameTime,
auto&& trackEndTime) {
int64_t trackEndTime) {
if (next_holder) {
next_tstamp = next_holder->Timestamp();
......@@ -570,8 +570,15 @@ nsresult WebMDemuxer::GetNextPacket(TrackInfo::TrackType aType,
// If we can't get frame's duration, it means either we need to wait for
// more data for MSE case or this is the last frame for file resource
// case.
MOZ_ASSERT(trackEndTime >= tstamp);
next_tstamp = trackEndTime;
if (tstamp > trackEndTime) {
// This shouldn't happen, but some muxers give incorrect durations to
// segments, then have samples appear beyond those durations.
WEBM_DEBUG("Found tstamp=%" PRIi64 " > trackEndTime=%" PRIi64
" while calculating next timestamp! Indicates a bad mux! "
"Will use tstamp value.",
tstamp, trackEndTime);
next_tstamp = std::max<int64_t>(tstamp, trackEndTime);
lastFrameTime = Some(tstamp);
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment