ttxt text positioning [Archive]

View Full Version : ttxt text positioning

charleski

14th November 2005, 14:45

About subtitles:
Great to see that Gabest has implemented font styles and colours - send him my thanks.
The one problem atm seems to be positioning of the subtitles. As far as I understand it from the GPAC document (http://gpac.sourceforge.net/auth_text.php) the text is rendered in a text box that can then be positioned on the screen. There's a general position specified in the TextStreamHeader and then it looks like each individual TextSampleDescription can have its own position specified through the TextBox fields. Is Gabest still working on implementing these?

I found that the following worked on getting subtitles to display in the center at the bottom:<TextStreamHeader width="176" height="30" layer="65535" translation_x="352" translation_y="540">
<TextSampleDescription horizontalJustification="center" verticalJustification="bottom" backColor="ff ff ff ff" verticalText="no" fillTextRegion="no" continuousKaraoke="no" scroll="None">
<FontTable>
<FontTableEntry fontName="Serif" fontID="0"/>
</FontTable>
<TextBox top="300" left="300" bottom="30" right="176"/>
<Style styles="Normal" fontSize="36" color="0 0 ff ff"/>
</TextSampleDescription>This is on a video stream with dimensions 704x560 and 'SAR' of 7/5, so it's squeezed to a 16:9 DAR. Strangely, setting the TextBox top and bottom values to 200 produced exactly the same output, and setting them to 100 produced text that was at the bottom but about 1/3rd of the way from the left edge, and the horizontal limits had been squeezed so it ended up split into 3-4 short lines. Is this something Gabest is still working on, or is there an error in the code I'm feeding it? [Edit] (BTW, the translation_x and translation_y fields appear not to play any role at all atm - if I set them to 0 the position is unaltered.)

TBH many of the features of TTXT like blinking, karaoke, highlighting, scrolling and hyperlinks are just fluff (IMO :) ), though probably worth implementing later. Styles and colours are really useful though, and font-switching would be a real bonus.

bond

14th November 2005, 15:09

Elias

14th November 2005, 15:16

charleski, lots of stuff has been fixed on ttxt yesterday not yet in the build posted by elias

but i can confirm most should be working now :)Life is sweet, and so is Gabest :D

charleski

26th November 2005, 17:13

Any further updates on the timed-text positioning issue? Since MPC seems to be the only .mp4 player that aims to handle this stream correctly I'm eager :).

JoeBG

26th November 2005, 17:18

Any further updates on the timed-text positioning issue? Since MPC seems to be the only .mp4 player that aims to handle this stream correctly I'm eager :).

ZoomPlayer does it very good

bond

26th November 2005, 17:42

Any further updates on the timed-text positioning issue?text positioning is supported by gabest in his mp4splitter+vsfilter in any directshow player, not just zoomplayer or some specific players

Since MPC seems to be the only .mp4 player that aims to handle this stream correctly I'm eager :). thats wrong. quicktime and osmo4 can do this too correctly

about your sample

<TextStreamHeader width="176" height="30" translation_x="352" translation_y="540">defines a big mainbox where all your subs can be displayed
in your case the box is only 176x30 big

it is moved to the right by 352, which means, assuming that you want the mainbox to be placed in the middle horizontally, with a 176 width mainbox, that the video has to be 880 width which is wrong (assuming that you dont want the mainbox to be bigger horizontally than the video)

<TextSampleDescription ... ">
<TextBox top="300" left="300" bottom="30" right="176"/>the textbox inside the textsampledescription defines again something like a box that is placed inside the mainbox (defined in the textstreamheader)
the reason for this is that you can have multiple textboxes for one ttxt stream. this way its possible for you to display different sublines of the same stream on different positions
this also means that the textbox size cant be bigger than the textstreamheader size

for the positioning you can have a look at this example:
<?xml version="1.0" encoding="UTF-8" ?>

