Skip to content

6.2.1 - ASS PlayRes through CRLF headers

Choose a tag to compare

View all tags
@superuser404notfound superuser404notfound released this 30 Jul 19:52
6.2.1
4e281c9

An ASS script declares the coordinate space its \pos tags are written in, and that declaration was dropped for every track whose header uses CRLF line endings, which is the common case for muxed subtitles.

Fixed

  • An ASS header that declares its play resolution with CRLF line endings is read again. The header arrives as codec extradata byte for byte as the muxer stored it, and muxed ASS is conventionally CRLF, so the line is PlayResX: 718\r. The trim used CharacterSet.whitespaces, which is space and tab but not CR, so the CR survived and Double("718\r") returned nil. Both lookups failed, playRes(fromASSHeader:) reported that the header declares nothing, and every \pos on the track normalized against libavcodec's 384x288 default instead of the declared space (#261).

    On a 718x480 script {\an1\pos(298,432)} reached the host at (0.776, 1.500) rather than (0.415, 0.900). Off-picture, which is indistinguishable from a cue that never arrived rather than a misplaced one, so the failure reads as a missing subtitle.

    Header lines now split on any newline, through Character.isNewline, and both trims are newline-inclusive. A lone-CR header was broken by a second mechanism and is covered too: splitting on "\n" collapsed such a header into a single line, so a trim fix alone would not have reached it. Tracks that declare no play resolution are unaffected, since 384x288 is then the correct basis, as are tracks that declare exactly 384x288.

    Only visible since 5.28.1: before that, placement was dropped on everything entering the retained store, so the wrong coordinates never reached a host on the drained embedded path and the cue rendered unplaced. Reported by rrgomes, traced to the line.

Changed

  • SubtitleTextPlacement.position no longer documents a [0, 1] range. A script may anchor outside the frame on purpose, so that is a range the engine cannot guarantee, and clamping or dropping such an anchor engine-side would hide the next wrong normalization basis exactly the way this one hid. A host that cannot draw off-picture should decide for itself what such a cue means: ignoring the anchor and falling back to alignment-only placement is a sound policy for it. Documentation only, no behaviour change.

Upgrading

.package(url: "https://github.com/superuser404notfound/AetherEngine", from: "6.2.1")

No API change and no source change for consumers. Hosts that honour SubtitleCue.placement get correctly normalized anchors on CRLF ASS tracks with no work.

Assets 3
Loading