Need user feedback about menuing systems

[Atamido]

There are currently a few menuing systems for rips and homemade movies, but they all seem to heve different drawbacks. Most require a seperate program to use the menu, instead of the media player. They don't work accross OS's, are specific to containers, are low on features, or the sources and API's are closed.

I am looking to start creating the specifications for a completely open system for Menuing and I really need some input on several different points, namely:

What menu authoring software have you seen that you liked and disliked, and why?
What features have you seen that you liked the best, and that you believe are most important?
How do you think these features would be best implemented?
What are the worst shortcomings?
What things make a menu most difficult to use?


The following are requirements that heve been set so far for the format:

* The entire menu must be able to be stored in major new containers, namely Matroska (http://matroska.org) and OGG (http://www.ogg.org), producing an entire menued video/audio presentation in a single file.
* The menu must be usable stored outside of a container, as would be necessary for legacy items such as AVI. (may be removed from requirements)
* The video file that is menued must be playable by a player that cannot handle the menus.
* The menu must have the ability to play more than one media file from the menu. (Ability to choose seperate movie files from a single menu)
* The menu must have the abiity to play back video and audio in the background of the menu, as in current DVDs.
* The menu must be able to use static pictures for the background to conserve space.
* The menu must be navigable by the four direction keys. (Up, Down, Left, Right)
* Must allow selecting chapters to go to.
* Must be able select different audio and subtitle tracks.
* Must allow playlist for skipping portions of video, or playing a specific sequence of video clips.

Edit: Updated list of requirements to be more clear and include more items.

[Milkman Dan]

Personally, I don't believe AVI compatibility for a Menuing system is a desireable trait. I'm of the opinion that the menuing should be tried into the container, so that it can take full advantage of the container, and be a plus for it.

Along those lines, I think MCF's menuing system looked just fine, though I haven't thought about the adaptation for Matroska. Since the MCF system was built around nested Atoms, this would translate directly into Matroska descriptors.

As for authoring, Scenarist Scenarist Scenarist.

[Atamido]

Storing video in AVI a desireable trait, but it has to be done. The requirement to be able to store the video outside of the container isn't just to make it work with AVI, its to make it completely container independant, and for debugging purposes. If you have a 4.3GB Matroska file, you don't want to have to re-mux the whole thing everytime you realize that you made a mistake. You should be able to author the Menu and try it out doing different things before you mux it into the file. Once you're satisfied that everything is how you want it, you do a direct stream copy of everything, including the menu file, to the new file. There is no need to have to do it all again, because you already tested everything out.

It also allow compatability with formats that would take time to develop a menu muxer for. Take ASF for instance. Somebody wants to have a video file in ASF, but nobody is going to make a tool to place this menu in ASF for another 4 months. But, you can still make the menu and use it until you have a way to mux it in. (Not that I ever intend to use ASF and WM9, but people will and do, so it has to be able to work.)

MCF's menu system was good and simple, but unfortunately was only for MCF, couldn't be used outside of the container, didn't support background audio/video, and I don't believe you could select different files from it. This if 4 requirements that it can't fill for a new menuing system, so while it was good for MCF, it doesn't fit the needs we have here.

What is it about Scenarist that you like/don't like? What more do you wish it could do?

[bond]

Just my 2 cents on this issue:

1) In my opinion it is very important that the menu only requires low space (usable on two cd rips) or that there is at least the option to build a small menu, for example without video background, etc...

2) In my opinion a menu at least should look like the original dvd menu at first sight!!!!!!

a) fullscreen background picture (perhaps taken from the dvd menu) - no motion necessary
b) background sound (taken from the dvd menu) - turn on/off option
c) option to select subtitles/different soundtracks
d) option to select chapters (this option hasnt to be as big as on dvds, with motion, etc... - just a list to choose from)
e) for 2cd rips: option to tell the player where cd1 and where cd2 can be found so that he plays both (playlist)
f) autostart in fullscreen if cd is inserted

[Milkman Dan]

Originally posted by Pamel
You should be able to author the Menu and try it out doing different things before you mux it into the file. Once you're satisfied that everything is how you want it, you do a direct stream copy of everything, including the menu file, to the new file. There is no need to have to do it all again, because you already tested everything out.