<TextStream version="1.0">
<TextStreamHeader width="176" height="174" layer="65535" translation_x="0" translation_y="0">
<TextSampleDescription horizontalJustification="left" verticalJustification="top" backColor="ff ff ff ff" verticalText="no" fillTextRegion="no" continuousKaraoke="no" scroll="None">
<FontTable>
<FontTableEntry fontName="Serif" fontID="0"/>
</FontTable>
<TextBox top="144" left="0" bottom="174" right="176"/>
<Style styles="Normal" fontID="0" fontSize="12" color="0 0 ff ff"/>
</TextSampleDescription>
</TextStreamHeader>
<TextSample sampleTime="00:00:00.000" text="'This is demonstration No8'">
</TextSample>
<TextSample sampleTime="00:00:03.000" text="'1. text-box is located ''below the video.'">
</TextSample>
<TextSample sampleTime="00:00:08.000" text="'2. text-box is located at'' the top of the video.'">
<TextBox top="0" left="0" bottom="30" right="176"/>
</TextSample>
<TextSample sampleTime="00:00:13.000" text="'3. text-box is located at'' the center of the video.'">
<TextBox top="57" left="0" bottom="87" right="176"/>
</TextSample>
<TextSample sampleTime="00:00:18.000" text="'4. text-box is located at'' the bottom of the video.'">
<TextBox top="114" left="0" bottom="144" right="176"/>
</TextSample>
<TextSample sampleTime="00:00:23.000" text="'End of demonstration No8'">
</TextSample>
<TextSample sampleTime="00:00:26.000" text="" />
</TextStream>
which shows you examples how to move subs of a 176x144 video stream

of course you can also have subs below the video easier by simply changing
<TextBox top="144" left="0" bottom="174" right="176"/>to
<TextBox top="0" left="0" bottom="0" right="0"/> and setting verticalJustification="bottom"
in that case the textbox = mainbox (the mainbox is 176x174, the video is 176x144, so the mainbox is bigger than the video vertically and the subs are displayed at the bottom, so under the video)

another way would be to give the mainbox the same size as the video (176x144), but move the mainbox below the video by using translation_y

this would be than
<TextStreamHeader width="176" height="144" translation_x="0" translation_y="30">which moves the mainbox down by 30, so the bottom part of the mainbox is below the video

split to where it belongs

Zero1

26th November 2005, 21:44

What about text outline? I didn't see anything obvious in the samples (unless I wasn't paying enough attention), so I wonder if this is something the decoder should add, or should be specified in the ttxt.

charleski

27th November 2005, 01:17

<TextStreamHeader width="176" height="30" translation_x="352" translation_y="540">defines a big mainbox where all your subs can be displayed
in your case the box is only 176x30 big

it is moved to the right by 352, which means, assuming that you want the mainbox to be placed in the middle horizontally, with a 176 width mainbox, that the video has to be 880 width which is wrong (assuming that you dont want the mainbox to be bigger horizontally than the video)
Ok, hang on here. I was going by the GPAC document I cited, which i assume is correct. In it they state:Text Position: in a 3GPP text stream, the text may be drawn in a given rectangle within the stream main display rectangle. This is known as the TextBox in 3GPP.
...
TextStreamHeader
...
translation_x : defines text stream horizontal translation in main display in pixels
...
TextBox
...
top : specifies vertical offset from stream main display rectangle top edge
(emphasis mine).
Now, that does seem to be quite explicit, that these values shift the text box containing the subtitles within the main display, which is obviously much bigger, say 720x576. So the code from the 1st paragraph above would define a main Text Stream box 176 pixels wide and 30 pixels high that is positioned 352 pixels from the left edge of the display and 540 pixels from the top edge. Such a box would clearly fit inside a 720x576 main display frame.

the textbox inside the textsampledescription defines again something like a box that is placed inside the mainbox (defined in the textstreamheader)
the reason for this is that you can have multiple textboxes for one ttxt stream. this way its possible for you to display different sublines of the same stream on different positions
this also means that the textbox size cant be bigger than the textstreamheader size
Well, this is one area where the GPAC document is confusing. they state:
Text Box: specifies a temporary box where this text sample is displayed.Which I interpreted as meaning that specifying a TextBox field for an individual TextSample just shifts the positioning and clipping box used for the associated sample. But they also say later on:The TextBox element specifies where the text should be drawn within the stream main display rectangle. If the text box is not found or empty, the entire display rectangle will be used for the default text box.Huh? It doesn't just default back to the box defined in the TextStreamHeader? Also, if you can use individual TextBox fields in each TextSample description to shift individual subtitles, why does the TextStreamHeader has a TextBox field at all? It appears to serve no purpose.

