This application is based upon and claims the benefit of priority from Japanese Patent Application No. 2007-004907, filed Jan. 12, 2007, the entire contents of which are incorporated herein by reference.
1. Field
One embodiment of the invention relates to an information storage medium such as an optical disc or the like, an information playback apparatus for playing back such information storage medium, and an information playback method for playing back such information storage medium.
2. Description of the Related Art
As disclosed in JP-A 11-110914 (KOKAI), the DVD (Digital Versatile Disc) standard specifies region codes to limit reproducible regions. The DVD standard adopts a scheme in which a content and a player hold unique region codes, and the content cannot be played back unless the two codes match. For example, it can be implemented that a DVD (region code: C1) purchased in U.S.A. cannot be played back by a player (region code: C2) purchased in Japan. The player has only one region code, but the content can have two or more region codes. If one of the plurality of region codes held in the content matches one region code held in the player, the content can be played back. That is, when the content has all region codes (defined in eight patterns in the DVD standard), it can be played back irrespective of the region codes.
The playback control based on the region codes so far is merely simple control to decide whether or not to play back.
A general architecture that implements the various features of the invention will now be described with reference to the drawings. The drawings and the associated descriptions are provided to illustrate embodiments of the invention and not to limit the scope of the invention.
Various embodiments according to the invention will be described hereinafter with reference to the accompanying drawings. In general, according to one embodiment of the invention, an information storage medium comprises a first area which stores playback control information used to control playback of contents, and a second area which stores a region flag indicating whether to enable or disable playback control based on a region code held in a player.
Embodiments according to the invention will be described hereinafter with reference to the accompanying drawings.
The points of this embodiment will be sorted out first.
By expanding and introducing a region code which is used to limit a reproducible region in a DVD into an HD DVD, playback control suited to each region (or along with the intentions of the contents producer, copyright holder, government, and the like) can be implemented.
(Point 1)
A flag which indicates whether to enable or disable playback control (region control) based on a region code is introduced into a reserve area of a setting file called DISCID.DAT in an information storage medium.
(Point 2)
A file (region file) used to branch a playlist (one of playback control files) loaded first according to a region code held in a player as an information playback apparatus is introduced.
(Point 3)
A property indicating a region code of a player is introduced into an API (a set of properties and functions which can be used in programming) for an HD DVD of a script (one of playback control files) included in playback control information.
In this way, a region control support player can execute playback control using that property, and a region control non-support player does not suffer any problem since a value “undefined” is merely set.
(Point 4)
An element which can be loaded by only a player having a specific region code is introduced into an XML (Extensible Markup Language) file (playlist, manifest, markup) included in the playback control information.
In this way, a region control support player can load that element, and a region control non-support player ignores that element.
(Point 5)
A region code attribute is introduced into respective elements of a playlist, manifest, and markup, and a player having a specific region code cannot load those elements.
The playback control information will be briefly complemented below. The playback control information includes a playlist, manifest, markup, script, and the like. The playlist is playback control information which controls whole playback, and can control to paste an application from a given time to another time, and so forth. The manifest is a list table of data used in that application. The markup is used to allocate elements on a window in the forms of buttons and the like. The script is playback control information which has various APIs such as a fastforward function, title jump function, and the like, and is used to execute processes using these APIs. For example, the script can pause playback at the 30th second using a timer.
With the above information, playback based on a region code on the information storage medium side (contents side) can be freely controlled. The DVD standard permits to play back a content only when a region code of a player matches that of the content, and inhibits playback when the two region codes do not match. By contrast, this embodiment allows advanced playback control according to a region code of a player. This advanced playback control not only permits or inhibits playback of a content in correspondence with a match or mismatch between region codes, but also displays a button background image X upon playback using a player with a region code n and a button background image Y upon playback using a player with a region code m.
The HD DVD is the next generation standard of a DVD, and is characterized by high-quality video and audio supports, improved interactiveness, network supports, and the like. Since a plenty of video and audio codecs (compression schemes) are supported, and fulfilling APIs (sets of properties and functions specified by the standard) are available, the contents producer can realize more attractive diversified contents. Due to these advances, transition from the existing DVD to the HD DVD is rapidly made.
The HD DVD standard specifies two different types of contents called a standard content and advanced content. The standard content is ranked as an expanded version of the existing DVD standard, has a data configuration close to the existing DVD, and readily gains the acceptance of a conventional DVD production studio and the like. The standard content has characteristic features of high-quality video and audio supports, expanded navigation commands (command group used in title jump, menus, and the like) that can be used, and the like. On the other hand, the advanced content is quite different from that of the existing DVD. The advanced content has a scheme for expressing playback control information using a programming language such as an XML (Extensible Markup Language) or ECMA (European Computer Manufacturer Association) script like home pages on the Internet in addition to the high-image quality video and audio supports of the standard content. Conventionally, all data required to play back a content need be loaded from a disc. However, the HD DVD advanced content can load data from a persistent storage (temporarily storage memory), and can download data from a network and can use them in playback in addition to a disc.
As described above, the HD DVD standard specifies the two different types of contents, which have different data structures and the like. This embodiment will explain the advanced content of these two different types of contents.
Since the HD DVD standard specifies two different types of contents, i.e., a standard content and advanced content, an HD DVD player executes, as start processing, a sequence for determining whether the content to be played back is a standard or advanced content, upon playback of the content. When the user inserts a disc, the player confirms if the content includes a file DISCID.DAT which describes an ID of an advanced content and the like. If the content includes this file, the player identifies that the content to be played back is an advanced content. If the content does not include any DISCID.DAT, the player confirms if ID information VMG_ID of a standard content is valid. If the ID information is valid, the player determines a standard content; otherwise, it determines an unknown content (neither an advanced content nor a standard content of the HD DVD). Since the invention targets at an advanced content of the HD DVD, the following description will be made under an assumption that the inserted disc is an advanced content.
Playlist: a playback control file described using an XML language.
DISCID.DAT: a setting file that describes a disc ID, provider ID, and the like.
Primary video set: made up of primary audio video data including video and audio data used in playback. The primary audio video data is configured by a main video (main video), main audio (main audio), sub video (sub video), sub audio (sub audio), sub-picture (subtitle), and the like.
Secondary video set: made up of video and audio data for the purpose of substitutions of a primary video set. The secondary video set includes three types, i.e., a substitute audio video (which substitutes a main video and main audio), a substitute audio (which substitutes a main audio), and a secondary audio video (which substitutes a sub video and sub audio).
Advanced application: data for an application used to allocate menu buttons on a screen and to make a trick play. The advanced application is configured by a manifest (an XML file used to specify use of data and the like in the application), a markup (an XML file used to specify button layouts, timing processing, and the like), a script (a playback control file described using an ECMA script), an image file, an effect audio (an effect sound audio file), fonts (Open-type fonts used to display messages on a screen and the like), and the like.
Advanced subtitle: a subtitle that can be described like an application using an XML in addition to a subtitle (sub-picture) synchronized with a video stream. A markup for an advanced subtitle obtained by specializing the markup for the advanced application to a subtitle is used.
The root directory of the advanced content is classified into three areas. The first area is an HVDVD_TS directory area which stores a primary video set. The second area is an ADV_OBJ directory area which stores data such as a playlist, DISCID.DAT, advanced application, advanced subtitle, secondary video set, and the like. The third area is a user defined area for other data. As in the example of
Note that a region file to be described later is included in the HD DVD advanced content, and is stored under, e.g., the ADV_OBJ directory. Alternatively, the region file may be stored under the HVDVD_TS directory or the ADV_OBJ directory. Alternatively, the region file may be stored in the user defined area.
S1: The player loads a DISCID.DAT file. After loading, the process advances to B1.
B1: To branch the processes, the player checks whether or not a display is defined. If the display is defined, the process advances to branch process in B2; otherwise, the process advances to branch process in B4.
B2: To branch the processes, the player checks whether or not SEARCH.FLG (a flag indicating if persistent storages are searched for an initial playlist; details of the data structure of the DISCID.DAT will be described later) is specified in the DISCID.DAT file is 1. If SEARCH.FLG=1, the process jumps to processing in S3; if SEARCH.FLG=0, the process advances to processing in S2.
S2: The player searches for playlist files (VPLST$$$.XPL) stored under specific directories of all persistent storages. After the processing, the process advances to S3.
S3: The player searches for playlist files (VPLST$$$.XPL) stored immediately under the ADV_OBJ directory in the disc. After the processing, the process advances to B3.
B3: To branch the processes, the player checks if one or more files VPLST$$$.XPL are found. If one or more files are found, the process advances to S4; if no file is found, the process advances to B4.
S4: The player starts playback using a file with a largest number of the found files VPLST$$$.XPL as an initial playlist.
B4: To branch the processes, the player checks whether or not SEARCH.FLG (a flag indicating if persistent storages are searched for an initial playlist; details of the data structure of the DISCID.DAT will be described later) is specified in the DISCID.DAT file is 1. If SEARCH.FLG=1, the process jumps to processing in S6; if SEARCH.FLG=0, the process advances to processing in S5.
S5: The player searches for playlist files (APLST$$$.XPL) stored under specific directories of all persistent storages. After the processing, the process advances to S6.
S6: The player searches for playlist files (APLST$$$.XPL) stored immediately under the ADV_OBJ directory in the disc. After the processing, the process advances to B5.
B5: To branch the processes, the player checks if one or more files APLST$$$.XPL are found. If one or more files are found, the process advances to S7; if no file is found, the process advances to S8.
S7: The player starts playback using a file with a largest number of the found files APLST$$$.XPL as an initial playlist.
S8: The player has failed the startup processing. The subsequent operation depends on the player.
As shown in
The advanced content allows to load data from a persistent storage (temporary storage memory) and to download data from a network in addition to data loading from a disc. Data according to the HD DVD format stored in these data sources are distributed to the navigation manager 2, data cache 4, and presentation engine 5 via the unit called the data access manager 3 which controls data accesses. The navigation manager 2 executed playback control. Playback control files described in XML and ECMA scripts and the like (playlist, manifest, markup, script, and the like) are sent from the data access manager 3 to this navigation manager 2 (not directly but after they are temporarily loaded in the data cache 4 in some cases), and their substances are interpreted. Instructions based on the interpreted playback control information are output to the presentation engine 5 and are used in playback control. Upon reception of a user operation such as a button operation of a remote controller or the like, the navigation manager 2 converts that operation into a playback control instruction, and outputs the instruction to the presentation engine 5. The data cache 4 is a memory which temporarily stores data used in playback. The presentation engine 5 determines actual video and audio outputs based on the playback control instructions and data (primary video set, secondary video set, and the like) used in playback, and converts video and audio data into information that can be used in playback. Since data for playback which are originally stored in a disc or the like are obtained by multiplexing video and audio data and the like, they cannot be used in playback intact. Hence, the presentation engine 5 executes processing (called demax processing) for selecting video and audio data and the like required for playback, and demultiplexing the multiplexed data. Since data generated by the above processing are encoded by various codecs (compression schemes), the presentation engine 5 decodes these data. The presentation engine 5 sequentially outputs playback data and the like to the AV renderer 6, which executes video superimposing processing and audio mixing processing, based on the data generated in this way and the playback control instructions from the navigation manager 2. Then, video and audio are output from a television monitor and loudspeakers in accordance with signals from the AV renderer 6.
The DISCID.DAT is a setting file used to set a contents ID, the location of a source from which a playlist is to be loaded, and the like.
CONFIG_ID: an ID of the setting file (12 bytes). This ID describes “HDDVD-V_CONF” using an IS08859-1 character code.
DISC_ID: an ID of the disc described by binary expression (16 bytes). This ID is padded by “1b” if a network is not used.
PROVIDER_ID: an ID of a provider described by binary expression (16 bytes). This ID is padded by “1b” if the provider ID directory in the persistent storage is not used.
CONTENT_ID: an ID of a content described by binary expression (16 bytes). This ID is padded by “1b” if the provider ID directory in the persistent storage is not used.
SEARCH_FLG: a flag indicating whether or not to search the persistent storage upon conducting an initial playlist search in the startup processing (1 byte). This flag describes “0b” if the persistent storage is not searched, and “1b” if it is searched.
reserved: 67 bytes are left as a reserved area.
A playlist is a playback control file used to describe information associated with initial system settings, synchronization information among objects used in playback, and the like. The playlist is described using an XML language, and stores playback control information indicating playback timings of a primary video set, secondary video set, advanced application, advanced subtitle, and the like (
The object mapping information as one type of title element information describes information associated with the playback start and end times of objects such as video and audio objects, advanced application, advanced subtitle, and the like, information of files used in their playback, and the like (
Elements that can be described as the object mapping information include a <PrimaryAudioVideoClip> element (which describes information of the playback start and end times of a primary audio video, the URI indicating the storage location of the object as a file, and the like), a <SubstituteAudioVideoClip> element (which describes information of the playback start and end times of a substitute audio video, the URI indicating the storage location of the object as a file, and the like), a <SubstituteAudioClip> element (which describes information of the playback start and end times of a substitute audio, the URI indicating the storage location of the object as a file, and the like), a <SecondaryAudioVideoClip> element (which describes information of the playback start and end times of a secondary audio video, the URI indicating the storage location of the object as a file, and the like), an <AdvancedSubtitleSegment> element (which describes information of the playback start and end times of an advanced subtitle, the URI indicating a manifest file of the advanced subtitle, and the like), an <ApplicationSegment> element (which describes information of the playback start and end times of an advanced application, the URI indicating a manifest file of the advanced application, and the like), and the like (
The advanced application described as the object mapping information of the title element information is called a title application. The title application is valid only during playback of the corresponding title (strictly speaking, only between the playback start and end times specified by the <ApplicationSegment> element). By contrast, an advanced application which is valid all the time during playback of the playlist is called a playlist application. Information associated with the playlist application can be described in the form of a <PlaylistApplication> element as a child element of the <TitleSet> element (
The <ApplicationSegment> element of the playlist designates a manifest file used in the corresponding application. The manifest is initialization information of the advanced application. The player launches the advanced application in accordance with information described in the manifest. The manifest describes information associated with a markup to be executed first, information associated with a script (plural designations allowed) executed in application start processing, and the like using an XML language.
A root element of the manifest is an <Application> element. As child elements of the <Application> element, an region element <Region>, script element <Script>, markup element <Markup>, and resource element <Resource> can be described. A plurality of <Script> and <Resource> elements can be described. One <Region> element need be inevitably described, and zero or one <Markup> element need be described.
The <Region> element specifies a region on a canvas of the application. The <Script> element designates a script file (details will be described later) used in the application. The <Markup> element designates a markup file used in the application. The <Resource> element designates all resources (including the script file and markup file in addition to image data, font data, and the like) used in the application.
The markup is a playback control file described using an XML language. The markup is used to allocate buttons on a window or to display a message. A plurality of markups cannot be played back at the same time for one advanced application.
A root element of the markup is <root>, and timing information, styling information, content information, and the like are described as its child elements (
The script is a playback control file described using an ECMA script. In the HD DVD, properties and functions unique to the HD DVD can be used in addition to properties (values that can be referred to by names: for example, a Player.countryCode property stores a country code of the player) functions (processing: for example, when a Player.playlist.pause( ) function is called, playback is paused) specified by the ECMA script standard. A set of properties and functions that can be used is called an API.
As shown in
Application API
specifies objects and the like that can be used by the application
System API
specifies a string array, timer, and the like that can be used in the HD DVD system
File IO API
specifies input/output functions and the like to the persistent storage
Diagnostics API
specifies objects and the like mainly used for debugging upon development of a player
Controller API
specifies actions associated with remote controller keys, a mouse cursor, and the like
Drawing API
specifies functions and the like used upon drawing graphics on a window
Network API
specifies functions and the like used to download playback data from locations on the Internet
Data Cache API
specifies properties and the like upon acquiring the size of the data cache (temporary storage memory)
Player API
specifies playback control functions and the like such as fastforward, title jump, video size conversion, and the like
Persistent Storage API
specifies properties and the like upon acquiring information associated with the persistent storage
XML API
specifies functions and the like used to manipulate information such as a markup or the like described using an XML language
Animated Property API
specifies functions and the like used to acquire and set elements and attributes described in the markup
Using these APIs, various actions such as storage of one frame of video data which is being played back in the persistent storage as a still image, drawing a picture on a window, changing message text displayed by the markup, and the like, can be implemented.
The region control means control of playback according to a region code held in each player. This embodiment expands the region control adapted in the existing DVD standard, and introduces the expanded control to the HD DVD standard. Since there are eight region codes 1 to 8 in the existing DVD standard, the invention also will give an explanation using eight region codes 1 to 8. Of course, if number of region codes increases, the invention is applicable.
The region control in the existing DVD standard merely allows only two branches, i.e., to permit a given player to play back a content and to inhibit another player from playing back that content. As shown in
If the player detects an unknown element in association with an XML file (playlist, manifest, markup), it does not load that element (and does not load its descendant elements if any).
If the player detects an unknown attribute in association with an XML file (playlist, manifest, markup), it does not load that attribute (but loads an element itself which is set with that attribute).
If the player detects an unknown property in association with a script file, it returns a value “undefined” specified by the ECMA script standard.
If an unknown function is called in association with a script file, an exception (exceptional error) occurs.
Values in areas defined as “reserved” in the HD DVD standard in all files which configure a content do not impose any influence on playback.
In order to implement playback control based on a region code, the player holds a region code. The storage unit (unit for holding player settings and settings associated with playback) 1 shown in
The player holds only one region code. As described above, the region code assumes any one of integer values “1” to “8” according to the existing DVD standard, and a player which does not support region control does not hold any region code value (it never refers to such value since it does not support the region control). A description of the following embodiments will be given under the assumption that the region code value falls within a range from 1 to 8. However, that value range may be changed.
The way the player holds the region code does not influence playback and the invention.
The region flag (which indicates whether to enable or disable the region control) is introduced into the DISCID.DAT as the setting file shown in
Since the region flag produces effects in combination with some embodiments to be described later, a description thereof will be given later together with the description of these embodiments.
In order to control an initial playlist (a playlist to be loaded first) to branch according to the region code of the player, a file (to be referred to as a region file hereinafter) which stores list information indicating region codes of players and the URIs (file locations) of corresponding initial playlists is introduced (
The file name of the region file is, for example, RGN$$$.XRG ($$$: 000 to 999). The advanced contents playback startup processing is executed, as described in the flowchart shown in
The region file can be updated by downloading it from the Internet to the persistent storage in the same manner as other files. In this case, a plurality of region files may be stored. Details such as selection of a region file to be used will be described later in “flowcharts showing the processing for controlling an initial playlist based on a region code”.
B1: The player checks, using the flowchart of
S1: The player loads the DISCID.DAT. The process advances to B2.
B2: If the player supports region control, the process advances to B3. If the player does not support region control, the process advances to initial playlist branch processing in normal playback (B5 in
B3: If the region flag of the DISCID.DAT is “1”, the process advances to initial playlist branch processing based on a region code (S2 in
S2: The player searches for region files RGN$$$.XRG stored under specific directories in all persistent storages, and the process then advances to S3.
S3: The player searches for a region file RGN$$$.XRG stored immediately under the ADV_OBJ directory in the disc, and the process advances to B4.
B4: If one or more region files RGN$$$.XRG are found, the process advances to S4; if no region file is found, the process advances to the initial playlist branch processing in normal playback (B5 in
S4: The player loads a region file RGN$$$.XRG with a largest number of $$$ of the found region files. The process advances to S5.
S5: The player acquires its region code, and the process advances to S6.
S6: The player selects an initial playlist according to the description of the loaded region file, and starts playback.
B5: If a display is defined, the process advances to B6; otherwise, the process advances to B8.
B6: If the search flag SEARCH_FLG of the DISCID.DAT is “0”, the process advances to S7; if SEARCH_FLG=“1”, the process jumps to S8.
S7: The player searches for playlists VPLST$$$.XPL stored under specific directories of all persistent storages, and the process advances to S8.
S8: The player searches for playlists VPLST$$$.XPL stored immediately under the ADV_OBJ directory in the disc, and the process advances to B7.
B7: If one or more playlists VPLST$$$.XPL are found, the process advances to S9; if no playlist is found, the process advances to B8.
S9: The player starts playback using a playlist with a largest number of $$$ of the found files VPLST$$$.XPL as an initial playlist.
B8: If the search flag SEARCH_FLG of the DISCID.DAT is “0”, the process advances to S10; if SEARCH_FLG=“1”, the process jumps to S11.
S10: The player searches for playlists APLST$$$.XPL stored under specific directories of all persistent storages, and the process advances to S11.
S11: The player searches for playlists APLST$$$.XPL stored immediately under the ADV_OBJ directory in the disc, and the process advances to B9.
B9: If one or more playlists APLST$$$.XPL are found, the process advances to S12; if no playlist is found, the process advances to S13.
S12: The player starts playback using a playlist with a largest number of $$$ of the found playlists APLST$$$.XPL as an initial playlist.
S13: The player has failed the startup processing. The subsequent operation depends on the player.
With this processing, a player which does not support region control executes normal playback. A player which supports region control and plays back a content with a region flag “0” also executes normal playback. A player which supports region control and plays back a content with a region flag “1” executes playback according to its region code. The merit of this embodiment lies in that the playback control based on a region code can be implemented without modifying the substance of the content (without changing the data structure described so far) by introducing only the region flag and region file. Also, as another merit, since the control can branch based on the region code at the time of the playback startup processing, the effects resulting from introduction of the region code can be achieved for the entire playback processing. In addition, this embodiment can assure compatibility with a player which does not support region control.
Region block information <RegionBlock><region> is introduced to the data structure of each XML file (playlist, manifest, markup) shown in
As a child element of the <RegionBlock> element, a <region> element can be described. The <region> element can only be described as the child element of the <RegionBlock> element. As the child elements of one <RegionBlock> element, one or more <region> elements can be described up to a maximum of eight.
The <region> element can have a “code” attribute. As the value of the “code” attribute, a plurality of integer values ranging from 1 to 8 can be designated by delimiting them by spaces (example: code=“1 2 5 8”).
Child elements of the <region> element in one <RegionBlock> element have to be the same elements.
A player which does not support region control cannot load the <RegionBlock> element (and its child elements).
When a player which supports region control plays back a content with a region flag “0” of the DISCID.DAT, it cannot load the <RegionBlock> element (and its child elements).
When a player which supports region control and plays back a content with a region flag “1” of the DISCID.DAT, it can load the <RegionBlock> element (and its child elements), and compares the “code” attribute values of the <region> elements with its region code to load child elements whose “code” attribute values match the region code. Note that the <RegionBlock> and <region> elements are used to branch processes by seeing if the child elements of the <region> elements are to be loaded, and do not influence playback after the branch processing.
When child elements of each <region> element in <RegionBlock> are the same as an element immediately before <RegionBlock>, the player does not load the element immediately before <RegionBlock> but loads child elements of the <region> element which is permitted to load.
When child elements of each <region> element in <RegionBlock> are different from an element immediately before <RegionBlock>, the player loads the element immediately before <RegionBlock>, and also loads child elements of the <region> element which is permitted to load.
When child elements of each <region> element in <RegionBlock> are empty, the player does not load an element immediately before <RegionBlock>.
Since the <RegionBlock> and <region> elements themselves are not loaded (they are not added to a tree), both a player which supports region control and a player which does not support region control can progress the playback processing in the same routine after loading of XML data.
After the loading processing, each XML file has to have a description according to the rules of XML files shown in
B1: If the player supports region control, the process advances to B2; if it does not support region control, the control skips that <RegionBlock> and starts the next loading processing.
B2: If the region flag of the DISCID.DAT is “1”, the process advances to B3; if it is “0”, the control skips that <RegionBlock> and starts the next loading processing.
B3: If child elements of <region> are not empty, the process advances to B4; if all child elements are empty, the process advances to S1.
S1: The player deletes the element immediately before <RegionBlock> from the tree, and starts the next loading processing of <RegionBlock>.
B4: If the element immediately before <RegionBlock> is the same as child elements of <region>, the process advances to S2; if they are different, the process advances to S3.
S2: The player deletes the element immediately before <RegionBlock> from the tree, and the process advances to S3.
S3: The player compares the “code” attribute values of <region> with its region code and adds child elements of <region> whose “code” attribute value matches the region code. The control then starts the next loading processing of <RegionBlock>.
The fourth to 15th lines describe a region block. Since a child element of <region> is <Title> and matches that of an element <Title> immediately before <RegionBlock>, <Title> immediately before <RegionBlock> is deleted. Since the region code of the player is “5”, <Title> of the child element bounded by <region code=“5 6 7 8”> and </region> is loaded.
The 18th to 29th lines also describe a region block. Since a child element <ApplicationSegment> of <region> does not match an element <PrimaryAudoVideoClip> immediately before <RegionBlock>, <PrimaryAudoVideoClip> is loaded, and the child element <ApplicationSegment> bounded by <region code=“3 5”> and </region> is loaded. Then, the result of the aforementioned loading processing is as shown in the right drawing of
A region property “region” used to implement region control is introduced to the API group shown in
The region property stores the region code of the player as a value of readonly unsigned int type (1 to 8). The content side cannot rewrite this value, and in case of a player which does not support region control and the region flag “0” of the DISCID.DAT, the region property stores an “undefined” value.
Based on the substance of the region property, the region property is introduced as the member of the Player object. However, if the region property is added as members of other objects, the function of the region property remains the same, and can be used in region control.
As described above, the region property can be used in various applications such as branch processing on the title level, that on the function level, i.e., video capture, and the like.
An element (region control element), which can be controlled to be loaded or not to be loaded according to the region code of a player, is introduced to each playback control XML file (playlist, manifest, markup) of the HD DVD shown in
Note that the region control element can be set with an attribute “regionCode” in addition to those of the source element. In the “regionCode” attribute, a plurality of integer values ranging from 1 to 8 can be set by delimiting them by spaces (for example: “3 7 8”).
A player, which does not support region control, does not load that element irrespective of the “regionCode” attribute value.
A player, which supports region control and plays back a content with the region flag “0”, does not load that element irrespective of the “regionCode” attribute value.
A player, which supports region control and plays back a content with the region flag “1”, compares the “regionCode” attribute value with its region code, and loads an element whose “regionCode” attribute value matches the region code or does not load the element if any “regionCode” attribute value does not match the region code (for example: when regionCode=“1 2 3 4”, if the region code of a player is 1, 2, 3, or 4, the player loads that element; if the region code is 5, 6, 7, or 8, the player does not load the element).
When the region control element is loaded, since it is handled as one of source elements, the contents producer need care about the limitations on the number of elements and the like. For example, a playlist has to have only one <TitleSet> element. When <RegionTitleSet regionCode=“3”> is described in addition to the description of <TitleSet>, if the region flag is “1” and the region code is “3”, the number of <TitleSet> elements is two, resulting in a violation. Hence, such description is inhibited. However, this embodiment is not always limited to this inhibition rule, and this inhibition rule is merely one scheme upon management. A “titleNumber” attribute of a <Title> element of a playlist has to be assigned in turn from 1. When <RegionTitle titleNumber=“1” regionCode=“4”> is described in addition to the description of <Title titleNumber=“1”>, if a player with the region code “4” plays back a content with the region code “1”, titleNumber=“1” appears twice, resulting in a violation. Hence, such description is inhibited. However, this embodiment is not always limited to this inhibition rule, and this inhibition rule is merely one scheme upon management.
As shown in
When a player does not support region control, it ignores the region code attribute.
Even when a player supports the region control, if the region flag is “0”, the region code attribute is ignored.
Only when a player supports a region code, and the region flag is “1”, the player compares the region code attribute value with its region code. If the region code attribute value set in elements matches the region code, the player does not load these elements; otherwise, the it loads these elements.
However, the contents producer has to consider that such elements are not loaded depending on the region code. For example, a “titleNumber” attribute of a <Title> element of a playlist has to be assigned in turn from 1. If the contents producer describes <Title titleNumber=“1”>, <Title titleNumber=“2” regionCode=“1”>, <Title titleNumber=“3”>, and the like in a content, if he or she plays back that content using a player with the region code “1”, a title “titleNumber2” is not loaded. Hence, such description is inhibited. However, this embodiment is not always limited to this inhibition rule, and this inhibition rule is merely one scheme upon management.
In the description of this example, a sub video and sub audio of <SecondaryAudioVideoClip> are simultaneously played back in addition to a main video and main audio of a primary audio video clip (<PrimaryAudioVideoClip>). However, since <SecondaryAudioVideoClip> is set with regionCode=“1 2”, when the region flag is “1” and the region code of a player is “1” or “2”, <SecondaryAudioVideoClip> is not loaded and the sub video and sub audio are not played back. In this way, by introducing the region code attribute to the secondary audio video clip element, playback of the sub video and sub audio can be limited.
In this example, a script “script1.js” and a markup “markup1.xmu” are executed as applications. However, since <Markup> is set with regionCode=“5 6 7 8”, when the region flag is “1” and the region code of a player is “5”, “6”, “7”, or “8”, the <Markup> element is not loaded, and that markup is not executed. In this way, by introducing the region code attribute to the markup element, a limitation can be imposed when, for example, a button set by the markup is not to be played back by a player with a specific region code.
In this example, a button with an ID “button1” is allocated at the center of a window to have a still image “photo01.jpg” pasted on the full window as a background. However, since <object> is set with regionCode=“8”, when the region flag is “1” and the region code of a player is “8”, the still image object is not loaded, and “photo01.jpg” is not displayed. In this way, by introducing the region code attribute to the object element, a limitation can be imposed so that a player with a specific region code is inhibited from displaying an image.
Assume that five playlists VPLST001.XPL, VPLST002.XPL, VPLST010.XPL, VPLST123.XPL, and VPLST198.XPL are present on a disc or persistent storage. When a player supports region control and the region flag is “1”, the region file is loaded, and VPLST001.XPL is loaded as an initial playlist for region “1” or “2” or VPLST002.XPL for region “3”, “4”, or “5”, according to the description of the region file. In case of region “6”, “7”, or “8”, since “none” is described in the region file, playback is not executed. On the other hand, when a player does not support region control or when the region flag is “0”, since a playlist with a maximum number of these playlists is loaded as an initial playlist, VPLST198.XPL is loaded in this embodiment. After the initial playlist is determined, playback according to that playlist then starts.
When a markup includes a description for setting a video capture button, and a script includes a description for enabling that button (to execute video capture) only when the region code of a player is “2” or “5”, no event is issued in normal playback (when the region is other than “2” or “5”, when a player does not support region control, or the like) even when the user presses the capture button. When a player with the region code “2” or “5” plays back that content, if the user presses the capture button, playback is paused and one scene is saved in the persistent storage as a still image.
This setting is effective when the contents producer does not want to present a certain scene for a specific region code. By contrast, since a jump destination is set as a title of a special content, the special content can be presented only for a specific region code.
In this manner, in case of only a specific region code, a button or the like appears, and a special function can be used.
As described above, by introducing the playback control function based on a region code to the HD DVD, more advanced playback control can be implemented in place of the two-branch control, i.e., “to play back” and “not to play back”. The invention also assures compatibility with a player which does not support playback control based on a region code. A player which does not support region control can play back a content including a scheme for region control without posing any problem (of course, when the contents producer wants to inhibit playback using a player which does not support region control, he or she can produce such content). In addition, by introducing a flag used to enable or disable the region control, two types of contents with and without region control can be easily produced.
While certain embodiments of the inventions have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modification as would fall within the scope and spirit of the inventions.
Number | Date | Country | Kind |
---|---|---|---|
2007-004907 | Jan 2007 | JP | national |