Hacker News new | ask | show | jobs
by amelius 3253 days ago
We're seeing a lot of different formats lately. So to make this more generic, I'm thinking we should move to an encoding-independent format. That is, the file contains an encoding-id, and the decoder can be downloaded from a standard location (a website run by a standards organization) using the encoding-id as a reference. Of course, this can be cached.

The decoder can be in different formats, e.g. bytecode, WASM, i386, ARM, etcetera. But of course, any binary decoders should be verified by the standards organization before it is published.
2 comments
icebraining 3253 days ago
Sounds like a recipe to leave out unpopular platforms in the cold. What are the chances Adobe or whoever makes their decoder compatible with Haiku or NetBSD? At least with a few standard formats, volunteers have some hope of writing their own decoders once every few years. Plus, what about more restricted platforms? Lots of featurephones include browsers that can decode JPEG and PNG, but good luck getting them to download and run a custom software based decoder.
link
a_t48 3253 days ago
The file does contain an encoding-id - it's the last three or so characters in the filename (alternatively, the first four bytes in the file data).
link
amelius 3253 days ago
Yes, but the amount of encodings is pretty limited. It's better (imho) to make the encodings free of any viewer or browser. That way, we can more easily handle a large variety of encodings, and different versions of encodings. Anyone could make a new encoder, and create files using them.

You can see it as a "democratization" of encodings.

link
janwas 3253 days ago
The FourCC at the beginning is indeed your encoding-id. This is common in file formats (e.g. RIFF). Out of curiosity, how is the 32-bit space insufficient?
link