I suspect there are some translation problems with the GPAC document, as for instance in the following:bottom : specifies vertical extend of the text boxThey probably meant 'extent', ie height, since 'extend' is a verb and thus has no meaning in that context, but it would be nice to be sure, as it's possible they were trying to convey a completely different meaning.

for the positioning you can have a look at this example:
...
which shows you examples how to move subs of a 176x144 video stream

Yeah, I have Demo No 8 compiled into a test .mp4, but of course the video frame is a lot larger. I'll run some more tests with different numbers.

of course you can also have subs below the video easier by simply changing
<TextBox top="144" left="0" bottom="174" right="176"/>to
<TextBox top="0" left="0" bottom="0" right="0"/> and setting verticalJustification="bottom"
in that case the textbox = mainbox (the mainbox is 176x174, the video is 176x144, so the mainbox is bigger than the video vertically and the subs are displayed at the bottom, so under the video)Why are you defining a TextBox with 0 height and 0 width there?

I suppose I should hunt through the industry MPEG4 and 3GPP documents to see if there's an official spec lying around.

quicktime and osmo4 can do this too correctlyI can't believe you're seriously regarding quicktime as an .mp4 player :p. Osmo4 can render all the streams, but it's very clearly designed merely as a demonstration piece.

[Edit]Btw, I installed the latest vsfilter and mp4filter, and nope, gabest's latest releases still have problems. I have a set of test .mp4 files using video encoded by x264, aac audio from Nero aac and muxed through mp4box. The subtitle streams are the demonstration files from GPAC muxed into the .mp4 through YAMB 1.3.1 (ie mp4box again).

Gabest's mp4splitter recognises the GPAC TTEXT stream, but doesn't load vsfilter to handle it. If I force vsfilter to always load, it hooks up its XFORM input to ffdshow's video output, but won't handle the text output from the splitter. If I analyse the file in graphedit, neither the GPAC Streaming Text Handler nor GPAC Streaming Text Handler (plain text) outputs of MP4 Splitter will connect to either input pin of DirectVobSub.

MPC does render the subtitles, as before, but they now appear in a white rectangle instead of having a transparent background, so it's actually worse.
Strangely, and this is a problem with 6.4.8.6 too, selecting an mp4 file in explorer and clicking Open With, then selecting MPC leads to it failing to recognise the subtitle stream properly and it is displayed as plain text without any positioning or style attributes.

Has anyone here actually authored and muxed their own subtitles into an mp4, and if so what steps did they take? I have a file that I'm sure I downloaded from this forum that's a snippet of Tron with German and English GPAC Stream subtitles in it (1Video_2Audio_2SUBs_timed_text_streams_.mp4), if the author of that file is reading, could you post the .ttxt file you used? Unfortunately it doesn't contain any style variants, but it would be useful to check.

BTW, I had a look at Apple's Quicktime 3GP subtitle specs (http://developer.apple.com/documentation/QuickTime/QT6_3/Chap1/chapter_1_section_1.html#//apple_ref/doc/uid/TP40000938-DontLinkChapterID_1) and they differ in subtle, yet important ways from the documentation given on the GPAC site. Given that GPAC is basically just 2 guys in France who decided to write some programs, I'm wondering whether I should bite the bullet and investigate using QT as a subtitle muxer instead.

bond

27th November 2005, 04:33

@zero1: ttxt simply doesnt know outlining. this doesnt mean that a ttxt decoder cant let the user place outlining around the text (mpc allows you to do that)
also you can place the subs below the video, so there is no need for outlining

