Hacker News Reader

Comment by eru | Hacker News Reader

You could stick the codec on the DVD itself? They are relatively small programs.

When the DVD format was new, a 300MHz Pentium II CPU could just barely decode the MPEG-2 stream. And that CPU cost almost two thousand dollars at launch:

https://www.cnet.com/tech/tech-industry/pentium-ii-release-d...

In other words, there was simply no way to ship affordable DVD players that would use a general purpose CPU for video decoding. It needed to be in hardware.

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

And with codec. What code it is in? For what architecture or operating system? What is system constraints it has to operate in? Do you have some specification? Do you need to due something beyond it for new codec.

And from security viewpoint running some arbitrary code from disk sounds like questionable idea. Specially for say pc or console...

> 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.

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.

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.

>You could stick the codec on the DVD itself? They are relatively small programs.

Consumer DVD players have (cheaper) ASICs for hardware-decoding of MPEG. The algorithm to decode is literally burned into the chip. It wouldn't have made economic sense for manufacturers to pay extra for general-purpose CPUs such as x86/ARM/MIPS to enable future scenarios of loading & executing arbitrary code from discs.

That would mean letting the disk execute arbitrary code on your machine. No way that ends well.

Bluray does this. And it has network support as an option.

https://en.m.wikipedia.org/wiki/BD-J

Admittedly not for codecs at least.

At least in the earlier years, DVD players had dedicated decoder chips (and often still have now I believe), because general-purpose CPUs weren’t powerful enough or else too expensive at the time. So there wasn’t a software codec you could upgrade.

Reply on news.ycombinator.com