AviSynth rendered subtitles to BluRay SUP/PGS and BDN XML (v2.08)

[hamletiii]

hamletiii, if the PES file made by BD Reathor Pro is dragged into the Scenarist project, can they be attached to the PG section of the playlist editor? If so, that means we can delete the PG objects from the project, right?

I'm not sure what's a playlist ediotr, do you mean Clips?
If you mean Clips, I don't think you can directly drag *.pes into the timeline, I might be wrong though, I don't have scenarist right now. If you drag the *.pes files into Data editor, the language codes will be the same as your project's default language, so you'll have to change it manually. If you just import the entire project, the language code setting will be retained.

[Rectal Prolapse]

Clips, sure. Anyhow, guess I'll have to look into it one day!

[hamletiii]

I just finished a project using tsmuxer, the subtitles are generated using avs2bdnxml and BDSup2Sub (BDSup). I didn't try scenarist this time because the stream is from HD-DVD which is not compilant with Blu-ray.

If splitting -s switch is turned on, there's occasionally the last picture which has only 1 or 2 frames of length, which will cause flickering. (reported less than 500ms in BDSup2Sub.)

- <Event Forced="False" InTC="01:14:56:11" OutTC="01:14:56:19">
<Graphic Width="1920" Height="1080" X="0" Y="0">00107915_0.png</Graphic>
</Event>
- <Event Forced="False" InTC="01:14:56:19" OutTC="01:14:57:03">
<Graphic Width="1920" Height="1080" X="0" Y="0">00107915_0.png</Graphic>
</Event>
- <Event Forced="False" InTC="01:14:57:03" OutTC="01:14:57:11">
<Graphic Width="1920" Height="1080" X="0" Y="0">00107915_0.png</Graphic>
</Event>
- <Event Forced="False" InTC="01:14:57:11" OutTC="01:14:57:19">
<Graphic Width="1920" Height="1080" X="0" Y="0">00107915_0.png</Graphic>
</Event>
- <Event Forced="False" InTC="01:14:57:19" OutTC="01:14:58:03">
<Graphic Width="1920" Height="1080" X="0" Y="0">00107915_0.png</Graphic>
</Event>
- <Event Forced="False" InTC="01:14:58:03" OutTC="01:14:58:04">
<Graphic Width="1920" Height="1080" X="0" Y="0">00107915_0.png</Graphic>
</Event>

For this example, the length of the sentence is 41 frames based on 23.976fps, if I use -s 8 command, the last picture will have only 1 frame, which seems too short to be displayed properly.

So is it possible to have a remainder check at the beginning so that pictures with 1 or 2 frames left be either dropped or appended to the last full frame sentence?

[ps auxw]

So is it possible to have a remainder check at the beginning so that pictures with 1 or 2 frames left be either dropped or appended to the last full frame sentence?
I have added such an option in the newest version (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-1.11.tar.bz2). By default, lines and line rests will not be split further, if the last segment would be shorter than 3 frames. Also, PNGs are now output in 8bit palette format and autocropped. I am still working on SUP output for the next version.

[Oleg Rode]

I am still working on SUP output for the next version.
:thanks:

[hamletiii]

I think there is a typo in the example code:
avs2bdnxml -t Undefined -l und -v 1080p -f 23.976 -a1 -81 -b0 -m3 -o output.xml input.avs

-81 should be -p1

Now, my experience on the latest version 1.11:

I really appreciate your effort in adding 8bit png support, this is a huge time saver since BDSup2Sub is no longer needed to downconvert 32bit png. And the png rendering quality is very good.

I think the tool is quite polished and powerful after the last couple months of development. Just be aware of not using complex subtitling syntax (I would not use any move, rotation, position, karaoke commands; fade seems ok), otherwise the program will generate invalid pictures, which if you don't remove the references to these invalid pictures in xml file prior to importing to Scenarist BD, it will not accept the file due to these errors. I think BDSup2Sub does have a checking mechanism which automatically removes the invalid pictures.


The following are my experiences of making this tool to work with Scenarist BD (latest 5.1x versions):
When importing the fresh generated xml file from this tool, Scenarist BD will keep both a "Import File Path" and "File Path" in property->name field, the former is the path of the original xml file, the latter is the *.pes file Scenarist BD generates. At this point, the original xml file path cannot be changed, if it's changed, Scenarist BD will successful compiling, but you will not see any subtitles.

If you want to remove the xml file with pngs, you can instead re-import the *.pes file (along with the correspond *.mui file Scenarist BD generated at the same time). This time there's only "File Path" in property->name field. The language option will be the project default setting, so changing to the correct language might be necessary.

[ps auxw]

I think there is a typo in the example code:
avs2bdnxml -t Undefined -l und -v 1080p -f 23.976 -a1 -81 -b0 -m3 -o output.xml input.avs

-81 should be -p1
Thanks, you are right. I renamed the switch, and forgot to change the example.

I think the tool is quite polished and powerful after the last couple months of development. Just be aware of not using complex subtitling syntax (I would not use any move, rotation, position, karaoke commands; fade seems ok), otherwise the program will generate invalid pictures, which if you don't remove the references to these invalid pictures in xml file prior to importing to Scenarist BD, it will not accept the file due to these errors. I think BDSup2Sub does have a checking mechanism which automatically removes the invalid pictures.
This is a curious problem. Do I understand correctly that the XML can be imported to Scenarist, when BDSup2Sub is used to palletize the pictures, even with complex subtitles? If so, I will compare results of both methods to find the difference and fix avs2bdnxml.


Also, I'm sorry SUP support is taking so long. I currently don't have much time to work on avs2bdnxml.

[hamletiii]

This is a curious problem. Do I understand correctly that the XML can be imported to Scenarist, when BDSup2Sub is used to palletize the pictures, even with complex subtitles? If so, I will compare results of both methods to find the difference and fix avs2bdnxml.



Sort of, but it comes with a cost - subtitle flickering.
The xml file avs2bdnxml outputs in the last step is faithfully based on what the png pictures are. So if avs2bdnxml generates a couple invalid pictures (usually with fast changing of coordinates or colors), there's no way the xml file can detect and skip them. I think BDSup2Sub can detect and remove those, plus optimizing the timecodes along the way. But in the end you'll get subtitle flickering due to missing pictures.

I don't think there's a way to put really complex subtitles on Blu-ray. The best practice is not using complex ass/ssa syntax in the first place.

[0xdeadbeef]

Just to avoid confusion: BD-SUP (as all other known subtitle formats used on standardized discs) is not meant to display a new large bitmap at each frame. There are several buffer limitations that are violated when too many large bitmaps are to be displayed in a too short amount of time. After all, subtitles are meant primarily to display the spoken words, not to display a video or smooth animation.

Therefore all subtitle formats, including BD-SUP, feature special display commands to e.g. allow fading via palette or alpha animations. This is also why all the bitmap subtitle formats are palette based.

So trying to achieve fade ins/outs with new bitmaps every frame is simply the wrong approach and can never be guaranteed to work with every possible bitmap size on every possible player.

This also applies to all other kinds of fancy animations that are neither palette animations, nor cropping animations or translations. While it may work with small pictures or slower update rates, large pictures and fast update rates will almost certainly lead to problems. To assure this to work, the converter would have to consider all memory/bandwidth limitations of the BD spec which would effectively make it some kind of authoring tool.

To create valid fading/cropping animations, you'd need a way to define them in the XML file and a tool to create the BD-SUP stream with the according display commands. Neither is actually available AFAIK.

Anyway, what BDSup2Sub removes are cropping and palette animations (especially targeted at fade ins/outs) since its main goal is to transfer readable subtitles from one format to another. It does in no way check the spec compliance of the stream nor does it remove/check/fix bitmap animations.

[Oleg Rode]

While it may work with small pictures or slower update rates, large pictures and fast update rates will almost certainly lead to problems.
But in most cases it is possible to make a workaround for the problem. Still, the breaking large subs to 2 or more small pictures is not a 100% wrong workaround method.
Therefore all subtitle formats, including BD-SUP, feature special display commands to e.g. allow fading via palette or alpha animations. This is also why all the bitmap subtitle formats are palette based.
Easy to say, difficult to apply. The main feature of avs2bdnxml - it creates the CORRECT picture from the script. To apply new engines of fades in/out may be dangerous for subs structure. Subs may be not correct. Still, the last word has only ps auxw

[0xdeadbeef]

But in most cases it is possible to make a workaround for the problem. Still, the breaking large subs to 2 or more small pictures is not a 100% wrong workaround method.
Decreasing the window/object size may help in some cases, but it is not a general solution. Especially since absolutely no checking is done whatsoever if some restrictions are violated.

Easy to say, difficult to apply. The main feature of avs2bdnxml - it creates the CORRECT picture from the script. To apply new engines of fades in/out may be dangerous for subs structure. Subs may be not correct. Still, the last word has only ps auxw
I didn't say it was easy to do. I just said that this would be solution for fade ins/outs that the designers of the PGS format had in mind.

[hamletiii]

Hi, ps auxw, it's been quite some time now, any updates on sup support maybe?
As far as for xml+png generation from version 1.11, I would like to add some of my recent discovery working with scenarist BD.
Image splitting (-b1) is necessary if subtitles are far apart AND the time codes are next to each other (the timings are usually colliding).
Eg:
01:10:02-01:20:27 "How are you" - This line placed at the top of the screen
01:15:20-01:24:15 "I'm fine" - This line placed at the bottom of the screen

In this case, avs2bdnxml will generate 3 pictures, 1 picture with "How are you" with timecode 01:10:02-01:15:20, 1 picture with "How are you" and "I'm fine" with timecode 01:15:20-01:20:27, and 1 picture with "I'm fine" with timecode 01:20:27-01:24:15. If no image splitting, scenarist will almost certainly always show an error and drop the last picture because the ending timecode from the second picture at 01:20:27 is the beginning timecode for the third picture and they are too close to each other.

One way to get around this is to put all the lines within half of the vertical pixels of the image, which is 540 pixels for any 1980*1080 HD video. I've never had trouble importing with this particular configuration, no matter how much word I put in there, as long as it's within 1920*540 region.

The reason I disable -b1 is because it is NOT working properly for me. There are three cases when things could go wrong. First is when fade in/out is used, the images are split unnecessarily, which causes scenarist to complain color palette exceeds 255. Fade in/out was working fine when -b1 is disabled. Second is some lines have unnecessary splits as well, which creates extremely tiny image. Third is some pictures are generated with "smearing".

Here is output with each example and the *.ass file I used to generate these types of pictures, not sure what goes wrong with my methods. http://www.mediafire.com/?01mqyjmzcmw

The command I used is:
avs2bdnxml -t testing -l eng -v 1080i -f 29.97 -a1 -p1 -b1 -o testing02.xml 00000.avs

Lastly, one more feature request, when "-s" switch is used, I would like to have both xml files with time splitting and with no time splitting, since disabling and enabling "-s" switch only differ from the xml file generated. Sometimes with -s enabled, muxing could go underflow in scenarist for some reason, while no splitting works fine.

Again, thank you very much for this wonderful tool.

[ps auxw]

Hi, ps auxw, it's been quite some time now, any updates on sup support maybe?
I'm sorry for just disappearing. SUP support was supposed to be done much earlier (it's about halfway done now), but I have been quite busy with studies etc. I should have more time for avs2bdnxml next month again.

