YouTube video, audio out-of-sync; one frame shown every few seconds

RESOLVED FIXED in Firefox 39

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: maja_zf, Assigned: jya)

Tracking

(Blocks: 1 bug, {regression})

40 Branch
mozilla40
x86
macOS
regression
Points:
---

Firefox Tracking Flags

(firefox38 unaffected, firefox39 fixed, firefox40 fixed)

Details

(URL)

Attachments

(5 attachments)

Posted file about:media
Regardless of playback quality, video hardly progresses while audio mostly sounds fine. Frame updates only very 20-30 seconds, sometimes with spinner showing. Audio pauses from time to time, due to slow buffering. Video is broken up in this way even after buffering is complete. After some time, YouTube displays an "are you experiencing interruptions" message. The video is not using Flash. Meanwhile, all videos play fine on beta 38 with MSE on.

I can reproduce this on 40.0a1 (20150415030206) both with and without e10s, and on 39.0a2 (20150415004020), but NOT on 38.0 (with MSE on). 

Mac OS 10.10.3, MacBook Pro (Retina, 13-inch, Mid 2014).
Blocks: 778617
Posted file mozregression log
This is as far as I could get with mozregression:
 Last good revision: 8af276ab8636
 First bad revision: 37ddc5e2eb72
Still same behaviour on Nightly build 20150423030204.
status-firefox38: --- → unaffected
Posted file about:support
Looks like more skip to next keyframe fall out.
Maja - can you try the builds before and after bug 1152218 landed?
Flags: needinfo?(mjzffr)
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #5)
> Maja - can you try the builds before and after bug 1152218 landed?

That wasn't it. The issue is still there both before and after that bug landed. (Tested https://hg.mozilla.org/mozilla-central/rev/eb3a1c0262e4 vs https://hg.mozilla.org/mozilla-central/rev/69795033e401)


I tried mozregression again, this time bisecting inbound. Here's what I got:

12:34.10 LOG: MainThread Bisector INFO Oh noes, no (more) inbound revisions :(
12:34.10 LOG: MainThread Bisector INFO Last good revision: cb4ecfdcf4b1
12:34.10 LOG: MainThread Bisector INFO First bad revision: a05f09431d9c
12:34.10 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cb4ecfdcf4b1&tochange=a05f09431d9c
Flags: needinfo?(mjzffr)
(Assignee)

Comment 7

4 years ago
Report errors back to MP4Reader in a similar fashion to the other MediaDataDecoder.
Attachment #8601241 - Flags: review?(giles)
(Assignee)

Updated

4 years ago
Assignee: nobody → jyavenard
Status: NEW → ASSIGNED
(Assignee)

Comment 8

4 years ago
Maja was kind enough to provide me with some very detailed log. All frames coming out of the decoder on her machine are flagged with kVTDecodeInfo_FrameDropped even though they appear entirely valid. We must ignore it.
Attachment #8601444 - Flags: review?(giles)
Comment on attachment 8601241 [details] [diff] [review]
Report decoding errors back to MP4Reader

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

There's an idea. I forgot all about mCallback->Error() yesterday!
Attachment #8601241 - Flags: review?(giles) → review+
Attachment #8601444 - Flags: review?(giles) → review+
Part 1 means we won't try to continue playing the stream after the platform decoder returns an error, right? At least that will be a more obvious error than stalling.
(Assignee)

Comment 11

4 years ago
In this particular case, no errors are reported, we only have the frames marked as dropped. 

On my machine (and my MBA) the only time I had frames marked as dropped, I also had an error later. This was during shutdown. 

So the two seems unrelated.
https://hg.mozilla.org/mozilla-central/rev/d9c414e61a09
https://hg.mozilla.org/mozilla-central/rev/43dd0a4dcfa8
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox40: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
(Assignee)

Comment 14

4 years ago
Comment on attachment 8601444 [details] [diff] [review]
Part2. Ignore kVTDecodeInfo_FrameDropped flag

39: Approval for part 2 only
40: Approval for 39 and 40.

Approval Request Comment
[Feature/regressing bug #]: bug 1062098:
[User impact if declined]: video playback will not work on mac. On some hardware frames are incorrectly tagged as dropped and we won't display them
[Describe test coverage new/current, TreeHerder]: Partial revert of commit. 
[Risks and why]: Very low. We've ran for several revisions without bug 1062098 applied. This is just reverting to the prior behaviour
[String/UUID change made/needed]: None
Attachment #8601444 - Flags: approval-mozilla-beta?
Attachment #8601444 - Flags: approval-mozilla-aurora?
Jean-Yves - Do you mean to uplift part 2 to aurora (still 39)?  40 is still Nightly until next Monday.
status-firefox39: --- → affected
Flags: needinfo?(jyavenard)
Marking this as a regression.   

Maja, can you have a look to make sure this is fixed in Nightly?

Let's make sure to verify the fix as well on Aurora once this is uplifted.
Keywords: regression
Fixed on Nightly, eee!
(Assignee)

Comment 18

4 years ago
(In reply to Liz Henry (:lizzard) from comment #15)
> Jean-Yves - Do you mean to uplift part 2 to aurora (still 39)?  40 is still
> Nightly until next Monday.

The issue affect 39 , so it needs to be uplifted there...
Flags: needinfo?(jyavenard)
Comment on attachment 8601444 [details] [diff] [review]
Part2. Ignore kVTDecodeInfo_FrameDropped flag

Approving both patches for uplift to aurora. This doesn't need uplift to beta after all as it wasn't broken in 38.
Attachment #8601444 - Flags: approval-mozilla-beta?
Attachment #8601444 - Flags: approval-mozilla-aurora?
Attachment #8601444 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.