XCD development

[raistlin2k]

@Koepi
I thought about the modifications in Oggmux again, I really hope you will add the iso639-feature. If you do, I guess, it would be best to show in the combo-box (perhaps named "Player internal")not short-terms but the real-name in English, since this is a language everybody understands.

@kxy
Well, if we arrange it that the correct subtitle (containing translations) gets asigned to the right audio-stream, this will be done for all CDs of a XCD-set for sure, there is no need to set an extra-switch, I guess.

@Toff
Any idea, how we can arrange this with the different sub-types, or how to define that one audio & one sub should be used together by default?

About the [L=%iso], how about this:
]L=%iso%[
[P=%Nr%]
{B=%nr%}

I know that DVD2AVI drops frames,that's why I used old flask for that because it works accurate, but you have to search the start-&end-frames for yourself, hard job, that's where vstrip (or something like that) could really help by splitting the parts, so that every transcoder can convert the parts and at the end we re-arrange them into one file!

Raist

[[Toff]]

I know that DVD2AVI drops frames,that's why I used old flask for that because it works accurate, but you have to search the start-&end-frames for yourself, hard job, that's where vstrip (or something like that) could really help by splitting the parts, so that every transcoder can convert the parts and at the end we re-arrange them into one file!


Even when you split the vob, DVD2AVI can't be used to encode each part, it still drop frame.
It's bad because I love DVD2AVI :)
And when you encode splited part separately you doesn't have the benefits of 2 pass encoding. But the great thing is that all pages start with a key frame.

ATM, my tool create a .lst file with the list of splitted VOB to encode.
The page start & end frame are extracted from the ifo which give the duration of each cell in the menu.
It also create a file with a list of frame to be forced key frame.


About the [L=%iso], how about this:
]L=%iso%[
[P=%Nr%]
{B=%nr%}

I will prefer :
[[L=%iso%]]
[P=%nr%]
[B=%nr%]
So you minimize the number of control character used for parsing.

About subtitles no idea ATM.

[raistlin2k]

Do you have a DVD offering such subs only for translations? Could you check the ifo-file to find out how the player knows that this is a sub that shall be used by default?

Perhaps we should extend sub-streams iso639 following way (by offering an additional combo-box in oggmux; sorry, koepi):
2. Audio "English" (en)
3. Audio "Deutsch" (de)
4. Subtitle "English" (en[t])
5. Subtitle "Deutsch" (de[t])
[t] means translation, [n] means numb, so player should change sub to 4, when audio is switched to 2, and to 5 when audio is 3.


[[L]] is ok, already done.

the thing with the key-frames is the point why I want to split the vob, because for example I copied the menu of Star Wars Episode I, there are some pages that look quite similar, so that no keyfvrame was generated at the beginning of a new page, so jump to the start-frame didn't work dince it was no keyframe.

Raist

[Blight]

Ok, I'm here, I don't have the strength and time to read through all this thread as it keeps changing and debating, so ...

Ask me specific design questions and I'll do my best to reply. And DON'T use acronyms.

[raistlin2k]

Thanks Blight for joining in so quickly.

About highlighting, you have the bitmap mask for all buttons on the same page, and for each button you have an highlighting color defined in a table. Also I think you can do different effect type with this mask, you can fill it with a solid color, or do some alphablending effect.

IMHO the easiest way for the player would be to have 1 bitmap for each button. This bitmap can be extracted from the full page bitmap by using button coordinate. You can even make a comparison to eliminate identical button bitmap so you can save space when you have a lot of button with the same shape.
When you enter in a button zone, the player will have to read the button bitmap, resize it to the button zone size and do is graphical operation.


That's the question, Toff & me are unsure and wanted to ask you how it can be done. It's no good to define a spec that is very hard to support in a player that's why we want to do it the other way round, you tell us how you can support it easily and we define the specs that way.

Thanks for your help
Raist

[Blight]

I'm not sure what you're referring to by "button zones".

There shouldn't be a problem highlighting a button with a color by using Alpha Blending. I don't think you'd want to stretch a button graphics as the result would look ugly (since we're dealing with software not hardware scalers). Sure, you can scale every bitmap using biliniar scalers, but it'll make the interface sluggish somewhat.