@charleski
i have to admit i was too lazy to read what you wrote :p
all i can say is that the sample i posted was taken from the 3gp test sample suite which is surely correct...
also all the alternatives i wrote where tested in qt7, osmo4 and vsfilter (and as they make sense logically) i think they are correct too
so if you want to do things differently, do so, but dont be surprised if it doesnt work out...
also make sure to read the official mpeg-4/3gpp specs (which are freely available) and not some apple/gpac docs if you think you know things better ;)

apart from that mp4box also supports the ttxt file format defined by apple and not just its own .ttxt format (the 3gpp/mpeg-4 specs dont define a text file format for "raw" ttxt)

charleski

27th November 2005, 05:55

@charleski
i have to admit i was too lazy to read what you wrote :p
... Geez
all i can say is that the sample i posted was taken from the 3gp test sample suite which is surely correct...Where did you get this sample? I have the demonstration files from the GPAC site as well, but GPAC is just 2 guys writing some programs - they don't represent any official standards organisation and it is entirely wrong to thing that they do.
also all the alternatives i wrote where tested in qt7, osmo4 and vsfilter (and as they make sense logically) i think they are correct tooI don't understand what you mean by this. Quicktime's format for timed text is different to GPAC's. That's clear on even the most basic scan of the documents. Are you saying that you managed to mux the same .ttext file into an .mp4 with both mp4box and a quicktime muxer?
Compare QT XML (http://developer.apple.com/documentation/QuickTime/QT6_3/Chap1/chapter_1_section_33.html#//apple_ref/doc/uid/TP40000938-DontLinkChapterID_1-TPXREF170) to one of the examples from the GPAC site, they have a very different syntax.

so if you want to do things differently, do so, but dont be surprised if it doesnt work out...No, that won't do at all. There's a problem here, and we need to face up to it rather than waving hands and pretending. The GPAC .ttxt specification is one possible method of converting XML into the binary stream needed for timed text presentation in .mp4 files. Quicktime provides another method, but are there others?

I think you should perhaps come back to this problem and think about it further when you're ready to look at it in more depth.
also make sure to read the official mpeg-4/3gpp specs (which are freely available) and not some apple/gpac docs if you think you know things better ;)Yeah... Can you post a link to some categoricalMPEG-4 Part 17 specs? I've managed to find some general binary format specifications for the BIFS, but that seems to be all that's publicly available. In fact, I get the feeling that this part of the standard hasn't really been fully formulated yet.
apart from that mp4box also supports the ttxt file format defined by apple and not just its own .ttxt format (the 3gpp/mpeg-4 specs dont define a text file format for "raw" ttxt)
So I might have more luck using the more precisely-defined documents from Apple? Will mp4box accept an XML file formatted according to Apple's specification (which is different to that on the GPAC site)? That would be worth a go, but have you tried this, or is this just a suggestion?

Look, if the tools for Mpeg-4 Part 17 subtitles haven't been fully developed yet, that's fine, but we need to know that so we can go out and make them. There's no use pretending that we have a working solution if it's not real.

bond

27th November 2005, 06:27

edit:

Ok, hang on here. I was going by the GPAC document I cited, which i assume is correct. In it they state:
(emphasis mine).
Now, that does seem to be quite explicit, that these values shift the text box containing the subtitles within the main display, which is obviously much bigger, say 720x576. So the code from the 1st paragraph above would define a main Text Stream box 176 pixels wide and 30 pixels high that is positioned 352 pixels from the left edge of the display and 540 pixels from the top edge. Such a box would clearly fit inside a 720x576 main display frame.yeah of course it fits, but its not placed in the middle of the video. i assume you want it to be in the middle

It doesn't just default back to the box defined in the TextStreamHeader?you are confusing the term "entire display rectangle ". you have to understand that the ttxt stream is totally independant of the video, eg you can also have ttxt without video
entire display rectangle refers to the rectangle defined in the textstreamheader

Also, if you can use individual TextBox fields in each TextSample description to shift individual subtitles, why does the TextStreamHeader has a TextBox field at all? It appears to serve no purpose.?it serves the purpose to not have the user to repeat the textbox over and over again for every text sample, but define it only once

