https://trixter.oldskool.org/2014/06/19/8088-domination-post...
As it turns out, the video was encoded in such a way that it could be played back using the display bandwidth of the original PC, BUT doing that encoding required a modern computer to perform in a reasonable amount of time.
In software, quite possibly not[0].
But I'm sure we could have built hardware decoders that were up to decoding AV1 or HEVC back in the 90s no problem, had those codecs existed at the time.
[0] Somewhat later than the timeframe we're talking about, but I remember with pain the moment I realised my 600MHz Athlon, with 256MB RAM and 32MB GeForce 256 video card, was thoroughly obsolete because it couldn't decode and play the original Half Life 2 preview without stuttering, screen tearing and, indeed, crashing.
I think this is a common trend for algorithms that are in wide use, where you have Moore's law like behavior on the hardware side and then also software optimizations that give their own order of magnitude speedups.
But anecdotally I'll share that one of my brother's college roomies was a consultant for RealVideo and was behind their initial codecs. He came back to them with algorithmic improvements a bit later and they just cold shouldered him saying the existing codec was good enough.
So who knows if the biz side folks at the time would have even seen value in better codecs, as unbelievable as that seems to us now in the streaming and zoom call world.
a) it's a legacy product that operators don't care about anymore.
b) latency is important for voice, but modern voice calls have terrible latency. POTS was digitized (for T1/PRI) with g.711 which provides a 8kHz sample rate and 13 or 14 bit samples encoded down to 8 bit. PRI lines were multiplexed one sample at a time. There's a small amount of algorithmic delay, but not much.
Modern voice calling is packetized, and most systems have packets of at least 20ms, you have more encode/decode time, you probably have a significant sampling buffer, and you may have to wait for network access, so the receiver needs to add a jitter buffer to manage that. Additionally, echo cancelation needs processing time, and it's also harder with longer latency. Some systems use longer packet times to reduce network overhead.
c) codecs: g.711 has a terrible pass band, GSM codec takes the same inputs and compresses it harder. g.722.2 (amr-wideband) is better, but it requires proper call setup and that is problematic for calls from one carrier to another. If you're calling via apps, there's potential for more flexibility, but you likely get whatever the developer thought was good enough.
You can technically have some then-contemporary FMV titles run on N64 with a 64MB cart. The hardware lends itself to it because it has the RSP, a secondary MIPS processor with re-programmable microcode. But the best video compression we had at the time was MPEG-2, which just wouldn't cut it.
https://holmesrpi.org/Books/NumComp2/WebPages/NumComp/Is%20T...