In my opinion, this pre-authoring step of emulation of the finished project is the job of the authoring software itself. This, logically, is where you iron out the bugs and looks in your menu. Muxing the whole things each time to test the menu is a waste in the first place, and doesn't represent the way people would really tend to do things. That's my thought, anyway.


It also allow compatability with formats that would take time to develop a menu muxer for. Take ASF for instance. Somebody wants to have a video file in ASF, but nobody is going to make a tool to place this menu in ASF for another 4 months. But, you can still make the menu and use it until you have a way to mux it in. (Not that I ever intend to use ASF and WM9, but people will and do, so it has to be able to work.)


I think this is a case of catering to too low a denominator as far as 'marketshare' of the codec/container space.


MCF's menu system was good and simple, but unfortunately was only for MCF, couldn't be used outside of the container, didn't support background audio/video, and I don't believe you could select different files from it. This if 4 requirements that it can't fill for a new menuing system, so while it was good for MCF, it doesn't fit the needs we have here.


Well, I never said the thing was bullet-proof. The MCF development cycle never got the the menu system really. We sat around talking about error resiliancy and crap like that, instead of things like features and how the files really worked.

In any event, I don't see use outside the container as a plus, it did, in fact, support background music and video (although it may not have made it into the spec page. Like I said, dev never got that far), and selecting external files was on the "to-discuss" list. I would have been very disappointed if it had not.

I mean, really, you guys can design it however you want, and I'm glad that some user input is going into this. Frankly though, I see the effort as a waste as far as this 'far-reaching' design concept you have. Matroska is already relying on at least 2 specs/designs that don't even exist yet, much less can be relied upon. Let's not add a third.


What is it about Scenarist that you like/don't like? What more do you wish it could do?
Work gets in the way, and I have run out of time. But I'm leaving a sticky note on my panel here to reply further concerning Scenarist.

[Atamido]

Originally posted by Milkman Dan
In my opinion, this pre-authoring step of emulation of the finished project is the job of the authoring software itself. This, logically, is where you iron out the bugs and looks in your menu.

I think this is a case of catering to too low a denominator as far as 'marketshare' of the codec/container space. Yes, but it is common to not notice the bug in the authoring software, but to notice it in the finished product. I know I have done this encoding video, even though I checked all of the previews first.

Besides, it is a useful feature for not to much added work, and there isn't a good reason not to have it.Originally posted by Milkman Dan
Matroska is already relying on at least 2 specs/designs that don't even exist yet, much less can be relied upon. Let's not add a third.
People keep saying things like this, but I'm not really sure what they are talking about. The only 2 specs that Matroska is relying on are the Matroska specs themselves, and the EBML specs. But the EBML specs were developed first, and then seperated into a seperate project so that other groups could benefit from them.

There are many projects that the Matroska team is associated with, but it is not relying on any of these, and none of them are anywhere in the specs. For example, subtitles were specificaly removed from the Matroska specs because it was felt that defining subtitle specs was outside the scope of the container. Members of the Matroska team also contribute to the USF (http://www.corecodec.com/modules.php?op=modload&name=phpBB2&file=viewforum&f=12) project because it looks like it has the potential to be a great subtitle format for everyone to use, but they are not relying on its development. There are other subtitle formats that already exist that could be used. You might say that Matroska is relying on a vfw replacement being built, but so is everyone else. The aging vfw interface isn't doing very well right now, and needs to be replaced so future codecs and applications can function properly.

As for the pre-occupation that some people have with error resiliency, that is just how some people are. Not really my thing. For instance, if theres a few more corrupted bits in one of my windows DLLs, its probably not going to crash more often. :rolleyes:

[Milkman Dan]

Originally posted by Pamel
Yes, but it is common to not notice the bug in the authoring software, but to notice it in the finished product. I know I have done this encoding video, even though I checked all of the previews first.

Firstly, I want to say....W00t! My motherboard shipped! Yay!

Right, anyway.

I just don't think it's worth separating the container from the menus even in this instance. To me, muxing isn't all that big a deal. If I can mux 1500fps in Vdub, I wouldn't think that Matroska would be all that much slower. If I have to re-mux something because I did something stupid, that just makes me more cautious the next time. But even if I do remux, it's not that big a deal.


Besides, it is a useful feature for not to much added work, and there isn't a good reason not to have it.


Are you the one going to be coding and be fully responsible for the menu system? I think only that person or team is in a postion to make that claim. If you are that person, and you truely think that, then I'll shut up about this, help contribute ideas, and if it works, it works. It just seems so counter-intuitive to the way I would approach the problem that I can't help but argue. Sorry. ;)


