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

ps auxw

20th April 2009, 20:11

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 somewhat experimental, but seems to work for many people.

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 (http://code.google.com/p/xy-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.
-d, --t-offset <string> Offset timecodes by this many frames or
given non-drop timecode (HH:MM:SS:FF).
-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.
-e, --even-y <integer> Enforce even Y coordinates. [on=1, off=0]
-a, --autocrop <integer> Automatically crop output. [on=1, off=0]
-p, --palette <integer> Output 8bit palette PNG. [on=1, off=0]
-n, --null-xml <integer> Allow output of empty XML files. [on=1, off=0]
-z, --stricter <integer> Stricter checks in the SUP writer. May lead to
less optimized buffer use, but might raise
compatibility. [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 by image
splitting. [on=1, off=0]

Example:

avs2bdnxml -t Undefined -l und -v 1080p -f 23.976 -a1 -p1 -b0 -m3 -u0 -e0 -n0 -z0 -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 will be written to the same directory as the XML file. 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/). You can generate SUP and BDN-XML output at the same time by specifying -o twice.
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 also 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.08 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.08.tar.bz2)
Website (http://ps-auxw.de/avs2bdnxml/)

Changes

Version 2.08

Fix PNG filename references when used with timecode offsets.

Version 2.07

Fix two bugs in timecode parsing function
Move most inline assembly to yasm

Version 2.06

Add option to add an offset to output timecodes
Change return value when no events were detected to 0
Add option to allow writing of empty output files
Add option to enforce even Y coordinates (may help avoid problems with interlaced video in DVD related use cases)
Fix SSE2 with more recent GCC versions
Add option for stricter checks on buffer/palette limits for SUPs
Fix bug where LastEventOutTC could be one frame early
Add additional checks to commandline argument parsing
PNG files are now always placed in the same directory as the XML file

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

27th July 2009, 05:30

sneaker_ger

27th July 2009, 15:41

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

27th July 2009, 17:11

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

30th July 2009, 01:19

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

7th August 2009, 07:02

ps auxw

7th August 2009, 16:31

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

12th August 2009, 08:58

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

12th August 2009, 16:04

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

15th August 2009, 14:29

sneaker_ger

15th August 2009, 23:18

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

17th August 2009, 03:24

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

17th August 2009, 15:14

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

17th August 2009, 19:43

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

17th August 2009, 22:37

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

17th August 2009, 23:09

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

17th August 2009, 23:30

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

18th August 2009, 00:53

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

18th August 2009, 04:32

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

18th August 2009, 05:18

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

18th August 2009, 15:12

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

18th August 2009, 16:13

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

18th August 2009, 16:25

Thanks. Exactly what I wanted to hear. :)

ps auxw

18th August 2009, 21:45

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

18th August 2009, 23:04

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

18th August 2009, 23:41

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

18th August 2009, 23:42

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

18th August 2009, 23:51

ps auxw

19th August 2009, 01:22

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

19th August 2009, 01:31

sneaker_ger

19th August 2009, 02:36

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

19th August 2009, 16:21

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

20th August 2009, 19:11

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

21st August 2009, 17:07

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

21st August 2009, 18:29

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

21st August 2009, 20:49

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

22nd August 2009, 16:54

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

22nd August 2009, 19:56

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

22nd August 2009, 20:58

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

ps auxw

23rd August 2009, 14:19

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

23rd August 2009, 14:36

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

23rd August 2009, 20:24

A quick note:

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

Dean

Oleg Rode

24th August 2009, 11:50

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

24th August 2009, 18:34

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

25th August 2009, 15:13

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

25th August 2009, 20:06

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

25th August 2009, 21:05

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

27th August 2009, 16:24

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

29th August 2009, 21:11

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

29th August 2009, 23:57

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

30th August 2009, 03:46

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

30th August 2009, 15:02

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

30th August 2009, 16:53

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

30th August 2009, 17:24

ps auxw

30th August 2009, 17:46

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

30th August 2009, 20:38

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

30th August 2009, 21:53

@ 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

30th August 2009, 22:17

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

31st August 2009, 07:52

sneaker_ger

31st August 2009, 14:06

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

Oleg Rode

31st August 2009, 20:56

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

31st August 2009, 21:32

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

31st August 2009, 22:15

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

31st August 2009, 22:16

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

31st August 2009, 22:27

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

1st September 2009, 12:33

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

1st September 2009, 14:56

... 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

1st September 2009, 16:03

@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

2nd September 2009, 06:46

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

2nd September 2009, 13:25

Thx! :thanks:

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

ps auxw

2nd September 2009, 15:47

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

2nd September 2009, 16:18

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

2nd September 2009, 17:02

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

2nd September 2009, 18:27

hamletiii

2nd September 2009, 18:35

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

2nd September 2009, 18:38

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

2nd September 2009, 19:00

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

3rd September 2009, 17:51

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

3rd September 2009, 18:57

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

3rd September 2009, 19:46

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

3rd September 2009, 20:24

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

6th September 2009, 14:36

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

6th September 2009, 16:53

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

6th September 2009, 20:21

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

ps auxw

6th September 2009, 20:46

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

6th September 2009, 21:22

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

6th September 2009, 22:36

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

7th September 2009, 00:02

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

7th September 2009, 00:27

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

7th September 2009, 22:16

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

8th September 2009, 21:58

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

8th September 2009, 22:09

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

9th September 2009, 09:22

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

10th September 2009, 16:50

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

10th September 2009, 20:41

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

10th September 2009, 20:44

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

11th September 2009, 13:13

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

12th September 2009, 12:22

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

14th September 2009, 23:18

hamletiii

16th September 2009, 00:26

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

16th September 2009, 03:33

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

16th September 2009, 18:53

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

hamletiii

28th September 2009, 22:10

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

29th September 2009, 23:25

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

1st October 2009, 16:18

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

hamletiii

18th October 2009, 16:09

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

21st October 2009, 17:44

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

25th October 2009, 22:20

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

26th October 2009, 00:04

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

29th October 2009, 14:20

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

29th October 2009, 15:05

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

6th February 2010, 07:47

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

7th February 2010, 15:17

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

8th February 2010, 23:13

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

19th March 2010, 15:00

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

19th March 2010, 15:30

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

19th March 2010, 16:08

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

19th March 2010, 19:43

Ah, ok. Thx.

hamletiii

19th March 2010, 23:25

hamletiii

19th March 2010, 23:29

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

25th March 2010, 03:29

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

26th March 2010, 15:12

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

28th March 2010, 08:15

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

28th March 2010, 21:18

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

2nd April 2010, 10:54

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

2nd April 2010, 12:39

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

2nd April 2010, 15:06

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

3rd April 2010, 18:53

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

5th April 2010, 15:52

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

13th April 2010, 19:22

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

14th April 2010, 13:49

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

14th April 2010, 18:28

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

12th May 2010, 15:30

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

16th May 2010, 03:12

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

16th May 2010, 10:03

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

3rd June 2010, 05:10

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

3rd June 2010, 09:32

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

10th June 2010, 14:39

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

11th June 2010, 11:02

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

26th June 2010, 01:18

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

1st July 2010, 13:43

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

2nd July 2010, 03:58

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

5th July 2010, 04:31

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

9th July 2010, 14:03

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

4th August 2010, 21:07

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

4th August 2010, 23:18

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

5th August 2010, 15:17

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

11th August 2010, 01:42

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

15th September 2010, 22:34

ps auxw

16th September 2010, 02:47

@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

16th September 2010, 08:37

@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

16th September 2010, 17:42

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

16th September 2010, 18:57

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

16th September 2010, 19:17

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

17th September 2010, 15:16

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

18th September 2010, 22:58

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

28th October 2010, 00:01

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

29th October 2010, 06:22

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

29th October 2010, 13:43

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

31st October 2010, 16:53

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

31st October 2010, 17:27

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

1st November 2010, 01:52

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

1st November 2010, 18:21

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

11th November 2010, 09:30

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

ps auxw

12th November 2010, 18:03

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

13th November 2010, 09:32

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

19th November 2010, 05:18

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

26th November 2010, 10:05

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

6th December 2010, 09:47

hamletiii

9th February 2011, 01:54

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