As far as for xml+png generation from version 1.11, I would like to add some of my recent discovery working with scenarist BD.
Image splitting (-b1) is necessary if subtitles are far apart AND the time codes are next to each other (the timings are usually colliding).
Eg:
01:10:02-01:20:27 "How are you" - This line placed at the top of the screen
01:15:20-01:24:15 "I'm fine" - This line placed at the bottom of the screen

In this case, avs2bdnxml will generate 3 pictures, 1 picture with "How are you" with timecode 01:10:02-01:15:20, 1 picture with "How are you" and "I'm fine" with timecode 01:15:20-01:20:27, and 1 picture with "I'm fine" with timecode 01:20:27-01:24:15. If no image splitting, scenarist will almost certainly always show an error and drop the last picture because the ending timecode from the second picture at 01:20:27 is the beginning timecode for the third picture and they are too close to each other.

One way to get around this is to put all the lines within half of the vertical pixels of the image, which is 540 pixels for any 1980*1080 HD video. I've never had trouble importing with this particular configuration, no matter how much word I put in there, as long as it's within 1920*540 region.
Interesting, This seems to be consistent with the buffer size hypothesis, which makes fast changing, big sized subtitles break.

The reason I disable -b1 is because it is NOT working properly for me. There are three cases when things could go wrong. First is when fade in/out is used, the images are split unnecessarily, which causes scenarist to complain color palette exceeds 255. Fade in/out was working fine when -b1 is disabled. Second is some lines have unnecessary splits as well, which creates extremely tiny image. Third is some pictures are generated with "smearing".

Here is output with each example and the *.ass file I used to generate these types of pictures, not sure what goes wrong with my methods. http://www.mediafire.com/?01mqyjmzcmw

The command I used is:
avs2bdnxml -t testing -l eng -v 1080i -f 29.97 -a1 -p1 -b1 -o testing02.xml 00000.avs

Thanks for reporting and providing the example, I'll look into this. I know how to fix the second problem. The third problem looks ugly and will require some bug hunting. As for the first, at which point/for which frames in the example does it happen?

Lastly, one more feature request, when "-s" switch is used, I would like to have both xml files with time splitting and with no time splitting, since disabling and enabling "-s" switch only differ from the xml file generated. Sometimes with -s enabled, muxing could go underflow in scenarist for some reason, while no splitting works fine.
I'll add that for the next version.

Again, thank you very much for this wonderful tool.
I am glad you find it useful. :)

[hamletiii]

The first problem happens the entire duration of the sentence. avs2bdnxml just splits the image to top half and bottom half, probably thinks the fading rate of the two pieces are different? The ass tag for the fading is {\fad(300,300)}. And it works fine with -b0.

The third problem is re-occuring probably every 50 pictures or so. It's just an estimation, but the pattern is definitely repeated.

Thanks for your quick response.

[ps auxw]

Once again, I have to apologize for the delays. Still, I finally had a bit of time to look into things. SUP output still needs work, but for now I have released a new version (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-1.12.tar.bz2), which should fix some problems.

The reason I disable -b1 is because it is NOT working properly for me. There are three cases when things could go wrong. First is when fade in/out is used, the images are split unnecessarily, which causes scenarist to complain color palette exceeds 255. Fade in/out was working fine when -b1 is disabled. Second is some lines have unnecessary splits as well, which creates extremely tiny image. Third is some pictures are generated with "smearing".
The third problem is fixed now. Color palette exceeding 255 might be fixed too, please test it. Unnecessary splits are not fixed yet, but will be disabled in the next version, with an option to reenable them since they do conserve a bit of buffer space.

[sneaker_ger]

