Bug 570904 implements buffered ranges for WebM. With large files in cases where the file is buffering in slightly unusual ways, insertion of the TimeDataOffset entries becomes quite expensive due to array shuffling (see bug 570904 comment 12). This can be fixed by switching mTimeMapping over to an ordered tree. std::map would be perfect, if it's possible to use that.

This works, but I don't know if using std::map in Gecko is acceptable. Repeating the test in bug 570904 comment 12 with this patch, no NotifyDataAvailable call took longer than 0.5ms except two, which took 1.5ms and 5ms. CalculateBufferedForRange is a bit slower (often taking 0.5 - 1ms per call), but I suspect most that time would disappear in an optimized build.

Also worth pointing out that the per-entry overhead using std::map is something like 44-64 bytes vs 16 bytes for the nsTArray approach. It's possible to reduce the number of entries per file by only storing entries for a single active track rather than for any track data we parse--it's common for there to be ~8 audio entries per video entry for files that aren't using laced blocks.

Mass closing do to inactivity. Feel free to re-open if still needed.