9th February 2011, 17:54

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

15th February 2011, 05:42

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

18th February 2011, 18:44

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

18th February 2011, 19:51

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

4th March 2011, 00:18

hamletiii

4th March 2011, 01:09

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

7th March 2011, 13:58

hamletiii

8th March 2011, 22:21

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

9th April 2011, 19:44

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

11th April 2011, 10:31

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

17th May 2011, 09:16

ps auxw

17th May 2011, 14:17

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

26th June 2011, 04:38

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

3rd September 2011, 14:03

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

3rd September 2011, 15:45

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

3rd September 2011, 18:39

hamletiii

4th September 2011, 11:21

ps auxw

5th September 2011, 00:06

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

5th September 2011, 12:34

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

5th September 2011, 12:44

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

twazerty

5th September 2011, 13:46

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

5th September 2011, 13:50

Try loadCplugin("assrender.dll").

twazerty

5th September 2011, 14:00

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

12th September 2011, 14:59

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

18th September 2011, 16:43

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

18th September 2011, 18:52

FILLIFY

20th July 2012, 21:22

OptimusX

7th August 2012, 03:56

I was last around for this program during the early revisions, but now I'm back with renewed interest and happy to see SUP export and some solutions to the buffer overflow problems! I have some simple colliding subs that appear on the top and bottom that I could never get to stop flickering, but now I'm going to give this another go!

OptimusX

7th August 2012, 03:58

easyavs2bdnxml
GUI supports last avs2bdnxml v2.05.
Original Chinese version's here http://bbs.siluhd.com/thread-385883-1-1.html
English/Russian version (with authored interface) is here http://www.adrive.com/public/n7BQPV/...nxml-0.3.4.zip

Hmmm it seems the english version is no longer available. I think your posted link is corrupted...I get "...nxml-0.3.4.zip" as part of the link.

qknet

20th August 2012, 07:35

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

Can you give an example of avs file? I have failed to produce one to work with avs2bdnxml.

Currently I stole the avs created by EasySub, which works, but it uses vsFilter. I would like to see if AssRender can make it faster

loadplugin("C:\Program Files\AviSynth 2.5\plugins\VSFilter.dll")
nw=1920
nh=1080
b=MaskSub("D:\Documents\Dropbox\subtitles\test.ass" ,nw, nh, 23.976, 161478)

d=b.killaudio

return d

OptimusX

10th September 2012, 23:41

The SUP output is awesome. Good work. You may not know it, but this program is becoming a standard in fansub applications for avchd and bd output.

djmasturbeat

17th January 2013, 01:21

easyavs2bdnxml
GUI supports last avs2bdnxml v2.05.
Original Chinese version's here http://bbs.siluhd.com/thread-385883-1-1.html
English/Russian version (with authored interface) is here http://www.adrive.com/public/n7BQPV/...nxml-0.3.4.zip

would you mind re-hosting this GUI?
the link for the Russian/English version does not work, maybe link is corrupted or file removed.

ps auxw

17th January 2013, 14:17

The SUP output is awesome. Good work.

Wow, I somehow missed that there are new posts in this thread. It's great to hear that it seems to be working well!

Too bad about the dead link for the GUI frontend.

djmasturbeat

20th January 2013, 20:21

okay, so I am trying this out but I am not the most adept at cli, so please advise what I am doing wrong.
I suspect it is something to do with
-t
I am not sure what we should be inputting for trackname.

I simplified dir path and filenames for myself as much as I can for easy cli call, but still get an error.
here is my cli and error

C:\Users\jonathan>C:\Users\jonathan>""C:\avs2bdnxml\avs2bdnxml.exe" avs2bdnxml -t PYCAL -l eng -v 1080i -f 30 -a1 -p1 -b1 -u0 -m3 -o "C:\avs2bdnxml\PYCAL\PYCAL.xml" "C:\avs2bdnxml\PYCAL.avs"
The filename, directory name, or volume label syntax is incorrect.

i also tried removing the -t but no love

C:\Users\jonathan>C:\Users\jonathan>""C:\avs2bdnxml\avs2bdnxml.exe" avs2bdnxml -l eng -v 1080i -f 30 -a1 -p1 -b1 -u0 -m3 -o "C:\avs2bdnxml\PYCAL\PYCAL.xml" "C:\avs2bdnxml\PYCAL.avs"
The filename, directory name, or volume label syntax is incorrect.

here is my avs for the ass, btw:
LoadPlugin("C:\MeGUI\tools\dgavcindex\DGAVCDecode.dll")
AVCSource("C:\LUPIN_RETURN_OF_PYCAL_CUSTOM\LUPIN_RETURN_OF_PYCAL\00002_1_01.dga")
LoadPlugin("C:\MeGUI\tools\avisynth_plugin\vsfilter.dll")
MaskSub("C:\avs2bdnxml\PYCAL_BD_SUBS.ass",1920,1080,29.970,85575)
#FlipVertical()

all the folders and paths do exist, as do the files I call (*.ass, *.avs)

thanks for any help for a noob.

ps auxw

20th January 2013, 21:11

C:\Users\jonathan>C:\Users\jonathan>""C:\avs2bdnxml\avs2bdnxml.exe" avs2bdnxml -t PYCAL -l eng -v 1080i -f 30 -a1 -p1 -b1 -u0 -m3 -o "C:\avs2bdnxml\PYCAL\PYCAL.xml" "C:\avs2bdnxml\PYCAL.avs"
The filename, directory name, or volume label syntax is incorrect.

i also tried removing the -t but no love

C:\Users\jonathan>C:\Users\jonathan>""C:\avs2bdnxml\avs2bdnxml.exe" avs2bdnxml -l eng -v 1080i -f 30 -a1 -p1 -b1 -u0 -m3 -o "C:\avs2bdnxml\PYCAL\PYCAL.xml" "C:\avs2bdnxml\PYCAL.avs"
The filename, directory name, or volume label syntax is incorrect.

Okay, I see multiple problems, and only one of them is an actual avs2bdnxml usage problem. "-f 30" is not supported, hopefully "-f 29.97" will work for you? You specified 29.970 in your AVS after all. If you really need 30fps, since calculation is done with non-drop frame timecodes, you could try replacing the frame rate in the resulting XML file, if it is actually supported, but I don't think this should be necessary.

As for the track name, it's just a string that is written to the XML file, like "Colored English subtitles" or whatever.

For the rest, you apparently have the prompt "C:\Users\jonathan>" copied into your command line. You also have an extra quote (") at afterwards. Additionally, there shouldn't be an "avs2bdnxml" after you already specified the path to the executable. Try the following:
"C:\avs2bdnxml\avs2bdnxml.exe" -t PYCAL -l eng -v 1080i -f 29.97 -a1 -p1 -b1 -u0 -m3 -o "C:\avs2bdnxml\PYCAL\PYCAL.xml" "C:\avs2bdnxml\PYCAL.avs"

If you do not feel comfortable with the command line, you can also copy this into a batch file (e.g. "runavs2bdnxml.bat") and double click that.

For your AVS, since you are directly specifying the frame size, number of frames etc. in the MaskSub call, you can throw out the parts about loading the video, since MaskSub doesn't use it anyway:
LoadPlugin("C:\MeGUI\tools\avisynth_plugin\vsfilter.dll")
MaskSub("C:\avs2bdnxml\PYCAL_BD_SUBS.ass",1920,1080,29.970,85575)

djmasturbeat

20th January 2013, 21:34

thanks for the fast reply
I had entered 30 fps b/c in the first page it was mentioned it worked better to use that then to edit the xml output and put 29.97 back in.

http://forum.doom9.org/showthread.php?p=1313944#post1313944

that said, when I use 30 I get an error

Is all this no longer needed for input to Scenarist? Or if it is needed, do I need to change it somewhere else (like the avs script) to work? Then I would edit the XML back to 29.97 for scenarist?

Other than that, thanks for the suggested cli call, it works with 29.97, I just need to be sure this won't botch input in scenarist, or go out of sync.

thanks again.

C:\Users\jonathan>"C:\avs2bdnxml\avs2bdnxml.exe" -t PYCAL -l eng -v 1080i -f 30 -a1 -p1 -b1 -u0 -m3 -o "C:\avs2bdnxml\PYCAL\PYCAL.xml" "C:\avs2bdnxml\PYCAL.avs"
Error: Invalid framerate (30).

ps auxw

20th January 2013, 21:40

In the beginning there were some bugs in the timecode calculation code, but they have long been fixed. Using 29.97 should be perfectly fine now.

djmasturbeat

20th January 2013, 21:45

ok
awesome
thanks so much for this great software =)
it really is getting to be known as quite the tool for enthusiasts to render subs for subbed blu-rays.

