Log in

View Full Version : Blu-Ray subtitle: minimum time difference


walexago
11th November 2013, 18:12
Hi,

do you know if in Blu-Ray specs there is a minimum time difference between two consecutives subtitles lines?

It's acceptable for example 1 ms or I must to use a greater value?

Thanks in advance

Ghitulescu
11th November 2013, 19:07
I use at least 1 frame between (last frame with subtitle, frame with none, frame with the next subtitle)

walexago
11th November 2013, 20:16
I use at least 1 frame between (last frame with subtitle, frame with none, frame with the next subtitle)

Thanks for info: but this means I must to work on many subtitle lines from my HDTV records.

I have some HDTV records (typically 1080i .ts, 25fps) with DVB/Teletext subtitle: if I extract these streams from .ts files, I get subtitle with very little difference like

8
00:03:49,874 --> 00:03:51,815
Text1

9
00:03:51,840 --> 00:03:52,640
Text2


In this case there is a difference of 25ms I need to adjust to 40ms (1 frame@25fps it's long 40ms); it's right? If so, it's very hard work.

Thanks in advance

bigotti5
11th November 2013, 22:12
Blu-Ray specs does not require time difference between two consecutives subtitles lines


...
<Events>
<Event InTC="00:00:05:00" OutTC="00:00:08:00">
<Text RegionStyleID="0" ReferenceText="First">00111B03030402021B010546495253541B0B00</Text>
</Event>
<Event InTC="00:00:08:00" OutTC="00:00:11:00">
<Text RegionStyleID="0" ReferenceText="Second">00121B03030402021B01065365636F6E641B0B00</Text>
</Event>
<Event InTC="00:00:11:00" OutTC="00:00:14:00">
<Text RegionStyleID="0" ReferenceText="Third">00111B03030602021B010554686972641B0B00</Text>
</Event>
...

walexago
11th November 2013, 23:48
Blu-Ray specs does not require time difference between two consecutives subtitles lines

Thanks bigotti5,

that's good news: I will try my subtitle without any modification :)

Ghitulescu
12th November 2013, 09:27
I thought you want to create a blu-ray from your own material.

You can put almost 1.1 HDTV material to a BD (like in the case of DVB->DVD, there might be some issues). I remember reading somewhere that the subtitles must be separated by at least 40ms even if the specs allow them be even overlapped.

ps auxw
16th November 2013, 19:55
There doesn't need to be a gap, as was stated before. However, it seems to be necessary to put consecutive subtitles into a single epoch, since some players introduce slight gaps otherwise. You can find a bit of information about this in the posts here: http://forum.doom9.org/showthread.php?p=1388713#post1388713

Well, it probably doesn't apply in your case, since you already seem to have tiny gaps in the source subtitles.

mariner
17th November 2013, 05:53
There doesn't need to be a gap, as was stated before. However, it seems to be necessary to put consecutive subtitles into a single epoch, since some players introduce slight gaps otherwise. You can find a bit of information about this in the posts here: http://forum.doom9.org/showthread.php?p=1388713#post1388713

Well, it probably doesn't apply in your case, since you already seem to have tiny gaps in the source subtitles.

Greetings ps auxw.

According to the author of this not so recent article (http://linkai8425.wordpress.com/2010/07/06/current-state-of-blu-ray-subtitle-rendering-software/), BDSup2Sub/easySUP/tsMuxeR failed to correctly render consecutive BD subtitles without flickering.

Is it still true today?

ps auxw
18th November 2013, 04:33
Greetings ps auxw.

According to the author of this not so recent article (http://linkai8425.wordpress.com/2010/07/06/current-state-of-blu-ray-subtitle-rendering-software/), BDSup2Sub/easySUP/tsMuxeR failed to correctly render consecutive BD subtitles without flickering.

Is it still true today?

I haven't followed the more recent development of BDSup2Sup and bdsup2sub++, so I couldn't say for sure whether that is still the case. If you mux PGS/SUP files produced directly by avs2bdnxml, you shouldn't get (or at least minimize in extreme cases) flickering though.

mariner
20th November 2013, 12:31
I haven't followed the more recent development of BDSup2Sup and bdsup2sub++, so I couldn't say for sure whether that is still the case. If you mux PGS/SUP files produced directly by avs2bdnxml, you shouldn't get (or at least minimize in extreme cases) flickering though.

Thanks for the kind reply, ps auxw.

1. Would you kindly help with the definition of epoch?

2. How does one find out if a BD sup has continuous subtitles grouped into a single epoch, as epoch does not seem to be used in xml?

3. When an BD sup created by easySUP is displyed in BDSup2Sub, there appears to be no gap in the timecodes of the consecutive subtitles. So what does it mean when the article mentioned "epoch cannot be too close to each other"?

4. It was mentioned in the article how one event can contain two graphic windows. While this is useful in the case of overlapping timecodes, it is not clear how this would help in eliminating flickering in continuous timecodes. Would you be kind enough to explain how this is done in avs2bdnxml?

Many thanks and best regards.

ps auxw
21st November 2013, 04:19
1. Would you kindly help with the definition of epoch?
An epoch basically contains a number of composition objects and associated data. There are some limits on how many of certain things can be contained within one epoch, which can be found in the thread I linked earlier.

2. How does one find out if a BD sup has continuous subtitles grouped into a single epoch, as epoch does not seem to be used in xml?
This is a little tricky. As you noticed, BDN XML doesn't contain any information about epochs, since those only get created when BDN XML is converted to SUP/by Scenarist. You could try to use "pgsparse.exe", which should be included with avs2bdnxml and run something like:
pgsparse.exe subtitles.sup > parsedsup.txt
Then, look through "parsedsup.txt" and check whether any "PCS start" packets have further "PCS start" packets before the next "PCS end" packet. If there are multiple, there should be multiple composition objects in that epoch.

3. When an BD sup created by easySUP is displyed in BDSup2Sub, there appears to be no gap in the timecodes of the consecutive subtitles. So what does it mean when the article mentioned "epoch cannot be too close to each other"?
I believe the "cannot be too close to each other" is a problem with implementations in certain players. Even though the timestamps seem to be fine, if a new epoch starts, some players seem to introduce a flicker.

4. It was mentioned in the article how one event can contain two graphic windows. While this is useful in the case of overlapping timecodes, it is not clear how this would help in eliminating flickering in continuous timecodes. Would you be kind enough to explain how this is done in avs2bdnxml?
There is a picture decoding buffer of 4MB, which gets filled up as composition objects within an epoch are decoded. Let's say, you are trying to place the letter "A" in the top left corner of the video and "B" in the bottom right. If you do that with a single window, you will need a big picture and use up a big part of the buffer, which in turn may make it necessary to start a new epoch, even though you are still within a section of consecutive subtitles. If you place both letters in their own window, you can save a lot of space, since both windows will be small. Apart from that, using multiple windows doesn't inherently prevent flickering.

mariner
27th November 2013, 05:20
An epoch basically contains a number of composition objects and associated data. There are some limits on how many of certain things can be contained within one epoch, which can be found in the thread I linked earlier.


This is a little tricky. As you noticed, BDN XML doesn't contain any information about epochs, since those only get created when BDN XML is converted to SUP/by Scenarist. You could try to use "pgsparse.exe", which should be included with avs2bdnxml and run something like:
pgsparse.exe subtitles.sup > parsedsup.txt
Then, look through "parsedsup.txt" and check whether any "PCS start" packets have further "PCS start" packets before the next "PCS end" packet. If there are multiple, there should be multiple composition objects in that epoch.


I believe the "cannot be too close to each other" is a problem with implementations in certain players. Even though the timestamps seem to be fine, if a new epoch starts, some players seem to introduce a flicker.


There is a picture decoding buffer of 4MB, which gets filled up as composition objects within an epoch are decoded. Let's say, you are trying to place the letter "A" in the top left corner of the video and "B" in the bottom right. If you do that with a single window, you will need a big picture and use up a big part of the buffer, which in turn may make it necessary to start a new epoch, even though you are still within a section of consecutive subtitles. If you place both letters in their own window, you can save a lot of space, since both windows will be small. Apart from that, using multiple windows doesn't inherently prevent flickering.

Thanks for the kind reply, ps auxw.

1. So each epoch has one "PCS end" packet, is this correct?

2. It seems BDSup2Sub/++ does not allow multiple events in a single epoch, and BDSup2Sub cannot handle multiple graphic objects in a single event.

3. How many events can avs2bdnxml squeeze into a single epoch?

4. Any chance of doing a GUI front end for avs2bdnxml?

Many thanks and best regards.

ps auxw
28th November 2013, 00:39
1. So each epoch has one "PCS end" packet, is this correct?
To the best of my knowledge, yes.

2. It seems BDSup2Sub/++ does not allow multiple events in a single epoch, and BDSup2Sub cannot handle multiple graphic objects in a single event.
I suppose that didn't change then.

3. How many events can avs2bdnxml squeeze into a single epoch?
By default, avs2bdnxml will start a new epoch, when any of the following is true:
- There is a gap of 1 frame or longer between the last and current event.
- The number of composition object becomes higher than 64.

If stricter mode (--stricter 1) is enabled, the following conditions are also considered:
- The buffer required to store decompressed composition objects from the epoch becomes bigger than 4MiB.
- The number of palettes becomes higher than 8. Note that palette handling is currently dumb, so this may limit the number of composition objects allowed within one epoch to 8-16.

4. Any chance of doing a GUI front end for avs2bdnxml?
I don't like coding GUIs, so probably not, at least from me. I think there might be one or two third-party GUIs out there somewhere. A Chinese one was mentioned in the avs2bdnxml thread.

mariner
28th November 2013, 12:48
By default, avs2bdnxml will start a new epoch, when any of the following is true:
- There is a gap of 1 frame or longer between the last and current event.
- The number of composition object becomes higher than 64.

If stricter mode (--stricter 1) is enabled, the following conditions are also considered:
- The buffer required to store decompressed composition objects from the epoch becomes bigger than 4MiB.
- The number of palettes becomes higher than 8. Note that palette handling is currently dumb, so this may limit the number of composition objects allowed within one epoch to 8-16.


So stricter mode (--stricter 1) should be enabled to avoid buffer overflow?


I don't like coding GUIs, so probably not, at least from me. I think there might be one or two third-party GUIs out there somewhere. A Chinese one was mentioned in the avs2bdnxml thread.

The Chinese GUI is not up to date and lacks basic formatting controls such as /outline/shadow/opacity/placement/line spacing etc.

Many thanks and best regards.

ps auxw
29th November 2013, 17:59
So stricter mode (--stricter 1) should be enabled to avoid buffer overflow?
If you want to be safe, yes.

The Chinese GUI is not up to date and lacks basic formatting controls such as /outline/shadow/opacity/placement/line spacing etc.
I see. However those kinds of things do not fall within the purview of avs2bdnxml, as they depend on how the subtitles are rendered, while avs2bdnxml only does the conversion from RGBA video served by AviSynth into other formats.

mariner
7th December 2013, 15:30
Thanks ps auxw.

Will post formatting questions at the avs2bdnxml thread.

Best regards.

ps auxw
8th December 2013, 15:43
Will post formatting questions at the avs2bdnxml thread.
Formatting doesn't pertain to avs2bdnxml. It depends solely on what you input. If you use VSFilter with a subtitle file for rendering, I would suggest using Aegisub (http://www.aegisub.org/) to help with your formatting needs.