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: https://phabricator.services.mozilla.com/D21717

--HG--
extra : moz-landing-system : lando
This commit is contained in:
Bryce Van Dyk 2019-03-01 18:20:00 +00:00
parent ce9fbb5584
commit 79377d1363

View File

@ -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();
(this->*pushPacket)(next_holder);
@ -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);
};