Menus like the original?

[REIGN_]

Sorry for posting here but i don't know where else to post. Is there a way to produce menus like the ones in the dvd for my divx encodes?

[raistlin2k]

Yeah, microDVD player can display such menu-rips.
Do you speak German?
I have a package for this microDVD system, my mDVDit 3.5:cool:
the best voted package on q-bert.c4.to, a german ripper-site.

unfortunately, downlaod link is broken & q-bert has no time for fixing it, but I can send you the manual per email if you want, the tools for menu-creation are available at doom9;)

The big disadvantage of microDVD pLayer is that it's not compatible with the XCD-specs, and that development was stopped, so i also stopped development of mDVDit:(

I just started working on XCDit, a completely new package for creating XCDs; it already supports chapters, several audiostreams and several subtitles. Menu-support is not yet integrated by the creators of XCD (thanks to avih & Dext), but is promised, I will integrate it into XCDit as soon as it's finished.

So if you want you menus now, send me your email-adress for mDVDit, otherwise I suggest you wait for XCDit.
Raist

[avih]

I just started working on XCDit, a completely new package for creating XCDs; it already supports chapters, several audiostreams and several subtitles. Menu-support is not yet integrated by the creators of XCD (thanks to avih & Dext), but is promised, I will integrate it into XCDit as soon as it's finished.

promised?? pls accept my apologies if someone did promise that, or if i misunderstood your english, but afaik, no one of the XCD team has promised to incorporate your menu system into XCD...

anyway, indeed, we need a menu system for XCD, and if you would be kind enough to share your ideas with us (as u obviously have good experience with the subject), maybe we can define a menu system specifications for XCD together. you might wanna talk to blacksun as well (the author of powerdivx, aka core media player), as he defined a menu system he calls dividivx, which powerdivx supports. there's also a tool to convert dvd menus to dividivx afaik.

maybe you can work together with him and us, and help in defining the XCD menu system?

and about your XCDit, can u give a bit more information about this application?

thanx
avi.

[raistlin2k]

Well, till now XCDit is not much more than an idea, i started development from my last mDVDit build (was not released to the public, because I stopped it and switched to XCDit).

Sorry, you misunderstood me, I didn't mean you will support my menu-system! I don't even have one. mDVDit didn't have it's own menu-system, it was just a tool to create menu according to microDVD standards.

All I wanted to say is that as soon you finish CD-level of XCD (inluding menus) I will work on tools to create such XCD-menus, or to change an original DVD-menu into a XCD-menu.

I'm really honored that you ask me to help you on the XCD-menus.
For sure, I will help you as much as I can. I know the DiviDivX-menu-system, but I don't like it, no good tools for creation of such menus, hard to setup etc. As microDVD is not open-source we cannot get this system for XCD 1:1, but I know the architecture of the microDVD.ini files quite good, so we could start from there creating a new menu-system, powerful as the old one from microDVD-Player.

Raist

P.S. I remember in one of your prior postings you wrote that prob CD & file level will be done by the same filter. Where will the information about the menu be saved? in the container-file or in a separate file burned in mode1? I think it would be easier to have an additional form1-file for that, otherwise ogm must be enhanced! Or is there space in the specs of MCF for such information? Or will it be possible to merge several files (ogm,ini,...) into one XCD-file?

[RadicalEd]

avih, if you guys need any info or help pertaining to menu systems like SVCD in developing the system for XCD, I may be able to lend a hand (you wouldnt believe the amount of time I spend designing these things)
Since SVCD is already f2m2, perhaps it would be a good idea to borrow some ideas from that system in designing the new XCD menu specs. Anyway if you need to know anything in the future PM me about it and I'll dig up an answer for you

[REIGN_]

I just wanted a tool to make the Menus exactly like the original that's it. raistlin2k i hope you can send your program.

[raistlin2k]

need your email-address for sending!

German is OK for you?

[avih]

@all:
there's a new specification for File-Level-XCD (FLX) at http://www.sf.net (follow the link at the bottom). now we should only implement that ;)

@raistlin2k:
you're welcome to read the xcd draft spec. the menu is an independant system, in an independant directory. so are the playlists. The menu system has no definition at all atm.