People keep saying things like this, but I'm not really sure what they are talking about.


Specifically, I'm talking about UCI and UFI. Although I had forgotten about USF. Last I had heard, much, if not all of the Matroska codec and format handling was built around the vague ideas of these two specs. They (and their creator, again, last I heard) are vapor, as Emmett Plant pointed out in the other thread.


There are many projects that the Matroska team is associated with, but it is not relying on any of these, and none of them are anywhere in the specs. For example, subtitles were specificaly removed from the Matroska specs because it was felt that defining subtitle specs was outside the scope of the container. Members of the Matroska team also contribute to the USF (http://www.corecodec.com/modules.php?op=modload&name=phpBB2&file=viewforum&f=12) project because it looks like it has the potential to be a great subtitle format for everyone to use, but they are not relying on its development.


This is an instance where the separation of the two products makes intuitive sense to me. To me, since subs don't need to be tailored to the container( our containers 'support' it already), this is just good object oriented design at work. But supporting more than just Matroska/MCF with a generic menuing system can't be generic to all containers. It would have to handle each differently. You can have a "wrapper," or just stick to menuing one container at a time. Besides, as a developer, I'm not interested in adding to the functionality of AVI, ASF, RM, etc. With the exception of Ogg, I see them all as either inferior to our solution, closed and unsupportable, or just legacy rubbish that needs to be jettisoned. It's wasted effort in my mind. In this regard, I can see where Emmett is coming from.



As for the pre-occupation that some people have with error resiliency, that is just how some people are. Not really my thing.

Right on brother. On that, we can agree.

[Milkman Dan]

So anyway, Scenarist.

I have very few complaints about how scenarist works. I liked it well enough to pattern -Gemma's workflow and GUI concept from the way I learned to author in Scenarist.

And really, my gripes with it have only to do with DVD-Specific applications and features. As far as general authoring is concerned, I love it. It's stable, it gives good reasons why something won't import, I've gotten used to the menu generation features, I like the way the preview works, etc. It's not a point and click program though; you have to think about what you are doing to make it truly work for you.

The thing I want to make sure gets into Matroska is the idea of Edition and non-linear playback.

Lets say I have 5 episodes of Cowboy Bebop in one large .Kav file. The series intro and outro are chapters 1 and N, respectively.

From the menu, I should be able to do one of two things. I should be able to specify:
1) Play order - Intro, episode1, outro; Intro, episode2, outro, ...etc
2) Play order - Intro, episode1, episode2, episode3, episode4, episode5, outro.

By manipulating the control flow and the chapters themselves, I can not only make more than one way to play the file, but I can also save significant space by storing the intro and outro only once.

That is the single most important Edition implementation detail I want to see supported in the spec.

Larger organizational units, like title sets and program chains, since I am used to these concepts, should be the units that the authoring program user manipulates. In my example above, instead of a chapter of the larger file, the intro could be a separate program chain, with it's own playback behavior (specified in the menuing system.) In that instance, I could playback the intro itself from the menu, and the default action could be to return me to the menu. If I entered into a normal viewing flow, then the playback order I already laid out would work as normal.

I can talk more, but I want to eat, and read some comments. Later.

[ChristianHJW]

Originally posted by Milkman Dan Specifically, I'm talking about UCI and UFI. Although I had forgotten about USF. Last I had heard, much, if not all of the Matroska codec and format handling was built around the vague ideas of these two specs. They (and their creator, again, last I heard) are vapor, as Emmett Plant pointed out in the other thread.
We can always hardcode codec support into the encoding tools and the parser, just like Tobias did with Vorbis. Quick and easy solution, no hassle, no problems, no headache .... but not what we want in the end.

Dont worry, we will have a nice codec API to use for our goals. XipH people could come up with one, Real may share their ( presumably excellent ) codec API with the rest of the world, UCI will be finished ( by Alex or somebody else ) or Erik Walthinsen will find the time to make something for the open source world, once gstreamer hits 0.6.0 release hopefully ( heck http://codecs.org ) ...

[Milkman Dan]

Uh...you had me until the no hassle, no worries, no headache part. It think it's all those things, plus kludgy and inelegent.

I thought it was a bit of a leap for us to depend on UCI in the first place. That number has balloned into 4 separate, but related projects.

Yikes.

[Atamido]

Focus people, focus. Try and stay on track with the purpose of the thread. The input has been great, but I need input on this, not that.

Originally posted by bond
1) In my opinion it is very important that the menu only requires low space (usable on two cd rips) or that there is at least the option to build a small menu, for example without video background, etc... I had thought this in my head, but apparently you're not psychic. This isn't clear in what I wrote, so the I updated the list of requirements to reflect this idea more clearly.2) In my opinion a menu at least should look like the original dvd menu at first sight!!!!!! I'll just take this to mean that you should be able to make menus that look like DVD menus. Doing a direct conversion of DVD menu's to whatever is something that I know little about. Has anyone ever seen this?a) fullscreen background picture (perhaps taken from the dvd menu) - no motion necessary The background should be able to be a static picture, or a moving one. Whatever you have the space/time to create. b) background sound (taken from the dvd menu) - turn on/off option Turning menu sound on and off should really be done by the application, but it should also be possible. c) option to select subtitles/different soundtracks Again, this was in my head, but I didn't think to write it down. An obvious requirement for a good Menu system. d) option to select chapters (this option hasnt to be as big as on dvds, with motion, etc... - just a list to choose from) See above. Could be done with video, or just a single picture. But chapters are a necessity. Added to list. e) for 2cd rips: option to tell the player where cd1 and where cd2 can be found so that he plays both (playlist) Already listed in the requirements. f) autostart in fullscreen if cd is inserted This is completely application dependant.


Looks like I may just remove the listed requirement to be able to play a menu outside of a container. Could people give some more feedback about this as to wether or not it should be a requirement?

Keep those comments coming!

[SirElvis]

From the menu, I should be able to do one of two things. I should be able to specify:
1) Play order - Intro, episode1, outro; Intro, episode2, outro, ...etc
2) Play order - Intro, episode1, episode2, episode3, episode4, episode5, outro.This is something I REALLY want to see. It's just stupid to put three(or more) episodes of something on one CD and have the intro and outro, which is the same for each episode, in each of the files. I'm already seperating intro/outro and episode content, but to be able to put everything in one file and have a menu to choose what you want to watch would be really cool ;).

[Atamido]

Originally posted by SirElvis
This is something I REALLY want to see. I'm already seperating intro/outro and episode content, but to be able to put everything in one file and have a menu to choose what you want to watch would be really cool ;).

I actually added this to the list of requirements before responding to Milkman Dan's comments. I've actually heard this request before and we had been discussing some possible ways of pulling it off over at another forum. Anyone interested can look here. (http://www.corecodec.com/modules.php?op=modload&name=phpBB2&file=viewtopic&t=255)


Keep those thoughts rolling in!

[[Toff]]

I didn't had time to read all the thread so no comment at the moment.

Some time ago there was a discussion about XCD menu.
There can be some interesting things in it :
http://forum.doom9.org/showthread.php?s=&threadid=31282&highlight=xcd+menu
You can find the last version of the specs in the last page.

The main purpose of XCD menu was to be able to reproduce DVD menu in a way as simple as possible.
Around that time I was also working on a tools to convert dvd menu to xcd. So if you have question on how DVD menu work I could try to answer them.

[kairos]

I have been thinking about menus for quite a bit of time. I figured an ifo type file could be muxed into a format such as ogg or mcf and parsed by a player. If the player doesn't support menus it plays through like a movie. This file could link the other files with an md5 tag or something, I believe mcf supports this from the specs for seemles multiple file playback. The menu should be 1 file that utilizes time codes to play a loop.

Taking suggestions from us is great so you can make this the best menu system available, but I would suggest you work with authors of media players shuch as Blight or BlackSun to determine the best way for the players to support menus. After all there is the mdvdp .ini files that can do some powerfull things, but no other player is willing to support it. The suggestions I've heard so far suggest that people want the same functinality as the real dvd as well as support from their favorit players. If that can happen then I would gladly go through a long process to make it work. After all there is still no one click process to making dvd rips and we've been at this for years.

[ChristianHJW]

Originally posted by kairos ... but I would suggest you work with authors of media players shuch as Blight or BlackSun to determine the best way for the players to support menus.
BlackSun is amongst the biggest contributors for both OGM and matroska, and we expect TCMP to become the first ( hopefully not the only one ) supporting all features of the menuing system .....