1120014 - Initialize mLast{Audio,Video}Time to 0, not -1

Status: RESOLVED FIXED

(Core :: Audio/Video, defect, P1)

Description

[Bobby Holley (:bholley)]

Part of bug 1119456.

Comment 1

[Bobby Holley (:bholley)]

Attachment: Initialize MediaSourceReader::mLast{Audio,Video}Time to 0 rather than -1. v1

There isn't actually any initialization code that sets them at 0. Instead, we
currently rely on the fact that our first decoder ends up active regardless of
what its buffered range reports.So as long as invoking the first Request{Audio,Video}Data
is resolved, this ends up ok. But while that is usually the case, it isn't _always_
the case, especially in the case where the MP4Reader rejects with WAITING_FOR_DATA.

Flagging the union of possible reviewers. Whoever gets to it first should
clear the rest.

Comment 2

[Ralph Giles (:rillian)]

Comment on attachment 8546932 [details] [diff] [review]
Initialize MediaSourceReader::mLast{Audio,Video}Time to 0 rather than -1. v1

Review of attachment 8546932 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. Missing a space after period in the third line of the commit message body.

Comment 3

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/84c65d67215f

Comment 4

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/84c65d67215f

Comment 5

[Ralph Giles (:rillian)]

Comment on attachment 8546932 [details] [diff] [review]
Initialize MediaSourceReader::mLast{Audio,Video}Time to 0 rather than -1. v1

Approval Request Comment
[Feature/regressing bug #]: MSE
[User impact if declined]: YouTube video playback stalls, less consistent testing.
[Describe test coverage new/current, TBPL]: Landed on m-c.
[Risks and why]: Low. Simple and MSE-specific.
[String/UUID change made/needed]: None.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/201fee3158c1