the dshow filter will be both File-Level-XCD (FLX) compliant and XCD-Level-1 compliant (check the spec). The filter aims only to play a single media file. the player itself will have to handle the playlists (if it's XCD-Level-2 compliant) or the menus (XCD-Level-3).

remember this: XCD is a storage system only. but since we have such a nice storage system for media files (m2f2 media + m2f1 backup), we thought that by adding these extra features (as playlists, menus, bin directory, maybe bootable, etc) it would make it more complete, and a true opensource multimedia-cd definition and implementation.

anyway, xcd has nothing to do with muxing, decoding etc. the filter is only a wrapper to the mode 2 form 2 storage system, and the other files of xcd are plain mode 2 form 1 files.

@raistlin2k & RadicalEd:
:) thanks guys for your willingness, that would be great.

anyway, it'll take us some time till we'll start working on CLX and Levels 2 and 3, since we have to upload many files to sourceforge (and learn how to use the CVS properly, i've managed to avoid that stuff so far in my life, but no more i guess ;) )

so, if you want to get actively involved and you have the time for that, you can compose together (or each you you by yourself, if u prefere so) a proposal for a menu system for xcd (or if you have one RadicalEd, i'd love to see a spec if that's ok with u).

thanx again
avi

[REIGN_]

Ja Deutsch ist gut fur mich. Mein e-mail adress: gkalogeropoulos@yahoo.com

[RadicalEd]

On it. I have far too much free time anyway and anything to help the XCD menu spec come along (we like menus.. yes we do). I'm doing some extra research on CD-I interactivity and the specific methods that VCD uses to access it's menu filesystem. Rastlin, my email is RadicalEdward000@aol (yea yea.. hey its only until the cable arrives in a week or so) anyway I'm totally in the dark when it comes to microDVD, but once again I spend a lot of time working with SVCD menus (as if you couldnt tell :rolleyes: ) so perhaps implementing similar M2F2 ideas will be productive. If you have any suggestions email me, once again I'm now in the process of researching the methods VCD uses to access the menu data. If I come upon something worth noting, i'll post it.

[avih]

very nice :)

although i have no experience at all with menus (didn't use them with svcd/vcd, i don't have a dvd drive and i didn't try to investigate the subject), i did thought of some applicable (imho) guidelines:

1. the menu system should be general enough to use/target different media types (i.e. audio/video/images/others)

2. it's usefull if the menu system has all/most of the important features that other menu systems (dvd/svcd/etc) have, such that it's possible to make menus replications/porting of the most common menu systems using automated tools with relatively small manual 'intervention'.

3. the menu system should have nothing to do with the filesystem (i.e. it shouldn't care about the storage level, form1/2 etc). the menu files themselves will most probably be mode 2 form 1 (=standard) files.

4. 'objects' used by the menu system (such as targets, backgound etc) are either media objects (audio/video/images/etc) or playlist objects. other menu files may be used as tergets as well. your assumption while defining the spec should be that each such object can be recognized by a short identifier.

5. the spec should allow and define a method to render a menu on a non-graphical display (or even a single line display), even if the menu contain graphical objects.

6. it is preffered that the file format is plain ascii, such that a menu file can be edited using a simple text editor.

7. it is preffered that the menu system will have well defined 'defaults' for different player capabilities, such that it allows the menu file to contain only the relevant info, and not 'forcing' the file to define every feature that the system supports for every menu 'item'.


regarding the process.
i think the best way is to first define a good set of functional features (asking help from other forum reader usually proves valuable ;) ). after we're happy with the features set, it's time to define the file structure to support these features. when defining the file format itself, it's important to keep it simple (and maybe even 'readable').

any other global guidelines that i didn't think of (or notes about irrelevant guidelines that i suggested) are naturally welcome as well.

cheers
avi.

[RadicalEd]

Ha, funny timing avih :D
I had written this in a new post and was just looking up some more stuff in the mean time when i decided to revisit the forum to check the new posts:

"Alright, I've formulated some basic stuff so far:
First of all, we want XCD to be compatible with future standalones that will support vorbis and divx and all that jazz, so the spec should be dirivitive of an already established spec like that of DVD or VCD.
Second, we want easy conversion from DVD menu to XCD menu, so the basic functions of the menus should resemble that of DVD.
Third, F1 and F2 will be needed for menu data on XCD; the motion menus should be stored in F2, whereas the still menus and menu information should reside in F1, similar to VCD"


looks like we're on the same basic page. Can't wait to hear from you rastlin, what do you think about all this so far?
In addition, motion to start a new thread in New A/V Formats. How bout it?

[avih]

hehe, yup, looks like we think alike ;)

