Inside DVD-Video/NAV PACKs
NAV (navigation) PACKs contain one PCI (Presentation Control Information) packet and one DSI (Data Search Information) packet. I’m not sure if the order of the two is important, but every VOBU must begin with a NAV PACK.
The PCI packet defines buttons. Here is also hidden the flag that turns on Macrovision APS copy-protection for the video in this VOBU.
(see here for more details for now)
Buttons are the way for the user to interact with the DVD-Video content. They can appear in both menus and titles. Their appearance and behaviour is defined by the currently-visible subpicture stream, in conjunction with information from the last-seen PCI packet. Since all this information is coming from the VOB file which is being continuously read by the player, buttons can be dynamic: they can appear and disappear, change their appearance, and move around over time.
Each button belongs to a button group, of which there may be up to three. Button groups fulfil two conflicting purposes: on one hand they allow different colour schemes (choice of highlighted/selected colours), on the other hand they offer alternative layouts when widescreen footage is being shown on a narrowscreen set in letterbox or pan-and-scan modes versus on a widescreen set. This is why, even though there is room for 36 button entries, a widescreen menu can be limited to as few as 12 buttons, if you provide three alternative button layouts for widescreen footage.
A button can be in one of 3 states: the normal state is that defined by the subpicture stream. One button will always be in the highlighted state: this is indicated by the subpicture pixels within the button’s rectangle having their colours (including transparency) taken from the relevant table entry in the PCI, overriding what the subpicture stream specifies. As the user uses the up/down/left/right keys on the remote, the highlighted state moves from button to button, according to the corresponding spatial relationship information as defined in the PCI tables.
Just to be clear: switching between normal, highlighted and selected states is done purely by changing the colours (and transparencies) assigned to the pixel values; the pixel values do not change from those specified in the subpicture stream.
Then, when the user presses the “OK” or “Enter” button, the highlighted button is (supposed to be) briefly shown in the “selected” state, and then the interaction command associated with that button is executed. Some players don’t seem to bother to show the button in the selected state.
Buttons can also be defined as “auto-action” buttons; this means the associated command is executed immediately the button becomes highlighted, without waiting for the “OK” press. This is particularly handy for defining menus that require more buttons than can fit on one screen; the “next screen” and “previous screen” buttons can be auto-action ones, saving the number of keypresses the user needs to switch between screens.
A common technique is for the “normal” state, as defined by the subpicture stream, to show no visible (opaque) subpicture pixels at all. Instead, it is up to the video layer to define what the user sees as the “normal” appearance of the buttons. This is because the video layer allows for more elaborate, full-colour images, while subpictures are limited to a maximum of four colours. Of course, the “highlighted” and “selected” embellishments are still limited to the four-colour maximum.
The DSI packet has links to preceding and following VOBUs at various predefined time offsets from 0.5 seconds up to 120 seconds. This helps the player to implement its trick-play (fast forward/reverse) modes. It also defines how VOBUs corresponding to different camera view angles are interleaved.