nsOggReader::GetBuffered reads from the media cache, so we'll be potentially reading *from disk* every time we call this. We call nsBuiltinDecoderReader::GetBuffered() in a few places, in particular in nsHTMLMediaElement::GetBuffered(), which runs on the main thread (so this could cause jank), but more critically we use it in nsBuiltinDecoderStateMachine::HasLowDecodedData which we call in nsBuiltinDecoderStateMachine::DecodeLoop and in AdvanceFrame. So when we're playing Ogg we'll potentially be reading *from disk* inside our a decode loop. On desktop the OS is probably caching or prefetching for most of these reads, but on mobile I'd guess this is less likely to be the case. WebMReader is smarter and builds an index as it receives data in OnDataAvailable() and uses that to service GetBuffered(), which is what we should do for Ogg.

While the logic to calculate the buffered range hasn't fundamentally changed. It is no longer called from the main thread. It's called only has new data is downloaded (which potentially could be very often as data is downloaded by block of 32kB) Not sure it's worth spending time on this as the benefits would be rather low considering how little used Ogg is