Open Bug 1054170 Opened 11 years ago Updated 9 months ago

HTML video element consumes memory too aggressively, and may cause OOM or freeze system

Categories

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

31 Branch
x86_64
Windows 7
defect

Tracking

()

UNCONFIRMED

People

(Reporter: duanyao.ustc, Unassigned)

Details

(Keywords: testcase)

Attachments

(2 files)

Attached file many-video-test.htm
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140716183446 Steps to reproduce: Create tens of detached (not presented in main html tree) or normal video elements, set preload=auto or preload=metadata, and set src to a HD video file (720p or above). Watch the memory usage of firefox in task manager. For convinience, you can use the attached htm file to accomplish steps above. Download the file to your disk, load it with FF, input the url to a local HD video file, and click "create 10 detached videos" or "insert 10 videos" several times. If interested, you can also test embed elements instead of video elements. Actual results: On my windows 7 64bit machine, for HD mp4 video, firefox comsumes 30~80 MB for each video element with preload=auto, and a bit less for preload=metadata. Webm consumes a bit less memory than mp4. Therefore, tens of detached video elements can exhauts the virtual memory of 32bit firefox. After that, newly created video elements begin reporting "decode error" in the console, and firefox may even crash. On my machine, 1080p mp4 can crash 32bit firefox for sure, but 720p can't. If the system hasn't enough physical memory, it may be also freezed. Expected results: Video elements in firefox should not consume too much memory, especially for detached ones. Ideally, browsers may discard most memories related to <video> when it not playing, and is invisible (either out of viewport or has display:none) or is detached from main DOM tree, only retain several states (readyState, currentTime, etc). Thus browsers should be able to handle hundreds of <video>s in a page with a small memory footprint.
My recent project is a html5 slideshow editor/viewer based on firefox. Some users added tens of videos to their slideshows, and encountered frequent issues from unplayable videos to browser crashes. I tried to hide slide pages outside the viewport by hidden attribute -- no effect; I tried to detach the DOM nodes of invisible pages -- no effect. HTML5 spec suggests web authors to release video resources by "removing all references to the element and allowing it to be garbage collected, or, even better, by removing the element's src attribute and any source element descendants, and invoking the element's load() method" ( http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content.html#best-practices-for-authors-using-media-elements ). However, I think this suggestion is not good at all. First, it make video/audio not consistent with other embeded elements (img, iframe, embed, object), because other embeded elements can release resources when invisible or detached. Second, it is required to modify src attribute to release resources, which is very undesired in some situations. For example, a slideshow html contains tens videos, and JS is disabled, so there is no way to modify src or preload attributes, so the browser crashes. For another example, in the slideshow editor, we have to modify a video elment's src when it is moved in/out of the viewport. This is not trival to implement, and also clutter other modules significantly, including the undo manager.
Component: Audio/Video → Audio/Video: Playback
Duan, I'm not sure I see what you describe when I use a current nightly build. Can you still reproduce using a current nightly build?
Flags: needinfo?(duanyao.ustc)
Keywords: testcase
Yes, I can still reproduce with 49a1 win32 (http://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-49.0a1.en-US.win32.zip). Here are 3 crash reports produced by the test case (many-video-test.htm) above: https://crash-stats.mozilla.com/report/index/bp-44c24765-389b-4a0b-a5b9-bd17e2160531 https://crash-stats.mozilla.com/report/index/bp-6151f2cd-e493-44dd-ac8b-44d3b2160531 https://crash-stats.mozilla.com/report/index/bp-07d5c112-7ca7-4ffc-8ffb-f5fa32160531 Steps: 1. Download many-video-test.htm above and put it along with a HD (1920x1080) mp4 file (say video1.mp4). 2. Open many-video-test.htm by firefox, keep all options as-is. 3. Click "insert 10 videos" 2-5 times. Firefox or the tab should crash.
Flags: needinfo?(duanyao.ustc)
Attached video video1.mp4
A HD mp4 file to reproduce crash.
At the point in time you filed this bug we had much bigger fish to fry. We should try to fix this issue.
Priority: -- → P2
Mass change P2 -> P3
Priority: P2 → P3
Ni JW to see if his dormant mechanism can fix this bug or not.
Flags: needinfo?(jwwang)
Yeah, the dormant mechanism definitely helps reducing memory usage.
Flags: needinfo?(jwwang)
Flags: qe-verify?
Severity: normal → S3

Changing qe-verify? to qe-verify+.

Flags: qe-verify? → qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: