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

[ps auxw]

AVS to BluRay SUP/PGS and BDN XML


News

As of version 2.00, avs2bdnxml supports direct conversion to the BluRay SUP format. This is still experimental.


History

First, a bit of history. I wrote avs2bdnxml in late 2008 as the result of a discussion with Daiz in the x264 IRC channel. Back then, there wasn't a reasonable way to actually do something useful with BDN XML files, so I mostly forgot about it. Now there are at least two programs, which can convert BDN XML+PNG to BD-SUP format. This resulted in me fixing a couple of bugs, and then deciding to post it here.


Purpose

Now, what does it do, you might ask. The answer to this is pretty simple. avs2bdnxml takes an AviSynth script which outputs RGBA, and turns it into a BDN XML file + PNG files. Now, it seems that Ulf wrote something similar (http://forum.doom9.org/showthread.php?t=146488). The main difference is that avs2bdnxml can convert anything AviSynth can generate to BDN XML (just make sure it still looks good after being palletized), not just subtitles.

For example you can turn the following (and combinations thereof) into BluRay subtitles:

Anything that VSFilter can render. SRT, (animated) ASS/SSA, etc..
Logos/pictures.
RGBA video overlays made with Adobe AfterEffects.



Usage


First you'll need an AviSynth script. If you have a regular subtitle file you want to render using VSFilter (you'll need at least VSFilter 2.39), do something like this:

video=AviSource("video.avi")
MaskSub("subtitles.ext",video.width,video.height,video.framerate,video.framecount)

If you have an RGBA video, do something like this instead:

AviSource("subtitles_RGBA.avi")
FlipVertical()

Now you'll have to run avs2bdnxml. Since it is a command line application, you'll either have to use cmd, some other shell or write a batch file.

Usage: avs2bdnxml [options] -o output input

Input has to be an AviSynth script with RGBA as output colorspace

-o, --output <string> Output file in BDN XML format
For SUP/PGS output, use a .sup extension
-j, --seek <integer> Start processing at this frame, first is 0
-c, --count <integer> Number of input frames to process
-t, --trackname <string> Name of track, like: Undefined
-l, --language <string> Language code, like: und
-v, --video-format <string> Either of: 480i, 480p, 576i,
720p, 1080i, 1080p
-f, --fps <float> Either of: 23.976, 24, 25, 29.97, 50, 59.94
-x, --x-offset <integer> X offset, for use with partial frames.
-y, --y-offset <integer> Y offset, for use with partial frames.
-s, --split-at <integer> Split events longer than this, in frames.
Disabled when 0, which is the default.
-m, --min-split <integer> Minimum length of line segment after split.
-a, --autocrop <integer> Automatically crop output. [on=1, off=0]
-p, --palette <integer> Output 8bit palette PNG. [on=1, off=0]
-u, --ugly <integer> Allow splitting images in ugly ways.
Might improve buffer problems, but is ugly.
[on=1, off=0]
-b, --buffer-opt <integer> Optimize PG buffer size. [on=1, off=0]

Example:

avs2bdnxml -t Undefined -l und -v 1080p -f 23.976 -a1 -p1 -b0 -u0 -m3 -o output.xml input.avs

Input and output are required settings. The rest are set to default, as per the example. Please note that the image files will be named 00000000_0.png, ..., 99999999_1.png, and written to the current working directory. Existing files with these names will be overwritten. XML files created with -b1 might not be supported by anything but Scenarist and EasyBD (http://www.dvd-logic.com/easybd/).
To get SUP output, just change the output filename extension to .sup, for example: -o output.sup
Wait until it's done. You should now have a nice BDN XML file, and a bunch of PNG files.
For some programs, you have to convert the PNG files to 8bit RGBA palette. This doesn't apply to BDSup2Sub and BDSupEdit. You can do this, using the -p switch.
Use a program like BDSupEdit (http://forum.doom9.org/showthread.php?t=146157) or BDSup2Sub (http://forum.doom9.org/showthread.php?t=145277) to convert the BDN XML stuff to a BD-SUP file. The rest is left as an exercise for the reader.



Download

avs2bdnxml v2.05 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.05.tar.bz2)
Website (http://ps-auxw.de/avs2bdnxml/)


Changes

Version 2.05

Fix crash when using XML and SUP output


Version 2.04

Minor fixes
Code cleanup regarding linked lists
Add new minimal window finding code
Fix PGS output more, especially WDS handling
Fix old bug in RLE encoder


Version 2.03

Output some statistics about previous epoch in pgsparse in end packet
Fix unnecessary epoch splits due to bad buffer calculation and more.
Some small fixes


Version 2.02

It is now possible to use -o twice, with different output formats
Corrections to SUP timestamp calculation
PGS decode buffer should contain palettized image data, not RGBA. Buffer usage calculation fixed.


Version 2.01

Restrict number of composition objects within an epoch to 64


Version 2.00

Options --seek and --count were added, to allow for partial processing of input video
For debug purposes, a stand-alone SUP file parser was added in debug/
Experimental SUP output support


Version 1.13

By default, images are no longer split into to composition objects, if the result would look ugly. For example, descenders should no longer get put into their own image. Reverting back to the old behaviour is possible using the --ugly option.
Ensure minimum size of 8x8 for composition objects


Version 1.12

Fix error in example
Fix double free, which could result in broken images when image splitting and palletized output were enabled.


Version 1.11

Add option to not split lines, if the rest isn't a minimum of 3 (default) frames long
Images are now autocropped by default
Images are now converted to 8bit palette by default
Misc bugfixes that should've been fixed before


Version 1.10b

Splitting of images is now disabled by default


Version 1.10

Add option to split events longer than a given number of frames, to allow better seeking
Change image filename format to XXXXXXXX_X.png
Add option to optimize for Presentation Graphics buffer usage, by auto-cropping images, and splitting them into two separate ones to minimize surface area, when necessary (enabled by default)
Use getopts for commandline argument parsing
Add Makefile


Version 1.9

Correct calculation of timecodes. Integer only, now.
Remove support for drop timecodes. If anybody really needs them, and has a way to check calculated timecodes are correct, please tell me.


Version 1.8

Fix crash with certain frame sizes (unaligned buffer used with SSE2)


Version 1.7

Terminate using exit/return instead of abort (no more "crashes")


Version 1.6

Zero transparent pixels to guard against invisible color information (Slight slowdown, but more robustness)
Add SSE2 runtime detection
Correctly set DropFrame attribute


Version 1.5

Validate framerates
Make non-drop timecodes the default for 23.976, 29.97 and 59.94
Fix bad timecode calculation due to float math optimization
Add integer SSE2 optimization (but most time is spent in AviSynth)
Don't uselessly swap R and B channels

[OptimusX]

I'd like to give this program a try, but I'm new to AVIsynth usage:

video=AviSource("video.avi")
MaskSub("subtitles.ext",video.width,video.height,video.framerate,video.framecount)

I'm trying to use an ASS file. What is the "avisource" referred to above? When using an ASS file, what is the video referenced to in this script?

How do I determine the "framecount" of the ASS file that I intend to use?

[sneaker_ger]

I too don't see what AviSource is supposed to do there but you may want to take a look at PunkGraphicStream (http://forum.doom9.org/showthread.php?t=148030) which was published recently.

[ps auxw]

I'd like to give this program a try, but I'm new to AVIsynth usage:

video=AviSource("video.avi")
MaskSub("subtitles.ext",video.width,video.height,video.framerate,video.framecount)

I'm trying to use an ASS file. What is the "avisource" referred to above? When using an ASS file, what is the video referenced to in this script?

How do I determine the "framecount" of the ASS file that I intend to use?

I am sorry if my description was a bit confusing. In this case "video.avi" is supposed to be the video the subtitles will be displayed on. I used it as a simple way of getting dimensions and length for the subtitle rendering. You can also use something like this:


MaskSub("subtitles.ass",1920,1080,23.976024,framecount)

Where framecount is the frame number of the underlying video after the last subtitle, or just the frame number of the last frame for the video the subtitles will be applied to. You can calculate it like this:
length in seconds * framerate

So if your last subtitle ends at 01:24:05.4 and the BluRay you will be mastering is 24000/1001 fps, your framecount will be: (60*60*1 + 60 * 24 + 5.4) * (24000 / 1001) = 120969 (round up)

Of course, you could also just use a high value for framecount that's sure to be more than enough (like 216000 for length below 2 hours). That'll just make conversion take a bit longer, but shouldn't hurt otherwise.

I hope things are a bit clearer now. If not, please ask.

[OptimusX]

Great explanation. I had a little problem because I didn't realize I had to manually add a plugin for AVISYNTH (vsfilter). I'm encoding some stuff now, so thank you for explaining so well!

[hamletiii]

I'm using aegisub to create the ass file, my video is NTSC 29.97fps nondrop, if I import the bdn-xml file straight into scenarist BD, the subtitle just gradually out of sync. So what process (framerate transform) do I need to apply, either on the original output or change the input framerate in command line?

The image output part is fine, quality is slightly better than tsmuxer (used fireworks to downgrade the pngs to 8 bit RGBA), but still has some white stuff uncleared on the outline (particularly visible in TotalMedia Theatre). So far the only tool that can generate perfect commercial quality Blu-ray subpicture is lemony pro, but that one is too hard to use. This tool seems promising, as long as if I can figure out how to get the timecodes fixed...

[ps auxw]

I'm using aegisub to create the ass file, my video is NTSC 29.97fps nondrop, if I import the bdn-xml file straight into scenarist BD, the subtitle just gradually out of sync. So what process (framerate transform) do I need to apply, either on the original output or change the input framerate in command line?
Please try the following:
1) Call avs2bdnxml with FRAMERATE as 30. Calling it with 29.97 should produce drop timecodes.
2) If this is still no good, open the .xml file and set FrameRate="29.97" in the format tag.
Does this help with the desync?

The image output part is fine, quality is slightly better than tsmuxer (used fireworks to downgrade the pngs to 8 bit RGBA), but still has some white stuff uncleared on the outline (particularly visible in TotalMedia Theatre). So far the only tool that can generate perfect commercial quality Blu-ray subpicture is lemony pro, but that one is too hard to use. This tool seems promising, as long as if I can figure out how to get the timecodes fixed...
The white pixels are most probably due to the 8bit conversion. Maybe a different program can give better results.

[hamletiii]

Yes, the 30fps corrected the drop problem, big thanks for the program and quick reply. But this option is not listed in the input:

FRAMERATE Either of: 23.976, 24, 25, 29.97, 50, 59.94

After getting the xml file, it has to be edited back to 29.97 since scenarist BD only takes 29.97 drop or non-drop.

And I assume for 23.976 non-drop source, I have to use 24 as input to avoid drop problem, right?

For the image quality, after I uncheck "Remove unused colors" in fireworks, the quality improves quite a bit. Now I have to look really close to see the white pixels, but they are there. So what's the reason you choose to output non 8bit RGBA pngs? It seems a little impractical to have true color pngs since most programs are designed to output BDMV structure.