It can of course be optional and taken care of by the player itself.

[[Toff]]

The menu is composed of a video and a script :

[P1]
Frames=592-1298
[B1]
Pos=327,317-577,352
[B2]
Pos=327,356-577,391
[B3]
Pos=327,395-577,430
[B4]
Pos=327,436-577,471

The script is divided in pages defined by a start_frame and an end_frame in the video, and each page can have several button defined by 2 points (top-left-corner,right-bottom-corner) in the orginal video size.

On DVD when you place your mouse on a button it can be highlighted. This information is stored for each page in one bitmap mask that can be extracted with subrip.
Here is an example :
Video : http://christophe.paris.free.fr/temp/matrix_menu.jpg
Mask : http://christophe.paris.free.fr/temp/matrix_menu_mask.png

We are asking ourself what is the easiest way for a player to support button highlighting.
Is it better to extract each mask button ? or keep the full page bitmap ?
Resizing is needed because the video is not always diplayed in it's original size. But the resizing is made on the mask so the quality is not important.

@raistlin2k
If we want to support this we may have to add an highligting color to the button. And maybe the operation to do (alpha blending, fill solid color, ...). We go into small details here.

There is something we have forgotten. The possibility to show a stills during a defined number of second. I think it's used on DVD for slideshow.

About "subs only for translations", I think it's called close-captioning and there is a thread about it in the subtitles forum.
I must read it ;)

[Blight]

This sounds bad.

Not all decoders support frame accurate seeking, not all decoders allow seeking while paused, you can't do frame-accurate looping of frame ranges without incurring quite a bit of CPU usage.

What do you mean by the mask can be ripped using sub-rip? You mean the DVD mask, or does the player need to somehow get a bitmap from the video stream itself?! This is not a practical method as inserting the SampleGrabber filter breaks overlay support.

You want the highlight to work on a playing video? This will require a special filter to be written and communicated to at all times! (what DVD Navigator does).

While this may be easy for porting DVD Menus, it's A BITCH to implement within a player as you'd basically have to write the entire DVD Navigator interface filter.

And unless you write it, and make it as accessible as the DVD Navigator filter, I personally will not support this.

I don't even think you can do it on a level of the DVD Navigator as the entire assumption when dealing with media files is different.

[raistlin2k]

Not all decoders support frame accurate seeking, not all decoders allow seeking while paused, you can't do frame-accurate looping of frame ranges without incurring quite a bit of CPU usage.

What do you mean? That it will not be possible? Old microDVD player was capable of doing so, we only had to provide that every frame-range starts with a key-frame. You don't think it will work?

Mask ripping with sub-rip is done on authoring site (extracting mask from a DVD), but how shall the mask be saved, as jpeg or as a frame inside of the menu-file.

To be honest, I'm not very good in specs of DVD, perhaps Toff can help with the highlight problem on playing video.
Otherwise, I think, we have to drop the idea of highlighting buttons.:(

Or are you, Blight, aware of another solution for this problem?

@[Toff] about still-period
Frame=x-y
When x=y > Still, additional line below:
Duration=%sec%

OK?

Raist

[Blight]

Any modification of the video stream is problematic, some content (MPEG2 using the WinDVD decoder for example) will NOT allow you to do it at all!

DivX 5.02 doesn't update the video image if you seek while paused.

If the user pauses the video, menu won't work anymore.

Basically you seem to be trying to define a standard without any experience with the actual process of what you're trying to achieve. Which is bad.

[raistlin2k]

Why PAUSE?

on a real DVD, menu can't be paused by the user, so why should he be able to do so on XCD?

I can't really follow you.

Raist

[[Toff]]

about highligting:
It's a small feature and it's hard to implement. So we can make it an option. If a player want to support it, it's possible to associate each button to a bitmap stored in a directory.
[P1]
Frames=592-1298
[B]{P1B1.bmp}
Pos=327,317-577,352
[B]{P1B2.bmp}
Pos=327,356-577,391
[B]{P1B3.bmp}
Pos=327,395-577,430
[B]{P1B4.bmp}
Pos=327,436-577,471
So there is nothing to put in the menu script, there is a direct relation between image name and button id.

Or we can add highlightmask, highlightcolor has optional line.
highlightmask=P1B1.bmp
highlightcolor=00AA99FF {first 00 for effect, 00 : fill, 01 : 50% transparency , ...}
I think it will be easier to do in DirectX9.


about frame accurate seeking:
Yes it can be a problem. We will have to use a correct decoders.
I will try to do some testing but there is a lot of thing to test so it can take some times.
In the worst case we can try to modify the ffdshow filter.


about still-period:
Duration=%sec%
Ok, and %sec% == 0 mean infinite time.

[raistlin2k]

About Highlighting & multi-language-menus

Are the buttons (and so the masks) always at the same position for all languages on a DVD, can we be sure about this? If so, we can use mask P1B1.bmp for button1 on every page1 in each language (& save space:)), but IF NOT, we have to change name to L1P1B1.bmp!