ps auxw

20th January 2013, 21:49

You're welcome. I'm glad it's useful. :)

djmasturbeat

20th January 2013, 22:17

if scenarist parser rejected this xml, is this possibly because of my *.ass subtitle script, more than likely?
If it is in my script, is there a way I need to tell avs2bdnxml where to split an epoch for a screen with text in several places, or should this be automatic?
If this isn't my issue, I will have to look in other places in the *.ass.

also...okay, sorry for the ignorance here, am I supposed to have actual png files too?
b/c I only have an xml output in the output folder.

thanks again.

ps auxw

20th January 2013, 23:10

also...okay, sorry for the ignorance here, am I supposed to have actual png files too?
b/c I only have an xml output in the output folder.

thanks again.

It won't work without the PNG files. Without them, Scenarist can't import, because there's nothing there. Check if they ended up in another folder, like the place you ran avs2bdnxml from or the avs2bdnxml folder. I should probably make it place the files in the same place as the XML file so this kind of thing doesn't happen...

djmasturbeat

20th January 2013, 23:15

ok, i found them.
since i ran cli from my username account (rather than cd first to C: or rather than using elevated command) it ended up in that main user directory terminal c:\users\myusername\*.png

yeah, probably a good idea to force default to same dir as the xml and then add ability to change it if desired.

thanks again.

djmasturbeat

3rd February 2013, 15:14

avs2bdnxml works great. However I have been experiencing a strange issue with avs2bdnxml (2.05), which creates a flicker. It has happened really since my first project.
I am curious if anyone else has observed such a thing, or if anyone has suggestions what might be causing this on my end... or if this may be a bug, or what?

I will try to make this as clear as I can.
If need-be, ps auxw, I can send you copies of the files: ass, avs, cli, xml+png for a few projects.
Any with an inline effect-hacked xml, will also contain the original output from avs2bdnxml (both have the same issue, detailed as follows).

I will render my .ass files with the newest build of avs2bdnxml, and there is almost always one line that mysteriously is doubled/duplicated.
It manifests itself in 2 forms:
1) 2 instances will appear in the same Epoch, with 2 Display Sets within that Epoch
2) It will show up as 2 consecutive Epochs
In either case, the repeated instance of this single line will always have a small gap in the times between these 2 occurrences.

I *can* fix it in ScenaristBD inside the PES editor (by removing the second instance, whether a new Epoch or new Display Set, and extending the ending time for the first instance to match the ending time of the second instance I remove).
*But* in order to fix it, I have to first fully mux the Blu-ray (time and PC-intensive), then watch the full movie first, really scrutinizing every line. This is sort of a big deal. This could become a compounded bigger issue when I will be adding multiple subtitles (which I have planned), all requiring watching the movie in those sub language, paying close attention to every line.

Usually the duplicated instance is happening near the start of a script, in the very first or second Epoch.
But not always.

The first time I noticed it, I thought at first it may have something to do with a preceding line (A Title) using a fade-in inline effect hacked into the xml. But whether I import in the original xml or the altered one, the result is the same. Then it happened on the very first subtitle in my most recent job, too.

for example the first lines are as such:
Dialogue: 0,0:01:24.64,0:01:26.73,Default,,0,0,0,,The year After Colony 195.
Dialogue: 0,0:01:27.68,0:01:30.87,Default,,0,0,0,,A group of Colony citizens\Nhostile toward the Alliance...
Dialogue: 0,0:01:30.95,0:01:34.64,Default,,0,0,0,,...sent young men to Earth\Non five Gundams.

after importing into scenarist and muxing and then watching I must track down multiple instances of lines inside the PES editor.

here is how this appears in Scenarist PES editor:

http://t.imgbox.com/adxDb3YV.jpg (http://imgbox.com/adxDb3YV) http://t.imgbox.com/abjFuB3n.jpg (http://imgbox.com/abjFuB3n)

here is another example from a different project, these screens I took a week, week and a half ago or so. These ones show in the same Epoch on 2 Display Sets, whereas the example above was 2 instances split across 2 Epochs:

http://t.imgbox.com/adle4gwQ.jpg (http://imgbox.com/adle4gwQ) http://t.imgbox.com/adlfjDMd.jpg (http://imgbox.com/adlfjDMd)

the xml file shows that this happens prior to importing to ScenaristBD:

<Event Forced="False" InTC="00:01:24:14" OutTC="00:01:24:15">
<Graphic Width="671" Height="59" X="625" Y="978">00002030_0.png</Graphic>
</Event>
<Event Forced="False" InTC="00:01:24:17" OutTC="00:01:26:16">
<Graphic Width="671" Height="59" X="625" Y="978">00002033_0.png</Graphic>
</Event>

the avs:

LoadPlugin("C:\MeGUI\tools\avisynth_plugin\vsfilter.dll")
MaskSub("C:\avs2bdnxml\Waltz_v3.ass",1920,1080,23.976,129984)
#FlipVertical()

my cli to run avs2bdnxml:
"C:\avs2bdnxml\avs2bdnxml.exe" -t Waltz -l eng -v 1080p -f 23.976 -a1 -p1 -b1 -u0 -m3 -o "C:\avs2bdnxml\Waltz_v3.xml" "C:\avs2bdnxml\Waltz_v3.avs"

thanks for any input, and thanks again for this great software.

ps auxw

3rd February 2013, 15:52

