> Well yes, on other hand there is also hardware acceleration case which make lot of sense when you are manufacturing devices at scale.

This. In those days any general-purpose CPU with enough grunt to do realtime software decoding of MPEG2 and hypothetical newer codecs would have needed a fan - which would have been a dealbreaker for a living-room appliance.

Easy: ship source code and the whole compiler toolchain, also in source form, with bootstrapping instructions for a generic machine that future archaeologists will trivially port to whatever architecture is in vogue in year 32768 !

Joke aside, this question is close to the file format obsolescence problem in long term digital preservation: the longer the term, the closer to bootstrapping the answer is.

In the shorter term, detailed metadata, widely used containers and choice of codecs that have well-known open source implementations is a good start.

The solution of the day would have been to put a .jar on each disc and it would have been a nightmare, I think.

There's a JAR on every SIM and payment card and it works fine.

https://en.m.wikipedia.org/wiki/Java_Card

That Java runs on the SIM, not on the AP. The DVD equivalent would be the Java running on the DVD itself, but a DVD is an inert plastic and aluminium sandwich. And even if it looks portable, it’s not. In practice there’s just enough quirks that code written for one Java Card won’t reliably install and run on all others. Actually portable Java Card that would work like DVD codecs would need to work didn’t come until eSIMs, which is decades later.

SIM cards are doing relatively basic transactional crypto functions, not processing many Mbps of data in real time.

Pretty sure bluray did something like this - some sort of java app definition that gets executed to display menus and the like.

For menus it makes sense. For compression schemes I see a lot of downside, mainly inefficiency of hardware.