Why are you defining a TextBox with 0 height and 0 width there? 0 means "use the values of the mainbox" for width and heigt obviously

[Edit]Btw, I installed the latest vsfilter and mp4filter, and nope, gabest's latest releases still have problems. I have a set of test .mp4 files using video encoded by x264, aac audio from Nero aac and muxed through mp4box. The subtitle streams are the demonstration files from GPAC muxed into the .mp4 through YAMB 1.3.1 (ie mp4box again).

Gabest's mp4splitter recognises the GPAC TTEXT stream, but doesn't load vsfilter to handle it. If I force vsfilter to always load, it hooks up its XFORM input to ffdshow's video output, but won't handle the text output from the splitter. If I analyse the file in graphedit, neither the GPAC Streaming Text Handler nor GPAC Streaming Text Handler (plain text) outputs of MP4 Splitter will connect to either input pin of DirectVobSub.

MPC does render the subtitles, as before, but they now appear in a white rectangle instead of having a transparent background, so it's actually worse.
Strangely, and this is a problem with 6.4.8.6 too, selecting an mp4 file in explorer and clicking Open With, then selecting MPC leads to it failing to recognise the subtitle stream properly and it is displayed as plain text without any positioning or style attributes. upload a small file showing this somewhere

Has anyone here actually authored and muxed their own subtitles into an mp4, and if so what steps did they take? yes, i have been able to create lots of mp4 files with ttxt streams with mp4box using as good as all ttxt features, which played perfectly fine in osmo4, qt7 and with gabests stuff

I have a file that I'm sure I downloaded from this forum that's a snippet of Tron with German and English GPAC Stream subtitles in it (1Video_2Audio_2SUBs_timed_text_streams_.mp4), if the author of that file is reading, could you post the .ttxt file you used? Unfortunately it doesn't contain any style variants, but it would be useful to check.mp4box of course can extract to .ttxt, so you dont need the original one

Where did you get this sample? I have the demonstration files from the GPAC site as well, but GPAC is just 2 guys writing some programs - they don't represent any official standards organisation and it is entirely wrong to thing that they do. i cant stand you downgrading the gpac devs great work by saying things like "just 2 guys writing some programs". if you find a bug than make a normal bug report and upload a sample showing it but dont write some wierd stuff with wild claims and flames downgrading other peoples work. if you think you can do it better you are welcome to write your own ttxt creation tool...
as i said i dont have a problem with mp4box

BTW, I had a look at Apple's Quicktime 3GP subtitle specs (http://developer.apple.com/documentation/QuickTime/QT6_3/Chap1/chapter_1_section_1.html#//apple_ref/doc/uid/TP40000938-DontLinkChapterID_1) and they differ in subtle, yet important ways from the documentation given on the GPAC site. Given that GPAC is basically just 2 guys in France who decided to write some programs, I'm wondering whether I should bite the bullet and investigate using QT as a subtitle muxer instead.

