PGS: Referencing Objects Outside the DisplaySet?

[wswartzendruber]

I've done piles of Blu-ray discs with my Rust PGS implementation. But it crashed on Star Trek VI 4K:

"Object referenced by composition not found."

This happens when a composition object inside of the PCS references an object not defined within the display set.

Now in the movie, it manifests as two captions being visible at the same time.

Does anyone who actually knows PGS know if this is a bitstream error on the part of the movie, or if this is actually a thing that PGS does? I'm assuming the object is elsewhere within the epoch...

I'd rant about how brain-deficient this format is, but I'm just way too tired right now...

EDIT: I'm going to go buy ice cream, root beer, and make a float.

[cubicibo]

If the PCS of the display set is a normal case, it should be able to use the content in the object buffer defined in previous display sets. Up to the latest acquisition or epoch start.
First time I hear about a PGS being like this. Probably yet another poor engineer that was requested to implement PGS from bad specs and had to experiment, like Avatar 3D subs.

Anyhow now you know the right way to flicker a subtitle with PGS. Simply set/unset the composition object in a normal case PCS every other frame :^)

[wswartzendruber]

On my local machine, I've got pgsmod currently outputting a warning whenever this is encountered and just not doing anything about it.

It seems like Start Trek VI has bad subtitles.

Is there any disagreement?

[cubicibo]

Yes, because this is allowed by the PGS specs. Palette updates works in a similar manner and reference an object defined in a previous display set.
A sample would be welcome, as always.

[wswartzendruber]

https://wswartzendruber.net/uploads/...ialogue.sup.xz

Two occurrences:

01:18:27.870
01:18:29.205

[cubicibo]

That's the standard way to display two (not synced) objects within an epoch and then undisplaying one after the other.
DS#1 (Epoch start): "Don't catch any bugs!" (Object#0), PDS#0
DS#2 (Normal case): "[laughing]" (Object#1) is displayed along Object#0 using PDS#0
DS#3 (Normal case): Undisplay Object#1
DS#4 (Normal case): Undisplay everything (empty composition list - end of epoch)
This would not work if DS#2 was an acquisition point or if there were a third object.

The other way is to perform epoch acquisitions. It is easier to follow what's going on on screen using the stream but much more intensive on the hardware decoder:
DS#1 (Epoch start): Object#0, PDS#0
DS#2 (Acquisition): Object #0, Object#1, PDS#0 (Object#0 and PDS#0 lost due to acquisition, have to be redefined)
DS#3 (Normal case): Undisplay Object#1 <- you can also do an acquisition here where you define again only Object#0 and the second window has no composition.
DS#4 (Normal case): Undisplay everything (empty composition list - end of epoch)

Also this is the preferred solution when you have complex epochs with many subtitles so you're sure the buffer is flushed frequently.

[wswartzendruber]

I think my Rust implementation is going to continue as-is, at least for now. It's been made under the assumption that PGS has clean abstraction, in other words, that display sets are self-contained (each PCS doesn't reference anything outside of the display set). At this point, I don't even trust epochs to be self-contained (something might not get undisplayed before the next EpochStart).

I've begun work on a .NET Standard 2.0 library. It already handles segments. But in order for the library to be useful, it will need to be intuitive to use. I am thinking of having an event-driven playback mechanic wherein events are executed such as ObjectDisplayed and ObjectRemoved, as well as things like ObjectChanged. PTS and DTS values would be passed by reference and could be modified here, if desired, along with the objects themselves