Inside DVD-Video/IFO Files
IFO (“information”) files impose a structure on the raw MPEG data. The VMG has an IFO file, and there is also one in each VTS. The two kinds of IFO files (VMG vs VTS) have a common initial structure, but differ in later parts.
(see diagram here for now)
Here are kept various tables of pointers to find the titles, chapters and so on. Here also the attributes of the video, audio and subpicture streams are summarized. Some of this (e.g. audio format) is redundant and could be obtained by scanning the actual MPEG data (though presumably having it here is more convenient for player initialization), while other info, particularly the language-code assignments, is important for letting the user configure the playback of the titles. This information does not include the actual stream IDs; these are to be found within each PGC (below).
Program Chains (PGCs)
(see here for diagram for now)
Each PGC has an entry in an IFO file. The PGC’s VM commands and colour table are kept here, along with pointers to find the corresponding MPEG data in the VOB files.
Note that the PGC colour table defines colours in Y,Cr,Cb format with no transparency component. Instead, transparency (which DVD-Video refers to as contrast) is specified when the colour is referenced in the subpicture stream, or in a menu button definition.
Here will also be found stream control information, 8 entries for audio streams and 32 entries for subpicture streams. These correspond in order to the audio and subpicture attributes entries in the earlier part of the IFO. They define the particular stream numbers corresponding to those streams within the MPEG data for this PGC. Note that each subpicture stream control entry has room for 4 different stream numbers, being the streams to use for narrowscreen footage on a narrowscreen TV, widescreen footage on a widescreen TV, or widescreen footage on a narrowscreen TV in letterbox or pan-and-scan modes.
The ability to have different stream IDs for corresponding streams in different PGCs is presumably to allow easier authoring of a disc, by being able to combine preexisting material from different sources, without having to reprocess them all to assign consistent stream IDs. The “SCR discontinuity” flag that each cell has looks like part of this purpose as well: it warns the player about discontinuities in clock timestamps, saving the authoring system the bother of reprocessing the MPEG data to assign consistent timestamps.
Cells and Programs Within the PGC
The cell position information table explicitly lists all the cells that make up this PGC. These cells do not have to occur in sequence in the MPEG data, and the same cells can be referenced multiple times. This allows for the same material to be presented in multiple different ways, without the need for complicated programming of explicit cell-level sequencing using the interaction machine.
The program map entry table defines the groupings of cells into programs within the PGC. Each entry specifies a starting index into the cell position information table, and specifies the inclusion of all cells listed from that point in the table up to prior to the start of the next program.
Both the VMG and VTS IFO headers include sections listing all the menus. These are grouped by language units, each identified by ISO639 language code. Within each language unit there can be one or more menus, and each menu can consist of one or more PGCs. However, it’s not clear that these language units serve anything more than an informational purpose, since all selection of menus is done by explicit execution of VM instructions.
The VMG IFO includes an additional section that assigns a sequential index to every title in every titleset. This is used for cross-domain jump instructions in the VM: instead of being able to say “jump titleset m title n”, you have to say “jump title i”, where i is an index into this table that lists m and n.
Each cell is identified by a 16-bit “VOB ID” concatenated with an 8-bit “cell ID” within that VOB. This “VOB” doesn’t correspond to the segmentation into multiple .VOB files in the output DVD-Video file structure; it could correspond to input MPEG source files used to author the structure, with each input file being assigned an incremental VOB ID starting from 1. Thus, if an input source MPEG file is smaller than 524272 sectors, then the next input source file will be concatenated onto the same output .VOB file, but the VOB ID will increase.
But does this really matter? The player doesn’t care how the input source files were divided up.
VMGM_C_ADT, VTSM_C_ADT, VTS_C_ADT
These xxx_C_ADT tables are indexed by VOBU number, and return information about which cell the VOBU belongs to. These tables define the cells.
VMGM_VOBU_ADMAP, VTSM_VOBU_ADMAP, VTS_VOBU_ADMAP
These xxx_VOBU_ADMAP tables are indexed by VOBU number, and return the starting sector, relative to the start of the containing VOB, of the VOBU.
Where the VOBs Are
Both the xxx_C_ADT and xxx_VOBU_ADMAP tables above locate things (cells, VOBUs) by sector number within the containing VOB. But there’s no table of where the VOBs themselves start. (Remember, VOBs have nothing to do with the division into .VOB files in the DVD-Video directory structure.) So how do you find the VOBs?
It seems to me the player has to deduce these, as follows:
- The first VOB begins at the start of the first .VOB file. From this, you can determine the start of each cell and VOBU within the first VOB.
- By examining the xxx_C_ADT tables, you can deduce the highest cell number within each VOB. This gives you the highest sector number within the first VOB.
- Therefore, the next sector following must be the start of the second VOB. Redoing from the previous step on this VOB lets you work out its highest sector number.
And so on in sequence, until you have all the VOBs mapped out.