BD/HD-DVD SUP experts: help needed

[0xdeadbeef]

This is directed to all experts regarding Blu-Ray and HD-DVD subtitle streams (SUP). Hope that someone out there is able and willing to help me out.

While developing BDSup2Sub, I stumbled over several issues that are still unclear to me and that I feel can't find on my own due to lack of documentation, reference tools or whatever. I'd really appreciate any help on these topics.

1) PTS and DTS time stamps of Blu-Ray SUPs
While I think that I understood the contents of the BD-SUP stream to a degree that I can create more or less correct packets containing palette, window and picture information, I'm not quite sure about the time stamps.
I understand that only the PTS info of the PCS packets is needed to identify the start and stop of display. Yet, while a SUP with correct PTS for (only) these two packets for each subtitle frame is displayed correctly in SupRead, I have reports that muxed to a transport stream, they are not displayed at all.

Since the DTS info is already missing in the SUPs created by EAC3TO, I'd suspect that TsMuxer analyzes the PTS info of the various packets and calculate a multiplex (or frame???) rate from the size of the packet and the according PTS info(s). Yet I was kinda unable to find out which PTS from which packets are needed for this and how to exactly determine the PTS from packet length and the known PTS of the start/stop PCS packets.

Here's an example of the various PTS time stamps from one frame of a BD-SUP created by EAC3TO ( offset to the preceding PTS after the packet name)

PTS Packet Offset
01704BA3 PCS <- start time (known)
01704B4C WDS -87
01703484 PDS -5832
01703532 ODS +174
01703532 END +0
01767B40 PCS +411150 <- end time (known)
01767AE9 WDS -87
01704BA3 END

Suprisingly, the PTS of the WDS packet (which follows after the PCS packet) has a smaller time stamp.
The time stamp of the PDS (palette) and ODS (picture RLE buffer) packets are way (!) before the start time stamp.
I played with the idea that e.g. the (negative?) offset of 5832 was somehow related to the size of the palette info. In this example, there are 254 palette entries, each 5 bytes in size. Ignoring additional data in this packet: (1270*8)/(5832/90000) = 156790 bits/s. Does this make any sense??? I wouldn't think so, especially since following this logic, the ODS packet would need a much larger offset - which it hasn't.
I kinda completely fail to see the logic in this.

Or am I completely off the track and it's the missing DTS info tha TsMuxer needs? At least (and in contrast to EAC3TO) it seems to export the DTS info for some packets.

Clues?

2) Order of Cb and Cr components in BD-SUPs and HD-DVD SUPs
I'm not quite sure about the order of the Cb and Cr color components in the palette info of BD- and HD-DVD SUPs and unfortunately, I didn't find a single example of a colored (non white) subtitle for either formats to verify this.
BDSup2Sup currently assumes that the palette info in a BD-SUP is stored like this: "Index, Y, Cb, Cr, Alpha", while it is stored like this in HD-DVD SUPs: "Y, Cr, Cb". Is this correct or a the Cr/Cb components swapped for either or both format(s)?
[EDIT]
Ok, found out myself that BD-SUP is definitely using "Y, Cr, Cb" ("Iron Man" uses colored captions). So HD-DVD is probably the same.

3) Video size in HD-DVD SUPs
While VobSub and BD-SUP contain size information (e.g. 1920x1080 or 720x480) of the video stream for each subpicture frame, the HD-DVD SUP format doesn't seem to have this kind of information. Is it safe to assume that the size of the video stream of a HD-DVD is always 1920x1080?

4) Maximum number of palette entries for BD-SUP
While it seems logical to assume that the maximum of entries is 256 for an 8bit palette, all the BD-SUPs I encountered had only 255 entries or less. Is there a limitation to 255 or is this just by chance?

5) Forced Subs in HD-DVD SUPs
I couldn't find any info if there are "forced" subtitles in HD-DVD SUPs as there are in BD-SUPs. If so, where?

6) Multi-Packet RLE-Buffers in HD-DVD SUPs
Since SUB/IDX as well as BD-SUP spread the RLE buffer over multiple packets, I wondered if HD-DVD SUP streams can do so as well.

7) WDS info used for what?
What exactly is the info in the WDS packet used for? As the image size and offset is also stored somewhere else, the info there seems to be redundant. So can the information from the WDS packet be discarded completely or is it useful for something?

[0xdeadbeef]

Ok, this is a frame from a stream demuxed by TsMuxer:

PTS DTS Packet Size
003B56F5 003B3FDF 16 0013
003B56A7 003B3FDF 17 000A
003B3FDF 00000000 14 04FD
003B407B 003B3FDF 15 2123
003B407B 00000000 80 0000
00411FED 003B56F4 16 000B DTS is more or less the PTS of the start PCS
00411F9F 003B56F4 17 000A
003B56F4 00000000 14 0002
003B56F4 00000000 80 0000

