Experiment with dynamic memory limits in source buffer stream |
||
Issue descriptionThe memory limits for MSE source buffers are hard coded [0]. For non-android cast builds we use lower limits [1]. Many chromeOs devices have only 2GB of memory and often experience memory pressure with source buffers (really their StreamParserBuffers) being a significant allocation. Thinking about the limits... The current limit of 150MB is decent for 1080p (about 5 minutes), but at 1440p and 4K resolutions this is under a minute of buffer. Say we cut this in half for 2GB systems - I think these higher resolutions are basically off limits when they otherwise may have been ok to playback (if CPU/GPU are good enough). 150MB is only 8% of 2GB - I don't find it all that bad as a starting point. Perhaps we start with todays limits and bump down in response to pressure. [0] https://cs.chromium.org/chromium/src/media/filters/source_buffer_platform.cc [1] https://cs.chromium.org/chromium/src/media/filters/source_buffer_platform_lowmem.cc Other discussion https://groups.google.com/a/google.com/d/msg/cwp-team/DI4RaGg2sQg/2pbNt6DnBgAJ https://groups.google.com/a/google.com/d/msg/videostack-eng/Uhsvl2_cn0o/EqJSvko4DQAJ
,
Dec 9 2016
I think we can significantly improve our behavior even with current hardcoded buffer sizes. Currently MSE GC algorithm is very conservative and only keeps removing data as long as necessary to get under the buffer size cap. This means that any video stream larger than 150MB will use ~150MB of memory in the steady state during playback. But we might try to do a more aggressive MSE GC pass if memory pressure is detected and remove as much data as possible without evicting the GOP containing the current playback position.
,
Dec 9 2016
Btw, there is already a wealth of info on WMPI memory usage available in WebMediaPlayerImpl::FinishMemoryUsageReport - should we add UMA stats logging in there? It would work both for MSE and src= paths.
,
Dec 12 2016
,
Jan 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0 commit f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0 Author: servolk <servolk@chromium.org> Date: Tue Jan 31 16:44:27 2017 Experiment with more aggressive MSE GC on memory pressure Add an experimental ReduceMSEBuffersOnMemoryPressure feature that will make MSE garbage collection algorithm more aggresive when we are under moderate or critical memory pressure. Until now the MSE GC algorithm didn't try very hard to free up memory as long as we are under hard-coded memory cap (150MB for video, 12MB for audio). With this CL the GC algorithm will halve the effective SourceBuffer memory limits under moderate memory pressure and will release as much stale data as possible under critical memory pressure. BUG=672976 Review-Url: https://codereview.chromium.org/2605993002 Cr-Commit-Position: refs/heads/master@{#447245} [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/content/browser/renderer_host/render_view_host_impl.cc [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/content/public/common/common_param_traits_macros.h [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/content/public/common/web_preferences.cc [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/content/public/common/web_preferences.h [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/content/renderer/render_frame_impl.cc [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/base/media_switches.cc [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/base/media_switches.h [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/blink/webmediaplayer_impl.cc [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/blink/webmediaplayer_impl.h [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/blink/webmediaplayer_impl_unittest.cc [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/blink/webmediaplayer_params.cc [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/blink/webmediaplayer_params.h [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/filters/chunk_demuxer.cc [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/filters/chunk_demuxer.h [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/filters/source_buffer_state.cc [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/filters/source_buffer_state.h [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/filters/source_buffer_stream.cc [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/filters/source_buffer_stream.h [modify] https://crrev.com/f94b4608f14a23fcc7e1a1d0f7a01c4a6fca8bb0/media/filters/source_buffer_stream_unittest.cc |
||
►
Sign in to add a comment |
||
Comment 1 by chcunningham@chromium.org
, Dec 9 2016