BDSup2Sub - convert and tweak bitmap subtitle streams (VobSub,BD-SUP,BDN XML,HD-SUP)

[0xdeadbeef]

I answered over there.
Anyway, as usual, I need the sample to give a more useful reply.

[deank]

Thank you!

Daniel_Lechu:

Hi, here´s 4 samples of subtitles ripped from Garfield and garfield 2 DVD.
http://www.megaupload.com/?d=WZRI5T09

Can u help me to learn how to fix the IDX, im new in subtitles and the only i know is extract from DVD to IDX/SUB or rip to STR with SubRip.

Thanks in advance


Edit with lastest responses: my subtitles are separated, only 1 subtitle/file.

Dean, Next Monday i´ll try to post in doom9

[avivahl]

@0xdeadbeef: I have another IFO/SUP (dvd) that doesn't work w/ the latest version (3.9.6). DVDSubEdit opens it and shows the subs. BDSup2Sub opens it and gives a "buffer offset error" when "seeking" to another frame. Will send it over PM.

[0xdeadbeef]

@deank:
I answered in your forum. In a nutshell: the IDX files in these samples are broken in several ways and I don't feel like adding workarounds for this.

@avivahl:
Ok, I analyzed that sample and I guess the problem is that in some of the frames, the odd lines are located first in the RLE buffer instead of 2nd as usual. Admittedly, BDSup2Sub currently can't cope with that inverted field order.
It should be easy to add a workaround though. Hope to fix this within the next few days. I'm just too tired to do it right now and dunno if I will have time tomorrow.

[0xdeadbeef]

Ok, I defeated my weaker self.

07.09.2009: 3.9.6 -> 3.9.7

• Fixed: Vobsub+SUP/IFO: files with swapped odd/even field order in the RLE buffer were not handled correctly.

[avivahl]

Wow. I couldn't expect a better answer than that.

[hubblec4]

Originally Posted by 0xdeadbeef

Ok, I defeated my weaker self.

07.09.2009: 3.9.6 -> 3.9.7

• Fixed: Vobsub+SUP/IFO: files with swapped odd/even field order in the RLE buffer were not handled correctly.

thanks for your work again

[Atak_Snajpera]

Could you add support for none standard resolutions? (sup -> sub/IDX) For example 1920x800. It would be great if we could crop top margin.

[0xdeadbeef]

Originally Posted by Atak_Snajpera

Could you add support for none standard resolutions? (sup -> sub/IDX) For example 1920x800. It would be great if we could crop top margin.

Most probably I don't get the request but how is that different from using the existing cropping feature?

[Atak_Snajpera]

Most probably I don't get the request but how is that different from using the existing cropping feature?

What is command to crop top margin then?

[0xdeadbeef]

The online help says: "/cropy:<n> crop the upper and lower n lines - default: 0"

Then again, you could also open the "move all captions" dialog.

[ps auxw]

Could you add support for two Graphics in a single Event for BDN XML input? This would be quite useful for animated subtitles, since with big images the Presentation Graphics buffer can overflow. Using two smaller images, which still cover the subtitles, avoids this.

References:
http://forum.doom9.org/showpost.php?...2&postcount=81
http://forum.doom9.org/showpost.php?...9&postcount=91

Example:

<?xml version="1.0" encoding="UTF-8"?>
<BDN Version="0.93" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="BD-03-006-0093b BDN File Format.xsd">
<Description>
<Name Title="Undefined" Content=""/>
<Language Code="und"/>
<Format VideoFormat="720p" FrameRate="23.976" DropFrame="false"/>
<Events LastEventOutTC="00:00:53:19" FirstEventInTC="00:00:53:16"
ContentInTC="00:00:00:00" ContentOutTC="00:01:02:12" NumberofEvents="3" Type="Graphic"/>
</Description>
<Events>
<Event Forced="False" InTC="00:00:53:16" OutTC="00:00:53:17">
<Graphic Width="456" Height="75" X="139" Y="621">00001288_0.png</Graphic>
<Graphic Width="405" Height="167" X="759" Y="176">00001288_1.png</Graphic>
</Event>
<Event Forced="False" InTC="00:00:53:17" OutTC="00:00:53:18">
<Graphic Width="456" Height="75" X="139" Y="621">00001289_0.png</Graphic>
<Graphic Width="404" Height="167" X="759" Y="176">00001289_1.png</Graphic>
</Event>
<Event Forced="False" InTC="00:00:53:18" OutTC="00:00:53:19">
<Graphic Width="456" Height="75" X="139" Y="621">00001290_0.png</Graphic>
<Graphic Width="404" Height="167" X="759" Y="176">00001290_1.png</Graphic>
</Event>
</Events>
</BDN>

[0xdeadbeef]

Originally Posted by ps auxw

Could you add support for two Graphics in a single Event for BDN XML input?

Short answer:
No!

Long answer:

I could add support for multiple pictures per frame to the BDN import, but internally, there will be (most probably) always only one picture due to the nature of the internal representation, to allow export to any other format and to not mess with the move/crop features. So when converting from XML to XML or whatever, all pictures of one frame will be merged to one.
Besides, implementation for PNGs using an 8bit palette would be a little tricky and "keep palette" would be impossible for different palettes.

Originally Posted by ps auxw

This would be quite useful for animated subtitles, since with big images the Presentation Graphics buffer can overflow. Using two smaller images, which still cover the subtitles, avoids this.

I severely doubt this. The decoded object buffer for PGS objects is 4MB in size by definition. Since an 8bit palette mode is used for PGS, this means that a picture 1920*1080 in size fits twice in the buffer. So it is simply impossible to get an overflow there with only one composition object within an epoch.

IMHO the wish for having two composition object per frame is based on wrong assumptions and the way I could implement it without breaking the whole program would create the very same BD-SUP stream.