As you can see, some DTS fields are nonzero here. The DTS of the end PCS is more or less the start PTS. But how is the start DTS 003B3FDF calculated? And how are the additional PTS (of packets 14=PDS, 17=WDS, 15=ODS) derived?

AFAIK the DTS in an MPG stream is calculated from the size of the field and the multiplex rate. But how should I know the multiplex rate of the target stream?
Besides, even if I add the packet sizes of ODS and PDS, the multiplex rate seems to0 low:
(0x2123*8+0x4fd*8)/((0x003B56F5-0x003B3FDF)/90000) = 1189035.53
This is about 1MBit/, but a Blu-Ray can have up to 48MBit/s.

What am I missing? Any M2TS gurus out there?

[GZZ]

4) Maximum number of palette entries for BD-SUP
While it seems logical to assume that the maximum of entries is 256 for an 8bit palette, all the BD-SUPs I encountered had only 255 entries or less. Is there a limitation to 255 or is this just by chance?

I think the last entries are reserved for Color value 0 (black) and alpha value 0 (complete transparent). I had a few subs where it had 1 palette lower then what index the rle code used. Ex it keept requesting index 255, but the palette only had 70 index used, so I assumed that the last value (255) is somehow reserved as a transparent index or something like that. Not that I like the idea of using a index, that isnt represented in the color palette.

Hope it makes sense.


