Webm went way too far when they stripped out support for subtitles. The engineers who made that decision should be ashamed.
[1] https://www.webmproject.org/docs/container/#webvtt-guideline...
[2] https://trac.ffmpeg.org/ticket/5641
[3] https://matroska.org/technical/codec_specs.html#s_textwebvtt
Fun fact: several broadcast standards use Bitstream TrueDoc Portable Font Resource, which was supported for embedded web fonts way back in Netscape 4:
https://people.apache.org/~jim/NewArchitect/webrevu/1997/11_...
https://web.archive.org/web/20040407162455/http://www.bitstr...
“The PFR specification defines the Bitstream portable font resource (PFR), which is a compact, platform-independent format for representing high-quality, scalable outline fonts.
Many independent organizations responsible for setting digital TV standards have adopted the PFR font format as their standard font format, including:
— ATSC (Advanced Television Systems Committee)
— DAVIC (Digital Audio Visual Council)
— DVB (Digital Video Broadcasting)
— DTG (Digital TV Group)
— MHP (Multimedia Home Platform)
— ISO/IEC 16500-6:1999
— OCAP (OpenCable Application Platform)”
[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libtiff
[2] https://exiftool.org/#supported (search for "TIFF-based")
That’s an impressive number of CVEs for a fairly modest piece of code, although the sheer number of them dated ≥ 2022 baffles me—has a high-profile target started using libtiff recently, or has some hero set up a fuzzer? In any case libtiff is surprisingly nice to use but very old and not that carefully coded, so I’m not that shocked.
I’m not sure about the absolute offsets, though. In which respect are those more error-prone? If I was coding a TIFF library in C against ISO or POSIX APIs—and without overflow-detecting arithmetic from GCC or C23—I’d probably prefer to deal with absolute offsets rather than relative ones, just to avoid an extra potentially-overflowing addition whenever I needed an absolute offset for some reason.
There are things I dislike about TIFF, including security-relevant ones. (Perhaps, for example, it’d be better to use a sequential format with some offsets on top, and not TIFF’s sea of offsets with hopefully some sequencing to them. Perhaps ISO BMFF is in fact better here; I wouldn’t know, because—well—ISO.) But I don’t understand this particular charge.
I think parsing file format with absolute offsets is similar to handling a programming language with all GOTOs, compared to relative offsets which are more like structured control flow.
So you’re absolutely going to see TIFF containers with JPEG or JPEG2000 tiles used for geospatial, medical, or hi-res scanned images, but given the sad state of open tooling for all of these, there’s little to no compatibility between their various subsets of the very flexible TIFF spec, especially across vendors, and more or less no FOSS tooling beyond libtiff. (Not even viewers for larger-than-RAM images!) Some other people have used TIFF but in such places where’s very little to be gained from compatibility (e.g. Canon’s CR2 raw images are TIFF-based, but nobody cares).
Why did this happen? Aside from the niche character of very large images, Adobe has abandoned the TIFF spec fairly quickly after it acquired it as part of Aldus, but IIUC for the first decade or so of that neglect Adobe legal was nevertheless fairly proactive about shutting up anyone who used the trademarked name for an incompatible extension (like TIFF64, which basically every modern hi-res imaging application requires). Admittedly TIFF is also an overly flexible mess, but then so are Matroska (thus the need for the WebM profile of it) and QuickTime/BMFF (thus 3GPP, MP4, ..., which are vaguely speaking all subsets of it).
One way or another, TIFF is to some extent what you want, but it doesn’t get a lot of use these days. No browser support either, which is likely important. Maybe the HEIF container (another QuickTime/BMFF profile) is better from a technical standpoint, but the transitive closure of the relevant ISO specs likely comes at $10k or more. So it’s a bit sad all around.