No, it’s definitely saying “if there is a H.264 hardware encoder available, MSE does not support VP8/VP9; but if there isn’t, then VP8/VP9 support under MSE is

No, it’s definitely saying “if there is a H.264 hardware encoder available, MSE does not support VP8/VP9; but if there isn’t, then VP8/VP9 support under MSE is enabled”. There is no ambiguity in the wording. It’s a curious restriction, but I suspect it’s to do with the use cases for MSE and perhaps some inferiorities of VP8 and VP9 codecs for the MSE use cases, though I’m not sure. Adaptive bitrate streaming is caring a bit more about the trade-offs in network, CPU and whatnot, so preferring a codec with hardware support is perhaps reasonable—though I do wonder why it wouldn’t still have VP8 if it had a hardware decoder. I certainly don’t know the details of all this, but the wording on MDN is very clear. Remember also that WebRTC requiring VP8 doesn’t imply that anything else in the browser support VP8. Safari 11, for example, supports WebRTC but doesn’t support WebM or indeed VP8 anywhere else. Only Safari 14 starts to support WebM, and there only from Big Sur on.