PGS: palette_id Defined without palette_update_flag

[wswartzendruber]

For my Rust PGS implementation, I had a pull request come through for palette_id to be preserved even when palette_update_id isn't set. The contributor stated that this caused VLC to correctly show the subtitles they had.

According to footnotes [0101] and [0102] of the patent, palette_update_id is set when the PCS (and therefore the DS?) defines only a palette update over a previous palette. If this is signaled, then palette_id defines the palette that is being updated.

It would seem, then, that defining palette_id without palette_update_id is nonsensical. So if that contributor's subtitles started working when this assumption was discarded, then either:

1. Their subtitles are bad and VLC is also behaving incorrectly.
-or-
2. These fields work differently in practice than the patent describes.

Can anyone help me with how these fields are used in practice? I need to have a solid understanding of this before continuing further with my PGS4NET (https://github.com/wswartzendruber/PGS4NET) project.

Here is the original pull request. (https://github.com/wswartzendruber/pgs-tools/pull/1)

[cubicibo]

Palette ID is always present. It tells the decoder which palette should be used to display the graphics at PCS.PTS, whatever they are drawn thanks to a WDS segment, or a palette update evaluated on an existing composition on the graphic plane.

[wswartzendruber]

Palette ID is always present. It tells the decoder which palette should be used to display the graphics at PCS.PTS, whatever they are drawn thanks to a WDS segment, or a palette update evaluated on an existing composition on the graphic plane.
I, er, hang on...

https://github.com/wswartzendruber/PGS4NET/commit/8163e374d167a8dd3f5e35c782d237982cf3f6dd

...okay, that's better.

So if palette_update_only is set, does that mean the PCS won't define any new composition objects because all its doing is a color update on an existing window+object pair?

[cubicibo]

When the palette update flag is set, the graphics controller is instructed to load the specified palette to the CLUT block after the graphic plane. You may additionally update the content of the palette of interest with a PDS (=> [PCS, PDS, END]) or use another existing palette previously defined (=> [PCS, END]).

And you are correct, hardware decoders do not care about the composition objects when the palette update flag is set. The composition objects are only meaningful when a WDS is provided, as the WDS triggers a new composition.
However, FFmpeg will fail if the composition objects are not kept, as it does not implement the graphic plane and re-renders the objects every display set.

Providing both WDS and palette_update_flag is most likely undefined behaviour, as both trigger a different type of screen update. Providing neither is a displayset that does not perform any visible operation, but may provide objects for future usage.

[wswartzendruber]

I must thank you so very much for your insight. If the PGS4NET project ever becomes successful, it will be because you have been a valuable benefactor.

[wswartzendruber]

So going by the first page of the patent, it looks like a single epoch can be responsible for really showing multiple captions by defining a large object at EpochStart with initial cropping, followed up by NormaCase display sets that change the crop rectangle?

I'm trying to work out what all can go in within an Epoch.

1. Palette updates.
2. Composition updates?

[cubicibo]

These are the two operation that triggers an output, with the second being done by a WDS.

But what you call a composition update can be anything. In a normal case you can freely define new objects or re-define existing ones while keeping the other already buffered objects. You may change the composition objects to update the cropping or forced flag, and so on. The composition information is carried to the display as long as you provide a WDS.

Moves, wipes, forced flag, or changing objects altogether -> WDS
Karaoke, fades, color effects on the same already drawn graphics -> palette update (no WDS)

You can indeed do karaoke, fades, and color effects by performing a standard normal case where you re-use buffered objects ([PCS(Normal), WDS, PDS, END]), but this operation is bandwidth constrained, as the graphic plane is drawn at 32e6 pixels per second (~50% of 1920x1080@29.97), while palette update are instantaneous and can be used on full screen overlays every frame.

[wswartzendruber]

What conditions have to be met for the player to pull everything off the screen?

[cubicibo]

A palette update with transparent entries or a display set [PCS, WDS, END] with no composition objects?

Palette update: PTS(PCSn+1) >= PTS(PCSn) +frame_duration
WDS action: PTS(PCSn+1) >= PTS(PCSn) + plane_write_duration

Plane write duration is the sum of "area of window_i * 90k/32e6 ceiled". +1 tick added to avoid PTS(WDS)=PTS(PCS).