i have only remarks:
the media format itself is irrelevant from the menu point of view (i.e. whether it's divx/xvid/mpeg2/mp3/vorbis/etc). the only thing that matters for the menu system is whether it's a static object (as an image) or dynamic one (i.e. that changes on the time axis, like video or audio stream). the menu also should not be concerned about the storage format (f1/f2), as that's the responsibility of XCD to store the media objects correctly.

and, you can open a new thread if you like, or just use this one as it's pretty much related only to xcd menus so far.

if during your research you find some interesting menu links, i'll be glad to have a look at these pages.

cheers again ;)
avi

[RadicalEd]

Well I've been reading up on CD-i over at icdia.org, but I'm not sure if theres any real useful info there yet. Anyway, just to clear up #1 on my suggestion list, I didnt mean to say that the menus should be vorbis or divx, what i was saying was that the structure should somewhat follow common DVD or VCD specs so that they will be playable on future standalone players. That is, I wasn't focusing on the point of what format the video should be, I was focusing on the fact that spec should be similar to allow some level of compatibility with future standalones.
Ah well I dunno, this thread is good but its in the DivX forum when what we're talking about should prolly be in new A/V. Acaila, if you want to move it for us that would be cool :)
Anyway, back to the research @_@

[raistlin2k]

First of all, I'm sorry that I didn't respond sooner, Having a big exam on Pharmacology in 3 weeks, I have almost no time left for my PC.

I think we start from a DVD-menu, to be honest, SVCD and VCD are outdated in my opinion.

Well, the menu-vobs from a DVD contain video & still-images in one file, the ifo-file contains all infos on this parts of a menu.

A problem I already had was that in some menus (like Star Wars Episode1) this stills and videos are mixed together, if you transcode them like a movei, it can happen that a still-image becomes no keyframe, because the prior video ends with the same picture, so the still-picture can't get used in the copy.

A way to come around with this is to use XMpeg, with that tool, I have to mark all separate sequences of the menu, so its guaranteed that each sequenz starts with a keyframe (that's the way mDVDit worked). Due to limitations of microDVD-player I had to place this still-pictures into separate jpgs (using DVD2avi,XMPEG can't save JPGS!), because it was unable to display only 1 frame of a file (even if it was a keyframe). So I had a video-file, an ini-file (see below) & several jpgs:mad: Horrible work!

This should be improved, new system should be able to show only 1 frame of the video-file as still image. So we would have only one video-file containing all video-sequenzes and still-pictures and a info-file, where information about buttons,actions and so on is saved.

I think it would be a great idea to start from such a mdvd.ini, I will ask Christophe Paris for the source-code of his "microDVD menu maker", a really good tool for setting up the button-positions etc.
(you can have a look at it, d/l it from doom9)
We just have to split the microDVD-related things (language-info, subtitle-info, chapters)from this tool, this info is saved in the ogm itself.

Or does anybody know a way to trancode the menu-vob into mp4 and then modify the original ifo for menu-usage?

Raist

[avih]

@raistlin2k:
first, good luck with your exams ;)

now, imo, don't think too much about the problems of 'transcoding' existing menus (i'me sure we can find plenty), since it's too early for that when we still didn't define the FEATURES of our menu system.

so, in order to have a common base of agreement, let's first agree on the guidelines in my previous post.

do u both agree on the guidelines then?

if the answer is no, post your corrections, and then we'll go on.

then, we should agree on the process. the process involves the next steps imo:

1. define the features (graphical buttons, overlayed video/audio/etc).
2. define the menu file format (NOT the media files format).
3. define the storage system (for the menu files and the media files).
4. think of methods for converting existing menus to xcd menus.

each of the above steps relies on the previous ones but is NOT affected by the latters (i.e. step 2 relies on step 1 , but is not affected by steps 3 and 4).

in your remarks, you've gone to steps 3 and 4, and the problems you noted indeed exist, but solving them without going through stages 1 and 2 may cause further problems later on.

so, do u both agree on the process?
again, if you don't, post your corrections or other remarks.

naturally, even if we agree now on the guidelines and the process, but in the future feel that they need modifications, we'll do tham. but it's a good atarting point when everyone have a common agreement base.

if you do agree both on the guidelines and the process it's great, and we should move to step 1 of the process. :)

raistlin2k, RadicalEd??
;)
avi.

[raistlin2k]

I agree completely to your guidlines. ;)
Just one question: what do you need 5. for?
I think it would be easier to leave this out, if it is not really needed. original DVD-menus are based on videos and still-pictures, we had to enhance this for a single-line-menu??