Thx for the new version. I also noticed the third behaviour.
Could you comment on the first three posts on this page (http://forum.doom9.org/showthread.php?t=145277&page=33)? If I understand 0xdeadbeef correctly the attempt to reduce buffer usage by splitting images might be (at least in practice) futile.

[ps auxw]

Could you comment on the first three posts on this page (http://forum.doom9.org/showthread.php?t=145277&page=33)? If I understand 0xdeadbeef correctly the attempt to reduce buffer usage by splitting images might be (at least in practice) futile.

It's hard for me to say anything definitive about it, but I think it's still worth trying. It should be noted, that I base my "buffer overflow"-assumptions mainly on the errors reported by Scenarist, not any PS3 decoding problems. It is correct, that in the SUP stream, images will be RLE encoded, but for display they will have to be decompressed, which is where the buffer should come into play.

You could probably even construct cases where the overhead due to the 2nd object increases the bandwidth.
This can be easily avoided, by not creating second objects below a given size. Figuring out the correct threshold would be a bit tricky, though.

[sneaker_ger]

Ah, ok. Thx.

[hamletiii]

As far as my experiments with Scenarist BD, splitting images into two windows could save bandwidth significantly. For a simple two sentences far apart with one sentence on the top of the screen and one on the bottom without splitting could easily spike as high as 9MB (the limit is only 4MB), while same picture splitting into two small regions occupy less than 1MB (well below the 4MB limit). With Tsmuxer, you don't have to worry about this that much since it doesn't check the bandwidth whatsoever, the worst case is that you get some flickering subtitle, but Scenarist BD will complain and refuse to import.

On the other hand, cropping images does NOT help in conserving bandwidth that much.

Thanks for the update, I'll test it with the same file to see if the color palette exceeding 255 is going away or not.

[hamletiii]

This can be easily avoided, by not creating second objects below a given size. Figuring out the correct threshold would be a bit tricky, though.

The particular threshold I found without splitting images is half of the vertical resolution.

[hamletiii]

Hi, ps auxw, I think the new version works. I've only tested the same file, no more color palette exceeding 255 error and color smearing problem. The importing process into Scenarist BD also has been smoother.

As for the second problem with unnecessary splits, is it hard to fix? Scenarist BD is reading these correctly, two windows with one big box and one tiny horizontal strip. The muxed result works fine on the software players (tmt3, powerdvd 8, scenarist QC). But on PS3, lines without characters "g j p q y" (has little tails drop below the line) will show cropped, which mean only the big box gets shown on the screen. Lines with characters "g j p q y" are unaffected. I haven't test with other fonts or languages.

Lastly, one more feature request, when "-s" switch is used, I would like to have both xml files with time splitting and with no time splitting, since disabling and enabling "-s" switch only differ from the xml file generated. Sometimes with -s enabled, muxing could go underflow in scenarist for some reason, while no splitting works fine.

Can you put this function in the next version? Thanks so much for the updates.

[ps auxw]

Hi, ps auxw, I think the new version works. I've only tested the same file, no more color palette exceeding 255 error and color smearing problem. The importing process into Scenarist BD also has been smoother.
Thanks for testing, good to hear it works now.

As for the second problem with unnecessary splits, is it hard to fix? Scenarist BD is reading these correctly, two windows with one big box and one tiny horizontal strip. The muxed result works fine on the software players (tmt3, powerdvd 8, scenarist QC). But on PS3, lines without characters "g j p q y" (has little tails drop below the line) will show cropped, which mean only the big box gets shown on the screen. Lines with characters "g j p q y" are unaffected. I haven't test with other fonts or languages.
That's a most peculiar behaviour from the PS3. I'll make a fix for that in the next days.

Lastly, one more feature request, when "-s" switch is used, I would like to have both xml files with time splitting and with no time splitting, since disabling and enabling "-s" switch only differ from the xml file generated. Sometimes with -s enabled, muxing could go underflow in scenarist for some reason, while no splitting works fine.Can you put this function in the next version? Thanks so much for the updates.
This is actually a bit more tricky. Would a two-pass mode be acceptable, where first a log file and PNGs are produced and faster second passes can be used to quickly generate XML/PNG files with different settings?

[hamletiii]

This is actually a bit more tricky. Would a two-pass mode be acceptable, where first a log file and PNGs are produced and faster second passes can be used to quickly generate XML/PNG files with different settings?

OK, this is harder than I thought. This feature would be useful only in some situation. If you have time to add it, a two-pass process sounds fine. But if you don't, I can absolutely live without this feature. Thank you.

[hamletiii]

That's a most peculiar behaviour from the PS3. I'll make a fix for that in the next days.



Now I think PS3 might work within spec, other software players are just generous on this one.

Here is a statement from the Scenarist Designer PS (sonic's solution to create Blu-ray menu) tutorial:

"Make sure no layers are less than 8 pixels wide or high."

Although this applies for menus (IGS), I think it maybe works the same way for subtitles (PGS). The ones don't display seems all have 4 pixels in height; while the ones with tails thus display have 16 pixels in height.

[0xdeadbeef]

As far as my experiments with Scenarist BD, splitting images into two windows could save bandwidth significantly. For a simple two sentences far apart with one sentence on the top of the screen and one on the bottom without splitting could easily spike as high as 9MB (the limit is only 4MB), while same picture splitting into two small regions occupy less than 1MB (well below the 4MB limit). With Tsmuxer, you don't have to worry about this that much since it doesn't check the bandwidth whatsoever, the worst case is that you get some flickering subtitle, but Scenarist BD will complain and refuse to import.
As noted before, bitmaps are RLE encoded in the PG stream. An empty line can be encoded with 2 bytes. With three bytes, you can encode up to 16384 empty pixels. With a correctly implemented RLE algorithm the size of an single subtitle shouldn't be increased by more than 2k (2*1080 = 2160 = 2.1k) just because one line is at the top of the screen and one at the bottom.

A worse scenario is text at the left and right (e.g. Japanese) since than no EOL markers can be used. However even if the subs use the full height, the gap can always be encoded with three bytes per line. So for a maximum of 1080 lines, the gap can be encoded with 3*1080 bytes which equals about 3.1k.
This is about the maximum amount of bytes you can save per frame if you split an image into two composition objects.

In a nutshell: empty pixels don't need a considerable amount of bandwidth. They just increase the initialization/decoding times a little which needs to be considered when calculating the PTS/DTS timestamps of the packets.

Here is a statement from the Scenarist Designer PS (sonic's solution to create Blu-ray menu) tutorial:

"Make sure no layers are less than 8 pixels wide or high."

Although this applies for menus (IGS), I think it maybe works the same way for subtitles (PGS). The ones don't display seems all have 4 pixels in height; while the ones with tails thus display have 16 pixels in height.

Indeed 8 pixels is the minimum width and height for a composition object defined in an ODS entry.

[ps auxw]

As noted before, bitmaps are RLE encoded in the PG stream. An empty line can be encoded with 2 bytes. With three bytes, you can encode up to 16384 empty pixels. With a correctly implemented RLE algorithm the size of an single subtitle shouldn't be increased by more than 2k (2*1080 = 2160 = 2.1k) just because one line is at the top of the screen and one at the bottom.

A worse scenario is text at the left and right (e.g. Japanese) since than no EOL markers can be used. However even if the subs use the full height, the gap can always be encoded with three bytes per line. So for a maximum of 1080 lines, the gap can be encoded with 3*1080 bytes which equals about 3.1k.
This is about the maximum amount of bytes you can save per frame if you split an image into two composition objects.
Indeed. Empty space encoded quite efficiently, but the problems seem to exist after decoding. At least error reports from Scenarist, like this one, lead me to believe this: http://forum.doom9.org/showpost.php?p=1321154&postcount=69

Although this applies for menus (IGS), I think it maybe works the same way for subtitles (PGS). The ones don't display seems all have 4 pixels in height; while the ones with tails thus display have 16 pixels in height.
Indeed 8 pixels is the minimum width and height for a composition object defined in an ODS entry.
Thanks, I will prevent creation of images with either dimension size below 8 in the next version.

[0xdeadbeef]

Indeed. Empty space encoded quite efficiently, but the problems seem to exist after decoding. At least error reports from Scenarist, like this one, lead me to believe this: http://forum.doom9.org/showpost.php?p=1321154&postcount=69

There is indeed a "decoded object buffer" defined for PG streams and it's 4MB (4*2^20 = 4194304) bytes in size. Then again, this is enough to store two complete frames at full HD resolution (1920*1080 = 2073600 which is roughly 1.98MB). AFAIK only the decoded bitmap data is stored in this buffer - palettes, and other composition information is stored in a separate buffer (composition buffer). The decoding buffer is valid within an epoch, so it can only overflow if there are multiple composition objects per epoch. This is kinda weird as usually there is only one subtitle per epoch and obviously one subtitle frame can't be larger than two full HD frames.

So yes, splitting composition objects can help to safe space in the decoding buffer, but there should be no reason to do this, because there is more than enough space in this buffer as long as you don't do very, very weird things within an Epoch.

Anyway, IMHO the source of the problem is somewhere else. Either Scenarist is somewhat wacky regarding the definitions of Epochs or something else is wrong.

[mp3dom]

The buffer of 4MB could be not enough if you have some subtitles that are consecutive. If you have, let's say, 10 subtitles and every subtitle start immediately at the end of its previous, the epoch will contain more than 1 subtitle (in this example, the epoch will contain 10 subtitles with a composition object made with the largest subtitle). In this case the 4 MB buffer could be not enough (quite easy if you made strange subtitles with lot of graphic or fancy fonts). Subtitles shorter than 2 frames could also lead to a buffer overflow.

[0xdeadbeef]

Hm, I never cared so much about the exact definition of behavior between two epochs. It is possible that subtitles have to be defined within an epoch if they should be displayed directly one after the other without the slightest gap. This isn't really interesting for "normal" subtitles which usually have a certain gap of a few hundred milliseconds between them and thus can be safely stored in separate epochs. Indeed my conception of epochs always was that usually one Epoch contains one subtitle and the rare case of multiple object definitions per Epoch is mostly used to display a 2nd subtitle line with a delay while still showing the first etc.
While there can be up to 8 palettes and 64 composition objects per Epoch, I would be pretty surprised to actually find a SUP stream that contains an Epoch with more than two or three composition objects. With more than 8 objects, they'd also have to share palettes.

However, probably this is the explanation of this whole issue: BDSup2Sub always uses one epoch per subtitle. If the end time of one subtitle equals the start time of the next subtitle, a standalone might introduce a short pause between these two subtitles as it has to clear the decoding buffer etc. between two Epochs. Scenarist however tries to avoid that gap by putting two or more subtitles in one epoch. If there are multiple gapless subtitles though, this leads to issues with palettes and/or a decoding buffer overflow.

[hamletiii]

However, probably this is the explanation of this whole issue: BDSup2Sub always uses one epoch per subtitle. If the end time of one subtitle equals the start time of the next subtitle, a standalone might introduce a short pause between these two subtitles as it has to clear the decoding buffer etc. between two Epochs. Scenarist however tries to avoid that gap by putting two or more subtitles in one epoch. If there are multiple gapless subtitles though, this leads to issues with palettes and/or a decoding buffer overflow.

So this explains why sometimes BDSup2Sub's timecode was different from original timecode from avs2bdnxml. Thanks for your informative replies.

[sneaker_ger]

So this explains why sometimes BDSup2Sub's timecode was different from original timecode from avs2bdnxml. Thanks for your informative replies.

Different timecodes? Are you sure they don't just come from BDSup2Sub's adjustments to synch to the framerate? :confused:

[0xdeadbeef]

Yep, I'd think this is unrelated as I talked about the handling of Epochs.
Besides, BDSup2Sub always shifts start/end times to the nearest frame which leads to slightly different times compared to tools which don't care about frame synchronization. Then again, the time codes in the XML format are always frame based, so BDS2S shouldn't adjust the times in this case anyway.

[Solaris]

Hi guys,

Good tool. I am looking to use this function in a little c# program I am writing. However, when I check the PNGs it creates, the fontsize is very small. So I need to set the fontsize, color etc from within my c# prgram. Is there a config or ini file that hold these parameters so that I can modify this?

Thanks in advance for your time.

[hamletiii]

Yep, I'd think this is unrelated as I talked about the handling of Epochs.
Besides, BDSup2Sub always shifts start/end times to the nearest frame which leads to slightly different times compared to tools which don't care about frame synchronization.

But isn't this frame synchronization feature intentionally put each composition object under per epoch? There are quite a few Japanese commercial discs have two window slicing with lots of composition objects under one epoch, so I don't think those are odd, avs2bdnxml can create them and import to Scenarist BD perfectly fine. It's just your implementation in BDSup2Sub is trying to create gaps as you said in post#129 which is not desirable for these types of subs.



Then again, the time codes in the XML format are always frame based, so BDS2S shouldn't adjust the times in this case anyway.

I'm referring to frames after the seconds, not the whole time codes.

[0xdeadbeef]

But isn't this frame synchronization feature intentionally put each composition object under per epoch? There are quite a few Japanese commercial discs have two window slicing with lots of composition objects under one epoch, so I don't think those are odd, avs2bdnxml can create them and import to Scenarist BD perfectly fine. It's just your implementation in BDSup2Sub is trying to create gaps as you said in post#129 which is not desirable for these types of subs.

Having multiple composition object is allowed of course, yet PTS/DTS calculation is already a nightmare for simple Epochs and since the available muxers assume the time stamps to be absolutely corrects, it's up to the subtitle tool to calculate them.
Besides, multiple composition objects are meant for effects like crossfades etc. which are hard to impossible to generically translate to any other format anyway.

These are the two main reasons why BDSup2Sub simplifies the subtitle stream to have one subtitle per Epoch. It doesn't introduce gaps deliberately though - they are introduced by the player's rendering implementation.

Always keep in mind that BDSUp2Sub is a subtitle converter, not a BD authoring tool.

[hamletiii]

While there can be up to 8 palettes and 64 composition objects per Epoch, I would be pretty surprised to actually find a SUP stream that contains an Epoch with more than two or three composition objects. With more than 8 objects, they'd also have to share palettes.

Since you mentioned fading, I looked more into the PES structure in Scenarist BD. This is the tree structure showing a subtitle that is capable of one line fading while the other line stay opaque all the time.

http://i44.photobucket.com/albums/f18/DVDmaster/Displayset_fading.png

The structure shows something called DisplaySet under Epoch which I don't see you mentioned it. Is this something not defined in Blu-ray subtitle spec? Each epoch can have one or two window, then a bunch of DisplaySets. Each DisplaySet has a palette and two composition objects which appears to have the same number as windows. The fading effect (in CompositionObject#2) is caused by altering palette in each DisplaySet, the subtitle picture is always the same png file.

So this DisplaySet seems to be one VERY important element since it simplifies things quite a bit, also gets around the limitations of 8 palettes and 64 composition objects per Epoch?

Also want to share my experience with fading in avs2bdnxml here. The way avs2bdnxml handles fading is by simply rendering each frame as a different picture, so one fading effect could generate lots of pictures. There's some limitations to this though:

1. It's not possible to generate one line fading while the other line stay opaque all the time without flickering. The altering palette method in the example however fades very nicely. I guess it's because the palette info is not stored in the 4MB decoding buffer although the palette alters each frame while the avs way has so many pictures packed together just simply overflows the buffer?

2. Only one line fading with no other line is possible, and the effect is actually pretty decent. But the fading time can not be very long. Some people have suggest to stay within 600ms.

[0xdeadbeef]

Well, as mentioned before, an Epoch doesn't simply have a start and an end, but can have multiple "acquisition" and "continue" events. All of them specify display updates and thus they define display sets. This is an abstract term though which includes several Epoch types and not a stream element.

Anyway, I dunno how this helps here. I don't think that the BDN XML format in its current form is able to store the information that would be needed to define palettes, objects, windows and epochs in a way that would be needed to allow an external converter to accurately convert it to BD-SUP.

Even if someone would define a new XML format to cover all of this, there would be no tool to create such files. Last but not least, someone would have to write the converter with authoring capabilities (calculating all the DTS/PTS timestamps for a complex PG stream with all plausibility and limitation checks will be a nightmare).

[ps auxw]

Sorry for disappearing again. Life is quite busy. For now, I have released avs2bdnxml v1.13 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-1.13.tar.bz2), which should fix the problems with tiny (below 8px dimension) pictures and ugly image splits.

@Solaris: avs2bdnxml does no subtitle rendering on its own. You will have to create a subtitle file with your desired font-size etc.. For this, I'd recommend taking a look at Aegisub, or even just SSA/ASS subtitle specification (as far, as you can call those that).

[hamletiii]

Hi, ps auxw, thanks for the update, will test it when I got more time. If everything works, I think this is probably the most intuitive and feature rich Blu-ray subtitle rendering tool out there.

And hopefully you'll get more time in summer to look into SUP support, so that people who want to do fancy Blu-ray subtitles with tsmuxer could benefit from this software as well.

[hamletiii]

OK, this appears to be the fading tags I'm looking for:


<?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-0092b BDN File Format.xsd">
<Description>
<Name Title="Title" />
<Language Code="eng" />
<Format VideoFormat="1080p" FrameRate="23.976" DropFrame="false" />
<Events NumberofEvents="3" Type="Graphic" />
</Description>
<Events>
<Event InTC="00:00:04:02" OutTC="00:00:07:02">
<Graphic>ak_Track_0001.png</Graphic>
<InlineEffect Type="Fade" Duration="00:00:00:05" Anchor="Start">
<Fade FadeType="FadeIn" />
</InlineEffect>
<InlineEffect Type="Fade" Duration="00:00:00:05" Anchor="End">
<Fade FadeType="FadeOut" />
</InlineEffect>
</Event>
<Event InTC="00:00:11:08" OutTC="00:00:14:08">
<Graphic>ak_Track_0002.png</Graphic>
<InlineEffect Type="Fade" Duration="00:00:00:23" Anchor="End">
<Fade FadeType="FadeOut" />
</InlineEffect>
</Event>
<Event InTC="00:00:13:09" OutTC="00:00:17:11">
<Graphic>ak_Track_0003.png</Graphic>
<InlineEffect Type="Fade" Duration="00:00:00:23" Anchor="Start">
<Fade FadeType="FadeIn" />
</InlineEffect>
</Event>
</Events>
</BDN>


The tags are recognizable by Scenarist BD. The first one, ak_Track_0001.png will fade in and fade out; the second and third are cross-fading effect I described in post#136 above. Note on cross-fading, the start time[in bold] of the third picture actually overlaps with the end time of the second picture. Also the actual graphics on the second and the third cannot have the same position. It appears that Scenarist BD automatically crops/splits windows for you, the graphics I tried are all 1920*1020 pictures with no additional width or height tags given as seen in the above text. So upto this point, we are looking at things too hard, at least for Scenarist BD, all you need are full size images with tag <Graphic>. You let Scenarist BD's built-in functions to handle all these cropping/window splitting! In addition, if avs2bdnxml could read the convert the fade tags in *.ass/ssa to fade tags in bdn format, then a proper fading could be achieved instead of the current frame based fading.

So for now, if you want to use Scenarist BD for image splitting, you can just use -a0, -b0 to force avs2bdnxml to output full size png files. For fading, do NOT add the \fad in your *.ass/ssa files, you can manually pick the pictures and apply the fading tags above after avs2bdnxml finishes image rendering.

Update:

I did a bit more testing. Scenarist BD's built-in functions can only handle cropping with one window and one composition object, it cannot split images into two composition objects. I think this goes back to the decoding buffer error discussion last year, and the whole purpose of having avs2bdnxml to support dual windown splitting. So -a1, b1 options are needed. The fading tags can still be applied to the cropped pictures. In the event that have two graphics:



<Event Forced="False" InTC="00:01:40:08" OutTC="00:01:49:00">
<Graphic Width="713" Height="74" X="96" Y="945">00003008_0.png</Graphic>
<Graphic Width="236" Height="66" X="96" Y="768">00003008_1.png</Graphic>
<InlineEffect Type="Fade" Duration="00:00:00:12" Anchor="Start">
<Fade FadeType="FadeIn" />
</InlineEffect>
<InlineEffect Type="Fade" Duration="00:00:00:12" Anchor="End">
<Fade FadeType="FadeOut" />
</InlineEffect>
</Event>



The two composition objects will fade in and out at the same rate.

But during two events crossfading, these two events can only have one composition object each, otherwise you'll get Error: The number of Graphic Element exceed 2.

Example:



<Event Forced="False" InTC="00:02:51:09" OutTC="00:02:55:17">
<Graphic Width="443" Height="207" X="92" Y="766">00005139_0.png</Graphic>
<Graphic Width="974" Height="140" X="474" Y="62">00005139_1.png</Graphic>
<InlineEffect Type="Fade" Duration="00:00:00:12" Anchor="Start">
<Fade FadeType="FadeIn" />
</InlineEffect>
<InlineEffect Type="Fade" Duration="00:00:00:12" Anchor="End">
<Fade FadeType="FadeOut" />
</InlineEffect>
</Event>
<Event Forced="False" InTC="00:02:54:29" OutTC="00:02:57:16">
<Graphic Width="443" Height="207" X="92" Y="766">00005267_0.png</Graphic>
<Graphic Width="745" Height="128" X="587" Y="62">00005267_1.png</Graphic>
</Event>



The above is invalid because during crossfading, it has four composition objects. While Blu-ray limits 2 composition objects at a time I guess.

Also currently crossfading is possible between two pictures that have close enough colors, if one picture has colors drastically different than the other picture, then the total combined colors will exceed 256, which will make Scenarist BD complain.

[ps auxw]

In addition, if avs2bdnxml could read the convert the fade tags in *.ass/ssa to fade tags in bdn format, then a proper fading could be achieved instead of the current frame based fading.
I would really prefer not to parse the actual subtitle format, so avs2bdnxml can stay format agnostic. Still, I might be able to add some fade detection anyway. Thanks for investigating this. I'll try it, when I have the necessary time.

Also currently crossfading is possible between two pictures that have close enough colors, if one picture has colors drastically different than the other picture, then the total combined colors will exceed 256, which will make Scenarist BD complain.
Mh, that really shouldn't happen. With -p1, the number of colors should be limited to 255. If more are necessary it should look worse, not fail. I'll have to take another look at this.

[hamletiii]

I would really prefer not to parse the actual subtitle format, so avs2bdnxml can stay format agnostic. Still, I might be able to add some fade detection anyway. Thanks for investigating this. I'll try it, when I have the necessary time.



Yeah, it's a good feature to have, but not necessary needed. For now, I can do them manually, it's not that much different from editing an ass/ssa file. I don't use fading that much anyway, so it's doable. Plus in order to use the fading tags, users must have Scenarist BD or similar program that can interpret them I guess.




Mh, that really shouldn't happen. With -p1, the number of colors should be limited to 255. If more are necessary it should look worse, not fail. I'll have to take another look at this.

Your program works fine. The pictures are indeed 255 colors at most. But when fading, if one of the picture is quite complex or colors are very different from the other, the intermediate color palettes generated by Scenarist BD used for fading will exceed 255.

This is an example:

http://i44.photobucket.com/albums/f18/DVDmaster/fadingpalette_problem.png

The left picture is the palette for the first picture, the right picture is the palette for the second picture which fills all 255 colors already. So when fading, the new palettes need to take colors from both palettes which will exceed 255 colors. I don't think there's a good way around this. In order to make the intermediate palettes not exceeding 255 colors, less colors can be indexed to each picture which means some dithering is needed and probably will degrade the subtitle quality, I would rather not have that happen.

[hamletiii]

Hi, ps auxw, I have given 1.13 some thorough tests for the past two weeks, this latest update has worked almost every way to my expectation except one thing:

One single line of subtitle in ass/ssa format occasionly will get split into two graphs. I've collected some samples HERE (http://www.mediafire.com/?gzg2yj5md20) to better demonstrates what I mean, stuff under 03_no splits_expected folder is the result I'm expecting (one line of subtitle in ass/ssa format should just have a single graph), the other two folders have this random splitting graphs which I'm not expecting.

The random splitting will have two side effects:

1. During two events crossfading, these two events can only have one composition object each, otherwise you'll get Error: The number of Graphic Element exceed 2.

Example:



<Event Forced="False" InTC="00:02:51:09" OutTC="00:02:55:17">
<Graphic Width="443" Height="207" X="92" Y="766">00005139_0.png</Graphic>
<Graphic Width="974" Height="140" X="474" Y="62">00005139_1.png</Graphic>
<InlineEffect Type="Fade" Duration="00:00:00:12" Anchor="Start">
<Fade FadeType="FadeIn" />
</InlineEffect>
<InlineEffect Type="Fade" Duration="00:00:00:12" Anchor="End">
<Fade FadeType="FadeOut" />
</InlineEffect>
</Event>
<Event Forced="False" InTC="00:02:54:29" OutTC="00:02:57:16">
<Graphic Width="443" Height="207" X="92" Y="766">00005267_0.png</Graphic>
<Graphic Width="745" Height="128" X="587" Y="62">00005267_1.png</Graphic>
</Event>



The above is invalid because during crossfading, it has four composition objects. While Blu-ray limits 2 composition objects at a time I guess.
So it is necessary to limit one line of subtitle in ass/ssa format to output a single graph.


2. It will confuse Scenarist BD, so that it's not possible to have a dual window splitting, it just lumps everything into a giant window. This is a minor problem since there's not much difference in decoding buffer usage.

Again, thanks for your effort in updating this software.

[ps auxw]

One single line of subtitle in ass/ssa format occasionly will get split into two graphs. I've collected some samples HERE (http://www.mediafire.com/?gzg2yj5md20) to better demonstrates what I mean, stuff under 03_no splits_expected folder is the result I'm expecting (one line of subtitle in ass/ssa format should just have a single graph), the other two folders have this random splitting graphs which I'm not expecting.

Fixing this will be tricky. Maybe it would help, if I made the "ugly" factor user configurable. It is used to not split subtitles, if:
(pixels for segment one + pixels for segment two) * ugly > pixels for unsplit subtitle
Maybe this could be used to avoid these "random" splits. Currently there is also a hard limit, which must not be exceeded to avoid splitting:
pixels for unsplit subtitle - (pixels for segment one + pixels for segment two) < 500 * 300
This should probably either be removed or changed to something more appropriate, I guess.

As you can see, deciding whether to split nearby subtitle parts is basically a bunch of heuristics, and a bit hard to get sensible results out of.

[hamletiii]

Fixing this will be tricky. Maybe it would help, if I made the "ugly" factor user configurable. It is used to not split subtitles, if:
(pixels for segment one + pixels for segment two) * ugly > pixels for unsplit subtitle
Maybe this could be used to avoid these "random" splits. Currently there is also a hard limit, which must not be exceeded to avoid splitting:
pixels for unsplit subtitle - (pixels for segment one + pixels for segment two) < 500 * 300
This should probably either be removed or changed to something more appropriate, I guess.

As you can see, deciding whether to split nearby subtitle parts is basically a bunch of heuristics, and a bit hard to get sensible results out of.

Thanks for the answer, this sounds too complicated. I'm happy with the current non-ugly splits.

Is there a parameter I can set in the MaskSub or somewhere else to specify a starting frame (not from 0) and an ending frame?
MaskSub("subtitles.ext",video.width,video.height,video.framerate,video.framecount)

I think another solution for the random splits is to take advantage of Scenarist BD by rendering the two lines separately to get two pictures, as long as the pixels from the two pictures aren't in conflict position, Scenarist BD will figure out how to dual window splitting them just like avs2bdnxml. But since these lines are at the very end of the movie, it would be a huge time saver if I can specify just the time segment.

Any news on *.sup support? Thanks.

[LowDead]

Following this thread with great interest :) Thank you for the nice app. Any chance for some kind of GUI? (I'm a little lazy ;-) )

//LD

[ps auxw]

Is there a parameter I can set in the MaskSub or somewhere else to specify a starting frame (not from 0) and an ending frame?
MaskSub("subtitles.ext",video.width,video.height,video.framerate,video.framecount)
You could use AviSynth's Trim() (http://avisynth.org/mediawiki/Trim) function. (The syntax can be a bit unintuitive, in some cases.) Example:

MaskSub("subtitles.ext",video.width,video.height,video.framerate,video.framecount)
Trim(200,299) # trim to 100 frames of video, starting with frame 200

Of course, timestamps in the generated XML file would still start from 0. Maybe options like "--seek" and "--frames" would be useful?

Any news on *.sup support? Thanks.
Not yet, but I should have some time to work on this quite soon. Sorry for all the delays. :(

[hamletiii]

You could use AviSynth's Trim() (http://avisynth.org/mediawiki/Trim) function. (The syntax can be a bit unintuitive, in some cases.) Example:

MaskSub("subtitles.ext",video.width,video.height,video.framerate,video.framecount)
Trim(200,299) # trim to 100 frames of video, starting with frame 200

Of course, timestamps in the generated XML file would still start from 0. Maybe options like "--seek" and "--frames" would be useful?



I was looking at trim the other day, and thought the timcode would be starting from 0 although never tried it. Appending skipped frames would be quite helpful if the user knows the range.

[Hyper Shinchan]

I dunno if anyone else had similar problems, but apparently both BDSup2Sub and BDSupEdit can't deal correctly with some subtitles splitted by the -b1 switch, the second line isn't displayed; is it a problem of those programs?
I've included the single line of the ass script that gave me problems (the avs script was created as: Masksub("filename",1920,1080,23.976,frame number)) if you want to test it by yourself.

[ps auxw]

@Hyper Shinchan: Those programs don't support split lines, like those produced by -b1. It only works with Scenarist, I think.

Also sorry for disappearing again. Things keep coming up, and I don't find the necessary time to work on this. :(