Also I've tried the pinned PunkGraphicStream which has almost the same function as this one, except it only generates sup file ready to use for tsmuxer. That program uses libass which generates the sup file quite fast, while this program scans every frame of the video and output png one by one which takes quite some time. Have you considered to improve the efficiency of the program?

[ps auxw]

An updated version can be found in the first post.

Yes, the 30fps corrected the drop problem, big thanks for the program and quick reply. But this option is not listed in the input:

FRAMERATE Either of: 23.976, 24, 25, 29.97, 50, 59.94
I have added 30 (non-drop) to the list.

After getting the xml file, it has to be edited back to 29.97 since scenarist BD only takes 29.97 drop or non-drop.
avs2bdnxml should now write 29.97 to the XML file, even when 30 is given.

And I assume for 23.976 non-drop source, I have to use 24 as input to avoid drop problem, right?
Yes, this is very likely.

For the image quality, after I uncheck "Remove unused colors" in fireworks, the quality improves quite a bit. Now I have to look really close to see the white pixels, but they are there. So what's the reason you choose to output non 8bit RGBA pngs? It seems a little impractical to have true color pngs since most programs are designed to output BDMV structure.
The reasons for not outputting 8bit RGBA PNGs are simplicity and flexibility. I would have to add colour quantization to avs2bdnxml, to which there are quite a number of different approaches giving different quality. By outputting 32bit RGBA, different ways of quantization can be applied as the situation warrants. Also, both BDSupEdit and BDSup2Sub seem to include support for 32bit RGBA images, so at least conversion to SUP should be sufficiently painless these days. There should be a way to convert SUP back to BDNXML (with 8bit PNG) too.

Also I've tried the pinned PunkGraphicStream which has almost the same function as this one, except it only generates sup file ready to use for tsmuxer. That program uses libass which generates the sup file quite fast, while this program scans every frame of the video and output png one by one which takes quite some time. Have you considered to improve the efficiency of the program?
At the moment, the frame comparison code is very unoptimized. I'll try to do something about this soonish. Of course, working directly with a subtitle file offers certain speed benefits (like only having to scan intervals with actual subtitles) that can not easily be surpassed with the approach avs2bdnxml uses, which, in turn, offers more flexibility for input formats.

[hamletiii]

Thanks for the quick update. Definitely looking forward to the optimized version.
And for downgrading from 32bit RGBA png, BDSup2Sub handles the job really well. I think it's either Fireworks or me screwed up in the process because the pngs from BDSup2Sub are really good, no more white pixels!
I've also tried time collision, and fade in/fade out, they import and compile fine in scenarist BD. The fading effect plays smoothly in Totalmedia Theatre.

[sneaker_ger]

I'm also having problems with subtitles being out of sync. I've attached a sample. Just compare the timing of the first and last line of the xml with the first and last line of the ass.

[ps auxw]

Thanks for the quick update. Definitely looking forward to the optimized version.
And for downgrading from 32bit RGBA png, BDSup2Sub handles the job really well. I think it's either Fireworks or me screwed up in the process because the pngs from BDSup2Sub are really good, no more white pixels!
I've also tried time collision, and fade in/fade out, they import and compile fine in scenarist BD. The fading effect plays smoothly in Totalmedia Theatre.
I'll try to find some time to work on it in the next few days. Also, it's good to hear that BDSup2Sub solved the white pixel and the resulting subtitles play well. :)

I'm also having problems with subtitles being out of sync. I've attached a sample. Just compare the timing of the first and last line of the xml with the first and last line of the ass.

Are you sure this is out of sync? Comparing the timestamps of the last/first non-comment lines, it looks fine to me. Please note that the last part in BDN XML timestamps (the 09 in 00:21:18:09) is given in frames, not hundredths of seconds.

[sneaker_ger]

Are you sure this is out of sync? Comparing the timestamps of the last/first non-comment lines, it looks fine to me. Please note that the last part in BDN XML timestamps (the 09 in 00:21:18:09) is given in frames, not hundredths of seconds.

Ah, OK. I thought it was hundredths of seconds. Really strange way of mixing time and number of frames...

I got desync of the subtitles when playing the test Blu-Ray I created and thought this would be the cause. But since my PC is slow and I don't own a standalone Blu-Ray player yet it could just be my slow PC causing those problems. I'll try to investigate more.

[Gokumon]

Ah, OK. I thought it was hundredths of seconds. Really strange way of mixing time and number of frames...

It's not that strange as other subtitle programs use this format as well to get frame accurate timing.

[sneaker_ger]

There are even more programs using that format?
I mean - why not go for frame numbers or time only - why mix? But whatever - not for me to decide, maybe there are valid reasons.

[OptimusX]

I was using a workflow of Aegisub -> DVD-Sup -> BD-Sup and would have a flicker problem with colliding subs.

Anyway, when I do Aegisub->avs2bdnxml->BD-Sup the "flicker problem" is gone! And the subs look really good! So far this is the only method that I know of when using many different sub styles that collide (as is common in anime subs).

Thank you!

[ps auxw]

I got desync of the subtitles when playing the test Blu-Ray I created and thought this would be the cause. But since my PC is slow and I don't own a standalone Blu-Ray player yet it could just be my slow PC causing those problems. I'll try to investigate more.

Maybe your problem is drop/non-drop calculation difference, like it was for hamletiii? Please try calling avs2bdnxml with FRAMERATE as 24 instead of 23.976 and editing the resulting XML file to FrameRate="23.976", if necessary. Should this indeed turn out to be the problem again, I'll add it to the docs.

[sneaker_ger]

Thx, that seems to do the trick. But it's highly irritating having to set the wrong framerate to say the least. Can you explain to me why and in which cases this has to be done?

Another problem:
<Event Forced="False" InTC="00:16:30:13" OutTC="00:16:33:23">
<Graphic Width="1280" Height="720" X="0" Y="0">00023774.png</Graphic>
</Event>
<Event Forced="False" InTC="00:16:33:18" OutTC="00:16:35:04">
<Graphic Width="1280" Height="720" X="0" Y="0">00023851.png</Graphic>

It's an excerpt from the subtitle I created (the same as my attachment above) and as you can see the subtitles overlap. This leads to the first line being shown for a only a few ms for the start time of the second line.

[OptimusX]

I've experienced the timing issue as well. When working with a .ass file timed to 23.976 video, I was not able to get it to time properly until I called avs2bdnxml with "24" and manually edited the xml file to 23.976.

[hamletiii]

I found this thread explaining the drop/non-drop timecodes.
http://forum.doom9.org/showthread.php?t=73400

This is not the first subtitle software that requires a framerate conversion. DVDMaestro for instance requires 29.97 fps for input and 30 fps for output for any NTSC 29.97 non-drop source.

Maybe a second level prompt could be added if user choose 24fps as input:
Is the source 23.976 non-drop frame or 24p?
If 23.976 non-drop frame -> xml writes 23.976 in the field
If 24p -> xml writes 24 in the field.

[sneaker_ger]

Thanks for the info - sadly two of the documents linked in there don't exist anymore. I don't fully understand yet, but I hope I got the most important facts straight:

1.) Choosing 23.976, 29.97 (or 59.94) makes avs2bdnxml create the timecodes in the "drop"-way?
2.) Choosing 24 means it creates non-drop "23.976", choosing 30 means creating non-drop 29.97?
3.) There's currently no way to create 59.94 fps material the non-drop way?
4.) 25 and 50 are probably always created the non-drop way because of PAL? (Yet another reason why PAL is superior)

More questions/requests:
5.) is choosing 24 really creating perfect non-drop 23.976 timecodes or will it go out of sync on long movies? (same question for 30)
6.) I find the usage of this really irritating and most programs seem to expect non-drop timecodes anyway so I suggest you add another switch for "drop" or "non-drop" and make non-drop the default. That's more user friendly as it does not let every new user of this program run into the same problem.

[ps auxw]

Another problem:
<Event Forced="False" InTC="00:16:30:13" OutTC="00:16:33:23">
<Graphic Width="1280" Height="720" X="0" Y="0">00023774.png</Graphic>
</Event>
<Event Forced="False" InTC="00:16:33:18" OutTC="00:16:35:04">
<Graphic Width="1280" Height="720" X="0" Y="0">00023851.png</Graphic>
This really shouldn't happen, so it's a bug. I'll go look for it.

1.) Choosing 23.976, 29.97 (or 59.94) makes avs2bdnxml create the timecodes in the "drop"-way?
2.) Choosing 24 means it creates non-drop "23.976", choosing 30 means creating non-drop 29.97?
3.) There's currently no way to create 59.94 fps material the non-drop way?
4.) 25 and 50 are probably always created the non-drop way because of PAL? (Yet another reason why PAL is superior)
5.) is choosing 24 really creating perfect non-drop 23.976 timecodes or will it go out of sync on long movies? (same question for 30)
6.) I find the usage of this really irritating and most programs seem to expect non-drop timecodes anyway so I suggest you add another switch for "drop" or "non-drop" and make non-drop the default. That's more user friendly as it does not let every new user of this program run into the same problem.
1) Yes.
2) Yes, for 30 the correct value of 29.97 is written to the XML too.
3) You should be able to give a frame rate of 60 and edit the XML. There is no error checking there, yet.
4) To my knowledge, this is correct.
5) The created timecodes should be correct.
6) It is quite irritating! I will definitely make the usage more clear in the next version (23.976, 29.97 and 59.94 will be non-drop by default, with 23.976d etc. for the drop version). I would have done so before, but I wasn't aware of the problem. That's the fun thing about A/V processing, there's always a surprise left. ;)

[sneaker_ger]

Thanks. Exactly what I wanted to hear. :)

[ps auxw]

I just finished the new version of avs2bdnxml (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-1.5.tar.bz2). The overlapping timecode issue should be fixed. I optimized the code, too. Sadly, the optimization didn't help as much as I had hoped, since the majority of time (4/5 or so, in my 720p test) is spent in AviSynth/VSFilter. Non-drop timecodes are the default now, editing the XML file to correct the framerate should be no longer necessary.

[sneaker_ger]

Thx, seems to work just fine.

But I just noticed: Aren't you and I mixing non-drop and drop? As it is now, isn't "drop" the default, while "23.976d" is in fact "non-drop"? :confused:

[ps auxw]