This sounds like a really strange problem. I see nothing in your command line, or the quoted ASS or AVS that should lead to such a small pause, especially since line splitting isn't even abled. Could you frame step through the output of your AVS and make sure that the problem isn't on that side (e.g. the subtitle somehow doesn't get rendered for a frame during that line)? Do you have a way of testing whether it happens with SUP output? Either way, please send me one set of ASS+AVS+XML+PNG files for a project where this occurred and I'll look into it.

djmasturbeat

3rd February 2013, 16:12

I have framestepped through the avs posted above, using avspmod, and noticed nothing like this on the .ass/.avs side.
In the Gundam example, the first sub line

Dialogue: 0,0:01:24.64,0:01:26.73,Default,,0,0,0,,The year After Colony 195.

in avspmod shows consistently from frame 2030 through 2079, with zero missing frames. No more subs till 2103, which is the next actual subtitle line proper:

Dialogue: 0,0:01:27.68,0:01:30.87,Default,,0,0,0,,A group of Colony citizens\Nhostile toward the Alliance...

Then all is okay after that.

I will send a pm to you after I post this, with links to the examples above.

The Lupin Pycal Ending scripts are really short, the Gundam Wing Endless Waltz is a full Movie, but only first line is affected. The main movie for Pycal was affected... but I forget which Epoch, so I left it out, but all 3 of the Pycal Endings were affected in the same way, which is where I first noticed this.

edit:
sup rendering... well, I would have to demux and remux the BD in other tools than Scenarist.

But this will cause other issues. I have had someone confirm to me that tsmuxer will not support time conflicts (overlapping subs and different subs changing at different times) as well as split epochs, even if contained in sups output from your software (this is the fault of the authoring tools, not your software). I use all these "time conflicts" and split epochs regularly, and Scenarist handles it fine, and so does avs2bdnxml.

But, for example these lines would not work in a sup imported to tsmuxer at all:

Dialogue: 0,0:51:08.26,0:51:12.94,Endless Waltz SE ED Lyrics Bold - Romanji,,0,0,0,,itoshisa wo inori ni kaete
Dialogue: 0,0:51:08.26,0:51:12.94,Endless Waltz SE ED Lyrics Bold - English,,0,0,0,,{\c&&H8BDAFF&&}I change this longing to prayers for you
Dialogue: 0,0:51:12.84,0:51:13.48,Default,,0,0,0,,It's here.
Dialogue: 0,0:51:13.07,0:51:17.84,Endless Waltz SE ED Lyrics Bold - Romanji,,0,0,0,,kono kodou wo tsutaetai yo
Dialogue: 0,0:51:13.07,0:51:17.84,Endless Waltz SE ED Lyrics Bold - English,,0,0,0,,{\c&&H8BDAFF&&}If only you could hear this heartbeat of mine

and of course Scenarist does not accept sup, it has its own proprietary version of sup, PES(+MUI).

I think the sup feature is nice for your software, but it appears that the shortcomings in some of the authoring tools will still require people to remove overlapping and time conflicting subs.

I can't even begin to guess how tsmuxer and others handle fade effects and alpha and turning subs on x/y axis with frz*** inside the ass. I can do all this in .ass and avs2bdnxml handles it perfectly, and scenarist is okay with it, to a degree (too much and I will get buffer underruns in audio and video, even if the 4 MB buffer -- auto update ticked -- shows nowhere near capacity in PES editor).

tl;dr, I don't think this would be an appropriate test for my subs, rendering to sup, since it would incur numerous other issues due to the authoring software needed to load a sup, rather than xml+png. It would not be a good litmus test, imo.

ps auxw

12th February 2013, 02:09

This is very strange. I have tested all three of your lupin samples and could not reproduce the duplicate line stutter issue. The only reason that I could imagine is some weird heisenbug in the inline assembly parts (or some other, annoying memory corrupting bug). Could you please test whether this build without inline assembly (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.05-noasm.tar.bz2) works correctly for you? It is probably a bit slower though.

But, for example these lines would not work in a sup imported to tsmuxer at all:

Dialogue: 0,0:51:08.26,0:51:12.94,Endless Waltz SE ED Lyrics Bold - Romanji,,0,0,0,,itoshisa wo inori ni kaete
Dialogue: 0,0:51:08.26,0:51:12.94,Endless Waltz SE ED Lyrics Bold - English,,0,0,0,,{\c&&H8BDAFF&&}I change this longing to prayers for you
Dialogue: 0,0:51:12.84,0:51:13.48,Default,,0,0,0,,It's here.
Dialogue: 0,0:51:13.07,0:51:17.84,Endless Waltz SE ED Lyrics Bold - Romanji,,0,0,0,,kono kodou wo tsutaetai yo
Dialogue: 0,0:51:13.07,0:51:17.84,Endless Waltz SE ED Lyrics Bold - English,,0,0,0,,{\c&&H8BDAFF&&}If only you could hear this heartbeat of mine

In what way do these lines not work?

and of course Scenarist does not accept sup, it has its own proprietary version of sup, PES(+MUI).
I believe there was some way for Scenarist to import PGS files by going through some sort of converter that is included with it. I could be remembering wrong though.

djmasturbeat

12th February 2013, 06:24

This is very strange. I have tested all three of your lupin samples and could not reproduce the duplicate line stutter issue. The only reason that I could imagine is some weird heisenbug in the inline assembly parts (or some other, annoying memory corrupting bug). Could you please test whether this build without inline assembly (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.05-noasm.tar.bz2) works correctly for you? It is probably a bit slower though.

a friend also tested the same things I sent you, and had none of the issues I did. He made sure to test with the latest build also.
weird.
I will try this other alt.build when I have time.
I have no idea what a heisenbug is tho, btw :whistle:

have to remember to google that later (going to bed now).

In what way do these lines not work?

from my understamding tsmuxer doesn't handle the overlapping subs and split epochs. I have not personally tested a sup or xml+png like this in tsmuxer, tbh. works great with scenarist and your tool, tho =)

I believe there was some way for Scenarist to import PGS files by going through some sort of converter that is included with it. I could be remembering wrong though.

there is a MUI generator, but I am pretty certain no .sup input as an ES. it takes the xml+png, renders them and creates its own proprietary sup-like file, PES, along with the MUI file. the PES(+MUI) can be imported later like a sup is in other tools.
if anyone knows a way for scenarist (BD or SD) to import a .sup, please tell me.

i will try to report back soon.

thanks for your sincere dedication.

paradoxical

12th February 2013, 15:21

I have no idea what a heisenbug is tho, btw :whistle:

It's just a pun on Heisenberg Uncertainty Principle.

ps auxw

12th February 2013, 17:54

a friend also tested the same things I sent you, and had none of the issues I did. He made sure to test with the latest build also.
weird.
I will try this other alt.build when I have time.
That really sounds strange. I did my tests using AviSynth 2.5.8 with VSFilter 1.0.1.5 (some 2008 Gabest build, apparently). If you use different versions and the new test build doesn't change anything, you could try matching the versions for these components.

from my understamding tsmuxer doesn't handle the overlapping subs and split epochs. I have not personally tested a sup or xml+png like this in tsmuxer, tbh. works great with scenarist and your tool, tho =)
There shouldn't really be any overlapping things in those subtitles when looking at it from after the avs2bdnxml processing step, as they just get merged.

there is a MUI generator, but I am pretty certain no .sup input as an ES. it takes the xml+png, renders them and creates its own proprietary sup-like file, PES, along with the MUI file. the PES(+MUI) can be imported later like a sup is in other tools.
if anyone knows a way for scenarist (BD or SD) to import a .sup, please tell me.
I think I misremembered after all. I can't find any documentation pointing that way.

It's just a pun on Heisenberg Uncertainty Principle.
Specifically a heisenbug (http://en.wikipedia.org/wiki/Heisenbug) is one of those annoying bugs that disappear or change under observation.

LambdaDriver

25th March 2013, 06:03

ps auxw

25th March 2013, 15:47

I've got a problem with avs2bdnxml in cmd line, following the tutorials and templates but whenever i try to run it i get "Only a Single input file is allowed."

my AVS script:
AVCSource("C:\Users\Graham\Working Files\3 - BD SUBBING\3 - REAuthored\00002_1_01.dga")
MaskSub("C:\Users\Graham\Working Files\3 - BD SUBBING\1 - Program Stuff\avs2bdnxml-2.05\avs2bdnxml-2.05\subs.ass",1920,1080,23.976,35160)

My avs2bdnxml comand
avs2bdnxml -t Undefined -l eng -v 1080p -f 23.976 -a1 -p1 –b1 –u0 -m3 -o ep1subs.xml ep1.avs

not sure whats going on
I'm not sure how it happened, but looking closely, it seems that the dash in front of the b1 and u0 arguments ended up as some look-alike Unicode character, not a dash. Since the arguments do not start with a proper dash, avs2bdnxml thinks you are trying to read input from three files "fakedashb1", "fakedashu0" and "ep1.avs". Try typing in the command without copy&paste and see if that helps.

sneaker_ger

25th March 2013, 18:18

And while it shouldn't cause any errors, your script's first line ("AVCSourc...") is not being used at all. MaskSub() creates its own clip.

LambdaDriver

26th March 2013, 02:10

man i feel real stupid right now, i copied most of the command from a tutorial. should have checked closer, was going nuts trying to figure out what i was doing wrong, dont use command line much. Thank you very much for the help!

also i know the ("AVCSourc...") isnt used in the subs, the line is used for previewing subs in MPC-HC

CantankerousDave

14th May 2013, 00:02

Any chance of a flag to add a SMPTE timecode offset? It's not always practical for the output to start at 01:00:00:00. BDSup2Sub lets you add a millisecond-based offset, but it doesn't support zone-based titles - and is a pain to compute.
It took a while to wrap my head around this tool, but it can do some really cool things. Thanks for creating it.

ps auxw

14th May 2013, 03:17

Any chance of a flag to add a SMPTE timecode offset? It's not always practical for the output to start at 01:00:00:00. BDSup2Sub lets you add a millisecond-based offset, but it doesn't support zone-based titles - and is a pain to compute.
Just to make sure I understand correctly: You mean a commandline flag that lets you specify an offset, which should be added to all timecodes that are output? If so, that shouldn't be hard. I'll try to get around to it soon.

It took a while to wrap my head around this tool, but it can do some really cool things. Thanks for creating it.
It's good to hear you find it useful. :)

CantankerousDave

14th May 2013, 04:55

Just to make sure I understand correctly: You mean a commandline flag that lets you specify an offset, which should be added to all timecodes that are output? If so, that shouldn't be hard. I'll try to get around to it soon.

It's good to hear you find it useful. :)

Yup, basically something that would function like the SMPTE Offset function inside MaestroSBT's Timing Properties menu that sets the zero point for the timecode calculations (as opposed to specifying the timecode you want the first event to display at).

The hardest part was remembering how to use AVIsynth. It's been a while.

ps auxw

15th May 2013, 01:57

Yup, basically something that would function like the SMPTE Offset function inside MaestroSBT's Timing Properties menu that sets the zero point for the timecode calculations (as opposed to specifying the timecode you want the first event to display at).

I have just uploaded avs2bdnxml 2.06 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.06.tar.bz2), which, among some other new things and fixes, has support for this. You can use the -d/--t-offset option to specify a timecode offset either in frames or as a non-drop frame timecode in the format HH:MM:SS:FF.

CantankerousDave

15th May 2013, 04:03

I have just uploaded avs2bdnxml 2.06 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.06.tar.bz2), which, among some other new things and fixes, has support for this. You can use the -d/--t-offset option to specify a timecode offset either in frames or as a non-drop frame timecode in the format HH:MM:SS:FF.

