Skip to content

6.19.2 - pgssub: a cue that ends on time without inventing a picture

Choose a tag to compare

@superuser404notfound superuser404notfound released this 10 Aug 07:36
· 831 commits to main since this release

One bundled-FFmpeg change, no engine source change beyond the pin and its test. Drop-in from 6.19.1, no API change.

A repair that took the wrong thing with it

PGS carries no end time. A cue is closed by the start of its successor, which means dropping a damaged display set does not just lose that set, it loses the successor that would have ended the previous cue: the earlier subtitle stays on screen past its authored end until the next intact set arrives. That is #142.

FFmpegBuild has repaired that since 2.1.1 by keeping the palette and object caches across composition state 3 (Epoch Continue), so a bare PCS + WDS + END set could render from retained decoder state.

That repair is withdrawn in FFmpegBuild 2.4.2. The caches are fixed arrays bounded by a count, not by an id namespace: parse_object_segment() rejects a previously unseen object id once objects.count reaches MAX_EPOCH_OBJECTS (64). Retained pre-connection objects therefore occupy the slots a self-contained connection display set needs, and a conformant set conveying a new object id was rejected with Too many objects in epoch although stock FFmpeg renders it. The finding came out of the upstream submission of the patch, FFmpeg PR 23851.

What ships instead

The recovery now sits where the damage is. Outside AV_EF_EXPLODE, a display set whose palette is missing returns the empty subtitle rather than failing: the pts is already set, no rectangle is allocated yet, and the result is the clearing form the object_count == 0 path returns a few lines above. EmbeddedSubtitleDecoder already treats a zero-rectangle PGS subtitle as a clear event, so the predecessor ends at its authored time without any engine change.

It also covers more than before. Any display set that lost its palette, truncated or partially received, closes its predecessor now, not only an Epoch Continue one. With strict error recognition the set is still rejected, unchanged.

What changes visibly

A damaged Epoch Continue set no longer re-renders the previous bitmap from retained state. The predecessor still ends at the authored time, and the damaged set itself shows nothing until the next intact display set, which is what it actually conveys.

Issue142PGSEpochContinueTests is rewritten to that contract and pins all four outcomes through avcodec_decode_subtitle2: the clearing cue and its pts, the unscoped recovery, the unchanged AV_EF_EXPLODE rejection, and a bare Normal set still rendering from retained state.

Dependencies

  • FFmpegBuild 2.4.2. Only Libavcodec changed; FFmpeg n8.1.2, four local patches as before.