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

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

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

Comment 1

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

Attachment: mozregression log

This is as far as I could get with mozregression:
 Last good revision: 8af276ab8636
 First bad revision: 37ddc5e2eb72

Comment 2

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

Still same behaviour on Nightly build 20150423030204.

Comment 3

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

Attachment: about:support

Comment 4

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Looks like more skip to next keyframe fall out.

Comment 5

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Maja - can you try the builds before and after bug 1152218 landed?

Comment 6

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

(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

Comment 7

[Jean-Yves Avenard [:jya]]

Attachment: Report decoding errors back to MP4Reader

Report errors back to MP4Reader in a similar fashion to the other MediaDataDecoder.

Comment 8

[Jean-Yves Avenard [:jya]]

Attachment: Part2. Ignore kVTDecodeInfo_FrameDropped flag

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.

Comment 9

[Ralph Giles (:rillian)]

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!

Comment 10

[Ralph Giles (:rillian)]

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.

Comment 11

[Jean-Yves Avenard [:jya]]

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.

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d9c414e61a09
https://hg.mozilla.org/integration/mozilla-inbound/rev/43dd0a4dcfa8

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d9c414e61a09
https://hg.mozilla.org/mozilla-central/rev/43dd0a4dcfa8

Comment 14

[Jean-Yves Avenard [:jya]]

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

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

Jean-Yves - Do you mean to uplift part 2 to aurora (still 39)?  40 is still Nightly until next Monday.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 17

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

Fixed on Nightly, eee!

Comment 18

[Jean-Yves Avenard [:jya]]

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

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 20

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/868aa45df966
https://hg.mozilla.org/releases/mozilla-aurora/rev/e4bdd73813c8