Steps to reproduce: * Enable gstreamer pref * Go to http://www.quirksmode.org/html5/tests/video.html Expected results: CPU isn't busy. Actual results: CPU is 100% busy.
6 years ago
Doesn't look to me like it's actually pegging a CPU. On my machine top *does* report 100% CPU usage, but looking closer it's just four cores each being used at 25%. Probably the ffmpeg software decoder.
The CPU load goes up without playing the video.
gstreamer usually syncs audio and video for clients so they don't have to deal with it -- stopping audio from coming down the pipeline if it's ahead of video, or vice versa. In our case, we just want |AmpleVideoFrames| video frames and |AmpleAudioUsecs| audio usecs, which can differ considerably (time-wise). So we'll end up being starved of one or the other until we start playback. This patch just disables the gstreamer audio/video sync because we already do that and it's just getting in the way.
This makes sense. I would add a comment explaining that we run with sync disabled otherwise DecodeAudioData and DecodeVideoFrame can get called in a tight loop, and that gst threads will still block on max-buffers (and not decode everything) if ffox threads can't keep up.
Attachment #766532 - Flags: feedback?(alessandro.d) → feedback+
Attachment #766532 - Flags: review?(cpearce) → review+
6 years ago
Depends on: 752796
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
You need to log in before you can comment on or make changes to this bug.