571 bytes, text/plain
867 bytes, text/plain
2.25 KB, text/plain
2.11 KB, patch
|Details | Diff | Splinter Review|
1.30 KB, patch
|Details | Diff | Splinter Review|
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).
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.
Looks like more skip to next keyframe fall out.
Maja - can you try the builds before and after bug 1152218 landed?
(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
Report errors back to MP4Reader in a similar fashion to the other MediaDataDecoder.
Attachment #8601241 - Flags: review?(giles)
Assignee: nobody → jyavenard
Status: NEW → ASSIGNED
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.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox40: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
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
Jean-Yves - Do you mean to uplift part 2 to aurora (still 39)? 40 is still Nightly until next Monday.
status-firefox39: --- → affected
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.
Fixed on Nightly, eee!
(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 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.
status-firefox39: affected → fixed
You need to log in before you can comment on or make changes to this bug.