Optimize deallocation performance of MSE buffered media objects |
|
Issue descriptionBug 774268 tracks moving the destruction of WMPI's ChunkDemuxer to a background task to avoid renderer hang crashes on Windows. That relocation of work defers potentially slow destruction work, but doesn't reduce the actual amount of destruction work (unless the renderer process is killed first, eg by closing all of it's tabs). Slower, memory constrained systems, may experience deferred ongoing disk churn as the destruction pages in all of those scoped_refptr StreamParserBuffers to decrement their ref counters and destruct them. Even on a Z620 linux machine, ~7-8GB of buffered media (low res compressed webm AV, about 3.9 million video frames, plus audio across about 130 elements) (before the fix for bug 774268 ) took about 4 seconds to destroy. With the fix for bug 774268 , the destruction appears instantaneous (e.g. page reload makes visual progress almost instantly versus the 4 second delay), but the destruction work would still consume those 4 seconds in the background. Possible optimization: * Investigate arenas / partition allocators for use in storing raw or unique_ptrs to StreamParserBuffers during MSE parsing and buffering; and copying from there to produce on-demand scoped_refptr DecoderBuffers on reading from the ChunkDemuxerStreams. This could enable rapid deallocation of buffered media. It could also enable rapid and more accurate determination of "how much media" is currently buffered, when servicing operations like MSE GC. Data, including MSE-WMPI destruction time and ChunkDemuxer destruction time (the latter is included in the fix for bug 774268 ), can assist measuring optimization priority and effectiveness. Initially CC'ing some folks who may have other optimization ideas.
,
Jan 8 2018
Note that ChunkDemuxer::RemoveId() can also trigger simulated exception (renderer hang) due to potentially long duration of paging in and destructing SourceBufferStream contents. After r527125, this is still happening, though at a much lower rate than ~ChunkDemuxer destruction duration causes of renderer hangs prior to r527125.
,
Feb 1 2018
Bug 807814 tracks fixing specifically the RemoveId() RendererHang crashes that exist in trunk even after bug 774288's fix.
,
Mar 29 2018
@#2-3, those are not in ~SourceBufferStream, but in ~SourceBufferState. The SBStreams are kept alive in ChunkDemuxer's |removed_streams_| until ~ChunkDemuxer (done in background by bug 774268 's fix). The remaining low rate of hangs including ChunkDemuxer::RemoveId() in the stack are related most commonly to StreamParser teardown (e.g. MP4 trun SampleInfo vectors, etc).
,
Dec 6
Buffered range removals (e.g. SourceBuffer.remove(start,end)) are also causing renderer hangs: https://crash.corp.google.com/browse?q=REGEXP_CONTAINS%28expanded_custom_data.ChromeCrashProto.url.raw%2C+%27primevideo%27%29+AND+product_name%3D%27Chrome%27+AND+expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BRenderer+hang%5D+media%3A%3AStreamParserBuffer%3A%3A%7EStreamParserBuffer%27 A more general fix might be to switch away from scoped_refptr<StreamParserBuffer> for buffered MSE media (e.g. within SourceBufferStream and SourceBufferRangeBy{Pts,Dts}). Perhaps std::unique_ptr<StreamParserBuffer>, with short-lived scoped_refptr copies of buffers created on-demand when reading from the demuxer. |
|
►
Sign in to add a comment |
|
Comment 1 by wolenetz@chromium.org
, Dec 21 2017