So we'll save each masks as one bmp & not whole page-mask at once.
Since I'm not very experienced with Subrip, is there a way to let it split the page into different bmps using ifo-info. All I know is that it uses ifo for language-showing of the sub-rips.

If Subrip doesn't support this, I will try to contact author & ask him if he can add this. Or are you, Toff, aware of another way?

Raist

[[Toff]]

Yes, I forgot language, L1P1B1.bmp is better.


So we'll save each masks as one bmp & not whole page-mask at once.

I think it will be easier for a future hypothetical support.


is there a way to let it split the page into different bmps using ifo-info

I don't think so.


If Subrip doesn't support this, I will try to contact author & ask him if he can add this. Or are you, Toff, aware of another way?

No I don't know other way. Or I must do it myself :)
That's not a priority.

about frame accurate seeking:
The Ogg DirectShow filter seek very well on KF.

[raistlin2k]

@Toff

Please visit this posting:
http://forum.doom9.org/showthread.php?threadid=29317&goto=newpost
It seems that OGM already offers such a standard for selecting default language. Please have a look at it, perhaps we can leave ISO639 & switch to LCID, would mean less work for Tobias & Koepi.

I already mailed Tobias, that all we would need is an additional string showing the personal string like "Francais", while "French" is used for LCID-identification by the player.

You can also have a look at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dx8_c/directx_cpp/htm/workingwithlcidsscript.asp

This is the link to the LCID-codes.

I think your highlight-mask-string is really not needed if we use standard-names for the masks (hopefully, SubRip can extract them directly in future versions:p) , but How about the highlight-color?
Do you really think this is only optional, but not obligatory?

I'm really happy, seems that specs are almost finished, just the thing with highlight-color & LCID vs. ISO639, we'll see!

Again, thanks for all help
Raist

[[Toff]]

It seems that OGM already offers such a standard for selecting default language. Please have a look at it, perhaps we can leave ISO639 & switch to LCID, would mean less work for Tobias & Koepi.

I already mailed Tobias, that all we would need is an additional string showing the personal string like "Francais", while "French" is used for LCID-identification by the player.

If we can get all the info we need with this I see no problem.
But how to differenciate French from French director's comments ?

Extra info available on DVD for subtitles :
not specified, normal, large, children, normal captions, large captions, childrens captions, forced, director comments, large director comments, director comments for children
Extra info available on DVD for audio :
not specified, normal, for visually impaired, director comments, alternate director comments


But How about the highlight-color? Do you really think this is only optional, but not obligatory?

You can make it optional for player who don't want to support button highlighting.
Or the player can just ignore it (maybe easier).

Something new :
If you want to play extra, an action to play another file would be great.
Action1=9(extra1.ogm)
Or where are stored infos about extra feature ?

[raistlin2k]

Tobias offered to support both, LCID & ISO639 that way, that filter translates all ISO639 inside of OGMs into LCID for the player, very nice,although I'm not quite sure if we really need then the iso-codes. It would be just to comply with all standards, but since only LCID is given to the player, I don't see a real advantage in using both, just confusing for the home-user and work for Tobias & koepi.