I don't understand what you mean by this. Quicktime's format for timed text is different to GPAC's. That's clear on even the most basic scan of the documents. Are you saying that you managed to mux the same .ttext file into an .mp4 with both mp4box and a quicktime muxer?
Compare QT XML (http://developer.apple.com/documentation/QuickTime/QT6_3/Chap1/chapter_1_section_33.html#//apple_ref/doc/uid/TP40000938-DontLinkChapterID_1-TPXREF170) to one of the examples from the GPAC site, they have a very different syntax.

No, that won't do at all. There's a problem here, and we need to face up to it rather than waving hands and pretending. The GPAC .ttxt specification is one possible method of converting XML into the binary stream needed for timed text presentation in .mp4 files. Quicktime provides another method, but are there others?inform yourself before you make wild claims
the 3gpp/mpeg-4 specs define how ttxt has to look like when being placed in .mp4 and .3gp, NOT how ttxt has to look like in "text form"

so for representing ttxt in text form apple invented its own format and gpac invented its own format (tough mp4box supports apples format too). still when being placed in mp4/3gp the stream will be in exactly the same way spec compliant, so its perfectly fine to use both...

if you think mp4box does anything wrong and was written by clueless people, have fun with quicktime...

I think you should perhaps come back to this problem and think about it further when you're ready to look at it in more depth. lol, better inform yourself before you make wild claims and accuse other people of being clueless...

Yeah... Can you post a link to some categoricalMPEG-4 Part 17 specs? I've managed to find some general binary format specifications for the BIFS, but that seems to be all that's publicly available. In fact, I get the feeling that this part of the standard hasn't really been fully formulated yet. ah you get this feeling...
obviously you are smarter than the experts of 3gpp and mpeg, maybe you can help them "formulating this part of the standard"...
inform yourself before making wild claims

google is your friend... the ttxt specs are available here (http://www.3gpp.org/ftp/Specs/html-info/26245.htm)

So I might have more luck using the more precisely-defined documents from Apple? Will mp4box accept an XML file formatted according to Apple's specification (which is different to that on the GPAC site)? That would be worth a go, but have you tried this, or is this just a suggestion?didnt i already answer this?

Look, if the tools for Mpeg-4 Part 17 subtitles haven't been fully developed yet, that's fine, but we need to know that so we can go out and make them. There's no use pretending that we have a working solution if it's not real. inform yourself before you make wild claims

that said back to the original topic: i have already pointed out how things are handled with positioning and i have nothing to add to it, also i pointed out three ways of how to place subs below video, if you think that you can ignore them or if you dont manage to use them the problem seems to be on your side and you wont fix it by insulting other peoples great work

charleski

27th November 2005, 19:00

Well bond, I didn't bother reading your whole post either. But I'm more interested in finding the answers to this problem.

In case anyone else is struggling with this as well and wants to get subtitles working, here's what I've worked out:
As I feared, there are quite a few problems with the XML specification on the GPAC site, probably because of language difficulties. Unfortunately poor translation can be quite devasting.

Unfortunately the same file will play differently in Osmo4 (0.4.0) and MPC (6.4.8.7), which makes testing the various parameters difficult. Osmo4 obviously has difficulties: if you stop a video and then restart it, the position of the subtitles will shift under certain circumstances. MPC is still clearly a work-in-progress as Gabest adds the new features, but it does operate consistently.

All my tests were conducted using mp4box (0.4.1) to mux ttxt files:
mp4box testbase.mp4 -add test.ttxt -out test.mp4

As far as positioning goes, the critical points are covered by this image from the 3gpp 26.245 specification:
http://homepages.nildram.co.uk/~cajking/3gppTTEXTPos.JPG
In the case where the video track takes up the whole of the display frame which is the majority of applications, you basically you have 3 rectangles to consider:

1) the main video frame - this has the dimensions of your video track after the 'SAR' transform has been applied. For example, if your input video is 704x560 with a 'SAR' of 14:10, the main video frame has dimensions of 986x560 (obviously there has to be some rounding here).

2) the TextTrack rectangle. This is defined in the TextStreamHeader field. The width and height are specified directly in the 'width' and height' fields. The position of this rectangle is defined by a translation matrix which includes translation parameters that define the offset from the top left corner of the main video frame. The matrix is just there for special handling on other tracks, and for video it can be disregarded (ie it's a unity matrix). The terms that we need to worry about are the translation_x and translation_y fields, which are the horizontal and vertical offsets respectively. The simplest way to deal with this set of parameters is just to set the TextTrack to cover the whole frame.
So, for the example video frame in 1), we set the following:
<TextStreamHeader width="986" height="560" layer="65535" translation_x="0" translation_y="0">
Note that this is the part where Osmo4 and MPC seem to part company. Osmo4 doesn't seem to interperet the width value correctly, but you should
be safe by just setting it to the transformed width of your video frame
.
3) The TextBox rectangle. This is where the GPAC spec goes wrong. As you can see from the picture, this is actually another box inside the TextTrack rectangle. You have to specify this box, it's not optional. The TextBox has 4 fields, which correspond to the x and y position of the top left corner of the box ('left' and 'top' respectively) and the x and y position of the bottom right corner ('right' and 'bottom' ). These values are offsets from the top left corner of the TextTrack rectangle.
So, to go back to our example: you want to display subtitles in a strip 60 pixels high across the bottom of your video. So you set the fields to the following values:
<TextBox top="500" left="0" bottom="560" right="986"/>

