MSE: Try to coalesce buffered ranges when fudge room changes
Before this change, an unsorted sequence of buffered ranges could result from complex scenarios (in both ByDts and ByPts API usage). A simple example of such unsorted ranges is [a,b) [c,d), where b > c. This change prevents one known cause of unsorted ranges: when buffering a set of frames emitted from FrameProcessor and those frames change the fudge room, use the new fudge room to try to coalesce any existing buffered ranges before buffering the new frames. This allows the buffering code to correctly identify the (at most one) existing buffered range to which a new buffer or coded frame group start time belongs. Code already exists to ensure that such fudge room changes are only increases. BUG=793247 TEST=SourceBufferStreamTest.RangeCoalescenceOnFudgeRoomIncrease_*, and no more local repro of fuzzer case in crbug 793247 Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: If6f78d56080ecb9bbdaef9df554c07f999d9a0ea Reviewed-on: https://chromium-review.googlesource.com/820656Reviewed-by:Dan Sanders <sandersd@chromium.org> Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org> Cr-Commit-Position: refs/heads/master@{#523641}
Showing
Please register or sign in to comment