Hey, awesome. I'll take it for a spin and see how its timecode output compares to those in XMLs that I know to be frame accurate.

CantankerousDave

15th May 2013, 22:35

Hey, awesome. I'll take it for a spin and see how its timecode output compares to those in XMLs that I know to be frame accurate.

Hm, I'm not having any luck figuring out the proper combination to get the offset to work. With MSBT, I would set the input to 23.976fps (the framerate my video is running at in my AVS script) and an output of 24fps (using -f 24 in the CLI), add the offset, and boom.

Example - Say my ASS file starts with this line:
Dialogue: 0,0:00:21.00,0:00:22.09,Default,NTP,0000,0000,0000,,Boo!

Using settings that I know to be frame accurate, 23.976 in, 24 out, and an offset of 01:48:11:07 should produce on/off times of 01:48:32:07 and 01:48:33:09 for this line. Instead, it returns 01:48:22:08 and 01:48:23:11. Weirdly, if I try to add 9 seconds 23 frames to the offset to compensate, it returns a start value of 01:48:23:07, a difference of only 9 frames. When I use these AVS and CLI settings on a script that actually does start at 01:00:00:00, the output is perfect, so it does seem to be something with the way the offset is either calculated or added.

AVS contents:
Avisource("XXXXX.avi")
MaskSub("XXXXX.ass",1920,1080,23.976,34647)
ConvertToRGB()

CLI:
avs2bdnxml -l eng -v 1080p -f 24 -d 01:48:11:07 -a1 -p1 -b1 -o XXXXX.xml XXXXX.avs

ps auxw

15th May 2013, 22:56

CantankerousDave

15th May 2013, 23:37

Thank you for testing. That sounds really odd. It seemed to work properly when I was testing. Especially the part where 9 seconds and 23 frames end up as a 9 frame difference. I'll take a hard look at it again tomorrow and see if I can find out what's wrong.

By the way, you don't need the AviSource bit, if you enter the values directly into MaskSub like that. ConvertToRGB also shouldn't be needed.

Oops, that should have been 23 frames, not 9. Math fail on my part. Thanks for the tip on the AVS - it seems to process the file much faster without it. I tried it again out of curiosity, and it still returned the same values.

As for the offset issue, the first and last frames of the full 25 minute script are off by the same 9 second, 23 frame amount, so the offset is being applied consistently, it's just not being converted to the correct numerical equivalent prior to being added to the output. Is it being calculated based on the -f flag in the command line? If the calculation is defaulting to some arbitrary frame rate, that would definitely explain it.

ps auxw

16th May 2013, 17:13

Is it being calculated based on the -f flag in the command line? If the calculation is defaulting to some arbitrary frame rate, that would definitely explain it.
It's using the correct frame rate. I actually just fixed it and released 2.07 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.07.tar.bz2). The bug was inside the commandline parsing code. It ended up ignoring the second digit of the second field and the hours field was getting added a second time as frames. Ugh. Anyway, I tested it with your sample data and it should work now.

One more thing about the AviSynth script: You might want to specify the frame rate as 24/1.001 instead of 23.976, just to be sure.

CantankerousDave

16th May 2013, 19:19

It's using the correct frame rate. I actually just fixed it and released 2.07 (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.07.tar.bz2). The bug was inside the commandline parsing code. It ended up ignoring the second digit of the second field and the hours field was getting added a second time as frames. Ugh. Anyway, I tested it with your sample data and it should work now.

One more thing about the AviSynth script: You might want to specify the frame rate as 24/1.001 instead of 23.976, just to be sure.