So your final TextStreamHeader goes as follows:
<TextStreamHeader width="986" height="560" layer="65535" translation_x="0" translation_y="0">
<TextSampleDescription horizontalJustification="left" verticalJustification="top" backColor="ff ff ff 00" verticalText="no" fillTextRegion="no" continuousKaraoke="no" scroll="None">
<FontTable>
<FontTableEntry fontName="Serif" fontID="0"/>
</FontTable>
<TextBox top="500" left="0" bottom="560" right="986"/>
<Style styles="Normal" fontSize="24" color="0 0 ff ff"/>
</TextSampleDescription>
</TextStreamHeader>
If you want to move individual subtitles, you can specify a TextBox inside the TextSample to override the default, as described in the GPAC spec.

Beware though, at present MPC and Osmo4 interperet the TextBox differently. As far as I can make out, MPC seems to be referencing the TextBox values to the untransformed video frame (ie, without taking into account any 'SAR' aspect ratio transform).
The following 2 pictures show the same frame from the same file rendered with Osmo4 and MPC:
MPC:http://homepages.nildram.co.uk/~cajking/MPC_BR.jpg
Osmo4: http://homepages.nildram.co.uk/~cajking/Osmo4_BR.jpg (This also shows the rather ugly anti-aliasing that Osmo4 uses, but tastes differ.)
The code used for the subtitle shown was <TextSample sampleTime="00:00:18.000" text="'4. bottom-right of the video 2bottom-right of the video 3bottom-right of the video 4bottom-right of the video 5bottom-right of the video 6bottom-right of the video bottom-right of the video '">
<TextBox top="480" left="400" bottom="540" right="704"/>
</TextSample>

So, to sum up: if all you want is to display a strip of subtitles across the bottom of your video, the current solutions appear to work, use the examples given and adjust to your input video size (change horizontalJustification to 'center' for centred subs). If you want to perform fancier effects on a real high-quality video stream (rather than a sample demostration piece), then you have problems, as the current state-of-the-art is not quite up to the task.

Another alternative is to use the XML spec given by Apple (http://developer.apple.com/documentation/QuickTime/QT6_3/Chap1/chapter_1_section_1.html#//apple_ref/doc/uid/TP40000938-DontLinkChapterID_1), which has a different syntax mp4box claims to support. I haven't tested this fully yet.

One important question is whether subtitles used in this way will be useable in future commercial offerings. As far as standards go, we're talking about MPEG-4 part 17, though the MPEG-4 standard includes other ways of presenting 2D material. The 3GPP 26.245 standard is included in Part 17 according to N7515 (http://www.chiariglione.org/mpeg/technologies/mp04-stf/), but it also refers to 'Future Timed Text Formats'. As Apple (who have a fair amount of clout) have adopted the 3GPP standard into Quicktime, there's a good chance it'll be used.

[edit] fixed a co-ordinates transposition

bond

27th November 2005, 20:25

if you think there is a bug in mp4box make a bug report on the gpac bug tracker

charleski

1st December 2005, 04:12

It looks like this is a rendering problem.

Mp4box seems to be muxing the ttext in correctly, as I can export it from QuickTime and the resulting TeXML file has the correct numbers.
While Osmo4's behaviour is inconsistent, it seems to be doing the rendering correctly when the file is first run, incorporating the proper aspect ratio transform.

As the MPEG-4 Part 17 (http://www.chiariglione.org/mpeg/working_documents/mpeg-04/streaming_text/streaming_text.zip) spec says, "For each text stream, the size of the Text Box shall be defined in the decoderConfiguration, textConfig, in units of square pixels." so the positioning produced by Osmo4 in the screencaps above is the right one, and MPC isn't taking the aspect ratio into account. Since a large number of .mp4 encodes are going to be anamorphic (that's one of the benefits of the format), this is a fairly important issue.