I don't really understand what you need this for.

The only thing you can choose in a menu and not in context-menu of a Dshow-player are so called specials of a DVD (making-off),all other menu options (language, subtitles, chapters) are available in Dshow-players via context-menu.

Following would be more easy to realize, I think: the info-file of the menu should be build in a way so that future-players can offer the menu-options without displaying the menu (e.g. language change, chapter-jump, specials while movie is running. In WinDVD for example language can be changed by the menu and by player interface)

We should make it possible for e.g. PowerDivX to use this menu-info-file for such options.
Then a menu as shown in 5. will not be needed anymore, isn't it so?

Raist
P.S. And now back to antibiotika
:(

[avih]

:) i thought this question might come up :)

ok, in my vision i see xcd as a general multimedia storage system.

one example is an xcd with mp3 (or ogg-vorbis) files. imaging you compress your favorite 15 Audio CDs albums to mp3 and put them all on a single XCD. now also imagine that this cd is played in a protable xcd compliant player. usually such players don't have graphical display, and many times that have only a single line of display.

how should the menus be presented on such devices??

it should be easy enough to take the menu file, and render it textually only (i.e. no overlays, no graphical buttons etc). yet, if the player does support the graphical features of the menu file, it will show that. otherwise, it won't. but the menu system should be flexible enough to allow non-graphical rendering.

i.e. if we use a graphical button. we can have some sort of 'ALT' tag that has the textual content of the button. and that's the field that the textual rederer will display.

here's another sample scenario. the player does have graphical capabilities, but it's might be too much time consuming for the developers to implement all these graphical features. would you tell them: "support all the features, or don't support menus at all"?? imo it's not the case. i'd preffere that such players will be able to render a functional menu and navigation system without the bells and whisles. (that's what i ment when talking about 'player capabilities' and 'default behaviour').

of course, if it'll turn out that it's way to hard, and imposes too many limits on the menu system, we might separate the menu spec into two: simple and advanced (where advanced has all the features of 'simple', with few more). however, atm, at least in theory, it seems that it should be possible to have a menu file with all the fancy features, yet possible to render on a textual system.

but, again, you're jumping to stage 2 of the process. i.e how to build the file such that it possible to render it on a textual system. let's start with stage 1 that is a definition of the functional features that such a menu system has.

cheers
avi.

[raistlin2k]

Well, the engineers of portable MP3-CD-Players don't take a look at such standards, you can trust me, i've got an Expanium by Philips, the first mp3-discman available in Austria.

It's really bad on sorting mp3s, it's not able to read joliet format, but reads only iso9660, so that albums are not in same order as in windows-explorer (due to nero, doing a somehow crazy naming in iso9660 mode. Solution was to burn all albums with numbers in front SHIT, or use WinOnCD in "Long names for NT", I don't know why I works then, but it does! Expanium reading NT-CDFS, but not Joliet??:confused: )


Believe me, such work only for XCD being available for mp3-CDs is useless, there will never be a discman supporting this menu-system or even XCD itself.
All the engineers have their own system for sorting files (there was an article about this in c'T, I'dont rmember the volume)

Raist

[avih]

you've just gave me the justification for XCD 'features' that might otherwise seems as limitations. xcd uses a completely standard iso9660 filesystem, and 8.3 naming convention. you can read that on the xcd spec published few weeks ago. the tracks will be ordered correctly, and the names of the media files will have serial numbers that match the track number :)

i knew we didn't have those XCD 'limitations' for nothing. ;)

and besides, with a short term 'vision' we won't get too far. dreaming is good, especially if it doesn't impose too many limitations on implementation. don't forget we do that for fun, and not for commercial reasons. we do hope though that the spec is solid enough to be adapted by commercial companies.

cheers
avi.

[RadicalEd]

Sounds good avih. I'm not really sure how much extra work the one-line display idea would take so I'm kind of unopinionated, although as you said embedding a sort of alt text sounds reasonable.
I've been reading the RealSystem IQ production guide and I'm getting the idea that with some extensive smil scripting one can write an interactive menu. While that dosent really tie into XCD, I want to try some things out.. I'll get back on that later.

Rastlin, for splitting menu-vobs use Vstrip. Load the vob in (not the ifo, never load the ifo with menus) click 'split by cell id' and let it run. That way it cuts the menu apart exactly and you dont have to try and do it yourself in Xmpeg. For a little more about this read my guide;
http://www.angelfire.com/anime3/airanime

Sorry, I know thats OT but I just couldnt let rastlin suffer with manual menu splitting.
Anyway, on with the project, we shall define the menu features. I say we steal most of DVD's features although perhaps we could elaborate on the 8-bit (or is it 4?) overlay and make full color overlay graphics possible or even small animations. That surely would jazz up menu buttons. I'm not sure if video and audio overlays in the menus would be useful for anything though. Stream switching capability is desireable, so the menu program will need support for morgan stream switching, ogg stream switching, eventual mcf stream switching, and basic access to different audio or sub files that may be on a disc. Or are you guys planning to include audio and sub switching as part of the level 2 and 3 XCD spec? That is, is XCD itself going to define a universal stream switching instead of relying on a specific file format and its dshow filter? (did that make sense..?) anyway, stream switching is a must. In addition, chapter entry. That shouldnt be too difficult to accomplish using simple timecodes. Well anyway, time to go eat food (food: its good and good for you!) so go ahead and add to the list of stuff to add support for. So far;
- 2-32 bit bitmap overlay (including multiple bitmaps for motion)
(support for gif animation as well?)
- access to different media objects (streams)
- access to entry points in specific objects through timecodes
- a special text-based version for one line displays (if that issue is proven possible/useful)

so as you can see.. much needs to be added. But I can do that after lunch

-edit- your post came through while I was writing avih. Yep, people dreaming big and acting on those dreams is how the really great stuff comes to be in this world ;)

[raistlin2k]

Thanks RadicalEd, for the tip with vstrip!:)