The timecode is now working perfectly (thanks for the 24/1.001 tip - I didn't know you could do that), but the PNG file names in the XML don't match those of the actual PNG files now.
For instance, the XML says:
Event Forced="False" InTC="01:59:17:01" OutTC="01:59:19:03">
<Graphic Width="724" Height="104" X="598" Y="870">00171769_0.png</Graphic>
</Event>
But the PNG containing the text that goes at that timecode is actually 00015978_0.png. The file names inside the XML seem to be taken from the new, shifted timecode while the actual output files are still based on the original, unshifted frame number.

I'm not sure which way is simpler, but it would probably be best to use the original frame numbers in both the XML and output PNGs. The frame number is handy for reference if you have the video open in VirtualDub and you don't have access to the timecode. Though it might be nice to have an option to use the name of the XML file as a base and simply number them sequentially. It's easier to keep track of what the PNGs belong to if the title of the show or movie is part of the file name. Then again, this tool makes it easy enough to re-render file sets that I guess it's not really necessary to archive the finished XML+PNG sets.

ps auxw

16th May 2013, 22:21

The timecode is now working perfectly (thanks for the 24/1.001 tip - I didn't know you could do that), but the PNG file names in the XML don't match those of the actual PNG files now.
For instance, the XML says:
Event Forced="False" InTC="01:59:17:01" OutTC="01:59:19:03">
<Graphic Width="724" Height="104" X="598" Y="870">00171769_0.png</Graphic>
</Event>
But the PNG containing the text that goes at that timecode is actually 00015978_0.png. The file names inside the XML seem to be taken from the new, shifted timecode while the actual output files are still based on the original, unshifted frame number.

I'm not sure which way is simpler, but it would probably be best to use the original frame numbers in both the XML and output PNGs. The frame number is handy for reference if you have the video open in VirtualDub and you don't have access to the timecode. Though it might be nice to have an option to use the name of the XML file as a base and simply number them sequentially. It's easier to keep track of what the PNGs belong to if the title of the show or movie is part of the file name. Then again, this tool makes it easy enough to re-render file sets that I guess it's not really necessary to archive the finished XML+PNG sets.

Oops! Well at least this one's easy to fix. This updated version (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.08.tar.bz2) uses the original frame numbers. I might add the part about using the XML filename for a base for PNG filenames at some later point. Sorry about the buggyness.

CantankerousDave

16th May 2013, 23:07

Oops! Well at least this one's easy to fix. This updated version (http://ps-auxw.de/avs2bdnxml/avs2bdnxml-2.08.tar.bz2) uses the original frame numbers. I might add the part about using the XML filename for a base for PNG filenames at some later point. Sorry about the buggyness.

Hey, no complaints at all. It's working perfectly now, and does everything I need it to do. Thanks for the rapid turnaround especially.

The base filename thing is just something for an "It would be nice if" list, since it works fine as-is. The only other thing I can think of would probably be non-trivial, since it would involve reworking how the program parses out the input file. Basically, the ability to parse out overlapping events individually - for example, two people are talking, and a sign appears behind them that you want to flag as FORCED. Having the ability to flag the sign as Forced=TRUE without affecting the dialogue titles would be very handy indeed. Even with cropped output, overlapping events are still essentially treated as a series of full-screen events (following the same flipbook style used in fullscreen DVD and Blu-ray subtitles), so multiple titles on a single page are subject to the same FORCED=TRUE/FALSE flag. Would an authoring program reject an XML that was produced by simply reading in each line of the ASS file individually and spitting out the calculated timecode to the XML, even if it contained overlapping IN/OUT events?

ps auxw

17th May 2013, 00:10

Hey, no complaints at all. It's working perfectly now, and does everything I need it to do. Thanks for the rapid turnaround especially.
I'm glad to hear it works now.

The base filename thing is just something for an "It would be nice if" list, since it works fine as-is. The only other thing I can think of would probably be non-trivial, since it would involve reworking how the program parses out the input file. Basically, the ability to parse out overlapping events individually - for example, two people are talking, and a sign appears behind them that you want to flag as FORCED. Having the ability to flag the sign as Forced=TRUE without affecting the dialogue titles would be very handy indeed. Even with cropped output, overlapping events are still essentially treated as a series of full-screen events (following the same flipbook style used in fullscreen DVD and Blu-ray subtitles), so multiple titles on a single page are subject to the same FORCED=TRUE/FALSE flag. Would an authoring program reject an XML that was produced by simply reading in each line of the ASS file individually and spitting out the calculated timecode to the XML, even if it contained overlapping IN/OUT events?
I'm not actually sure about how authoring programs would handle overlapping events. Maybe you could make a file manually and test it. As for parsing the actual ASS file, I'd rather not do something like that, as it would reduce the generality of avs2bdnxml. Currently, it is not limited to any specific input format.

CantankerousDave

17th May 2013, 01:57

I'm glad to hear it works now.

I'm not actually sure about how authoring programs would handle overlapping events. Maybe you could make a file manually and test it. As for parsing the actual ASS file, I'd rather not do something like that, as it would reduce the generality of avs2bdnxml. Currently, it is not limited to any specific input format.

Yeah, it ought to be possible to tweak the XML file in a text editor and do it manually, but you'd have to keep track of the total number of events as you tweak the files. I *think* I saw another program that handled events that way, but it was too bare-boned to be usable.

TheSkiller

17th May 2013, 20:58

During playback of a DVD only a single subpic (subtitle) can be displayed at any time. This subpic may contain as many lines (or any other kinds of graphics) as needed but it's always just one object, hence individual subtitles cannot overlap. It's up to the authoring software to deal with it. They can be merged into a single subpic but in that case you either have everything that is contained within forced or not.

zpfbj0

7th June 2013, 17:17

Is it normal(features) or bug?
1. video format(width & height) take effect in .avs file, but useless in avs2bdnxml command option(-v)
2. video fps take effect in avs2bdnxml command option(-f), but useless in .avs file
Both of the .avs file and avs2bdnxml command option has these 2 parameters, what's the different？

ps auxw

8th June 2013, 15:57

Is it normal(features) or bug?
This is expected behavior.

1. video format(width & height) take effect in .avs file, but useless in avs2bdnxml command option(-v)
The -v option specifies the type of resolution written to the XML file. Having this separate allows you to have the AviSynth script output only a partial frame, while still getting the correct resolution in the XML file. The -x/-y options are provided to adjust the positions of the sub pictures in these cases. For example, if you have a 1080p video, but have your AviSynth script output a video with a height of 540 (just the bottom half, where you expect your subtitles), so processing is faster, you can use -y 540 -v 1080p to have avs2bdnxml produce identical output.

2. video fps take effect in avs2bdnxml command option(-f), but useless in .avs file
FPS provided by AVS are ignored. The option only accepts frame rates allowed in BDN-XML files, thus enforcing compliance. I might be a good idea to check that the AVS is providing the same frame rate specified by -f, but this might be unnecessarily restrictive, when the difference is small (e.g. rounding errors). Of course, if you use e.g. VSFilter to generate your subtitles, your AviSynth script still has to work with the correct frame rate.

Legremlins_Keitaro

22nd September 2013, 18:59

One little question, When .png file were generate, there's all have "shadow", I don't see in the avs2bdnxml.exe /? the option to disable shadow. Is it possible and How ?

TheSkiller

22nd September 2013, 21:48

Depends on what subtitle format you feed to avs2bdnxml via AviSynth.
If it's Subrip (srt) there are no styling options provided by the srt script. If it's Aegisub (ass) you can use Aegisub to style your subtitles in almost every way you could imagine.

ps auxw

22nd September 2013, 22:10

What TheSkiller said. I'm also pretty sure that Aegisub can open SRT files, so if that's what you have, you can import it there, style it and save it as ASS for further conversion.

Legremlins_Keitaro

23rd September 2013, 06:53

Hmm exact it's srt. I make a try to convert .srt to .ass with aegissub and after convert the .ass with avs2bdnxml.

Taizenshū

8th August 2015, 12:51

Sorry I don't know where to post this. But I'm have an issue with AVS2BDXML not working properly.

It was working fine before I formatted my PC (there were issues). But after formatting and installing Avisynth and VSFilter It's not working like it use to. I keep getting this:

http://i.imgur.com/mza9WEEm.png (http://i.imgur.com/mza9WEE.png)

This is my script, I have no idea what's wrong:

MaskSub("subs.ass",1920,1080,23.976,69607)

sneaker_ger

8th August 2015, 15:28

Did you try what you were told to try?
I believe a 240 frame clip is generated when an AviSynth error occurs. Try opening your .avs file in a media player. Did put (some version of) vsfilter into your AviSynth plugin autoload folder? If not, need to load it manually in your script.

Taizenshū

8th August 2015, 16:20

Did you try what you were told to try?

I did. It gave me the exact same result.

sneaker_ger

8th August 2015, 16:23

What is the error message that's shown in the media player? How does your AviSynth script look like? What vsfilter.dll version do you use and where did you put it?

Taizenshū

8th August 2015, 16:30

What is the error message that's shown in the media player? How does your AviSynth script look like? What vsfilter.dll version do you use and where did you put it?

There is no video in the script, so whenever I put it in the media player it says "Cannot render video file" (I'm using MPC).

This is how my Avisynth script looks like now:

LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\VSFilter.dll")
MakeSubs("00001.ass",1920,1080,23.976,69607)

And this is what I put in cmd:

avs2bdnxml -t Undefined -l und -v 1080p -f 23.976 -a1 -p1 -b0 -m3 -u0 -e0 -n0 -z0 -o output.sup 00001.avs

I'm using VSFilter ver. 3.0.0.306 that I got from here (https://code.google.com/p/xy-vsfilter/wiki/Downloads?tm=2) and placed it in the plugins folder.

sneaker_ger

8th August 2015, 16:34

"MakeSubs"? I only know "MaskSub".

There is no video in the script, so whenever I put it in the media player it says "Cannot render video file" (I'm using MPC)
Try VirtualDub. It should show the AviSynth error message. Make sure you only use 32 bit VirtualDub or MediaPlayer to open 32 bit AviSynth. Same goes for plugins: 32 bit AviSynth can only load 32 bit vsfilter.

Taizenshū

8th August 2015, 16:51

"MakeSubs"? I only know "MaskSub".

Try VirtualDub. It should show the AviSynth error message. Make sure you only use 32 bit VirtualDub or MediaPlayer to open 32 bit AviSynth. Same goes for plugins: 32 bit AviSynth can only load 32 bit vsfilter.

Sorry that was a typo. So installed the 32bit version of VSFilter and now it's giving me this:

http://i.imgur.com/PaUy1jum.png (http://i.imgur.com/PaUy1ju.png)

I tried loading the avs file in VirtualDub but it's giving me this error:

http://i.imgur.com/Pmthv5K.png

sneaker_ger

8th August 2015, 17:10

That's strange, almost like AviSynth isn't installed. What does AviSynth Info Tool (http://forum.doom9.org/showthread.php?t=170647) show? Do you have the the latest stable version (http://sourceforge.net/projects/avisynth2/files/latest/download)?

Taizenshū

8th August 2015, 17:18

sneaker_ger

8th August 2015, 17:29

Then I don't know why VirtualDub does not display the AviSynth error message. What error message here:
avs2pipemod.exe (http://www.mediafire.com/download.php?alg424t3kx7ak5d) -info 00001.avs
?

Taizenshū

10th August 2015, 15:46

Then I don't know why VirtualDub does not display the AviSynth error message. What error message here:
avs2pipemod.exe (http://www.mediafire.com/download.php?alg424t3kx7ak5d) -info 00001.avs
?

I'm away from home for now. I'll check when I get back next week.

Taizenshū

16th August 2015, 05:32

Sorry for the double post but I just wanted to as what should I do with with the software you sent?

Music Fan

12th September 2015, 13:33

Hi,
how to get transparency around a video converted in sup with avs2bdnxml ?
I'd like to display a black & white video (for example in 640*480) over a 1080p video (and use the little video as an interactive subtitle file). Thus the borders should be transparent, but if I add borders with avisynth (to get a 1080p file without resizing the 480p video), these borders are black. How to turn it transparent ?
Does the avisynth script have to send 1080p or it can be 640*480 and avs2bdnxml center this video with transparency all around in a 1080p window if resolution is set on 1080p in the avs2bdnxml script ?
Because I guess that the final sup has to get the same resolution than the video with which it will be muxed.

I can ask it differently : let's imagine I have a little animated logo I'd like to use as a subtitle file : how to choose its size and place in the video (using avisynth as input) if I want it to be displayed over a corner of the 1080p video ?
Thanks.

sneaker_ger

12th September 2015, 13:58

AviSynth needs to output in RGBA format (RGB with alpha channel) for avs2bdnxml to get the transparency info. The resolution should be the same as for your video (e.g. 1920x1080).

Music Fan

12th September 2015, 14:42

You mean the resolution of the avisynth script ?
If yes, how to add transparency with avisynth around the video (or logo, subtile or whatever) ?

ps auxw

12th September 2015, 14:48

You mean the resolution of the avisynth script ?
If yes, how to add transparency with avisynth around the video (or logo, subtile or whatever) ?

You can use a small video with the "--x-offset" and "--y-offset" options of avs2bdnxml to center it. This would be faster than having avs2bdnxml process a full size video too. You still have to ensure that the video is RGBA, i.e. add ConvertToRGB32.

Another way of achieving what you want would be using BlankClip to create a transparent video and then using Overlay to add your smaller video.

Please be aware that stuffing a video with many frames into the subtitle stream may lead to compatibility issues due to buffer limitations. If you only have a few frames it should be fine.

Music Fan

12th September 2015, 15:31

Thanks !
I tried with a black & white video resized in 176*100 and didn't specify any x or y position : the subtitle (muxed in TS with TSMuxer) is correctly displayed (in the top left corner) by VLC but not by MPC-HC.
The sup is fluid, as the video (23.976 fps).
I also tried with a 1080p video, it's accepted by avs2bdnxml and the (huge) sup is accepted by TSMuxer but VLC plays it with difficulty.

Is there a maximal recommanded bitrate for sup files (for dvd and Blu-ray) and how to see or calculate their bitrate ?

Is there a kind of compression in sup files or all frames have the same size (in the case of a sup created from a video, which means same resolution for all frames but with different content in all frames because of the movement) ?

sneaker_ger

12th September 2015, 15:55

I also tried with a 1080p video, it's accepted by avs2bdnxml and the (huge) sup is accepted by TSMuxer but VLC plays it with difficulty.
Did you use -a/--autocrop? There should not really be a difference in the final output between providing full 1080p resolution script vs a small script with offset as long as both have the same input. If you try to encode a "real" 1080p video you will exceed all the limits in terms of playback compatibility.

Is there a maximal recommanded bitrate for sup files (for dvd and Blu-ray) and how to see or calculate their bitrate ?
IIRC there should be warning if BluRay limits are exceeded.

Is there a kind of compression in sup files or all frames have the same size (in the case of a sup created from a video, which means same resolution for all frames but with different content in all frames because of the movement) ?
IIRC: simple run length compression (RLE).

Don't even think about doing anything crazy. The format is for common subtitles, not screen-filling animations/videos.

Music Fan

12th September 2015, 16:30

Did you use -a/--autocrop?
I guess yes, I used the script in 1st post containing -a1

IIRC there should be warning if BluRay limits are exceeded.
There was no warning while the 1080 sup is probably far beyond the BluRay limits.

I made another test with offset (50 for x and y) but the sup (from 176*100 video) is still in the top left corner with VLC, as if there were no offset, I don't know if it's a VLC or avs2bdnxml bug.:confused:

I tried to play the ts (put in AVCHD folder with TSMuxer) with 2 standalone Blu-ray players but none managed to play the sup from 176*100 video :o
When I turn on subtitles, the video begins to stutter a lot and sub are never displayed.
I believed it would be ok at this low resolution, especially because it was played from a USB key (which generally allows high bitrates).
I have to tell that both my players usually play subtitles in AVCHD folder created with TSMuxer, thus the problem is probably the bitrate but not the presence of subtitles.

Don't even think about doing anything crazy. The format is for common subtitles, not screen-filling animations/videos.
Actually I saw 2 commercial dvd's with complex subtitles ;
-one of classical music that can display musical scores (partitions) over the video
-the other is Men in Black with an optional "video commentary" : 2 guys were filmed during their commentary and the video was converted into a kind of black & white shadow encoded in sup, thus it's not as detailed as a video but we see the form of their body moving all along the commentary.

sneaker_ger

12th September 2015, 16:38

There was no warning while the 1080 sup is probably far beyond the BluRay limits.
Maybe I'm not remembering correctly. I'll let ps auxw answer...

ps auxw

12th September 2015, 18:36

Maybe I'm not remembering correctly. I'll let ps auxw answer...

I'm a little fuzzy on that too and I don't have the time to check right now, but you might have to use "-z1" to enable these.

If you are going to put video into the SUP, make sure it is low resolution and as low color/low detail as possible to save buffer space. To get a very rough approximation of the bitrate, you could store the frames as PNG with a the lowest compression level that still compresses. However, bitrate isn't really the problem. The issue is more how much space the decoded pictures take up.

I made another test with offset (50 for x and y) but the sup (from 176*100 video) is still in the top left corner with VLC, as if there were no offset, I don't know if it's a VLC or avs2bdnxml bug.:confused:

It used to work, but possibly hasn't be tested much recently, so there might be a regression. I'll try to take a look at it when I have time.

Edit: It's an avs2bdnxml bug. The offsets are currently only applied for XML output, not SUP output. This should be easy to fix. Thanks for reporting it.

ps auxw

12th September 2015, 19:07

Please test whether the offset issue is fixed with this: [removed]

Edit: Updated the archive to prevent a regression with offset handling and BDN-XML output.

Music Fan

13th September 2015, 08:30

Thanks for the update but there is a problem with the sup export, nothing appears now in VLC. And when I open the sup in Subtitle Edit, I get this message : "... does not contain any subtitles or contains errors", while the sup created yesterday is recognized (even its resolution is displayed ; 176 * 100, as the avisynth output).
And the sup size is three times smaller than the sup created yesterday with the same options.

By the way, I tried again MPC-HC (with Windows 7, yesterday I ran XP, I have both OS in dual boot) and it plays the TS created yesterday, but the sup is resized and covers the whole video, while the same TS is ok with VLC which shows the sup in the top left corner.

If you are going to put video into the SUP, make sure it is low resolution and as low color/low detail as possible to save buffer space. To get a very rough approximation of the bitrate, you could store the frames as PNG with a the lowest compression level that still compresses.
How can I choose the compression if I export in sup ?
The video is in black and white and if I lower the resolution, this will become very little (176*100 is not that big over a 1080p video), do you believe a blur in the avisynth script may help to lose detail -and thus increase sup compression- without lowering resolution ?

edit : I made another test : I opened the sup created yesterday with v2.08 in Subtitle Edit and exported it in Blu-ray SUP (thus nothing change except the x and y positions) : the resulting sup muxed in TS is now correctly playable in MPC-HC (except a mysterious out of sync problem) but not anymore in VLC, the opposite of the orignal sup !

edit 2 : AVCHD on USB key done with the sup that went through Subtitle Edit is played a little bit better (still stutters but less) than the AVCHD containing the original sup (done with v2.08), which probably means that Subtitle Edit makes a kind of correction (but the sup size is nearly the same than the original sup, a little bit bigger ; 17657 KB and 17504 KB for a 1 minute sup in 176*100 exported in 1080p).

ps auxw

13th September 2015, 13:23

Music Fan

13th September 2015, 15:57

Blur likely won't help
You said earlier that low detail would help.

just reducing colors without dithering.
It's black and white.

ps auxw

13th September 2015, 16:49

You said earlier that low detail would help.

It's black and white.

Since the compression is RLE, it only compresses when there are multiple pixels with exactly the same color following one after the other. If it's already black and white, it's probably not going to get much better in that regard.

Music Fan

14th September 2015, 08:26

Ok, but I got 2 ideas ;
-lower even more resolution to lose detail then upscale it to get a reasonable size
-divide the framerate by 2 to lose fluidity then double framerate (with ChangeFPS() to simply duplicate frames), that may help for the RLE compression.

I can also add opacity but I don't know if it may help to decrease sup size.

edit : with this method, the sup is 2 times smaller. But I'm afraid it doesn't change anything for the player because as you said, only the decompressed sup's bitrate does matter. It's less detailed and less fluid but has probably the same bitrate after RLE decompression because at the end of the avs script, the framerate and resolution are the same.

edit 2 : strange thing ; for Subtitle Edit, there are 2 times less frames than what avs2bdnxml created, as if all the duplicated frames were discarded ! But each frame lasts 2 times longer, which means the timecodes of 2 successive and identical frames are merged for Subtitle Edit (and sup's speed is ok in VLC).

ketsuban

23rd November 2015, 15:28

Before anything else, big thanks ps auxw for having created the most useful and complete tool to render Blu-ray compliant subtitles, exploiting very well all the capabilities of the spec. I must thank as well all the users who have posted here along the years, since they contributed positively to improve it and provided very useful complementary information.

Being that said, I would like to ask if there could be a chance of including a new feature in this program, which I think it would make it even more outstanding. My proposal concerns the possibility of adding a feature consisting on converting existing XML+PNG subtitles to SUP and vice versa. If that was possible, I would be able to save a lot of time, especially if I could convert SUP subtitles to XML+PNG. I will next justify the motivation of proposing the inclusion of this feature.

Sometimes, I receive some SUP files provided by a third party extracted through tsMuxeR, in order to perform some operations with them (such as corrections, FPS modification, etc.). In order proceed with them, I need to convert it to XML+PNG, both for editing and for lately adding them to a Scenarist BD project in order to reauthor the content with the modified subtitles.

The problem with having only the SUP subtitles is that there is no tool capable of converting them back to XML+PNG correctly if there are some subtitles with dual windows partition of events (a well-known issue with programs such as BDSup2Sub); therefore, if I want to obtain the full subtitles without losing those who are in the second window, when that happens and if actually happens, I need to artificially convert correctly them through BD Reauthor Pro depending in the case:

a) If I have been provided a MKV with the SUP file muxed in them (for instance, coming from a BD Remux), I must artificially convert it to m2ts and demux it through BD Reauthor Pro in order to obtain a correct XML+PNG file.

b) If I only have a SUP file, I must mux it together with a dummy video with a greater or equal length than the OutTC of the last event, consuming a lot of time and unnecessary writting in the HDD as in the previous case.

Therefore, since this program handles well both XML+PNG and SUP formats, I though it would be interesting to add a supplementary tool to convert between the two formats, which, albeit being out of the main purpose of this tool, which is rendering subtitles, I'm sure it would become a very useful feature for some users like me when they face a situation as the one I mentioned above.

sneaker_ger

23rd November 2015, 17:58

The problem with having only the SUP subtitles is that there is no tool capable of converting them back to XML+PNG correctly if there are some subtitles with dual windows partition of events (a well-known issue with programs such as BDSup2Sub)
Have you tried BDSup2Sub++ 1.0.2?

ketsuban

23rd November 2015, 18:38

Have you tried BDSup2Sub++ 1.0.2?

Yes, and I still get the errors/warnings "Multiple PDS/ODS definitions: Result may be erratic" and "Duration of frame X is shorter than 533.867 ms" associated to the problem with multiple windows and short effects (events with concatenated subpictures), which should not appear.

ps auxw

26th December 2015, 02:36

Therefore, since this program handles well both XML+PNG and SUP formats, I though it would be interesting to add a supplementary tool to convert between the two formats, which, albeit being out of the main purpose of this tool, which is rendering subtitles, I'm sure it would become a very useful feature for some users like me when they face a situation as the one I mentioned above.

I like the idea and will probably work on it, once I find the time, but that might still be a while off.

XStylus

25th May 2016, 22:01

I like the idea and will probably work on it, once I find the time, but that might still be a while off.

I realize I'm necroposting, but I'd just like to add a +1 to that request.

What'd also be handy is a way to convert the BDN XML to a standard XML readable in an NLE such as Final Cut or Premiere. That way we can load this into an NLE and preview the subpics in there.

I currently know of no other way to easily preview these subpics against video.

ps auxw

25th May 2016, 23:44

I realize I'm necroposting, but I'd just like to add a +1 to that request.
That's just the way this thread tends to go. ;)

What'd also be handy is a way to convert the BDN XML to a standard XML readable in an NLE such as Final Cut or Premiere. That way we can load this into an NLE and preview the subpics in there.

I currently know of no other way to easily preview these subpics against video.

Interesting. Do you have a pointer for format docs of such "standard XML"?

XStylus

26th May 2016, 01:24

Interesting. Do you have a pointer for format docs of such "standard XML"?

Perhaps "standard" was the wrong word. More like typical. It's FCP7's standard, but it has been adopted by other NLEs such as Avid and Premiere. I can gladly provide example files though.

Will also be glad to throw money if it gets that particular feature done faster. ;)

ps auxw

28th May 2016, 12:48

Perhaps "standard" was the wrong word. More like typical. It's FCP7's standard, but it has been adopted by other NLEs such as Avid and Premiere. I can gladly provide example files though.

Will also be glad to throw money if it gets that particular feature done faster. ;)

If you PM me some samples, I'll take a look at it.

mp3dom

14th July 2016, 11:00

Is it possible to implement a dithering algo for the 8bit palette rendering? (or an enable/disable option) This can be really helpful when rendering subtitles with smooth gradients that actually are rendered with lots of color banding

ketsuban

12th August 2016, 13:45

I have found by mere chance a possible minor bug involving the time accuracy of some frames. My suspicions are mainly focused on the fact that it is possible that somewhere an inexact rounded fps value is used instead of the exact quotient in the case of non-integer fps such as 23.976 (24000/1001) or 29.97 (30000/1001). The particular example where I have found this issue is the following one, with a 29.97 (30000/1001) fps interlaced video:

The first video frame where it is intended to display that particular line, assuming, by the spec convention, that the frames start to be indexed by 0, is the frame number 37477. The time set in Aegisub for that purpose in format H:MM:SS:CS is 0:20:50:45, namely, at t=20*60+50.45=1250.45 s. Therefore, multiplying by 1001/30000 we have 37476.023976024, and therefore, according to the Aegisub criteria, rounding up the value the subtitle will appear in the frame starting from ceil(37476.023976024)=37477. Indeed, this is the desired result in Aegisub and the subtitle is displayed correctly there. However, after rendering this subtitle in avs2bdnxml, the subtitle appears however starting by the frame 37476, one frame before expected. This result is obtained if we use instead for the computations the inexact value 29.97, since 1250.45*29.97=37475.9865, and therefore ceil(37475.9865)=37476, which is coherent with my initial assumption about the possibility of using somewhere the inexact value. If the time value is changed by increasing an unit the CS to 0:20:50:46 then the issue is corrected in the BDN+XML output, because the result is still correct in Aegisub since in this case we have 1250.46*30000/1000=37476.3236763237 (approx.), hence ceil(37476.3236763237)=37477, and on the other hand 1250.46*29.97=37476.2862, and thus ceil(37476.2862)=37477 as well.

I have checked a bit the source code and it looks like you are doing the things well, so the problem might be in the output values provided by the AviSynth engine, although I am not completely sure. In any case, albeit I have only reported here this issue involving InTC values, I guess it happens as well in the OutTC case. If you could check this issue, confirm and fix it (if possible), I would be very grateful.

By the way, many thanks for considering my last request.