View Full Version : AviSynth rendered subtitles to BluRay SUP/PGS and BDN XML (v2.08)
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
I'd like to give this program a try, but I'm new to AVIsynth usage:
video=AviSource("video.avi")
MaskSub("subtitles.ext",video.width,video.height,video.framerate,video.framecount)
I'm trying to use an ASS file. What is the "avisource" referred to above? When using an ASS file, what is the video referenced to in this script?
How do I determine the "framecount" of the ASS file that I intend to use?
sneaker_ger
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
I'm using aegisub to create the ass file, my video is NTSC 29.97fps nondrop, if I import the bdn-xml file straight into scenarist BD, the subtitle just gradually out of sync. So what process (framerate transform) do I need to apply, either on the original output or change the input framerate in command line?
The image output part is fine, quality is slightly better than tsmuxer (used fireworks to downgrade the pngs to 8 bit RGBA), but still has some white stuff uncleared on the outline (particularly visible in TotalMedia Theatre). So far the only tool that can generate perfect commercial quality Blu-ray subpicture is lemony pro, but that one is too hard to use. This tool seems promising, as long as if I can figure out how to get the timecodes fixed...
ps auxw
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
Thanks for the quick update. Definitely looking forward to the optimized version.
And for downgrading from 32bit RGBA png, BDSup2Sub handles the job really well. I think it's either Fireworks or me screwed up in the process because the pngs from BDSup2Sub are really good, no more white pixels!
I've also tried time collision, and fade in/fade out, they import and compile fine in scenarist BD. The fading effect plays smoothly in Totalmedia Theatre.
sneaker_ger
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
No, I think everything is correct. In the non-drop time code thread (http://forum.doom9.org/showthread.php?p=480776#post480776) the example given for a non-drop time code of a certain frame ("For example, 02:34:17:12 (non-drop-frame) is 277722 frames") matches the way it is now calculated in avs2bdnxml, and it seems to be correct from a theoretical point of view too.
You're right - stupid me.
ps auxw
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
The easiest way is to use the following AviSynth-Script and skip through it frame by frame with VirtualDub:
BlankClip(240,1280,720,"YV12",fps=24000,fps_denominator=1001)
SupTitle("color_bdsup2sub.sup",false)
Crop(0,100,0,0)
AddBorders(0,0,0,100)
TextSub("color.ass")
Besides vsfilter you'll also need the SupTitle plugin (http://www.zachsaw.co.cc/?pg=suptitle_pgs_avisynth_plugin).
Sometimes the subtitles appear 1 frame too late, sometimes they disappear 1 frame too late and sometimes both happens. In this specific sample it appears too late. I also created a .sup using PunkGraphicStream and the result was correct, so it's probably not an issue of SupTitle.
sneaker_ger
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)?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.