[ps auxw]

Originally Posted by 0xdeadbeef

I severely doubt this. The decoded object buffer for PGS objects is 4MB in size by definition. Since an 8bit palette mode is used for PGS, this means that a picture 1920*1080 in size fits twice in the buffer. So it is simply impossible to get an overflow there with only one composition object within an epoch.

As much as I would like it, if this was true, it isn't. If you read the avs2bdnxml thread you will find that Oleg Rode had trouble with flickering subtitles. Later PHD_1976 tried muxing these subtitles with Scenarist, which reported overflows. After cutting down on image size, so no overflows occured, flickering stopped. It seems graphics are kept in buffer longer than should be necessary.

(Wait, looking at it, it is not the PGS buffer, that overflows, but the Decoded Object buffer, sorry.)

[0xdeadbeef]

As I said: while this is a nice theory this is technically impossible since even a full screen picture per epoch only fills half of the 4MB.

[ps auxw]

Maybe you have another way to explain that:

• Subs were flickering.
• Scenarist complained about buffer overflow.
• Splitting the subs shut up Scenarist and got rid of flickering.

Since automatic splitting requires some ugly calculations, I'd be glad to get rid of it again, so another way to solve the problem would be more than welcome.

[Oleg Rode]

Originally Posted by 0xdeadbeef

a full screen picture per epoch only fills half of the 4MB.

OK, can you help me? I got colorful and beautiful subs (xml+png). BDSup2Sub perfectly eats them. I can accept a little loss of quality in my subs. So, what settings do I need to set in your program to produce Blu-Ray standard compatible subs? I do something wrong and I receive flickering on big objects - especially from 00001288_0.png to 00001483_0.png

Here is a xml+png subtitles pack.
http://rapidshare.com/files/278292300/Valkyria.zip.html

Sorry for my English

[0xdeadbeef]

Firstly, you should rethink the idea of "Blu-Ray standard compatible" (in bold print!) subtitles. It's the authoring tool that is responsible for creating BD compliant streams in the end and only the authoring tool can e.g. guarantee bandwidth limits.

Unfortunately, since some muddlehead decided to leave all the DTS/PTS info from the original multiplexed stream in the SUP files, instead of invalidating or removing it as its the case for HD-DVD and DVD subtitle formats, current free multiplexers seem to assume that the information in the SUP is always valid. Which is a bold assumption to say the least.

This makes the BD-SUP (PGS) format an even more complex beast since in addition to the PGS bells and whistles, it also contains an awful amount of DTS and PTS time stamps which have to consider how long decoding of a composition object takes or how long it takes to render an object. While BDSUp2Sub tries to calculate all of these time stamps to my best knowledge, there is absolutely no checking done if e.g. the created PGS stream hits the bandwidth limits of a Blu-Ray or if there are too many frames to be rendered in a too short amount of time for the graphics processor of a standalone. I must admit that I somewhat doubt this is the case, but then again if you want to display a new 256 color near fullscreen picture every frame, chances are it is.

Apart from this, BDSup2Sub was created to convert typical simple subtitles, not to create fancy animations. It creates the most primitive type of epoch, but doesn't make any use of more advanced PGS features as palette and cropping animations, multiple windows or multiple composition objects per window. All of these features are of course also used to save bandwidth and distribute it more efficiently.

Anyway, chances are that the flickering you observe is caused by simpler causes. E.g. time gaps of a frame due to rounding errors when converting from/to the weird BDN time format. Yet it's also possible that the simple epoch format used by BDSup2Sub (and any other free tool creating BD-SUP format AFAIK) is just not the correct choice for animated subtitles.

Which brings us back to the original request: as far as I can tell, the only benefit of two composition objects per epoch would be a slightly reduced decoding and rendering time. Since these times are typically pretty short, this could only lead to problems if you're really pushing the PGS format to its limits by e.g. using large palettes and updating images at very high frequency.
E.g. the pixel decoding rate is 128e6 bit/s or 16 Million pixels per second. At 24p, this means that 667334 8bit pixels can be decoded per frame (if I didn't make any dumb calculation error). Unfortunately, this is quite a simplification though since also clearing of the screen buffer etc. has to be taken into account.
Anyway, even if saving a little bit of time would really help in some cases, it surely wouldn't fix the issue itself.

[EDIT]
Ok, I had a look at the sample. The problem is most probably really the combination of fading and large images. Firstly, fading in/out is not supposed to be done this way in any subtitle format since this cost too much bandwidth and needs too many updates in a too short amount of time for the graphics processor. Instead only the palette should be updated. However AFAIK there is currently no free tool chain available that will create BD-SUPs with palette animations. Also it would be very difficult to reverse engineer a palette fade from analyzing images, especially if they are truecolor ARGB images. Instead the fade would have to be defined in the XML format (e.g. alpha start value, alpha end value, fade period). Yet I dunno if there are even keywords defined for this.
Splitting the image into two composition objects would maybe really help in this case, yet the main problem is this brute force fading approach.

[deank]

I posted a week ago in easySUP's thread, but I'll repost here again:

edit: I also changed the default 'merge' and 'min display' times of bdsup2sub, so probably it will cause more smooth processing of animated subtitles and no flickering. Still I had no time to test it yet.

edit2: Ok, so I gave it a try with ASS subtitles uploaded by Oleg Rode. There is no flickering and subtitles show and disappear smoothly (fade in/fade out) with 23.976fps 1280x720 source. I was testing on PAL PS3 (60GB model) with firmware 3.00.

TMT also plays these fade in/out 'animation' just fine.

[0xdeadbeef]

Well, maybe there is no problem at all, but theoretically speaking: a software player running even at a not so fast PC will never have problems to render some subtitles in time. On a standalone things might look different.