About the additional info about streams (commentary / caption):
Like in LCID, there is no spec for that in ISO630, is it? So there is again no advantage of ISO639 over LCID??

So we need a new ID additionally to LCID, I guess?
Tobias offered to integrate it like that:
Español[spa][C]

But now we need an interface to communicate with the player, any idea, Toff? Tobias wrote he will think about it, bur perhaps we can help him anyway since he is already doing a lot for us.

Raist

[[Toff]]

I see no problem using LCID if it's easier.
If I need iso639, conversion are quite easy to do.

But how you use LCID ? with the code or the string ?
"French" or "0x040c"
If you use the string, user will be tempted to make typo error ;)


Like in LCID, there is no spec for that in ISO630, is it? So there is again no advantage of ISO639 over LCID??

no advantage here.



So we need a new ID additionally to LCID, I guess?

Yes


Tobias offered to integrate it like that:
Español[spa][C]

I suppose it's :
user definable string[iso639-2_code][language_extension_code]
It's sounds great to me.
Also there is a lot of code in iso639-2 ! Using iso639-1 maybe easier.
how language_extension_code is defined ?



But now we need an interface to communicate with the player, any idea, Toff? Tobias wrote he will think about it, bur perhaps we can help him anyway since he is already doing a lot for us.

I'm not a DirectShow expert, and I have no idea :(

[raistlin2k]

I think that the drop-down list of languages offered in OggDS (or OggMux) is already the LCID-one. So user has to choose from a drop-down-list the LCID, Tobias will add an additional field for the user definable-string, that's all, so no problem with type error!

I don't know if it's ISO639-2 or -1, depends again on Tobias. Altough I guess it might get somehow complicate to offer both, iso & LCID, how shall these be arranged in the combo-box? Do we really need two possible eg "English" in the drop-down, one with LCID & one with ISO, sounds somehow too much.

So I think it would be easier to stick with only one standard

eg user definable string [LCID] [Language_extension_code]

about that extension code:
actual, there is only one possible parameter for audio & sub each:
[C] in audio indicates commentary
[T] in sub indicates translation, means caption, but I guess using T for translation is better, how many people know that caption is the correct word for such "translation"-subs. Moreover we could get in conflict with [C] from audio-streams.

Cheers
Raist

[raistlin2k]

Hello, just wanted to say I'm back (had my big test yesterday) I look forward to release a modified spec-file including all things discussed here in the next days, hope we can finalize it then, so that we can handle it over to the authors of the XCD-players to get cool XCD-menus very soon:)

BTW, as already reported here in the forum, Tobias added support for the Iso639-standard being part of XCD-menu-spec in his latest oggDS-release, he is really a great guy, always taking care of our wishes.

So, thanks to all helping me in setting up those specs, especially
Tobias & Toff.

Cheers
Raist
P.S. It's so good to be back.

[raistlin2k]

After having printed out the whole thread, so I don't miss anything, I re-read the whole thread and checked my latest spec-file.

Now it's done, I hope everybody feels fine with this one, if not, please tell me, as long as their is no player supporting this, we can modify it without problems, afterwards we have to archieve downwards-compatibility.

@[Toff]
By reading all the printed, I found one request of yours, I forgot till now, the action9 offering playback of extra-feature. Well it was already there as feature 6. Taken from mdvd.ini, it just worked another way, all specials were mentioned in the menu-file (like audio&sub as well), but we don't have this info in XCD-menu-file, so I changed feature6 to your proposal. Thanks for the advice.

Raist

[[Toff]]

So, where are those sweet latest spec, I don't see any attachement ;)

[raistlin2k]

Don't know, checked my posting with "edit", attachment is there.
Perhaps we have to wait for admin?!?
Raist

[BlackSun]

Originally posted by raistlin2k
Don't know, checked my posting with "edit", attachment is there.
Perhaps we have to wait for admin?!?
Raist

yup, it may contain malware :) So we test and infect our comp for your safety :)