1349679 - HTML5 videos displaying only one distinct frame of the video

Status: UNCONFIRMED

(Core :: Audio/Video: Playback, defect, P3)

Description

[Dan D (volunteer tester from the community)]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170322030208

Steps to reproduce:

Have multiple tabs open/high system resource usage

Have multi-process enabled

Load an HTML5 video (Happens with YouTube, news sites, or simple <video> element videos)


Actual results:

Video plays. However, only one distinct frame is shown. The seek bar shows that the video is progressing, so a user may assume that the video is visually simple (just one picture) and working fine.

Sometimes closing an unrelated tab will cause the video to start playing normally.

Comment 1

[Dan D (volunteer tester from the community)]

To reproduce, CPU usage should reach 100% and stay there.

It doesn't happen every time I try to play a video, but pretty often if CPU usage is high (~100%).

I think what I'm seeing is basically video frame drops, dropping all but one frame. This is unusual; intermittent frame drops and maybe stuttering audio are typical, but dropping all frames but one, and having smooth audio all the while, is not so normal. (to be clear: audio plays normally during this bug.)

Haven't re-tested with latest Nightlies.

Comment 2

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

JW - although this is a degenerate situation, I'd say we may want to at least show the key frames.

Comment 3

[JW Wang [:jwwang] [:jw_wang]]

In bug 1258870, we drop late frames instead of pushing them to the compositor. So if decoding is very slow (due to busy CPU), all frames will be late and dropped, and no frames will be updated at all. The change is to keep AV sync and this bug is just a consequence of it when decoding is very slow.

I think we need to strike a balance between dropping all late frames to achieve perfect AV sync and updating frames so the user knows playback is in progress.

It might be a good idea to enforce sending key frames to the compositor. WDYT?

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to JW Wang [:jwwang] [:jw_wang] from comment #3)
> It might be a good idea to enforce sending key frames to the compositor.
> WDYT?

I agree it's probably a little less degenerate if we show some frames rather than dropping everything.

Note once we do this, the few frames we paint will be out of sync with the audio. So I predict we'll instead get bug reports about very few frames being painted, and those that are painted being out of sync.