Basics

This is an advanced topic, that require a bit more knowledge of DVD structure. You may skip this topic if you want, you usually don't need Menu Cells for any normal projects.

You may already realized that DVD specifications are quite complex and there are more than one way how to achieve some task. Menus in Cells are such example. With a normal menu we internally (during compiling) put each menu to its own so called "program chain" (or PGC). You can have many of such menus (PGCs) in a VTS and you can have also many VTS's on your DVD. However each program chain has in fact also smaller units called Cells. On our normal menu there is only one cell in each PGC and the menu is added to that cell.
The DVD specifications allows us to have more cells in a program chain. This is what we call Menu Cells.

On the image below is the situation where each menu is in separate PGC (in each PGC first cell). This is a normal menu as it is described previously.

This second image shows situation where each PGC has more than one cell. Each of the cell has (is) a menu.

So we see, each cell can be used as a place for separate menu.
The obvious question would be why would we want (or need) to have more cells in a PGC. We don't necessary need it, but in some special cases using cell menus can simplify the design.

•	We need a large amount of related menus (for example for CBT, Quiz, Training etc...) We can have up to 30 Cells per each PGC menu and we can have 640 of such menus per VTS

•	We need to switch between menus for some special effects, like jumping buttons or background/button change This is the situation described in Switched Menus topic, but here we can use cells instead of separate menus.

•	Disabling or enabling buttons depending on different conditions Using VM commands we can switch to a cell that has some buttons disabled depending on the previous choice

•	Show buttons on menu with some delay (for example intro without buttons, then loop with buttons)

As you may see all the above can be done also without cells, by simply adding more new menus, but using cell menus will simplify the whole design.

•

If cell has no VM command then it become seamless and the next cell will play without any delay. When using seamless cells with audio or motion, there is no jump or stutter in audio or video between the cells. So you can for example create a motion intro that will seamlessly continue into a motion loop without pause. (This is the single most significant reason why to use cells)

•

Faster switching even between non-seamless cells within one PGC (cells with VM command)
This is not much of an issue in the modern players, since modern players have much faster VM command interpreters and that means even normal menus should switch rather quickly. But in theory the cell-to-cell should be faster than menu-to-menu because there is only one line of VM Command on cell, but there can be many lines of commands on menus.

•	Unknown player bugs The players developers may not always test their firmware for more than one cell in a menu and there can be some related bugs on few players.

Each PGC (also what we call a "menu") has its PRE and POST commands. Such commands can have up to 128 lines. In case we have multiple CELLs inside the menu, each cell also have its cell command that is executed at the end of the cell playing time. A Cell command can have only 1 line.

The image below shows the relationship between PRE/POST and cell commands inside one DVD-lab PRO menu.

In a simple situation the flow of commands (marked by red arrows) when entering menu will be: PRE commands - play CELL1 - Cell1 cell command - play CELL 2 - Cell 2 cell command - POST Command. This of course assumes that none of the cell will be still (that means infinite timeout). If a button is called form any Cell then neither that cell command, nor POST command will be invoked.