Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Subtitles

Reply
 
Thread Tools Search this Thread Display Modes
Old 14th February 2023, 04:00   #1  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 418
PGS: Referencing Objects Outside the DisplaySet?

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.

Last edited by wswartzendruber; 14th February 2023 at 04:08.
wswartzendruber is offline   Reply With Quote
Old 16th February 2023, 00:26   #2  |  Link
cubicibo
Registered User
 
Join Date: Feb 2022
Posts: 121
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 :^)
cubicibo is offline   Reply With Quote
Old 16th February 2023, 06:41   #3  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 418
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?
wswartzendruber is offline   Reply With Quote
Old 17th February 2023, 13:29   #4  |  Link
cubicibo
Registered User
 
Join Date: Feb 2022
Posts: 121
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.
cubicibo is offline   Reply With Quote
Old 18th February 2023, 02:53   #5  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 418
https://wswartzendruber.net/uploads/...ialogue.sup.xz

Two occurrences:

01:18:27.870
01:18:29.205
wswartzendruber is offline   Reply With Quote
Old 18th February 2023, 16:25   #6  |  Link
cubicibo
Registered User
 
Join Date: Feb 2022
Posts: 121
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.
cubicibo is offline   Reply With Quote
Old 20th February 2023, 16:14   #7  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 418
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
wswartzendruber is offline   Reply With Quote
Old 27th February 2024, 06:45   #8  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 418
Does PCS.CompositionState = ACQUISITION reset everything like EPOCH_START?
wswartzendruber is offline   Reply With Quote
Old 27th February 2024, 09:11   #9  |  Link
cubicibo
Registered User
 
Join Date: Feb 2022
Posts: 121
No. The existing buffer allocations (their size) are kept. And the windows should be identical.
cubicibo is offline   Reply With Quote
Old 9th March 2024, 20:27   #10  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 418
The only place I see for an object's active palette to be set is PCS.palette_id.

Does that set a palette? That seems like it doesn't allow for multiple objects to be put up at once each with their own palettes.
wswartzendruber is offline   Reply With Quote
Old 9th March 2024, 22:21   #11  |  Link
cubicibo
Registered User
 
Join Date: Feb 2022
Posts: 121
It is always useful to have the decoder model in mind:


The graphics plane is just a 2 MiB 2D buffer where the uncompressed ODS are copied, as instructed by the composition objects. Then, the 8-bit value of each graphics plane pixel is evaluated in the CLUT block, to fetch the associated palette entry. The CLUT block essentially transforms a WxH array to WxHx4. There is no additional mapping related to object ID, or regioning that maps to one palette or the other in the CLUT block.

In short, the objects always share a common palette. This can be annoying when your stream uses Normal Cases to define an object to accompany an already buffered and displayed one: both objects have to be quantized together, despite them being (partially) independant.

Interactive Graphics Stream permits to associate a specific palette to a given object, but the rendering process is different and much slower.

Last edited by cubicibo; 9th March 2024 at 22:29.
cubicibo is offline   Reply With Quote
Old 10th March 2024, 01:32   #12  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 418
Thank you, as always. You have yet to post an answer that doesn't make things clearer. I am grateful and my project only benefits.

What is the purpose of CompositionObjects and Windows each being able to declare X and Y values? I see that they typically match, but what if they do not?
wswartzendruber is offline   Reply With Quote
Old 10th March 2024, 10:53   #13  |  Link
cubicibo
Registered User
 
Join Date: Feb 2022
Posts: 121
Once you have performed an epoch start (= wiped out the graphic plane according to PCS width and height fields), the graphics controller should only have to re-render the active area: the windows.

Writing 1920x1080 pixels requires ~65 miliseconds at 256 Mbps, or 2-3 frames at 23.976 or 29.97. If you want to achieve frame-by-frame effects, with the decoding overhead, you need to convey the relevant screen area of the overlaying process. Composition Objects are also not necessarily the same size. How would you define the area you have to erase?
This is why changing windows is forbidden. Some decoders would not erase the graphics plane consistently and left-overs would be displayed.

Last edited by cubicibo; 10th March 2024 at 12:32.
cubicibo is offline   Reply With Quote
Old 22nd June 2024, 22:20   #14  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 418
Hi cubicibo,

I've come back to my .NET PGS project after taking a break.

Can I assume that it is undefined behavior for windows to overlap?
wswartzendruber is offline   Reply With Quote
Old 23rd June 2024, 14:32   #15  |  Link
cubicibo
Registered User
 
Join Date: Feb 2022
Posts: 121
It is forbidden by authoring softwares, the answer is then yes. On reference decoders, the overlap will have the content of the secondly rendered window. No alpha blending between windows is performed: the overlap is simply written twice and the first write is lost.
The is_compliant function in SUPer should answer all of your future interrogations and questions in regard to compliancy.

Last edited by cubicibo; 23rd June 2024 at 14:35.
cubicibo is offline   Reply With Quote
Old 23rd June 2024, 14:48   #16  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 418
Whoa, thanks!

That's a whole lot better than surfing this forum looking for your posts with a notebook and writing everything down.
wswartzendruber is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 08:40.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.