Split PGS in half (screen)

[tormento]

There are some PGSs that uses upper and lower part of the screen with indipendent and overlapping timings, such as anime ones.

I have asked many times the author of SubtitleEdit to support them but it doesn't seem a urgent issue.

I am here to ask a workaround, i.e. rendering the PGS on a fullscreen, split the screen in upper and lover halves, save the two PGS, so I can OCR them separately and combine later.

Or something likewise.

[von Suppé]

Would you know if PGS streams where images have overlapping times and different positions, are bluray compliant? I don't think I ever encountered/noticed them.

Only workaround I can think of is creating fullframe images with one line keeping its position and where a second is added in the second somewhere. Should they have different end times obviously a third image is required.

As a workflow, you can input text for each textbox with proper start- and end timestamps. Export as fullframe SUP. Convert to xml-png and edit the concerning images. After which convert back to SUP. Lot of work...

[tormento]

Originally Posted by von Suppé

I don't think I ever encountered/noticed them.

They are not overlapping, they simply split variations of the same images in time, keeping and taking away parts that are "overlapping" in time in the image, to have the perception of overlapping PGS, as that is not possible. They are present both in action movies (lot less overlapping parts) and above all animes (where overlapping gets insane).

Get this example.

Originally Posted by von Suppé

Only workaround I can think of is creating fullframe images

I want to simplify my life, during and after OCR, not making worse. The program I use (Subtitle Edit) has no problems recognizing them as characters but they are mixed and overlapped in time.

These are the extracted lines before manual (!) post processing. I just manually added {\an2} ASS tag during the OCR process, to split images/lines that were both on the upper side {\an8} and the lower side {\an2}. During post processing, I group them by time and position but it's really tedious process.

As you can see it's not a problem of OCR itself but of it getting confused of different lines in different text positions, such as top and bottom.

[cubicibo]

Everything is a pain with PGS, but this python script does what you want. Install SUPer as explained in the topic.

I tested it very quickly it seems to work fine. It is a bit slow because we have to decode and re-encode all offending big objects.

[jpsdr]

As far i remember, in Scenarist, when you import subtitles <xml>+PNG, if timing overlaps it's rejected.
But it's difficult to do, and you can't "overlapp" too much, because otherwise your subtitle is rejected (at the end of the process) with buffer overload => you have some kind of limit size buffer, and if after around 6-7 continuous timing subtitles you don't have a break of... around 0.2s without subtitle displayed, you hit "buffer overload".

[cubicibo]

He meant two subtitle lines being shown at the same time at different location (e.g. one on top, one on the bottom).
But yes, if you try to update the graphics too often, you either blow the coded object buffer (1 MiB), its bandwidth (16 Mbps) or the bandwidth at the output of the decoder (128 Mbps). Object buffer itself is never blown up on acquisition unless cropping is used (but cropping does not appear to even work).

[wswartzendruber]

Where does the 1 MiB object buffer limit come from?

[cubicibo]

The patent describes it in drawing 26-27, reference number 13.
TS packets of PG data arrives at, at most, 16Mbps. The coded object receives pieces of PG segments contained in TS packets and concatenate the bytes to get full PG segments. Disclosures 0234 and 0235 state this.
Disclosure 0236 additionally states that the PG segments are consumed from this buffer on their respective DTS. So the buffer is theoretically never full if DTS = 0 for all segments. Of course, this buffer is never empty because segments are only consumed when the blocks ahead are available.