Open DavidBuchanan314 opened 3 years ago
Came across a note that Apple devices use a system like this, using an iDOT ancillary chunk to store metadata - https://www.hackerfactor.com/blog/index.php?/archives/895-Connecting-the-iDOTs.html
Might be worth looking into to support that (not standardized, naturally).
Seeing how everyone decided to tackle this issue now I cleaned up my specification for the occasion: https://github.com/libspng/png-restart-marker
PNG is an extensible format - you can add custom Ancillary chunks to a file, and decoders will ignore any such chunk that they don't recognize.
If an Ancillary chunk was added, to store the offsets of the zlib sub-streams, then a decoder could take advantage of this information to parallelize decoding.
Optionally, to allow parallel defiltering, the pixel values of the last row in each block could be included, compressed (this comes with an obvious file-size penalty, however)(thinking about this some more, it'd make more sense to just never use filtering on the first row of each block)Thinking even more about this, a sufficiently intelligent client requesting PNGs over the network could use this metadata to request each chunk over a parallel connection (e.g. using HTTP range requests)