No, I think everything is correct. In the non-drop time code thread (http://forum.doom9.org/showthread.php?p=480776#post480776) the example given for a non-drop time code of a certain frame ("For example, 02:34:17:12 (non-drop-frame) is 277722 frames") matches the way it is now calculated in avs2bdnxml, and it seems to be correct from a theoretical point of view too.

[sneaker_ger]

Yet another problem:

Sometimes the subtitle timing is 1 frame off. I'm not sure if it's the fault of avs2bdnxml or the fault of BDSup2Sub/BDSubEdit.

Sample (http://www.mediafire.com/?ymjyz1emyjy)

[sneaker_ger]

No, I think everything is correct. In the non-drop time code thread (http://forum.doom9.org/showthread.php?p=480776#post480776) the example given for a non-drop time code of a certain frame ("For example, 02:34:17:12 (non-drop-frame) is 277722 frames") matches the way it is now calculated in avs2bdnxml, and it seems to be correct from a theoretical point of view too.

You're right - stupid me.

[ps auxw]

Sometimes the subtitle timing is 1 frame off. I'm not sure if it's the fault of avs2bdnxml or the fault of BDSup2Sub/BDSubEdit.

Thanks for reporting. Could you tell me how you checked that the subtitle is 1 frame off? Also, is shifted or is just the beginning or end wrong, and in which direction is it off? The time code in the XML looks correct, and I'm not sure I am looking at the SUP files in the correct way.

[sneaker_ger]

The easiest way is to use the following AviSynth-Script and skip through it frame by frame with VirtualDub:
BlankClip(240,1280,720,"YV12",fps=24000,fps_denominator=1001)
SupTitle("color_bdsup2sub.sup",false)
Crop(0,100,0,0)
AddBorders(0,0,0,100)
TextSub("color.ass")
Besides vsfilter you'll also need the SupTitle plugin (http://www.zachsaw.co.cc/?pg=suptitle_pgs_avisynth_plugin).

Sometimes the subtitles appear 1 frame too late, sometimes they disappear 1 frame too late and sometimes both happens. In this specific sample it appears too late. I also created a .sup using PunkGraphicStream and the result was correct, so it's probably not an issue of SupTitle.

[sneaker_ger]

After thinking about it, it's probably an error in BDSup2Sub and BDSubEdit. The xml file clearly states that the subtitle should be displayed at "00:00:01:00", which is frame number 24 (or the 25th frame) and the resulting .sup is one frame too late. Please have a look at it anyway since I want to make sure it's really an error in both of the programs before contacting them.

Another thing - totally unrelated to my problem - I noticed is that even when using "23.976d" the "drop" parameter in the xml is "false".

[ps auxw]

The easiest way is to use the following AviSynth-Script and skip through it frame by frame with VirtualDub:
BlankClip(240,1280,720,"YV12",fps=24000,fps_denominator=1001)
SupTitle("color_bdsup2sub.sup",false)
Crop(0,100,0,0)
AddBorders(0,0,0,100)
TextSub("color.ass")
Besides vsfilter you'll also need the SupTitle plugin (http://www.zachsaw.co.cc/?pg=suptitle_pgs_avisynth_plugin).
Thanks, this helps.

After thinking about it, it's probably an error in BDSup2Sub and BDSubEdit. The xml file clearly states that the subtitle should be displayed at "00:00:01:00", which is frame number 24 (or the 25th frame) and the resulting .sup is one frame too late. Please have a look at it anyway since I want to make sure it's really an error in both of the programs before contacting them.
I have looked over the code once more and also tried making a SUP with PGS. After converting that SUP to BDN XML with BDSup2Sub, it matched the output of avs2bdnxml, so that really should be correct.

Another thing - totally unrelated to my problem - I noticed is that even when using "23.976d" the "drop" parameter in the xml is "false".
Thanks, this will be fixed in the next version. I forgot to add code to adjust that attribute.

[ps auxw]

New version (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-1.6.tar.bz2): I fixed the DropFrame bug and made detection of empty and different frames a bit more robust. Detection of SSE2 is now automatic.

[deank]

Thanks for this handy application! I wonder why I didn't see it earlier!

I have a small question. If for some reason the application executes exit() I get a crash window + :


This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

For example when there is no data processed as in:


Progress: 100/100 - Lines: 0 - Done
No events detected. Refusing to write XML file.


Is it possible to make avs2bdn exit with return 0 or at least in a fashion that won't make it crash?

Thank you once again!

Dean

[ps auxw]

Thanks for this handy application! I wonder why I didn't see it earlier!
I'm glad to hear you find it useful.

Is it possible to make avs2bdn exit with return 0 or at least in a fashion that won't make it crash?
Here's quick fix (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-1.7.tar.bz2). It should get rid of this problem.

[hamletiii]

Just reminds me that this program (ver1.6) will not output anything if the subtitle line contains empty space only. I just need some dummy transparent subtitle tracks the other day.

[deank]

I'm glad to hear you find it useful.
Here's quick fix (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-1.7.tar.bz2). It should get rid of this problem.

Thanks. I added 'advanced subtitle options' in multiAVCHD thanks to your program in combination with bdsup2sub.

I did a lot of tests yesterday and I found it a bit slow and I remember you saying that most of the time is spent by avisynth, so here is what I did:

Testing scenario:

* video with resolution 1920x1080 @ 23.976fps
* duration ~1hr 17mins (~110 000 frames)
* SRT subtitles with 1000 lines
* .styles file for VSFilter (no affect on speed)
* .avs script, using full frame (1920, 1080 parameters)

* avs2bdnxml.exe run time: 28 mins
* bdsup2sub.jar run time: 8 mins
* Total time for processing: 36 mins

---------------------

Now, I decided that there is no need for avisynth to create a full frame 1920x1080, since subtitles usually use about 30% of the screen. Having this in mind and expecting quality input text subtitles (since I'm a translator and create subtitles), which won't have more than 2 or 3 lines of text I decided to reduce the frame sizes, processed by all applications involved (avisynth+avs2bdnxml+bdsup2sub):

Before I start I am aware of font size, bottom offset and video resolution (of course), so I set a frame height to be not 1080 but 3.2*(font_type) mod 4. For example with 65pt font you get a frame of 1920x208 pixels.

* video with resolution 1920x1080 @ 23.976fps
* duration ~1hr 17mins (~110 000 frames)
* SRT subtitles with 1000 lines
* .styles file for VSFilter (using PlayResY: 208)
* .avs script, using new frame (1920, 208 parameters)

* avs2bdnxml.exe run time: 7 mins
* bdsup2sub.jar run time: 2 mins
* Total time for processing: 9 mins

A small modification is needed in the .xml file before it is passed to bdsup2sub:

All Y offsets (Y=0) are changed to Y= (original_frame_height - new_frame_height - bottom_offset), as in the example (using bottom offset of 32pixels), Y=1080 - 208 - 32 = 840.

Also the "VideoFormat" option in the <Format/> section is set with the proper (original) resolution (i.e. "1080p") - I added the 'p' because I saw that bdsup2sub uses it, instead of using the plain numeric value. I guess "1080" is okay, too.

I implemented these steps in multiAVCHD and now producing the .sup/PGS from SSA, ASS, SRT and microDVD sub text subtitles takes 5 to 10 times less, depending on the resolution.

And thanks again for your contribution!

Dean

[sneaker_ger]

That's a nice speed up but you should probably make it optional since ASS is often used for translations of signs for example. (Or even simpler: translations of tv speakers in the background are often put at the top of the screen) That would destroy the subtitles.

If you want more speed you may want to try AssRender (http://forum.doom9.org/showthread.php?t=148926&highlight=assrender) as a vsfilter alternative or PunkGraphicStream. (http://forum.doom9.org/showthread.php?t=148030) They are not as powerful as vsfilter+avs2bdnxml and the latter has a serious problem with big subtitles at the moment but I expect them to get better.

[deank]

Yes, there is now an option for 'full-frame' generation. Thanks for the suggestion :)

[ps auxw]

Just reminds me that this program (ver1.6) will not output anything if the subtitle line contains empty space only. I just need some dummy transparent subtitle tracks the other day.

This is due to the way it works. avs2bdnxml only looks at the frames. If a frame is completely transparent/empty, it will assume that there is no subtitle in that frame. You could use a dummy line and replace all references to PNGs with a single one to a transparent PNG though.

* Total time for processing: 36 mins
[...]
* Total time for processing: 9 mins
Nice idea. Once I add real commandline argument parsing, I'll add a way to set X and Y offsets, so the XML can be generated correctly with smaller frame sizes.

[Oleg Rode]

Perfect! Perfect results! Yes, VSFilter rendering engine is ideal! Thank a lot! Yes, your program requires to write AviSinth script, to calculate frames, but it is produces perfect subs!

This is fantastic! It looks like my problem to render ASS subs to Blu-Ray SUP is closed. :)

Sorry for my English :(

[deank]

A quick note:

The application crashes if avisynth parsed width is < ~700px or height is < ~104px.

Dean

[Oleg Rode]

There is a problem - flickering animated subtitles. What to do? i tried both BDSupEdit & BDSup2Sub - problem remains.

Here is an AviSynth script
MaskSub("Senjou no Valkyria - 01.ass",1280,720,23.976,33002)

And here is a program script
avs2bdnxml Script.avs Undefined und 720p 23.976 output.xml

And here is a subtitle file and AVCHD structure sample (burn it to DVD-RW disk, insert to Blu-Ray player and manually enable first subtitle)
http://rapidshare.com/files/270858243/Valkyria.zip.html

Tested on my PlayStation 3. Sorry for my English :(

[ps auxw]

A quick note:

The application crashes if avisynth parsed width is < ~700px or height is < ~104px.

Dean
Thanks for reporting, I'll look into it when I have time.

There is a problem - flickering animated subtitles. What to do? i tried both BDSupEdit & BDSup2Sub - problem remains.

And here is a subtitle file and AVCHD structure sample (burn it to DVD-RW disk, insert to Blu-Ray player and manually enable first subtitle)
http://rapidshare.com/files/270858243/Valkyria.zip.html
Having the XML output would've been useful too, but I can generate this myself, of course. Also, maybe this is related to the problem sneaker_ger reported. If timing is 1 frame off after conversion to SUP, it could lead to flickering subs where exact timing is required.

[sneaker_ger]

I don't get any blinking when using MPC-HC or SupTitle (http://forum.doom9.org/showthread.php?t=148167) (looks like this (http://www.mediafire.com/?5wfyy3jozwn)). Question is: does the blu-ray standard allow for such fast changing subtitles making it a PS3 specific problem?

[deank]

I get the same flickering in TMT and PS3...

Btw I decided to create a small front-end (gui like) to avs2bdnxml+bdsup2sup. (http://forum.doom9.org/showthread.php?p=1318490#post1318490)

[Oleg Rode]

Having the XML output would've been useful too, but I can generate this myself, of course. Also, maybe this is related to the problem sneaker_ger reported. If timing is 1 frame off after conversion to SUP, it could lead to flickering subs where exact timing is required.
Tried to set 23.976 to avs2bdnxml - flickering exist.
Tried to set 23.976d to avs2bdnxml - flickering exist.
Tried to set 24 to avs2bdnxml - flickering exist.
Tried to set 24 to avs2bdnxml and manually set 23.976 in .xml file - flickering exist.
Tried to set 24 to avs2bdnxml, set 24 in AVS script and set 24 fps in tsMuxeR for video - flickering exist.
Tried to set 25 to avs2bdnxml, set 25 in AVS script and set 25 fps in tsMuxeR for video - no sync :) but also no flickering.

Guys, I don't know what to do. Where to dig? Is there a problem with accuracy? Something like 23.976 is NOT the same as 24000/1001?

Sorry for my English :(

[ps auxw]

The application crashes if avisynth parsed width is < ~700px or height is < ~104px.
Should be fixed now (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-1.8.tar.bz2).

Tried to set 23.976 to avs2bdnxml - flickering exist.
[...]
Tried to set 25 to avs2bdnxml, set 25 in AVS script and set 25 fps in tsMuxeR for video - no sync :) but also no flickering.
I have now generated a couple of different XML files, like you said. There are still some bad timecodes in the output, for example:

<Event Forced="False" InTC="00:00:53:16" OutTC="00:00:53:16">
<Graphic Width="1280" Height="720" X="0" Y="0">00001288.png</Graphic>
</Event>
<Event Forced="False" InTC="00:00:53:16" OutTC="00:00:53:18">
<Graphic Width="1280" Height="720" X="0" Y="0">00001289.png</Graphic>
</Event>

As you can see, both start at the same timecode. Probably some rounding errors. I'll try to fix this. It might help with the flickering too.

[Oleg Rode]

Tried manually remove these bad timecodes from xml file
<Event Forced="False" InTC="00:00:53:16" OutTC="00:00:53:16">
<Graphic Width="1280" Height="720" X="0" Y="0">00001288.png</Graphic>
</Event>

Bad luck - flickerings exist :(

[sneaker_ger]

Could you do a test with PunkGraphicStream? Maybe it's not a problem of the subtitles but of the muxer (or the player). Do you have the possibility to mux with a different program (e.g. Scenarist)?

[ps auxw]

I have corrected timecode calculation now (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-1.9.tar.bz2). (Drop timecode support is dropped for now, the results weren't correct anyway. If anybody needs it and can verify calculated timecodes, I can try adding it back correctly.) Even if removing the duplicate timecode entries failed to fix the flickering, maybe it still helps somehow? Otherwise, try what sneaker_ger suggested.

[Oleg Rode]

I have corrected timecode calculation now. (Drop timecode support is dropped for now, the results weren't correct anyway. If anybody needs it and can verify calculated timecodes, I can try adding it back correctly.) Even if removing the duplicate timecode entries failed to fix the flickering, maybe it still helps somehow? Otherwise, try what sneaker_ger suggested.
Not working - flickering exist.
Could you do a test with PunkGraphicStream?
Results much worse. Flickerings are on all animated subs.
Maybe it's not a problem of the subtitles but of the muxer (or the player). Do you have the possibility to mux with a different program (e.g. Scenarist)?
OK, i'll try.

[sneaker_ger]

The new version 1.9 still creates overlapping timecodes on Oleg's sample:
<Event Forced="False" InTC="00:00:03:17" OutTC="00:00:03:18">
<Graphic Width="1280" Height="720" X="0" Y="0">00000089.png</Graphic>
</Event>
<Event Forced="False" InTC="00:00:03:18" OutTC="00:00:03:19">
<Graphic Width="1280" Height="720" X="0" Y="0">00000090.png</Graphic>
</Event>

Or am I misinterpreting the timecodes?
Is "00:00:03:17" the first frame it is to be shown on and "00:00:03:18" the first frame it is supposed to be NOT shown on?

[sneaker_ger]

@ Oleg:

Could you test this sample (http://www.mediafire.com/?hhmo1iyqdzz) (rename to "valkyria.7z", it somehow screwed up the name) on your PS3? Don't mind subtitles and video not being in sync, only look for blinking.

[ps auxw]

Is "00:00:03:17" the first frame it is to be shown on and "00:00:03:18" the first frame it is supposed to be NOT shown on?

I think this is the case, but I am not sure. It would be nice if anybody knew for sure and clarify the situation.

[sneaker_ger]

I had a little talk about the timecodes being 1 frame off in BDSup2Sub and it turns out that it's not an error in BDSup2Sub (nor in BDSubEdit) but actually an error in SupTitle. It just so happens that there's also an error in PunkGraphicStream and both errors nullified each other which made me draw a wrong conclusion.

[Oleg Rode]

@ Oleg:

Could you test this sample (http://www.mediafire.com/?hhmo1iyqdzz) (rename to "valkyria.7z", it somehow screwed up the name) on your PS3? Don't mind subtitles and video not being in sync, only look for blinking.
There is a problem - wrong AVCHD structure. I created a new one and put .m2ts file from your image. Result is not good, but I noticed a strange thing - sometimes subs are playing correctly. In other words - I start to play sample, somewhere in the middle I press "previous chapter" button and sample plays again from the beginning (of course we got only one chapter). I do this again and again and sometimes (somewhere in 1 of 7 times) there is no flickering. At least at "fading in" period. May be subs are changing too fast? May be to try slow down animation? I.e. let's 1 picture will be visible during 2-3 frames.

Sorry for my English :(

[sneaker_ger]

That could be possible, but it would be a shame having to cripple animations. It also does not explain why there are no problems when using 25 fps.
What about this one:
http://www.mediafire.com/?45efdmygwyj

[Oleg Rode]

That could be possible, but it would be a shame having to cripple animations. It also does not explain why there are no problems when using 25 fps.
What about this one:
http://www.mediafire.com/?45efdmygwyj
Much worse than previous :( Flickerings are all the time.

[sneaker_ger]

Ah, my fault. Try this one (http://www.mediafire.com/?nzmjmowmrmj).

[Oleg Rode]

Ah, my fault. Try this one (http://www.mediafire.com/?nzmjmowmrmj).
No, the same result as previous. The best result was in this message
http://forum.doom9.org/showthread.php?p=1320068#post1320068

Again, about the nature of flickering. I tried to make frame-by-frame review of this sample (Yes, PS3 allows to do this. It is need to press one time "pause" and then keep clicking on "fast forward" button). And I noticed, that first frame subtitle exist, the next frame - no subs, again the next frame - sub is visible, the next frame - no sub etc. So, when I do frame-by-frame review of the sample from this message (this message) - subs were not disappeared.

[sneaker_ger]

Your last link does not work. So you are saying that one of the samples worked fine (no blinking) when going through the video frame-by-frame, while playing real time made the subtitles blink again? That's really strange.
Would be really good if some of the pros could look into it. Especially why the 25 Hz material works fine and the 24/1.001 Hz material doesn't. Perhaps the timing is inaccurate or wrong. Timing of 25 Hz material is simpler because one frame get's shown exactly 40 ms while 24/1.001 material get's shown for 41,708333... ms.
I don't have the knowledge to fix this. (If it actually can fixed on our side and it's not a problem of the PS3.)

[ps auxw]

Is "00:00:03:17" the first frame it is to be shown on and "00:00:03:18" the first frame it is supposed to be NOT shown on?

Just in case the implementation is indeed wrong, here's a version which should set OutTC to the last frame the subtitle appears on: http://www.ps-auxw.de/avs2bdnxml/avs2bdnxml-outtc-test.tar.bz2

[Oleg Rode]

Your last link does not work.
From this post
http://forum.doom9.org/showthread.php?p=1320068#post1320068

Again, but why was there problem with 24 fps?

[sneaker_ger]

Just in case the implementation is indeed wrong, here's a version which should set OutTC to the last frame the subtitle appears on: http://www.ps-auxw.de/avs2bdnxml/avs2bdnxml-outtc-test.tar.bz2

BDSup2Sub seems to interpret the timecodes in the way of your original program.

From this post
http://forum.doom9.org/showthread.php?p=1320068#post1320068

Again, but why was there problem with 24 fps?

I wish I'd knew why...

[PHD_1976]

Hi!
Recently i've tested easySUP (http://forum.doom9.org/showthread.php?p=1320802#post1320802) part of which is a GUI for avs2bdnxml.

This was my original message, please read it.
(I'm sorry beforehand if the problem already solved)
I chose BDN XML+PNG output to use it with Scenarist.
Well, Scenarist accepted XML structure but hung on first png file.
I've compared your png and png file Scenarist is happy with and they differ.
Due to BD White Papers (Application Definition Blu-ray Disc Format):
Graphics planes
... One graphics plane is assigned for subtitling applications
(Presentation Graphics or Text Subtitles) ...

... Each graphics plane has 8-bits per pixel,
with each pixel value referring to an index entry in a Palette
for translation to YCrCb color and 8-bit (256level) alpha.

So, PNG IHDR chunk must have ColorType=3 (yours is 6 AFAIR), and two more chunks must be present:
PLTE chunk - palette and tRNS chunk - transparency.

Being fed with png having such header Scenarist feels itself very happy

[ps auxw]

... Each graphics plane has 8-bits per pixel,
with each pixel value referring to an index entry in a Palette
for translation to YCrCb color and 8-bit (256level) alpha.
avs2bdnxml produces 32bit RGBA PNG whereas some programs require 8bit palette PNG. I also explained the reason for using 32bit PNG output (http://forum.doom9.org/showpost.php?p=1313944&postcount=9) before. Conversion is already explained in the first post:
For some programs, you have to convert the PNG files to 8bit RGBA palette. This doesn't apply to BDSup2Sub and BDSupEdit. You can probably do this with a tool like pngquant (http://www.libpng.org/pub/png/apps/pngquant.html) or pngnq (http://pngnq.sourceforge.net/).
You can also use BDSup2Sub to output BDN XML from a BDN XML source. This should also have the PNGs palletised. If easySUP allows output in BDN XML format, doing this automatically might be a good idea.

[sneaker_ger]

@PHD_1976:

sorry to have you referred to this thread just to get referred back to the easySUP thread... :o
And it get's even better: could you do us a favor? We are having problems problems with blinking subtitles on the PS3 and I'd like to rule out tsmuxer as the cause. Could you mux these subtitles (http://www.mediafire.com/?d2b2oi3hoiu) with Scenarist (just include any kind of video and audio, does not matter, it has to be 24000/1001 = 23.976 fps material though) and upload the result for us? I don't own Scenarist so I can't do it myself.

[PHD_1976]

ps auxw ,
tnank you for the explanation

sneaker_ger,

I've created a project with your subs and short video.
Scenarist (I use v4.3) accepted subtitles while creating a project but gave an error while muxing and didn't create a BD:

Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=4220489
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=4747220
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=4747220
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=4747220
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=4747220
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=5272420
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=5798630
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=6324840
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=6324840
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=6324840
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=6850529
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=7376218
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=7376218
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=7376218
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=7376218
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=7376218
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=7901386
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=8426554
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=8426554
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=8426554
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=8426554
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=8426554
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=8951201
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=9475848
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=9475848
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=9475848
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=9475848
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=9999974
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=10524100
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=10524100
Error : The Decoded Object Buffer(DB) overflows. limit size=4194304, occupancy size=10587442
Error : PG Encode error(PG#1). See above message.


I don't know what it means really.
Actually I've never seen such colorful subs.
BTW, xml script says its german, but they are russian actually, but it doesn't matter right now.

[sneaker_ger]

Thx! :thanks:

Seems as if we have broken some limit. I hope there's a good way to work around it.

[ps auxw]

I've created a project with your subs and short video.
Scenarist (I use v4.3) accepted subtitles while creating a project but gave an error while muxing and didn't create a BD:

Thanks, this is helpful. After looking around a bit, I found the following information:

Buffer considerations Before any graphics can be displayed, they need to be loaded into the BD-ROM player's buffer for rendering. There are separate buffers for Interactive and Presentation Graphics known as `decoded object buffers'. The Interactive Graphics `decoded object buffer' is 16MB, while the buffer for Presentation Graphics is 4MB. For BD-J graphics the buffer size is 45.5MB (5MB of which can be used for audio), but all graphics are rendered as 32-bit images, thus they take up more buffer space. There is also a separate `coded object buffer' which holds the entire encoded stream. The composition segment is copied to the `composition buffer'. There are separate size limits for the composition and coded object buffers. Overloading the player buffers will result in the BD-ROM player displaying an error message. Therefore, remember at all times that you need to try and conserve memory. Design the graphics as if they're destined for a web page.
The subtitle pictures are too big for their 4MB buffer. Anyway, cropping the images to minimum size should help a bit. Obviously, from looking at sneaker_ger's subtitles it's not enough yet. Those ~1010x521 frames are still enough to fill up the buffer quickly. If you look at the buffer's occupancy size, you will see it differs by ~526731B, which corresponds to the subtitle frame size. Since the buffer overflows, it seems obvious that images are kept for a certain time, not just until they go out of use. Now, the question is how long a picture is kept in buffer. Probably about one second or so? I couldn't find any information about that.

For the next version of avs2bdnxml, I should implement automatic cropping of output pictures. Dropping some similar subtitle frames and displaying the last one longer for the corresponding time, might be another acceptable way of freeing some buffer space, but this would require knowing how long each picture is kept in buffer.

[sneaker_ger]

The problem is that the subtitles I've sent PHD_1976 already are cropped by BDSup2Sub, so that there's probably no need to implement autocropping twice.

[ps auxw]

The problem is that the subtitles I've sent PHD_1976 already are cropped by BDSup2Sub, so that there's probably no need to implement autocropping twice.

I see, but I'll have to autocrop anyway, if I want to implement accurate frame dropping to fit the buffer. Alternatively, that could be implemented in BDSup2Sub.

[hamletiii]

@PHD_1976:

sorry to have you referred to this thread just to get referred back to the easySUP thread... :o
And it get's even better: could you do us a favor? We are having problems problems with blinking subtitles on the PS3 and I'd like to rule out tsmuxer as the cause. Could you mux these subtitles (http://www.mediafire.com/?d2b2oi3hoiu) with Scenarist (just include any kind of video and audio, does not matter, it has to be 24000/1001 = 23.976 fps material though) and upload the result for us? I don't own Scenarist so I can't do it myself.

Here's your subtitle compiled in Scenarist BD 5, with the large sized subpictures causing overflow removed. No obvious flickering viewed in TMT3

http://www.mediafire.com/?tqmzrzlivwz

[hamletiii]

For the next version of avs2bdnxml, I should implement automatic cropping of output pictures. Dropping some similar subtitle frames and displaying the last one longer for the corresponding time, might be another acceptable way of freeing some buffer space, but this would require knowing how long each picture is kept in buffer.

Seeing as you can drop similar subtitle frames, is that possible to implement splitting timecodes for the same subtitle?
Here's the example timecodes for the same subtitle sliced to several parts:


InTC="00:06:29:01" OutTC="00:06:29:09">
<Graphic>00000_1_01_0643.png</Graphic>
</Event>
<Event Forced="false" InTC="00:06:29:09" OutTC="00:06:29:17">
<Graphic>00000_1_01_0644.png</Graphic>
</Event>
<Event Forced="false" InTC="00:06:29:17" OutTC="00:06:30:01">
<Graphic>00000_1_01_0645.png</Graphic>
</Event>
<Event Forced="false" InTC="00:06:30:01" OutTC="00:06:30:09">
<Graphic>00000_1_01_0646.png</Graphic>
</Event>
<Event Forced="false" InTC="00:06:30:09" OutTC="00:06:30:17">
<Graphic>00000_1_01_0647.png</Graphic>
</Event>
<Event Forced="false" InTC="00:06:30:17" OutTC="00:06:31:01">
<Graphic>00000_1_01_0648.png</Graphic>
</Event>
<Event Forced="false" InTC="00:06:31:01" OutTC="00:06:31:09">
<Graphic>00000_1_01_0649.png</Graphic>
</Event>
<Event Forced="false"

The benefit of doing this is that when you rewind/FF the video, the subtitles immediately shows up.

[sneaker_ger]

Thx, let's see if it works on Oleg's PS3.
The question why at 25 fps there's no flickering remains though.

[ps auxw]

Seeing as you can drop similar subtitle frames, is that possible to implement splitting timecodes for the same subtitle?
The benefit of doing this is that when you rewind/FF the video, the subtitles immediately shows up.

Well, I can't yet. ;) But I'm working on it. Splitting shouldn't be a problem. Might take a bit though, since I'll be quite busy with other things over the next two weeks.

[hamletiii]

Well, I can't yet. ;) But I'm working on it. Splitting shouldn't be a problem. Might take a bit though, since I'll be quite busy with other things over the next two weeks.

Please take your time.
Here (http://www.mediafire.com/?sharekey=342b0405c4c1a8e12fb2ca15d7ea42d9e04e75f6e8ebb871) is an entire subtitle example, unfortunately the pngs are in Japanese. I think for the timecodes, they just split each sentence 8 frames apart.


I think this stream also does cropping, and it crops subtitles with large areas to two smaller areas. Here (http://i44.photobucket.com/albums/f18/DVDmaster/compositionobject.png) is a demonstration when you import it into scenarist BD, the PES editor is showing two composition objects, and it's only taking 0.1M of buffer for spanning quite a large area. So take sneaker_ger's subtitle for example, 1000*500 ones, there are actually a lot of empty space between lines on the upper right corner and lower left corner, if these are cropped separately and still placed correctly in their position, then buffer overflow should be taken care of.

[Oleg Rode]

Here's your subtitle compiled in Scenarist BD 5, with the large sized subpictures causing overflow removed. No obvious flickering viewed in TMT3

http://www.mediafire.com/?tqmzrzlivwz
Again, wrong AVCHD structure. I opened a .m2ts file with tsMuxeR and created a new one. Result is perfect, sub is moving smoothly and no flickerings at all :). Still, I don't see the bottom part of the sub. Must be like this.
http://pic.ipicture.ru/uploads/090903/thumbs/CAngqbB38l.png (http://ipicture.ru/Gallery/Viewfull/23171361.html)
Is it correct? There is a foto (well, picture is not very good :p)
http://pic.ipicture.ru/uploads/090903/thumbs/9RCV112iTE.jpg (http://ipicture.ru/Gallery/Viewfull/23171033.html)

So, what is the solution of the problem?

[hamletiii]

Scenarist will only output Blu-ray structure, you'll need deank's goBD (http://forum.doom9.org/showpost.php?p=1255353&postcount=30) or wirepole's AVCHD-patcher (https://cid-8ea621696fd320b1.skydrive.live.com/browse.aspx/%E5%B7%A5%E5%85%B7%E7%A8%8B%E5%BC%8F/AVCHD-Patcher) or manually hex editing index.bdmv or just burn a Blu-ray Disc to avoid remux in tsmuxer.

I removed the large sized subtitles (in your first photo) because they are too big, causing the same buffer overflowing error as PHD_1976. So it appears that both Scenarist and tsmuxer gives you good results as long as the large subtitles are removed, it just might be tsmuxer muxes the overflowing ones anyways which causes flickering. If you want to keep them, I think you'll have to cut and crop the large pictures to two small regions. We'll have to wait and see if ps auxw can do anything about it.

[ps auxw]

Please take your time.
Here (http://www.mediafire.com/?sharekey=342b0405c4c1a8e12fb2ca15d7ea42d9e04e75f6e8ebb871) is an entire subtitle example, unfortunately the pngs are in Japanese. I think for the timecodes, they just split each sentence 8 frames apart.


I think this stream also does cropping, and it crops subtitles with large areas to two smaller areas. Here (http://i44.photobucket.com/albums/f18/DVDmaster/compositionobject.png) is a demonstration when you import it into scenarist BD, the PES editor is showing two composition objects, and it's only taking 0.1M of buffer for spanning quite a large area. So take sneaker_ger's subtitle for example, 1000*500 ones, there are actually a lot of empty space between lines on the upper right corner and lower left corner, if these are cropped separately and still placed correctly in their position, then buffer overflow should be taken care of.

This is very interesting. The BDN XML scheme (http://www.urusoft.net/forum/viewtopic.php?id=5446) seems to tell me that an event can have 0-2 graphical or text components. This means it should be possible to split images into two rectangles with minimum surface area to minimize buffer usage. Will try to implement that instead of just autocropping.

[ps auxw]

I finished version 1.10 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-1.10.tar.bz2) now. See the first post for changes and new syntax. Since I couldn't quite figure out the way buffer is calculated, this version does not yet have Presentation Graphics buffer overflow checks.

Seeing as you can drop similar subtitle frames, is that possible to implement splitting timecodes for the same subtitle?
This is implemented now, see the --split-at or -s option.

http://pic.ipicture.ru/uploads/090903/thumbs/9RCV112iTE.jpg (http://ipicture.ru/Gallery/Viewfull/23171033.html)

So, what is the solution of the problem?
Please try again with the new version. It should be much more efficient in buffer use for your subtitles.

[Oleg Rode]

Please try again with the new version. It should be much more efficient in buffer use for your subtitles.
Well, not so fast. Neither BDSupEdit, nor BDSup2Sub understand subs splitting (they see only upper part of the sub). I am a shame to ask, but may be you can write simple xml to sup converter? Or add a .sup output to your program?

[Oleg Rode]

Well, Scenarist also does not accept created subs. Any recommendations?

[ps auxw]

Well, Scenarist also does not accept created subs. Any recommendations?
I might've gotten the XML wrong. For now, use "-b0" should disable image splitting, but of course it'll flicker again.

I am a shame to ask, but may be you can write simple xml to sup converter? Or add a .sup output to your program?
That would take some time and I'm quite busy currently. Maybe it will work, once the format is corrected(?).


hamletiii: Could you generate and post a BDN XML file for the subtitles on that screenshot (http://i44.photobucket.com/albums/f18/DVDmaster/compositionobject.png), so I can check the format?

[hamletiii]

http://www.mediafire.com/?wnajh2nbaa2

This is the entire example file, including all the pngs and the xml generated by BD Reauthor Pro from a Japanese commercial disc.

I'll try your new version when I have access to Scenarist BD to see if I get the same result as Oleg Rode.

[ps auxw]

http://www.mediafire.com/?wnajh2nbaa2

This is the entire example file, including all the pngs and the xml generated by BD Reauthor Pro from a Japanese commercial disc.

Thank you, but I have looked through all the subtitles in the archive and did not find a case where two subtitles in different positions where displayed at the same time, like in the screenshot. (I did not see any カセットテプ subtitle either, but might just have missed it.) Are you sure it is the right file?

[hamletiii]

I downloaded the rar, yes it's the right one. Look for png end with 1280-1287, 1280-1285 are the bottom horizontal lines "カセットテープ：ギタの音", 1286-1287 are the right vertical lines "唯：けいおん！".
BD Reauthor Pro don't crop the subtitle, so I think the secret is within the xml file.

[ps auxw]

I downloaded the rar, yes it's the right one. Look for png end with 1280-1287, 1280-1285 are the bottom horizontal lines "カセットテープ:ギタの音", 1286-1287 are the right vertical lines "唯:けいおん!".
BD Reauthor Pro don't crop the subtitle, so I think the secret is within the xml file.

Ah, you are right, there are those frames. Sorry for the trouble. Still, it doesn't look quite right:
<Event Forced="false" InTC="00:14:23:02" OutTC="00:14:23:10">
<Graphic>00000_1_01_1280.png</Graphic>
</Event>
<Event Forced="false" InTC="00:14:23:10" OutTC="00:14:24:13">
<Graphic>00000_1_01_1281.png</Graphic>
</Event>
<Event Forced="false" InTC="00:14:24:18" OutTC="00:14:25:02">
<Graphic>00000_1_01_1282.png</Graphic>
</Event>
<Event Forced="false" InTC="00:14:25:02" OutTC="00:14:25:10">
<Graphic>00000_1_01_1283.png</Graphic>
</Event>
<Event Forced="false" InTC="00:14:25:10" OutTC="00:14:26:14">
<Graphic>00000_1_01_1284.png</Graphic>
</Event>
<Event Forced="false" InTC="00:14:27:03" OutTC="00:14:27:11">
<Graphic>00000_1_01_1285.png</Graphic>
</Event>
<Event Forced="false" InTC="00:14:27:11" OutTC="00:14:27:19">
<Graphic>00000_1_01_1286.png</Graphic>
</Event>
<Event Forced="false" InTC="00:14:27:19" OutTC="00:14:28:21">
<Graphic>00000_1_01_1287.png</Graphic>
</Event>

I don't think this can work. Maybe BD Reauthor Pro "linearized" the subtitles.

[hamletiii]

OK, regarding the file generated by BD Reauthor Pro, I've tried the following 2 methods:
1. Import the entire project xml file, compile the disc. Result is 1:1 copy of original.
2. Manually add in video and audio, then import subtitle xml file, compile the disc. Result is as what the timecodes would give you, the subs will just go like crazy.

So the project xml file is definitely doing some work there in cross referencing (not sure if your term "linerized" is the same meaning?) these picture events.

http://www.mediafire.com/file/ogctmqygmnd/project.rar

I'm not sure if the Scenarist project file will help you, but I've uploaded it anyway.


More details in comparing the differences after importing:
Methold 1. There are 382 Epoches. Most time: one Epoch has one window and one DisplaySet, one DisplaySet (CompositionState: Epoch Start) has one Palette and one compositionobject. Other time: one Epoch has two windows and multiple DisplaySets, the first DisplaySet (CompositionState: Epoch Start), second and anything after (CompositionState: Normal Case), one DisplaySets could also have two CompositionObjects which reside in their respective window.


Methold 2. There are 404 Epoches. Most time: one Epoch has one window and one DisplaySet, one DisplaySet (CompositionState: Epoch Start) has one Palette and one compositionobject. Other time: one Epoch has two windows and multiple DisplaySets, the first DisplaySet (CompositionState: Epoch Start), second and anything after (CompositionState: Acquisition Point), one DisplaySets always has only one CompositionObjects which reside in window#1 or window#2.


• Epoch Flag sets the composition state for the Display Set; options are:

• Normal Case means that the Display Set contains only elements that are changed from the previous composition.
• Acquisition Point means that the Display Set contains all elements needed to display the next composition.
• Epoch Start indicates the start of a new Epoch; the Display Set contains all elements needed to display the next composition.
• Epoch Continue means that the Epoch may be continued across into this graphics stream from the previous graphics stream when seamless
connection conditions apply. The Display Set contains all elements needed to display the next composition.

[hamletiii]

So I just tested version 1.10 briefly with the b1 switch.
BDSup2Sub totally ignores the second object in the event.
So I went with my old method, using Fireworks to downconvert the png32 to png8. The xml file imports fine and compiles. The subtitles show up ok in TMT3.
About the Normal Case/Acquisition Point flag for the second DisplaySet, I don't think that matters.
I'll try the split function later.

[hamletiii]

Well, Scenarist also does not accept created subs. Any recommendations?

Which version of Scenarist are you using?
4.5 and below seems to have more restriction than the latest 5.0+, at least that's my experience.

Could you send me your original ssa/ass file?

[ps auxw]

OK, regarding the file generated by BD Reauthor Pro, I've tried the following 2 methods:
[...]
Thank you very much for the detailed information.

So I just tested version 1.10 briefly with the b1 switch.
BDSup2Sub totally ignores the second object in the event.
So I went with my old method, using Fireworks to downconvert the png32 to png8. The xml file imports fine and compiles. The subtitles show up ok in TMT3.
About the Normal Case/Acquisition Point flag for the second DisplaySet, I don't think that matters.
I'll try the split function later.
So with current Scenarist, -b1 seems to work? This is very good news. I'll take a deeper look at the project file and other information posted before anyway.

I'm still busy the next two or so days, but afterwards I'll try adding color palletisation and possibly SUP/PGS output.

Edit: Actually, before I do that, I'll ask 0xdeadbeef if he can add support for multiple Graphics per Event to BDSup2Sub.

[Oleg Rode]

Edit: Actually, before I do that, I'll ask 0xdeadbeef if he can add support for multiple Graphics per Event to BDSup2Sub.
Thanks a lot. I had to do this request, but I didn't know how to correctly figure a question :D

[ps auxw]

Thanks a lot. I had to do this request, but I didn't know how to correctly figure a question :D

It seems like I will have to implement it myself, after all. This might take a while.

[ps auxw]

Well, Scenarist also does not accept created subs. Any recommendations?Which version of Scenarist are you using?
4.5 and below seems to have more restriction than the latest 5.0+, at least that's my experience.

Could you send me your original ssa/ass file?

I think it was in here: http://rapidshare.com/files/270858243/Valkyria.zip.html

[hamletiii]

I just finished testing on a full length 2hr movie by using -s switch today, it worked as expected. Since splitting creates a lot of pngs, it took more than one hour for scenarist BD to import and encode them to it's *.pes file, not to mention another hour for avs2bdnxml and BDSup2Sub to get the right xml+pngs. So I was curious about if these *.pes files can be used in other projects. So I just drag the *.pes file into Scenarist's project, and it accepts without any further processing.

So this leads me to go back to check if the files generated by BD Reauthor Pro has these *.pes files, and they are right under the demuxed folder. For the sample I've uploaded here, after importing, it already has all the correct references and structures:

http://www.mediafire.com/file/nmuzi3wtctz/00000_1_01.rar


tsMuxer cannot recognize these streams though.

[Oleg Rode]

Which version of Scenarist are you using?
4.5 and below seems to have more restriction than the latest 5.0+, at least that's my experience.
I have access to Scenarist 5.0

Can you tell, what do I need to do after creating xml+png files? Do I need to reconvert pictures or do I need to set special commands to avs2bdnxml?

[Rectal Prolapse]

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?

[hamletiii]

I have access to Scenarist 5.0

Can you tell, what do I need to do after creating xml+png files? Do I need to reconvert pictures or do I need to set special commands to avs2bdnxml?

The pngs generated from avs2bdnxml are 32 bit, Blu-ray in HDMV mode only supports 8 bit png, so you'll have to convert the pngs to 8 bit.
After creating xml+png from avs2bdnxml, you need to use BDSup2Sub, choose xml+png as output.

[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. :(

[Hyper Shinchan]

@Hyper Shinchan: Those programs don't support split lines, like those produced by -b1. It only works with Scenarist, I think.
Actually other splitted subtitles didn't seem to be a problem for those programs, I can post more samples if it's needed. Anyway if it's a problem with those two programs (that surely doesn't support all the functions of Scenarist) it could be worth mentioning it either in the printed help or in your home page.

[ps auxw]

Actually other splitted subtitles didn't seem to be a problem for those programs, I can post more samples if it's needed. Anyway if it's a problem with those two programs (that surely doesn't support all the functions of Scenarist) it could be worth mentioning it either in the printed help or in your home page.
Peculiar. As is, I can't even look at the sample you posted above, since it isn't approved yet. Also, good point about mentioning -b compatibility issues. I put a note in the first post.

[hamletiii]

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.

Not sure about BDSupEdit, but BDSup2Sub does not support -b1. This has been talked about several times in this thread and the BDS2S thread. The author 0xdeadbeef also confirms (http://forum.doom9.org/showpost.php?p=1389088&postcount=129) that -b1 is not supported and he has no intention to add such support. This means subtitles created by avs2bdnxml and many Japanese BDs with similar features are not supported.

-b1 (need avs2bdnmxl ver 1.13, previous versions have bugs) works extremely well with Scenarist BD. Scenarist BD reads the region size from the tags, but the window size is based on the overall size of these pictures after Scenarist BD did the Epoch combining step.

[hamletiii]

Actually other splitted subtitles didn't seem to be a problem for those programs, I can post more samples if it's needed. Anyway if it's a problem with those two programs (that surely doesn't support all the functions of Scenarist) it could be worth mentioning it either in the printed help or in your home page.

Are you sure those are dual window splitted like what -b1 does? I would be curious to see it. Can you upload the sample on a file sharing site such as megaupload or mediafire?

[Hyper Shinchan]

Are you sure those are dual window splitted like what -b1 does? I would be curious to see it. Can you upload the sample on a file sharing site such as megaupload or mediafire?

I'm sorry, I've jumped to conclusion without checking the properly, I simply didn't notice that they were missing while watching the movie on the PS3 (and after searching for splitted subs I noticed that my scripts had other than the one I've posted that I've recognized as missing while watching the movie), now I've checked them and they're not processed correctly by BDSup2Sub, I'm sorry.

The author 0xdeadbeef also confirms that -b1 is not supported and he has no intention to add such support. This means subtitles created by avs2bdnxml and many Japanese BDs with similar features are not supported.
You say that many Japanese BDs use them, have you mentioned that to him?

Also, good point about mentioning -b compatibility issues. I put a note in the first post.
Thank you very much, some people (like me) could simply start using your program without checking all the discussions in doom9 and they could encounter similar issues, that note will save them some problem.

[hamletiii]

You say that many Japanese BDs use them, have you mentioned that to him?

Thank you very much, some people (like me) could simply start using your program without checking all the discussions in doom9 and they could encounter similar issues, that note will save them some problem.

Please read pages 5-7 in this thread, all your questions should be answered already. I believe reading the threads is the best way to learn things if you encounter problems.

So basically, BDS2S is a subtitle CONVERSION tool instead of a rendering tool. The author is not bothered to extend his tool to cover all BD Specs. Your best bet is to wait for ps auxw's direct sup support or someone else to come up a fully spec compliant xml+png->sup program.

For now if you still want to use BDS2S, my suggestion is to keep all your subtitle within half of your vertical resolution (540 pixels for 1080) given any time. This way you can get the correct results without using -b1. I know it sucks that you can't put subtitles anytime anywhere you want, but this is just the way it is for now, unless you are using Scenarist BD...

[ps auxw]

Once again I have to apologize for a long-ish period without updates. Still, I bring some nice news. I just uploaded avs2bdnxml 2.01 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.01.tar.bz2) with experimental SUP output support. Please note, that I do not currently have access to BluRay playback hardware or software, so I could not do any real world tests, but the output files look reasonable, compared to reference files. If you experience any problems, please report them. If it works, I'd be happy to hear about that too. ;)

I have also added the options "--count" and "--seek" to support partial processing of input files.

[hamletiii]

Thanks for your hard work. This software just gets better and better.
I did a brief test with a pretty complex *.ass (dual window consecutive multiple composition objects in one epoch), but there's some problem with the "compositionposition structure" as reported by Scenarist BD.

The generated sup does not work in TMT3, only the first subtitle shows up, then never goes away. If you drag the timeline around, there's no subtitle showing up.
So then I demuxed the project with BD Reauthor Pro, got the *.pes file, then drag the *.pes file into Scenarist BD, got the following error:


Error : Out of range - there are out of range value(s), in the CompositionPosition structure.
Error : PG Decode error. K:\ALL MUXING\PES testing2\00000_1_01.pes offset=0x70120 (first byte of invalid segment).
Error : FilePath : K:\ALL MUXING\PES testing2\00000_1_01.pes,
Decode failed.



HERE (http://www.mediafire.com/?61wcwf1zfha53xx) is the sample, the invalid one is using avs2bdnxml 2.01, the valid one is xml+png from avs2bdnxml 1.13 muxed with Scenarist BD then demuxed with eac3to.

Also can you make avs2bdnxml to generate *.sup AND xml+png at the same time?

The pgsparse.exe in the debug folder looks interesting, but I don't see it automatically generates reports?

[ps auxw]

Thank you for the bug report. I'll look into it today.

Also can you make avs2bdnxml to generate *.sup AND xml+png at the same time?
I'll see what I can do. Edit: Implemented. In the next version, you can use "-o" twice, with different output formats.

The pgsparse.exe in the debug folder looks interesting, but I don't see it automatically generates reports?
It writes the information to standard output. You can generate a report like this:
pgsparse.exe input.sup > report.txt

Edit: Were identical settings used for avs2bdnxml in both cases? If so, which? The content of those SUP files seems to be a bit different. Actually, the valid file looks a bit munged (e.g. the dts field is always set to 0). Could you possibly send me the .ass and .avs files too?

Edit 2: I just released avs2bdnxml 2.02 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.02.tar.bz2) with the aforementioned double-output and some fixes to SUP output. I am not sure, whether any of them could possibly help with the CompositionPosition structure problem. If not, having the .pes file might be useful so I can look at the data near 0x70120 for clues.

[hamletiii]

The double output works, but sup output is still the same result. In addition, I tested in Scenarist QC this time, the subtitle formatting is messed up, only composition object 2 is showing up in window 1, composition object 1 is supposed to be showing up in window 2 but is showing a wrong positioned composition object 2 instead, and the first subtitle shows up and goes away repeatedly...

The command I used is:


avs2bdnxml -t testing -l zho -v 1080p -f 23.976 -a1 -p1 -b1 -m3 -u0 -o test.sup -o testing.xml xx.avs



I've included the *.pes file generated by Scenarist BD, *.ass, *.avs this time HERE (http://www.mediafire.com/?vup6na3d48nv717), let me know if you need anything else.

[ps auxw]

Thank you very much for the thorough information.

The double output works, but sup output is still the same result. In addition, I tested in Scenarist QC this time, the subtitle formatting is messed up, only composition object 2 is showing up in window 1, composition object 1 is supposed to be showing up in window 2 but is showing a wrong positioned composition object 2 instead, and the first subtitle shows up and goes away repeatedly...
That sounds very peculiar. It will be interesting to see what the problem is. Although, I have some pretty good ideas about the cause. In any case, the next update might take a few days.

I've included the *.pes file generated by Scenarist BD, *.ass, *.avs this time HERE (http://www.mediafire.com/?vup6na3d48nv717), let me know if you need anything else.
Unless I am missing something, the .avs and .ass files are not included in the file.

Edit: testing_invalid_tsmuxer.sup and testing_valid_tsmuxer.sup are identical files. Is that intended?

[hamletiii]

Lol, I made so many mistakes this morning... THIS (http://www.mediafire.com/?mm0mdy7578p4x1v) is an updated package.

Testing_invalid_tsmuxer.sup and testing_valid_tsmuxer.sup are supposed to be different, sorry for the confusion...
The valid one is xml+png generated by avs2bdnxml 2.02, import into Scenarist BD, which produces a *.pes, then muxing the project, and lastly the *.m2ts is demuxed by tsmuxer.
The invalid one is *.sup produced by avs2bdnxml 2.02, then using tsmuxer to output a Blu-ray Disc structure with audio/video, and the *.m2ts is demuxed by tsmuxer.

Testing_invalid_tsmuxer.sup should be identical to test_org.sup which is the original sup generated by avs2bdnxml 2.02, it suggests that tsmuxer doesn't alter the sup in any way while the sup extracted by eac3to resets all DTS timestamp to 0.

Upon examining the reports from pgsparse you provided, I can see that the valid sup is likely to be what I see in Scenarist BD's PES Editor, while the invalid sup is quite different from what the correct implementation should be.

[ps auxw]

Thanks for the updated package. It will make testing much easier. And yes, there still are some pretty big differences. I'll try to get rid of them. ;)

[fransky]

excellent work here. Are there any more inline effects supported other than fadein/fadeout in the xml, which Scenarist BD also supports?

[ps auxw]

So, slightly longer delay again, sorry. I hope I'll get to work more on this in the next days.

excellent work here. Are there any more inline effects supported other than fadein/fadeout in the xml, which Scenarist BD also supports?
Take a look at this thread (http://www.urusoft.net/forum/viewtopic.php?id=5446) with the XML Schema. There seem to be at least Crop, Position and Color effects too. No idea how they work or if Scenarist supports them, though.

[hamletiii]

The inline fading effect was generated by Lemony Pro, which works on Scenarist BD.
The fading also can be written as a global function, and called in subsequent block instead of individual function in the example I gave earlier:



<?xml version="1.0" encoding="UTF-8"?>
<BDN Version="1.00" 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="2" Type="Graphic" />
</Description>
<Effects>
<Effect EffectID="FadeIn1" Type="Fade" Duration="00:00:00:12" Anchor="Start">
<Fade FadeType="FadeIn" />
</Effect>
<Effect EffectID="FadeOut1" Type="Fade" Duration="00:00:00:12" Anchor="End">
<Fade FadeType="FadeOut" />
</Effect>
</Effects>
<Events>
<Event InTC="00:00:05:14" OutTC="00:00:08:14">
<Graphic>ue_Track_0001.png</Graphic>
<Effect EffectID="FadeIn1" />
<Effect EffectID="FadeOut1" />
</Event>
<Event InTC="00:00:11:23" OutTC="00:00:14:23">
<Graphic>ue_Track_0002.png</Graphic>
<Effect EffectID="FadeIn1" />
<Effect EffectID="FadeOut1" />
</Event>
</Events>
</BDN>



There's some difficulties in applying fading from the graphics generated in avs2bdnxml though, because it tends to use too much color to index each picture. Pure thin black boarder with white text should be fine, but other fancier colors will almost always having problem, this is especially true when you need cross fading.

I'm not sure if crop, position, color effects are supported in subtitles, I can't seem to make those happen in Lemony. But they are definitely supported in Interactive Graphics - IGEffect Editor, where you can archieve some slide in/out effects using a combination of cropping and moving. You could also specify an initial color palette and an ending palette, Scenarist BD will fill in the missing ones. The cropping and moving can also be applied upto two individual windows, but if the windows are too far apart, you'll run into timing issue which the animation won't be smooth... Anyway, it's pretty neat stuff without using animated button.

[fransky]

thanks for explaining, ps auxw and hamletiii.
fading shouldn't be any problem for me now. I'm now more concerned about moving subtitles. Let's say a line moving from left to right of the screen. The way avs2bdnxml does is producing an png image for each frame. It often causes buffer overflow, especially if another line of subtitle appears during the motion. It would be very nice if avs2bdnxml could output xml+png in a way that let Scenarist BD or other tools understand it's a moving line. So it won't need multiple images for one moving line. Maybe I'm asking too much. But some idea about possibility is appreciated.

[Daiz]

I think the easiest way to do that would be to read the .ass file along with the .avs file and look for lines with the \move command, then just render the first frame and use the \move-command parameters as help to produce the BDN-XML movement... but I don't know how easy that would be to pull off. I guess it should be easier than trying to implement some sort of motion tracker or whatever else would be required to do it otherwise.

[hamletiii]

I think the easiest way to do that would be to read the .ass file along with the .avs file and look for lines with the \move command, then just render the first frame and use the \move-command parameters as help to produce the BDN-XML movement... but I don't know how easy that would be to pull off. I guess it should be easier than trying to implement some sort of motion tracker or whatever else would be required to do it otherwise.

I believe we are already doing that for fading. But we don't know the exact move command (if there is) like the fade for Scenarist BD to implement.

[hamletiii]

DVDLogic has a new tool called EasyBD (http://www.dvd-logic.com/easybd/features.html) which can take xml+png and create pes+mui. I assume it works the same way as Scenarist BD to allow dual window multiple composition objects configuration.

[ps auxw]

Interesting. If it works well, I will put a link to it in the first post. Could anybody test?

(Yes, I'm still alive, just too busy. :()

[Hyper Shinchan]

Interesting. If it works well, I will put a link to it in the first post. Could anybody test?
I've tested it and it seems that it works fine; unlike last time with BDSup2Sub I'm pretty sure that it works, I've checked that both objects appear correctly.
Anyway I only made a fast test with a pair of subtitles, more testing is needed; also Scenarist gives you a warning if there's something wrong with your XML, I wonder if EasyBD gives similar warnings.
BTW I've used it only to mux a dummy AVC stream and the subtitles, I've used tsmuxer to remux the subs in AVCHD with the video and audio (and I've tested it with the PS3).
Did you test it by yourself hamletiii?

[hamletiii]

I've tested it and it seems that it works fine; unlike last time with BDSup2Sub I'm pretty sure that it works, I've checked that both objects appear correctly.
Anyway I only made a fast test with a pair of subtitles, more testing is needed; also Scenarist gives you a warning if there's something wrong with your XML, I wonder if EasyBD gives similar warnings.
BTW I've used it only to mux a dummy AVC stream and the subtitles, I've used tsmuxer to remux the subs in AVCHD with the video and audio (and I've tested it with the PS3).
Did you test it by yourself hamletiii?

No, I haven't tested it. But DVD-Logic has a good record at making software that's compliant to specification. And they are working with Sonic closely with the EDGe program. So I think it's probably going to work. I'll test it and compare the result with Scenarist BD when I got time.

Muxing is not the main problem with subtitle get screwed up here, as long as you are using the same frame rate and resolution. But before muxing, the subtitles have to be in sup or pes format so that these muxers can mux. This is where things get wrong. At this time, it seems nobody except Scenarist BD can fully support the specification of BD subtitles. It seems most programmers understand only part of it, but never fully understand what's going on. Wirepole has wrote some good discovery here (http://wirepole.spaces.live.com/default.aspx), but it's in Chinese. I think it could be useful to ps auxw.

What gets wrong with BDSup2Sub is that it deliberately puts gaps between subtitles with timings that are very close so that it can write just one composition object per epoch. This is NOT the right way to handle the situation. Plus it cannot handle dual window configuration which is an even bigger problem.

[ps auxw]

Ok, I have now added a note about EasyBD to the first post.

At this time, it seems nobody except Scenarist BD can fully support the specification of BD subtitles. It seems most programmers understand only part of it, but never fully understand what's going on. Wirepole has wrote some good discovery here (http://wirepole.spaces.live.com/default.aspx), but it's in Chinese. I think it could be useful to ps auxw.
Thanks. While I do not know Chinese, maybe I'll get some useful information from there. Now, if I just got around to actually working on this...

[hamletiii]

I've tested it and it seems that it works fine; unlike last time with BDSup2Sub I'm pretty sure that it works, I've checked that both objects appear correctly.
Anyway I only made a fast test with a pair of subtitles, more testing is needed; also Scenarist gives you a warning if there's something wrong with your XML, I wonder if EasyBD gives similar warnings.
BTW I've used it only to mux a dummy AVC stream and the subtitles, I've used tsmuxer to remux the subs in AVCHD with the video and audio (and I've tested it with the PS3).
Did you test it by yourself hamletiii?

OK, I did some small tests. I'm rather disappointed with the result. I used the same files in my post#162 (http://forum.doom9.org/showpost.php?p=1454471&postcount=162) as a stress test, but unfortunately the program crashes. Then I tested some simple scripts with no image splitting (dual window), and it compiles fine. So I can pretty much say that this program doesn't support dual window configuration. I didn't test fading tag support, but it'll probably NOT work. I'm not impressed with the GUI as well...

[hamletiii]

Hi, ps auxw, just in case if you could start working on this program again, could you implement this:
In the event a really big picture is generated, it would be best to split them no matter how ugly they are. I think if the vertical pixels go over 540 (half of 1080), you need split.

Here is an example why this is needed:

http://i44.photobucket.com/albums/f18/DVDmaster/5c13ade7.png

This subtitle needs some busy on screen translation. So the timings are really close. Therefore Scenarist BD tries to group these seven lines together by putting them into one epoch. The problem came after this. Now since one of the picture is so large (avs2bdnxml didn't split them probably the lines are not too far apart?), Scenarist BD is unable to put a dual window structure for the entire epoch! This increases buffer usage significantly. So there are two solutions after this:
1. Reduce the text on each picture, which means you can't put as many text as you want. Reducing pixel counts help reducing buffer usage.
2. Splitting the pictures so that Scenarist BD can put them into two windows.

And here's what it looks like after I manually split the picture:

http://i44.photobucket.com/albums/f18/DVDmaster/9019757b.png

Scenarist BD picks up the dual window here. And it easily saves 8% of buffer!

So I think if a picture has more than 540 pixels, it needs split. I think it is somewhat similar to what you proposed here (http://forum.doom9.org/showpost.php?p=1416039&postcount=144). But in this case, I just want it split no matter how ugly the picture is, as long as the final result looks seamless.

[ps auxw]

I will add something like that as soon as I get around to working on this, hopefully in the not too far future. Also, at least in that case a non-ugly split should've been found. If that is not the case, well. I have an idea for a better splitting algorithm that might help. :)

[hamletiii]

I will add something like that as soon as I get around to working on this, hopefully in the not too far future. Also, at least in that case a non-ugly split should've been found. If that is not the case, well. I have an idea for a better splitting algorithm that might help. :)

In my example, it shouldn't be too hard to find the right splitting coordinates, but avs2bdnxml didn't pick up. I was actually doing something more complex at first like this:

http://i44.photobucket.com/albums/f18/DVDmaster/02f75cb3.png

I think it would be much harder to distinguish the pixels in this situation?

Well, it's good to hear you have a better idea.

[Oleg Rode]

I will add something like that as soon as I get around to working on this, hopefully in the not too far future. Also, at least in that case a non-ugly split should've been found. If that is not the case, well. I have an idea for a better splitting algorithm that might help. :)
Hi again and thanks for your work. The .sup output option works very well. Your subs splitting engine produces very good results. The problem exists only with very complex subs, but these subs are not used very often.
Best regards and, again, sorry for my English.

[hamletiii]

Well, I wouldn't call it work "very well". The sup output definitely needs some more work, dual window splitting is quite off from the correct implementation. But still, it's a big step forward towards the right direction since so far none of the other free and some commercial subtitle software I tried can do this, I bet some author didn't even know you can have multiple composition objects under one epoch, others aren't willing to add such support.

[hamletiii]

Hi, ps auxw. Since the wirepole blog I posted earlier has been down, here is the article (http://www.mediafire.com/?qd44uin3p729p1w) that's related to the ies, pes, sup format I had saved. I took some time to translate it as well, hopefully it could be useful for you to figure out how to output sup correctly.

[ps auxw]

Hi, ps auxw. Since the wirepole blog I posted earlier has been down, here is the article (http://www.mediafire.com/?qd44uin3p729p1w) that's related to the ies, pes, sup format I had saved. I took some time to translate it as well, hopefully it could be useful for you to figure out how to output sup correctly.

Thank you very much for the translation, this should be quite helpful.

Edit: Just adding a note to say it might take another month, possibly a bit longer, before I can get back to work on this.

[hamletiii]

With the help from someone on another forum, we were able to finally figure out ALL four inline effect tags: fade, crop, position, and color.
Again, it would be cool if avs2bdnxml could support converting these tags from *.ass tags without having to manually adding these afterwards.
The difficulty in doing this is when -b1 splitting is specified, it would be very hard to apply the tags.

I've collected all tag usages in one article which is a bit long, it's available HERE (http://www.mediafire.com/?ge19y4pwswiiwdg) for anyone who's interested.
Again, these tags only works on Scenarist BD, different version may behave somewhat differently.

[twazerty]

When I run it via Wine under linux (ubuntu) I get some errors. I noticed a makefile for linux. Is it possible to run this application native on Ubuntu?

[ps auxw]

General update: I'm finally getting around to working on this again. The SUP writer is much improved, but some new bugs were introduced, which I have to fix before I can release it. Well, at least there's progress after long last.

When I run it via Wine under linux (ubuntu) I get some errors. I noticed a makefile for linux. Is it possible to run this application native on Ubuntu?
Somewhat. You have to modify avs2bdnxml.c, about line 227:
p_param->i_width = 1920;
p_param->i_height = 1080;
p_param->i_fps_den = 30000;
p_param->i_fps_num = 1001;

Adjust the video parameters hardcoded there. The input file has to be raw RGBA data without any headers. Using a FIFO should work. (NB: The Linux makefile isn't really intended for general use, just for hunting memory bugs with valgrind.)

[twazerty]

If it runs via Wine it is okay too. I see I didn't use the latest version. Now it almost runs okay. The output only contains the first word of each line (srt file).

Installed Avisynth under wine. Loaded the VSFilter in the avs. Any ideas?

[hamletiii]

General update: I'm finally getting around to working on this again. The SUP writer is much improved, but some new bugs were introduced, which I have to fix before I can release it. Well, at least there's progress after long last.


That's great to hear you finally start working on it. I'll be glad to test it once you are done.

[ps auxw]

If it runs via Wine it is okay too. I see I didn't use the latest version. Now it almost runs okay. The output only contains the first word of each line (srt file).

Installed Avisynth under wine. Loaded the VSFilter in the avs. Any ideas?
I'm afraid not. I could never get VSFilter to produce usable results under wine.

That's great to hear you finally start working on it. I'll be glad to test it once you are done.
I have just released avs2bdnxml v2.04 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.04.tar.bz2), which hopefully fixes some/most problems with SUP output. My apologies for the repeated delays.

[twazerty]

I'm afraid not. I could never get VSFilter to produce usable results under wine.

Indeed I see VSFilter problems with Wine on the internet.

It would be very very nice if this application works on linux. Just some ideas:
Use ffmpeg input instead of avs. Maybe you can play a purple screen in ffmpeg with subtitles on top of it and then filter this purple color out of the image leaving pure subtitle images.

The reason I am looking for this is because I am updating AVCHDCoder so it works on linux. And your application is one of the features I haven't found an alternative for. Since VSFilter doesn't work correctly under wine I was hoping for another solution.

[sneaker_ger]

Try AssRender (http://forum.doom9.org/showthread.php?t=148926) instead of vsfilter.

[twazerty]

Try AssRender (http://forum.doom9.org/showthread.php?t=148926) instead of vsfilter.

I get an error that it isn't an Avisynth 2.5 plugin???

[sneaker_ger]

Try loadCplugin("assrender.dll").

[twazerty]

Try loadCplugin("assrender.dll").

Thanx. Lines show up when I test it in MPCHC on Windows but avs2bdnxml doesn't detect any lines on linux via wine.

Edit: After putting some fonts in the fonts dir in Wine it runs fine and it produces correct images. Huge Thanx!!!

[ps auxw]

Good to hear you got it working for you, although, since you're not using VSFilter anymore, you might want to give PunkGraphicStream (http://forum.doom9.org/showthread.php?t=148030) a try. It's based on the same subtitle rendering library as assrender.dll.

Apart from that, I don't suppose anybody has given the reworked SUP output a try yet?

[river1]

avs2bdnxml crashed when using -o twice
like this
avs2bdnxml -t Undefined -l und -v 1080p -f 23.976 -a1 -b1 -p1 -m3 -o output.sup -o output.xml input.avs
CPU: Using SSE2 optimized functions.
avis [info]: 1920x1080 @ 23.98 fps (4300 frames)
Progress: 112/4300 - Lines: 1Assertion failed: pal != NULL, file avs2bdnxml.c, line 1145

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

[ps auxw]

avs2bdnxml crashed when using -o twice
like this
avs2bdnxml -t Undefined -l und -v 1080p -f 23.976 -a1 -b1 -p1 -m3 -o output.sup -o output.xml input.avs
CPU: Using SSE2 optimized functions.
avis [info]: 1920x1080 @ 23.98 fps (4300 frames)
Progress: 112/4300 - Lines: 1Assertion failed: pal != NULL, file avs2bdnxml.c, line 1145

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Oops. Thanks for reporting this. avs2bdnxml v2.05 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.05.tar.bz2) should fix the problem.