Regarding the PTS value calculation, I cant figure it out. Been posting around the forum, but no one seems to know. :(

I you have figure it out, please let me know.

/GZZ

[0xdeadbeef]

This posting is rather old and since nobody ever answered it, I kinda didn't feel responsible to post my progress here.

I think the last entries are reserved for Color value 0 (black) and alpha value 0 (complete transparent). I had a few subs where it had 1 palette lower then what index the rle code used. Ex it keept requesting index 255, but the palette only had 70 index used, so I assumed that the last value (255) is somehow reserved as a transparent index or something like that. Not that I like the idea of using a index, that isnt represented in the color palette.
Indeed AFAIK the whole palette (256 entries) must be filled with a fully transparent color before it is changed by PDS segments, so a fully transparent color never has to be defined (still most SUPs do it). Palette entry 0xff by definition must stay fully transparent as this is the color index used for clearing the screen.

Regarding the PTS value calculation, I cant figure it out. Been posting around the forum, but no one seems to know. :(
I you have figure it out, please let me know.
I think I have figured it out, yet the feedback is not overwhelming if the SUPs exported by BDSup2Sub now always show up correctly on all standalones.

Anyway, this is what I figured out for a typical SUP in hours and hours and hours of work. I can only hope that you can appreciate how much work I put in this and give me some credit for it at least:


Misaligned SUP

epoch1 : windows and object size = 452*61, video size = 1920*1080

PTS DTS Packet Size
003B56F5 003B3FDF 16 0013 PTS-DTS=5910 -> (9*1920*1080)/3200 = 5832 , 9*452*61/3200 = 78, 5832+78 = 5910
003B56A7 003B3FDF 17 000A PTS(WDS)-PTS(PCS) = 78 = 452*61*9/3200
003B3FDF 00000000 14 04FD PTS(PDS) == DTS(PCS)
003B407B 003B3FDF 15 2123 PTS(ODS) - DTS(ODS) = 156 = 452*61*9/1600
003B407B 00000000 80 0000 PTS(END) == PTS(ODS)

00411FED 003B56F4 16 000B DTS is more or less the PTS of the start PCS
00411F9F 003B56F4 17 000A PTS(WDS)-PTS(PCS) = 78 = 452*61*9/3200
003B56F4 00000000 14 0002
003B56F4 00000000 80 0000

[rica]

I kinda didn't feel responsible to post my progress here.


No comment here.

[0xdeadbeef]

No comment here.
Sorry, but this is just dumb. Please don't post (here) if you have nothing to say.

[rica]

Sorry, but this is just dumb. Please don't post (here) if you have nothing to say.

OK mom.
You are the one who leaves nothing to say anything more not me btw.
Take care.

[GZZ]

I have 2 question regarding your calculations.


Misaligned SUP

epoch1 : windows and object size = 452*61, video size = 1920*1080

PTS DTS Packet Size
003B56F5 003B3FDF 16 0013 PTS-DTS=5910 -> (9*1920*1080)/3200 = 5832 , 9*452*61/3200 = 78, 5832+78 = 5910
003B56A7 003B3FDF 17 000A PTS(WDS)-PTS(PCS) = 78 = 452*61*9/3200
003B3FDF 00000000 14 04FD PTS(PDS) == DTS(PCS)
003B407B 003B3FDF 15 2123 PTS(ODS) - DTS(ODS) = 156 = 452*61*9/1600
003B407B 00000000 80 0000 PTS(END) == PTS(ODS)

00411FED 003B56F4 16 000B DTS is more or less the PTS of the start PCS
00411F9F 003B56F4 17 000A PTS(WDS)-PTS(PCS) = 78 = 452*61*9/3200
003B56F4 00000000 14 0002
003B56F4 00000000 80 0000


The text in red, where did you come up with these numbers, are they calculated based on something else or just some numbers you just figured out to make it work ?

I did a calculation and based on the results it very close to Supread and TSmuxer results, but still not spot on, so there must be a small variation that isnt taking into account. But your numbers are still highly appreciated.

[0xdeadbeef]

I have 2 question regarding your calculations.
You're welcome. It's always a pleasure to help when people are so overwhelmingly grateful.


The text in red, where did you come up with these numbers, are they calculated based on something else or just some numbers you just figured out to make it work ?
9/3200 and 9/1600 are just simplified (canceled down) versions of
90000/256000000*8 and
90000/128000000*8
were 90000 is the time resolution, 8 is for bit->byte conversion and the large numbers are the decoding and composition pixel rates (in bits per seconds).

I did a calculation and based on the results it very close to Supread and TSmuxer results, but still not spot on, so there must be a small variation that isnt taking into account.
The above example is exported from TsMuxer and the results are 100% exact. Note that the values have to be (always) rounded up ("ceil" function). E.g. 155.0925 is rounded up to 156 etc.
Then again, the above example is a very simple example of course. E.g. if the windows and image size differ, this has to be taken into account. There also could be more than one window or more than one composition object etc.
You'll soon find out that (non-interactive) presentation graphics streams can be pretty complex and that some of your current assumptions of the BD-SUP format are wrong.

[GZZ]

9/3200 and 9/1600 are just simplified (canceled down) versions of
90000/256000000*8 and
90000/128000000*8
were 90000 is the time resolution, 8 is for bit->byte conversion and the large numbers are the decoding and composition pixel rates (in bits per seconds).


Thanks for explaning this.


The above example is exported from TsMuxer and the results are 100% exact

Yes it is, I had a wrong parentheses, so the calculation was off. I did a test on the original file and your calculations are spot on, this is great.


You'll soon find out that (non-interactive) presentation graphics streams can be pretty complex and that some of your current assumptions of the BD-SUP format are wrong.

I try not to make any assumptions here, I know it can be very tricky, but I did myself test the load procedure alot and still havent found any subs my program dosnt load, not said that its fail proff, as I havent tested every subs I can find.


Thanks again.

[0xdeadbeef]

I try not to make any assumptions here, I know it can be very tricky, but I did myself test the load procedure alot and still havent found any subs my program dosnt load, not said that its fail proff, as I havent tested every subs I can find.
Just wait until people begin to complain. Less than half of the SUPs I tried loaded correctly. Even then only the simple cases (which is the vast majority though) were displayed correctly. Which is still pretty impressive for a 0.1. Yet, it's still a long way to go.

Admittedly BDSup2Sub 2.8 and 2.9 have different issues with complex SUPs as well. 3.0 will reduce these issues to a minimum, but still there are lots of things in a PGS that it doesn't support (and some it never will).

Just one hint about wrong assumptions: there is no dedicated end marker at all.

BTW: after canceling loading, BDSupEdit doesn't allow to load another files as all (but help) menu items stay disabled.

[GZZ]

Can you post some of these subs, then I could debug them and maybe we couldt help each other.

Please post one of them, you cant get working in my tool.

Email it to me at Henrik @ hbar.dk

BTW: after canceling loading, BDSupEdit doesn't allow to load another files as all (but help) menu items stay disabled.

I have a look on that one, thanks.

[0xdeadbeef]

Please post one of them, you cant get working in my tool. Email it to me at Henrik @ hbar.dk
I uploaded a 23MB ZIP with a few examples to SendSpace and sent you a PM. All of these show correctly in BDSup2Sub 3.0. Also SupRip does a fairly good job on most of them (apart from wrong color order and failing on fade outs).

I have a look on that one, thanks.
There are some more issues tough. E.g. I exported an upscaled SUP which has all kind of issues (cropped bitmaps, background rectangles turned into funny shapes). Also the SUPs that are loaded ok are not always processed correctly (missing frames).
Then again, I guess the samples I sent you will keep you busy for a while.