PGS: EpochStart vs. AcquisitionPoint

[wswartzendruber]

Greetings! In my endeavors into PGS handling, I have encountered the following different sequences throughout my bitstreams:

1. EpochStart -> Normal
2. EpochStart -> AcquisitionPoint -> Normal
3. AcquisitionPoint -> Normal

In all cases, Normal display sets have repeat definitions of windows but nothing else in it and these seem to effectively clear the screen.

#1 above seems to be the norm. EpochStart puts captions up and Normal tears them down.

I can find occurrences of #2 here and there, but it's not that common. EpochStart is the initial application of a/some caption(s), AcquisitionPoint refreshes the player's memory in case it happens to seek directly to that display set, and as is the usual case Normal clears the screen.

The one that has me really confused is #3. Particularly because I see this pattern mixed in with bitstreams that also use #1.

Why would a bitstream use #3 for a particular caption instead of just using #1?

[cubicibo]

An epoch ends only when the next one starts. A Normal Case with no composition does not terminate the epoch, it just wipes the graphic plane to remove the overlaid compositions. It may be followed by another Normal Case featuring a new composition that reuses the object in the buffer. E.g. to blink a subtitle.

So, use-cases #1, #2 and #3 can all lead to #3 as long as the windows are identical. Additionally, there may be more than one Normal Case after an Acquisition Point or an Epoch Start to perform some operations with the defined objects or compositions. #1 to #1 means an epoch start between two subtitles: these cannot be displayed one after the other without a screen blink, as the graphic planes are always erased on epoch start.
#3 alone would likely originate from a sliced stream or seamless branching M2TS.

Here's a sample file: Nichijou60fps_NC (https://cdn.discordapp.com/attachments/1111362568515244152/1149826737631408259/test_palups_ncs.7z?ex=65456d98&is=6532f898&hm=fd5edee174b78c4f542e8498b05911fe9e3d355f7493f9510bb1c7262ac4e638&) contains long epochs with sequences of #1 and #2 always followed by numerous #3s. There's even some Normal Cases with object redefinition (00:00:41:01, 00:00:45:31, 00:01:05:36, ...) to illustrate some capabilities of Normal Case. Be aware that those NC have an incorrect DTS in this sample, but this is irrelevant to this discussion.