BUT, my name's Raistlin Majere, wizard of the Dragon Lance, not rastlin:devil:

Well, back to XCD-menu.
Your list of features is almost complete, what should be added:
- specials (should be choosable, very simple, only linking to an additional file containing e.g. making-off)

As I already mentioned, microDVD-player lacked of showing 1 frame of a video as still-image. So jpgs had to be used for menu-still-images.
This does not only result in more authoring work (two different ways, depending if source is video or just picture), but also in color-problems, for example: The Game has a real cool menu (puzzle-pieces flying around), but when it comes to a still-image in my copy, the color of the puzzle-pieces is not the same as in video (there is more color, in DivX color looks less strong (YV12!)).

So i think it would be better to do it like a real DVD, store the still-images in the same video-codec as the video-sequences, will make less work on reproduction of DVD-menu and result in a menu without these color-jumps!

Still-givs I don't like, only 8 byte color depth, destroys all good pictures! animated gifs are a nice idea,but are not needed for the reproduction of a DVD-menu, or do you know a DVD with such animated buttons, besides video-buttons, I mean, which can't be saved in a gif without heavy quality-loss!

Raist

[RadicalEd]

Ups.. must read more carefully ^^; sorry raistlin

Anyway, about animated buttons and things, remember that we arent trying to simply design a menu spec that will allow easy transfer from DVD, but also a universal and versitile system for XCD that will allow authors to go above and beyond the limits of existing menu systems. We've got to think of everything that can practically be applied to a menu, because XCD has the potential to become the best CD-based storage format for the next few years.

Also I really wanted to drop a personal note- you guys continue working on it, I may not be able to contribute much over the next week or so. Have to straighten plans out to go across-state to meet a very interesting person I met on the internet 2 years ago.. her and I have some 'catching up' to do ;) :D anyway aside from that finals, HDD cleaning (2 gigs left of 40 ^^;; ), guide updates, and trying to get this damned smil to work with my realmedia... its going to be a busy 2 weeks. I'll try to do some good in the midst of the mess, but I cant promise that I'll be operating at optimum performance. So pull some stuff together while I'm incompassitated k? Thanks guys.. never a dull moment :rolleyes:

btw- you guys can just call me ed :cool:

[avih]

np ed, we're not in a hurry in any way ;) take your time. relax ;)

when you become available, would you and raistlin2k like to compile a nice feature list, in a nice document? (notepad is enough, but it should be very clear and 'spec-like') ?

this doc should NOT be concerned with different video/visual/audio formats or storage (don't mention mode2 or files etc.. or gif or animated gif or bmp or mp3 etc). just use the terms :'a/v stream', 'audio stream', 'video stream' and 'static visual' (the 1st three can be just called 'stream', the latter is a static image, as in jpg or gif or whatever, but don't concern yourself with the formats or storage yet)).

we'll have other ppl look at that as well, and if everyone is happy with that list, we'll continue to the next phase..


cheers
avi.