Patent Application
20140229819
Multimedia players are devices that render combinations of video, audio or data content (“multimedia presentations”) for consumption by users. Multimedia players such as DVD players currently do not provide for much, if any, user interactivity during play of video content—video content play is generally interrupted to receive user inputs other than play speed adjustments. For example, a user of a DVD player must generally stop the movie he is playing to return to a menu that includes options allowing him to select and receive features such as audio commentary, actor biographies, or games.
Interactive multimedia players are devices (such devices may include hardware, software, firmware, or any combination thereof) that render combinations of interactive content concurrently with traditional video, audio or data content (“interactive multimedia presentations”). Although any type of device may be an interactive multimedia player, devices such as optical media players (for example, DVD players), computers, and other electronic devices are particularly well positioned to enable the creation of, and consumer demand for, commercially valuable interactive multimedia presentations because they provide access to large amounts of relatively inexpensive, portable data storage.
Interactive content is generally any user-selectable visible or audible object presentable alone or concurrently with other video, audio or data content. One kind of visible object is a graphical object, such as a circle, that may be used to identify and/or follow certain things within video content—people, cars, or buildings that appear in a movie, for example. One kind of audible object is a click sound played to indicate that the user has selected a visible object, such as the circle, using a device such as a remote control or a mouse. Other examples of interactive content include, but are not limited to, menus, captions, and animations.
To enhance investment in interactive multimedia players and interactive multimedia presentations, it is desirable to ensure accurate synchronization of the interactive content component of interactive multimedia presentations with the traditional video, audio or data content components of such presentations. Accurate synchronization generally prioritizes predictable and glitch-free play of the video, audio or data content components. For example, when a circle is presented around a car in a movie, the movie should generally not pause to wait for the circle to be drawn, and the circle should follow the car as it moves.
Many interactive multimedia environments are currently implemented or planned for implementation on “thin” players, or computing platforms that are purposely resource-constrained in terms of processing power, memory and other resources, often for cost reasons. To efficiently utilize available resources, it can be desirable for applications running on the players to use a declarative approach which often results in simpler and less processor intensive programming.
In a declarative programming paradigm, the semantics required to attain the desired outcome are implicit in the description of the outcome. It is not usually necessary to provide a separate procedure (i.e., write a script or embed executable code) to get the desired outcome. An application author uses declarative programming to generate declarative content which is typically expressed in the form of assertions.
For example, web pages are often considered declarative because they describe what the page should look like—e.g., title, font, text, images—but do not describe how to actually render the graphics and web pages on a computer display. Another application, such as a browser or interactive media player application, takes declarative content to render the graphics to meet the author's objectives.
A declarative approach is in contrast to a procedural approach (also called an “imperative” approach) using traditional languages such as Fortran, C, and Java, which generally require the programmer to specify an algorithm to be run to control or manipulate the interactive media player. Thus, declarative programs make the goal explicit and leave the algorithm implicit, while imperative programs make the algorithm explicit and leave the goal implicit. It is noted that an application need not be purely declarative or purely procedural. Declarative applications often make use of script, which is itself procedural in nature, and a procedural object may be embedded in a declarative application.
Common examples of declarative programming languages include HTML (HyperText Markup Language) and XML (eXtensible Markup Language). These are both markup languages which combine text and information that supplements or describes the text called “tags.” XML is the newer language which is seeing increased use to create graphics, user interfaces, web services (such as electronic shopping and web searches) and other functions because of its extensibility through its support for the user-creation of tags that are described and defined as to their permitted use.
XML thus provides a flexible and straightforward tool for applications to generate interactive experiences for users. However, due to the inherent declarative nature of markup languages, it may presently be difficult for authors to write applications that are able to respond to changes in the interactive multimedia environment. That is, interactive multimedia typically operates in a dynamic environment where states of applications running on the player change as video content progresses and the system (i.e., the player and its applications) receives events such as user inputs. Accordingly, while many interactive multimedia arrangements perform very satisfactorily, it would still be desirable for arrangements using a declarative approach to be able to capture and respond to state changes in the environment while preserving a high degree of resource efficiency.
It will be appreciated that the claimed subject matter is not limited to implementations that solve any or all of the disadvantages of specific interactive multimedia presentation systems or aspects thereof.
Using declarative language application instructions, actions associated with playing interactive content of an interactive multimedia presentation are conditionally triggered based on a state change of a particular media object. Media objects include, for example, user-selectable visible or audible objects that are typically presented concurrently with video in the interactive multimedia presentation. Certain declarative application instructions specify the characteristic of the media object, while other declarative application instructions specify the actions associated with playing or rendering the interactive content based on one or more attribute state changes. The state change is detected, in one illustrative example, by querying a structured representation of the application such as a document object model (“DOM”), which includes nodes associated with the application instructions, the media object, and/or the characteristic. When state changes are detected, one or more of the specified actions are triggered to thereby declaratively respond to the state change.
In an illustrative example, content element attributes include those selected from foreground, enabled, focused, actioned, pointer and value which are arranged in a DOM and recursively introspected using an XPATH query. Values associated with these attributes typically change over the course of an interactive media presentation and such values determine how user interactions or events are distributed to applications running in the interactive multimedia presentation.
This Summary is provided to introduce a selection of concepts in a simplified form. The concepts are further described in the Detailed Description section. Elements or steps other than those described in this Summary are possible, and no element or step is necessarily required. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended for use as an aid in determining the scope of the claimed subject matter.
In general, an interactive multimedia presentation includes a video content component and an interactive content component. The video content component is referred to as a movie for illustrative purposes, but may in fact be video, audio, data, or any combination thereof.
The interactive content component of the presentation, which is arranged for rendering by an interactive content manager at a rate based on a timing signal, is in the form of one or more applications. An application includes instructions in declarative form (e.g., an XML “markup”) or in script form. The application instructions are provided for organizing, formatting, and synchronizing the presentation of media objects to a user, often concurrently with the video content component. Both the script and markup components of an application may invoke a variety of methods or services through the use of a script API (application programming interface) or markup API, respectively.
Methods, systems, apparatuses, and articles of manufacture discussed herein use application instructions in declarative form to trigger actions associated with playing the interactive content component of an interactive multimedia presentation. Examples of application instructions usable as described above include markup elements and attributes. Characteristics of media objects may be specified by style or non-style attributes of content elements associated with the media objects. Some useful attributes are defined by one or more XML schemas. For example, one or more XML schemas promulgated by the DVD Forum set forth attributes that change values based on user input received during play of an interactive high-definition DVD movie. Actions associated with playing interactive content may further be specified within timing, style and animation elements. Some elements usable in this manner are set forth in XML schemas promulgated by the DVD Forum.
Other elements are defined by XML schemas for Synchronized Multimedia Integration Language (“SMIL”), which are published by the World Wide Web Consortium (“W3C”). XPATH queries may be used to query structured representations of applications such as DOMs to detect values of attributes and changes in such values.
Turning now to the drawings, where like numerals designate like components,
In operation, Presentation System 100 handles interactive multimedia presentation content (“Presentation Content”) 120. Presentation Content 120 includes a video content component (“video component”) 122 and an interactive content component (“IC component”) 124. Video component 122 and IC component 124 are generally, but need not be, handled as separate data streams, by AVC manager 102 and IC manager 104, respectively.
Presentation System 100 also facilitates presentation of Presentation Content 120 to a user (not shown) as played presentation 127. Played Presentation 127 represents the visible and/or audible information associated with Presentation Content 120 that is produced by mixer/renderer 110 and receivable by the user via devices such as displays or speakers (not shown). For discussion purposes, it is assumed that Presentation Content 120 and played presentation 127 represent high-definition DVD movie content, in any format. It will be appreciated, however, that Presentation Content 120 and Played Presentation 127 may be any type of interactive multimedia presentation now known or later developed.
Video component 122 represents the traditional video, audio or data components of Presentation Content 120. For example, a movie generally has one or more versions (a version for mature audiences, and a version for younger audiences, for example); one or more titles 131 with one or more chapters (not shown) associated with each title (titles are discussed further below, in connection with presentation manager 106); one or more audio tracks (for example, the movie may be played in one or more languages, with or without subtitles); and extra features such as director's commentary, additional footage, trailers, and the like. It will be appreciated that distinctions between titles and chapters are purely logical distinctions. For example, a single perceived media segment could be part of a single title/chapter, or could be made up of multiple titles/chapters. It is up to the content authoring source to determine the applicable logical distinctions. It will also be appreciated that although video component 122 is referred to as a movie, video component 122 may in fact be video, audio, data, or any combination thereof.
Groups of samples of video, audio, or data that form video component 122 are referred to as clips 123 (clips 123 are shown within video component 122, AVC manager 102, and playlist 128). Referring to AVC manager 102, information associated with clips 123 is received from one or more media sources 160 and decoded at decoder blocks 161. A media source is any device, location, or data from which video, audio, or data is derived or obtained. Examples of media sources include, but are not limited to, networks, hard drives, optical media, alternate physical disks, and data structures referencing storage locations of specific video, audio, or data.
Decoder blocks 161 represent any devices, techniques or steps used to retrieve renderable video, audio, or data content from information received from a media source 160. Decoder blocks 161 may include encoder/decoder pairs, demultiplexers, or decrypters, for example. Although a one-to-one relationship between decoders and media sources is shown, it will be appreciated that one decoder may serve multiple media sources, and vice-versa.
Audio/video content data (“A/V data”) 132 is data associated with video component 122 that has been prepared for rendering by AVC manager 102 and transmitted to mixer/renderer 110. Frames of A/V data 134 generally include, for each active clip 123, a rendering of a portion of the clip. The exact portion or amount of the clip rendered in a particular frame may be based on several factors, such as the characteristics of the video, audio, or data content of the clip, or the formats, techniques, or rates used to encode or decode the clip.
Referring again to Presentation Content 120, IC component 124 includes media objects 125, which are user-selectable visible or audible objects, optionally presentable concurrently with video component 122, along with any instructions (shown as applications 155 and discussed further below) for presenting the visible or audible objects. Media objects 125 may be static or animated. Examples of media objects include, among other things, video samples or clips, audio samples or clips, graphics, text, and combinations thereof.
Media objects 125 originate from one or more sources (not shown). A source is any device, location, or data from which media objects are derived or obtained. Examples of sources for media objects 125 include, but are not limited to, networks, hard drives, optical media, alternate physical disks, and data structures referencing storage locations of specific media objects. Examples of formats of media objects 125 include, but are not limited to, portable network graphics (“PNG”), joint photographic experts group (“JPEG”), moving picture experts group (“MPEG”), multiple-image network graphics (“MNG”), audio video interleave (“AVI”), extensible markup language (“XML”), hypertext markup language (“HTML”), extensible HTML (“XHTML”), extensible stylesheet language (“XSL”), and WAV.
Applications 155 provide the mechanism by which Presentation System 100 presents media objects 125 to a user. Applications 155 represent any signal processing method or stored instruction(s) that electronically control predetermined operations on data. It is assumed for discussion purposes that IC component 124 includes three applications 155, which are discussed further below in connection with
Interactive content data (“IC data”) 134 is data associated with IC component 124 that has been prepared for rendering by IC manager 104 and transmitted to mixer/renderer 110. Each application has an associated queue (not shown), which holds one or more work items (not shown) associated with rendering the application.
Presentation manager 106, which is configured for communication with both AVC manager 104 and IC manager 102, facilitates handling of Presentation Content 120 and presentation of played presentation 127 to the user. Presentation manager 106 has access to a playlist 128. Playlist 128 includes, among other things, a time-ordered sequence of clips 123 and applications 155 (including media objects 125) that are presentable to a user. The clips 123 and applications 155/media objects 125 may be arranged to form one or more titles 131. For illustrative purposes, one title 131 is discussed herein. Playlist 128 may be implemented using an extensible markup language (“XML”) document, or another data structure.
Presentation manager 106 uses playlist 128 to ascertain a presentation timeline 130 for title 131. Conceptually, presentation timeline 130 indicates the times within title 131 when specific clips 123 and applications 155 are presentable to a user. A sample presentation timeline 130, which illustrates illustrative relationships between presentation of clips 123 and applications 155 is shown and discussed in connection with
Presentation manager 106 provides information, including but not limited to information about presentation timeline 130, to AVC manager 102 and IC manager 104. Based on input from presentation manger 206, AVC manager 102 prepares A/V data 132 for rendering, and IC manager 104 prepares IC data 134 for rendering.
Timing signal management block 108 produces various timing signals 158, which are used to control the timing for preparation and production of A/V data 132 and IC data 134 by AVC manager 102 and IC manager 104, respectively. In particular, timing signals 158 are used to achieve frame-level synchronization of A/V data 132 and IC data 134. Details of timing signal management block 108 and timing signals 158 are discussed further below, in connection with
Mixer/renderer renders A/V data 132 in a video plane (not shown), and renders IC data 134 in a graphics plane (not shown). The graphics plane is generally, but not necessarily, overlayed onto the video plane to produce played presentation 127 for the user.
With continuing reference to
Regarding IC component 124, as mentioned above in connection with
The particular amount of time along horizontal axis 220 in which title 131 is presentable to the user is referred to as play duration 292 of title 131. Specific times within play duration 292 are referred to as title times. Four title times (“TTs”) are shown on presentation timeline 130—TT1293, TT2294, TT3295, and TT4296. Because a title may be played once or may be played more than once (in a looping fashion, for example) play duration 292 is determined based on one iteration of title 131. Play duration 292 may be determined with respect to any desired reference, including but not limited to a predetermined play speed (for example, normal, or 1×, play speed), a predetermined frame rate, or a predetermined timing signal status. Play speeds, frame rates, and timing signals are discussed further below, in connection with
It will be appreciated that implementation-specific factors such as display techniques and specific rules regarding play sequences and timing relationships among clips and media objects for each title may impact upon exact values of a title's play duration and title times therein. The terms play duration and title times are intended to encompass all such implementation-specific details.
Although title times at/within which content associated with IC component 124 is presentable are generally predetermined, it will be appreciated that actions taken when the user interacts with such content may only be determined based on user input while Played Presentation 127 is playing. For example, the user may select, activate, or deactivate certain applications, media objects, and/or additional content associated therewith during play of Played Presentation 127.
Other times and/or durations within play duration 292 are also defined and discussed herein. Video presentation intervals 240 are defined by beginning and ending times of play duration 292 between which particular content associated with video component 122 is playable. For example, video clip 1230 has a presentation interval 240 between title times TT2294 and TT4296, and video clip 2250 has a presentation interval 240 between title times TT3295 and TT4296. Application presentation intervals, application play durations, page presentation intervals, and page durations are also defined and discussed below, in connection with
With continuing reference to
Application play duration 320 is a particular amount of time, with reference to an amount (a part or all) of play duration 292 within which media objects 125 associated with application 155 are presentable to and/or selectable by a recipient of played presentation 127. In the context of
The intervals defined by beginning and ending title times obtained when an application play duration 320 associated with a particular application is conceptualized on presentation timeline are referred to as application presentation intervals 321. For example, referring to
Referring again to
Media objects associated with a particular page may be presented concurrently, serially, or a combination thereof. As shown, initial page 330 has associated initial media object(s) 331, and subsequent pages 335 have associated media object(s) 336. The intervals defined by beginning and ending title times obtained when a page duration associated with a particular page is conceptualized on the presentation timeline (see
The number of applications and pages associated with a given title, and the media objects associated with each application or page, are generally logical distinctions that are matters of design choice. For example, designation of a particular initial page is not necessary, more than one page of an application may be presented concurrently, or an application may be started with no pages (or an initial page that contains nothing). Pages of an application may be loaded and unloaded while keeping the application and script intact. Multiple pages may be used when it is desirable to manage (for example, limit) the number or amount of resources associated with an application that are loaded into memory during execution of the application. Resources for an application include the media objects used by the application, as well as instructions 304 for rendering the media objects. For example, when an application with multiple pages is presentable, it may be possible to only load into memory only those resources associated with a currently presentable page of the application.
Resource package data structure 340 is used to facilitate loading of application resources into memory (optionally, prior to execution of the application). Resource package data structure 340 references memory locations where resources for that application are located. Resource package data structure 340 may be stored in any desirable location, together with or separate from the resources it references. For example, resource package data structure 340 may be disposed on an optical medium such as a high-definition DVD, in an area separate from video component 122. Alternatively, resource package data structure 340 may be embedded into video component 122. In a further alternative, the resource package data structure may be remotely located. One example of a remote location is a networked server. Topics relating to handling the transition of resources for application execution, and between applications, are not discussed in detail herein.
Referring again to application 155 itself, instructions 304, when executed, perform tasks related to rendering of media objects 125 associated with application 155, based on user input. One type of user input (or a result thereof) is a user event. User events are actions or occurrences initiated by a recipient of played presentation 127 that relate to IC component 124. User events are generally, but not necessarily, asynchronous. Examples of user events include, but are not limited to, user interaction with media objects within played presentation 127, such as selection of a button within menu 280, or selection of the circle associated with graphical overlay 290. Such interactions may occur using any type of user input device now known or later developed, including a keyboard, a remote control, a mouse, a stylus, or a voice command. It will be appreciated that application 155 may respond to events other than user events, such as system events, document object model events, or other types of events.
In one implementation, instructions 304 are computer-executable instructions encoded in computer-readable media (discussed further below, in connection with
Script 308 includes instructions 304 written in a non-declarative programming language, such as an imperative programming language. An imperative programming language describes computation in terms of a sequence of commands to be performed by a processor. In most cases where script 308 is used, the script is used to respond to user events. Script 308 is useful in other contexts, however, such as handling issues that are not readily or efficiently implemented using markup elements alone. Examples of such contexts include system events, state management, and resource management (for example, accessing cached or persistently stored resources). In one implementation, script 308 is ECMAScript as defined by ECMA International in the ECMA-262 specification. Common scripting programming languages falling under ECMA-262 include JavaScript and JScript. In some settings, it may be desirable to implement 308 using a subset of ECMAScript 262, such as ECMA-327.
Markup elements 302, 306, 310, 312, and 360 represent instructions 304 written in a declarative programming language, such as Extensible Markup Language (“XML”). In XML, elements are logical units of information defined, using start-tags and end-tags, within XML documents. XML documents are data objects that are made up of storage units called entities (also called containers), which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. There is one root element in an XML document, no part of which appears in the content of any other element. For all other elements, the start-tags and end-tags are within the content of other elements, nested within each other.
An XML schema is a definition of the syntax(es) of a class of XML documents. Some XML schemas are defined by the World Wide Web Consortium (“W3C”). Other XML schemas have been promulgated by the DVD Forum for use with XML documents in compliance with the DVD Specifications for High Definition Video, and for other uses. It will be appreciated that other schemas for high-definition DVD movies, as well as schemas for other interactive multimedia presentations, are possible.
At a high level, an XML schema includes: (1) a global element declaration, which associates an element name with an element type, and (2) a type definition, which defines attributes, sub-elements, and character data for elements of that type. Attributes of an element specify particular properties of the element, such as style properties and state properties as described below, using a name/value pair, with one attribute specifying a single element property.
Content elements 302, which may include event elements 360, are used to identify particular media object elements 312 presentable to a user by application 155. Media object elements 312, in turn, generally specify locations where data defining particular media objects 125 is disposed. Such locations may be, for example, locations in local or remote storage, including locations on optical media, or on wired or wireless, public or private networks, such as on the Internet, privately managed networks, or the World Wide Web. Locations specified by media object elements 312 may also be references to locations, such as references to resource package data structure 340. In this manner, locations of media objects 125 may be specified indirectly.
Timing elements 306 are used to specify the times at, or the time intervals during, which particular content elements 302 are presentable to a user by a particular application 155. Examples of timing elements include par, timing, or seq elements within a time container of an XML document. Some timing elements are defined by standards published by the W3C for Synchronized Multimedia Integration Language (“SMIL”). Other timing elements are defined by standards published by the DVD Forum (for example, DVD Specifications for High Definition Video). The standards are incorporated by reference herein for all purposes. Different timing elements associated with other timing models for use with declarative language documents are also possible.
Style elements 310 (and corresponding style attributes) are generally used to specify the appearance of particular content elements 302 presentable to a user by a particular application. Certain style elements are defined by the W3C and/or by the DVD Forum in one or more published specifications. Examples of specifications published by the W3C include specifications relating to XSL and specifications relating to cascading style sheets (“CSS”).
Event elements 360 are elements with a user-specified name and a variable set of user defined parameters that are usable for identifying the occurrence of a particular condition during playback of the markup DOM. In one illustrative example, event elements are only consumable by script. Thus, event elements are declarative elements that are contained within the construct of a timing element (e.g., timing elements 306) used to notify script (e.g., script 308) of any type of condition that can be described by its syntax. Event tags may be derived from or be similar to event tags specified by the W3C, or they may be different from event tags specified by the W3C.
Markup elements 302, 306, 310, and 360 have attributes that are usable to specify certain properties of their associated media object elements 312/media objects 125 to thereby both synchronize the rendering of the markup elements and to coordinate the activation of events declared in the markup. In one illustrative implementation, these attributes/properties represent values of one or more clocks or timing signals (discussed further below, in connection with
A sample XML document containing markup elements is set forth below (script 308 is not shown). The sample XML document includes style 310 and timing 306 elements for performing a crop animation on a content element 302, which references a media object element 312 called “id.” The location of data defining media object 125 associated with the “id” media object element is not shown. It will be appreciated that the sample XML document below is provided for illustrative purposes, and may not be syntactically legal.
The sample XML document begins with a root element called “root.” Following the root element, several namespace “xmlns” fields refer to locations on the World Wide Web where various schemas defining the syntax for the sample XML document, and containers therein, can be found. In the context of an XML document for use with a high-definition DVD movie, for example, the namespace fields may refer to websites associated with the DVD Forum.
One content element 302 referred to as “id” is defined within a container described by tags labeled “body.” Style elements 310 (elements under the label “styling” in the example) associated with content element “id” are defined within a container described by tags labeled “head.” Timing elements 306 (elements under the label “timing”) are also defined within the container described by tags labeled “head.”
With continuing reference to
Timing signal management block 108 is responsible for the handling of clocks and/or timing signals that are used to determine specific times or time durations within Presentation System 100. As shown, a continuous timing signal 401 is produced at a predetermined rate by a clock source 402. Clock source 402 may be a clock associated with a processing system, such as a general-purpose computer or a special-purpose electronic device. Timing signal 401 produced by clock source 402 generally changes continually as a real-world clock would—within one second of real time, clock source 402 produces, at a predetermined rate, one second worth of timing signals 401. Timing signal 401 is input to IC frame rate calculator 404, A/V frame rate calculator 406, time reference calculator 408, and time reference calculator 490.
IC frame rate calculator 404 produces a timing signal 405 based on timing signal 401. Timing signal 405 is referred to as an “IC frame rate,” which represents the rate at which frames of IC data 134 are produced by IC manager 104. One illustrative value of the IC frame rate is 30 frames per second. IC frame rate calculator 404 may reduce or increase the rate of timing signal 401 to produce timing signal 405.
Frames of IC data 134 generally include, for each valid application 155 and/or page thereof, a rendering of each media object 125 associated with the valid application and/or page in accordance with relevant user events. For illustrative purposes, a valid application is one that has an application presentation interval 321 within which the current title time of play duration 292 falls, based on presentation timeline 130. It will be appreciated that an application may have more than one application presentation interval. It will also be appreciated that no specific distinctions are made herein about an application's state based on user input or resource availability.
A/V frame rate calculator 406 also produces a timing signal—timing signal 407—based on timing signal 401. Timing signal 407 is referred to as an “A/V frame rate,” which represents the rate at which frames of A/V data 132 are produced by AVC manager 102. The A/V frame rate may be the same as, or different from, IC frame rate 405. One illustrative value of the A/V frame rate is 24 frames per second. A/V frame rate calculator 406 may reduce or increase the rate of timing signal 401 to produce timing signal 407.
A clock source 470 produces timing signal 471, which governs the rate at which information associated with clips 123 is produced from media source(s) 161. Clock source 470 may be the same clock as clock 402, or based on the same clock as clock source 402. Alternatively, clocks 470 and 402 may be altogether different, and/or have different sources. Clock source 470 adjusts the rate of timing signal 471 based on a play speed input 480. Play speed input 480 represents user input received that affects the play speed of played presentation 127. Play speed is affected, for example, when a user jumps from one part of the movie to another (referred to as “trick play”), or when the user pauses, slow-forwards, fast-forwards or slow-reverses, or fast-reverses the movie. Trick play may be achieved by making selections from menu 280 (shown in
Time references 452 represent the amounts of time that have elapsed within particular presentation intervals 240 associated with active clips 123. For purposes of discussion herein, an active clip is one that has a presentation interval 240 within which the current title time of play duration 292 falls, based on presentation timeline 130. Time references 452 are referred to as “elapsed clip play time(s).” Time reference calculator 454 receives time references 452 and produces a media time reference 455. Media time reference 455 represents the total amount of play duration 292 that has elapsed based on one or more time references 452. In general, when two or more clips are playing concurrently, only one time reference 452 is used to produce media time reference 455. The particular clip used to determine media time reference 455, and how media time reference 455 is determined based on multiple clips, is a matter of implementation preference.
Time reference calculator 408 receives timing signal 401, media time reference 455, and play speed input 480, and produces a title time reference 409. Title time reference 409 represents the total amount of time that has elapsed within play duration 292 based on one or more of the inputs to time reference calculator 408.
Time reference calculator 490 receives timing signal 401 and title time reference 409, and produces application time reference(s) 492 and page time reference(s) 494. A single application time reference 492 represents an amount of elapsed time of a particular application play duration 320 (shown and discussed in connection with
Page time reference 494 represents an amount of elapsed time of a single page play duration 332, 337 (also shown and discussed in connection with
Table 1 illustrates illustrative occurrences during play of played presentation 127 by Presentation System 100, and the effects of such occurrences on application time reference 492, page time reference 494, title time reference 409, and media time reference 455.
The movie begins playing when the timing signal has a value of zero. When the timing signal has a value of 10, the application becomes valid and activates. Application time 492, as well as page time 494 associated with page one of the application, assumes a value of zero. Pages two and three are inactive. Title time 409 and media time 455 both have values of 10.
Page two of the application loads at timing signal value 15. The application time and page one time have values of 5, while the title time and the media time have values of 15.
Page three of the application loads when the timing signal has a value of 20. The application time has a value of 10, page two time has a value of 5, and page one time is inactive. The title time and the media time have values of 20.
The movie pauses at timing signal value 22. The application time has a value of 12, page three time has a value of two, and pages one and two are inactive. The title time and media time have values of 22. The movie resumes at timing signal value 24. Then, the application time has a value of 14, page three time has a value of four, and the title time and media time have values of 22.
At timing signal value 27, a new clip starts. The application time has a value of 17, page three time has a value of 7, the title time has a value of 25, and the media time is re-set to zero.
A user de-activates the application at timing signal value 32. The application time has a value of 22, the page time has a value of 12, the title time has a value of 30, and the media time has a value of 5.
At timing signal value 39, the user jumps, backwards, to another portion of the same clip. The application is assumed to be valid at the jumped-to location, and re-activates shortly thereafter. The application time has a value of 0, page one time has a value of zero, the other pages are inactive, the title time has a value of 27, and the media time has a value of 2.
At timing signal value 46, the user changes the play speed of the movie, fast-forwarding at two times the normal speed. Fast-forwarding continues until timing signal value 53. As shown, the application and page times continue to change at a constant pace with the continuous timing signal, unaffected by the change in play speed of the movie, while the title and media times change in proportion to the play speed of the movie. It should be noted that when a particular page of the application is loaded is tied to title time 409 and/or media time 455 (see discussion of application presentation interval(s) 321 and page presentation interval(s) 343, in connection with
At timing signal value 48, a new title begins, and title time 409 and media time 455 are re-set to values of zero. With respect to the initial title, this occurs when the title time has a value of 62, and the media time has a value of 36. Re-setting (not shown) of application time 492 and page time 494 follows re-setting of title time 409 and media time 455.
Having access to various timelines, clock sources, timing signals, and timing signal references enhances the ability of Presentation System 100 to achieve frame-level synchronization of IC data 124 and A/V data 132 within played presentation 127, and to maintain such frame-level synchronization during periods of user interactivity.
With continuing reference to
The method begins at block 600, and continues at block 602, where an application having declarative language instructions is accessed. Certain declarative instructions specify characteristics of media objects. Other declarative instructions specify actions associated with playing or rendering interactive content of the presentation based on state changes of the characteristics. During play of the interactive multimedia presentation, the characteristics will typically take on a variety of different states. That is, as one or more interactive applications load and run (for example, to create an interactive menu or provide other interactive content to a user) a variety of states defined by content element attributes (as described below) typically change to reflect the changing interactive environment,
At block 604, a structured representation of the application, such as a DOM as shown in
Referring to block 602, application instructions 304 (shown in
Certain attributes may be defined with respect to user events. One type of user event that may affect the value of a style attribute or a state attribute is a gesture event. A gesture event is any user-initiated action (such as an input from a device such as a keyboard, remote control, or mouse) that affects presentation of a media object within played presentation 127. Values of characteristic states and attributes in general, and of style or state attributes in particular, can assume alternate, or binary, states. Examples of such alternate or binary states include true or false, on or off, zero or one, and the like. Alternatively, values of characteristic states and attributes can assume general values, such as string values or numeric values. In a further alternative, values of characteristic states and attributes can assume values within pre-defined sets, such as values representing particular colors within a pre-defined set of colors.
Referring again to block 602, within application instructions 304 (shown in
Referring again to the flowchart of
During play of Presentation Content 120/played presentation 127, the states of declarative language instructions associated with a particular application 155 (such as content elements 302, timing elements 306, style elements 310, media object elements 312, event elements 360, and/or attributes (and optionally, attributes of the attributes) of each), are maintained within a structured representation of the application. One example of such a structured representation is a DOM. Structures and functions of DOMs are described by one or more specifications published by the W3C.
When an application is loaded, its markup is loaded and parsed to create a DOM. As the application runs in the interactive environment, the user interacts with the application, events are fired, scripts are run, etc., various aspects of the environment, including state attributes, change which are reflected as modifications to the DOM. Accordingly, the DOM as originally loaded when an application is first started typically differs from the “live” DOM that is dynamically maintained during that application's lifetime.
DOM 700 (or portions thereof) may be periodically queried using XPATH queries or other types of queries (XQUERY, for example) to determine when attribute nodes (such as style attributes or display attributes) have particular values. In one implementation, XPATH queries determine when attribute nodes change values. As discussed above, attributes may have binary values, numeric values, string values, or other types of values. Attribute nodes (represented by nodes 704 and 706 in DOM 700, respectively) resolve to particular values as the interactive multimedia presentation plays and/or in response to events such as user events. In one implementation, XPATH queries resolve to true or false based on the queried values. In this manner, active time intervals for particular media objects may be formed, and XPATH may advantageously be used within timing structures to refer to and/or monitor information within content data structures. Queries may be performed concurrently on one or more attribute nodes, and expressions or conditions involving logical references to attributes may also be used to define queries. For example, Boolean operands such as “AND,” “OR,” and “NOT”, along with other operands or types thereof, may be used to define such expressions or conditions. In some instances, it may also be possible to skip some periodic querying. For example, based on the analysis of query results and/or other information, periods of time when query results will not change could be identified, and querying skipped during those periods.
XPATH queries may be performed on the DOM at a rate based on a timing signal such as timing signal 401or timing signal 471. It will be understood that timing signals 401 and 471 may be referred to directly or indirectly to establish times at which the DOM is queried. For example, timing signal 401 may be referred to indirectly via clock source 402, IC frame rate calculator 404, A/V frame rate calculator 406, application time 492, or page time 494. Likewise, timing signal 471 may be referred to indirectly via clock source 470, elapsed clip play time(s) 452, time reference calculator 454, media time reference 455, time reference calculator 408, or title time reference 409, for example. In addition, expressions involving logical references to clocks, timing signals, time reference calculators, and/or time references may also be used to define when queries are performed on the DOM. For example, Boolean operands such as “AND,” “OR,” and “NOT”, along with other operands or types thereof, may be used to define such expressions or conditions.
When particular actions are triggered by state changes detected via queries of the DOM, appropriate content is accessed and instructions relating to the actions are executed. For example, an external event-handler generally accesses event-related content and arranges for execution of instructions relating to the events. Work items (not shown) resulting from execution of instructions relating to triggered actions are placed in queue(s) (not shown), and are performed at a predetermined rate, such as the rate provided by IC frame rate 405. IC data 134 (for example, the rendering of particular media objects in accordance with user input) resulting from performance of work items is transmitted to mixer/renderer 110. Mixer/renderer 110 renders IC data 134 in the graphics plane to produce the interactive portion of played presentation 127 for the user.
Thus, an application provides certain declarative language instructions that specify states of a particular characteristic of a media object, and other declarative language instructions that specify actions (such as rendering of media objects, event generation, changes in variables, and other actions) associated with playing interactive content of an interactive multimedia presentation based on a state change of the characteristic. The actions associated with playing the interactive content may be conditionally triggered by periodically querying a structured representation of the application to detect the state changes. The XPATH function is well suited for querying DOMs to detect such state changes.
Accordingly, to provide the capability for graphics generated by applications to react to state changes in the interactive multimedia environment, the markup elements are arranged to include state attributes. Such state attributes are exposed to the applications through use of a DOM as described above. In an illustrative example, the state attributes include those shown in Table 2.
Column 1 in Table 2 lists six state attributes. Column 2 lists the values the attributes can take. In this illustrative example, all the attributes except “value” are arranged to utilize Boolean values of True or False. The value attribute typically uses text or other non-Boolean information that is input from a user for its value.
The application author is able to set the initial values, as indicated in column 3, for state attributes. However, the values change based on user interaction through the receipt of gesture events that are described above. In particular, the state attributes of foreground, pointer, and actioned are changed by Presentation System 100 and will not be changed by markup or script. That is, actions of the Presentation System 100 override markup and script. However, the state attributes of focused, enabled, and value may be set by markup or script and the values so set will override the value that would otherwise be set by the Presentation System 100. And, in particular, script can override the state attributes of focused and enabled unless otherwise explicitly instructed through an “unset” instruction implemented through a script API to relinquish control back to an animation engine disposed in Presentation System 100. The rules governing the changing of attribute values thus establish a well defined order of control by establishing precedence and are summarized in the fourth column of Table 2.
Gesture events, in this illustrative example, are handled using markup processing. Other kinds of events are managed by script processing. The mapping of gesture events is handled in markup through style and timing expressions which are predicated on state properties described by the state attributes. Gesture events are handled by the Presentation System 100 by first converting the time of the gesture into an application time (e.g., application time reference 492) and then modifying the state properties of any affected elements in the DOM. While gesture events are handled by markup, they can still be propagated to script by setting up an appropriate event listener.
An example of how the method of
The application includes a content element arranged as a button graphic called “Mybutton” which has the state attribute “focused.” The focused state attribute can assume the states of focused and not focused (i.e., true or false), based on gesture events of a user.
As shown in Table 2, the content elements, such as Mybutton, become focused after an activation gesture is received. Such activation gesture is received, for example, when a user manipulates a “hotspot” area of Mybutton my moving the tip of the cursor into a predefined area (called the “extent”) around the button graphic. Another way to create an activation gesture to change a content element state attribute to true using a keyboard, for example, to manipulate the content element to have focus.
When a content element is focused, it receives focus events such as user inputs (e.g., button pushes, selections, activations, text input, etc.) irregardless of its relative display order. This order, called “Z order” represents the layering of the graphics associated with content elements on a display. For a group of N graphical objects, a Z order=0 means that the graphic appears farthest away while a graphic having a Z order=N−1 appears on top of all the other graphics on the display. Thus, in many instances the focused content element will have a Z order=N−1 as it is the topmost object on the display and would be the one typically engaging in interaction with the user and receiving user events. However, a content element having a focused state attribute does not necessarily always have to have the highest Z order. In addition, at most one content element at a time has focus. In cases when a markup specifies more than one content element to have a state of focused, the lexically later element takes precedence. In this illustrative example, it is also possible to use style, animation or an XML application programming interface (“API”) to change the focused state of a content element.
Once a content element's state attribute is set to true that state is held. Thus, the content element is not focused (i.e., it focused attribute is false) in two cases: when the user selects a different content element to move to the focused state, for example by selecting another menu item from menu 280, and; when a pointer device moves into the extent of the element and a cancel gesture is received. After such cancel gesture, no content elements have a state attribute of focused.
As shown in Table 2, the actioned state is initially set to false. The actioned state changes to true at the start of an activation gesture which targets the content element and returns to false after the activation gesture ends. Such activation gesture is typically generated using a pointer device (e.g., a remote control or mouse) or with a keyboard. In the case of a pointer device, the activation gesture from the pointer device starts with a pointer-down event (such as a push of a mouse button) and lasts until a pointer-up event (such as the mouse button release). An activation gesture delivered by a keyboard has a duration of one tick.
It is further possible to change the actioned state of a content element using style, animation or an XML API to program instructions to simulate a user activation gesture on a content element. In both cases of actual or simulated activation gestures, actioned events are delivered to the single content element having a state attribute of focused equal true by changing the actioned state attribute of that element.
The pointer state of a content element is initially false. The value changes to true whenever the cursor hotspot intersects the content element. Otherwise the value is set to false. However, this behavior only occurs during those times when the cursor is enabled in an interactive media presentation. Thus, pointer move events are delivered to the single application containing the element which contains the pointer by changing the pointer state attribute to true. Such pointer move events are delivered irrespective of the application's Z order. Pointer click events are delivered to element in the application which contains the pointer regardless of whether it has focus. If the content element is able to receive focus, then this will occur as a result of the pointer click. If the content element is able to be actioned, then it will be actioned as result of the pointer click.
The foreground state attribute is set to true by the Presentation System 100 whenever an application is the front-most application in the Z order (i.e., it has the highest Z order). It is set to false whenever the application is located elsewhere in the Z order. Foreground events are delivered to the application when it gains or loses focus by changing the foreground state attribute to true.
The enabled state attribute is set to true by default. Actions of the Presentation System 100 will not change the enabled state attribute. However, style, animation or the XML API may change a content element's enabled state to false. When false, a content element is unable to receive focus.
Value events, such as those generated by a user inputting text to create a value, are delivered to the application containing the content element whose value changes by changing the value state attribute for the content element. Such events are delivered to the application regardless of Z order. The value state of a content element is able to be changed using style, animation or an XML API, and the value state is dependent upon the object type.
Input, area and button content elements are typically used to represent a user input object that responds to user events. An area content element behaves like a button in terms of activation but is definable in terms of shape and other parameters. The content elements associated with area an button are initially set with a value of false as shown in Table 2. The value toggles when the content element's actioned state attribute changes from to true.
The value of the value state attribute for an input or object content element is initialized to any desired value. The default is an empty string. The value state becomes editable, depending on the particular input device used, when there content elements' focus state changes from false to true.
Pseudo code illustrating declarative language instructions usable to conditionally trigger rendering of the media object associated with the content element, for example, MyButton, which has a state attribute called “focused” as described above, that may be either true or false based on a particular gesture event, is illustrated below:
It can be seen that the “par” timing element sets forth the action of rendering the media object associated with the “Mybutton” element. The action is triggered (that is, the media object is rendered) when a query of a DOM node representing the focused attribute of the Mybutton element resolves to true, and the action is stopped (that is, the media object is not rendered) when a query of a DOM node representing the focused attribute of the Mybutton element resolves to false. Although in this example the renderable media object is the same media object that has the characteristic configured to assume a number of states, the renderable media object(s) may be different.
The process(es) illustrated in
A processor 802 is responsive to computer-readable media 804 and to computer programs 806. Processor 802, which may be a real or a virtual processor, controls functions of an electronic device by executing computer-executable instructions. Processor 802 may execute instructions at the assembly, compiled, or machine-level to perform a particular process. Such instructions may be created using source code or any other known computer program design tool.
Computer-readable media 804 represent any number and combination of local or remote devices, in any form, now known or later developed, capable of recording, storing, or transmitting computer-readable data, such as the instructions executable by processor 802. In particular, computer-readable media 804 may be, or may include, a semiconductor memory (such as a read only memory (“ROM”), any type of programmable ROM (“PROM”), a random access memory (“RAM”), or a flash memory, for example); a magnetic storage device (such as a floppy disk drive, a hard disk drive, a magnetic drum, a magnetic tape, or a magneto-optical disk); an optical storage device (such as any type of compact disk or digital versatile disk); a bubble memory; a cache memory; a core memory; a holographic memory; a memory stick; a paper tape; a punch card; or any combination thereof. Computer-readable media 804 may also include transmission media and data associated therewith. Examples of transmission media/data include, but are not limited to, data embodied in any form of wireline or wireless transmission, such as packetized or non-packetized data carried by a modulated carrier signal.
Computer programs 806 represent any signal processing methods or stored instructions that electronically control predetermined operations on data. In general, computer programs 806 are computer-executable instructions implemented as software components according to well-known practices for component-based software development, and encoded in computer-readable media (such as computer-readable media 804). Computer programs may be combined or distributed in various ways.
Functions/components described in the context of Presentation System 100 are not limited to implementation by any specific embodiments of computer programs. Rather, functions are processes that convey or transform data, and may generally be implemented by, or executed in, hardware, software, firmware, or any combination thereof, located at, or accessed by, any combination of functional elements of Presentation System 100.
With continued reference to
As shown, operating environment 900 includes or accesses components of computing unit 800, including processor 802, computer-readable media 804, and computer programs 806. Storage 904 includes additional or different computer-readable media associated specifically with operating environment 900, such as an optical disc, which is handled by optical disc drive 906. One or more internal buses 920, which are well-known and widely available elements, may be used to carry data, addresses, control signals and other information within, to, or from computing environment 900 or elements thereof.
Input interface(s) 908 provide input to computing environment 900. Input may be collected using any type of now known or later-developed interface, such as a user interface. User interfaces may be touch-input devices such as remote controls, displays, mice, pens, styluses, trackballs, keyboards, microphones, scanning devices, and all types of devices that are used input data.
Output interface(s) 910 provide output from computing environment 900. Examples of output interface(s) 910 include displays, printers, speakers, drives (such as optical disc drive 906 and other disc drives), and the like.
External communication interface(s) 912 are available to enhance the ability of computing environment 900 to receive information from, or to transmit information to, another entity via a communication medium such as a channel signal, a data signal, or a computer-readable medium. External communication interface(s) 912 may be, or may include, elements such as cable modems, data terminal equipment, media players, data storage devices, personal digital assistants, or any other device or component/combination thereof, along with associated network support devices and/or software or interfaces.
On client-side 1002, one or more clients 1006, which may be implemented in hardware, software, firmware, or any combination thereof, are responsive to client data stores 1008. Client data stores 1008 may be computer-readable media 804, employed to store information local to clients 1006. On server-side 1004, one or more servers 1010 are responsive to server data stores 1012. Like client data stores 1008, server data stores 1012 may include one or more computer-readable media 804, employed to store information local to servers 1010.
Various aspects of an interactive multimedia presentation system that is used to present interactive content to a user synchronously with audio/video content have been described. An interactive multimedia presentation has been generally described as having a play duration, a variable play speed, a video component, and an IC component. It will be understood, however, that all of the foregoing components need not be used, nor must the components, when used, be present concurrently. Functions/components described in the context of Presentation System 100 as being computer programs are not limited to implementation by any specific embodiments of computer programs. Rather, functions are processes that convey or transform data, and may generally be implemented by, or executed in, hardware, software, firmware, or any combination thereof.
Although the subject matter herein has been described in language specific to structural features and/or methodological acts, it is also to be understood that the subject matter defined in the claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
It will further be understood that when one element is indicated as being responsive to another element, the elements may be directly or indirectly coupled. Connections depicted herein may be logical or physical in practice to achieve a coupling or communicative interface between elements. Connections may be implemented, among other ways, as inter-process communications among software processes, or inter-machine communications among networked computers.
The word “illustrative” is used herein to mean serving as an example, instance, or illustration. Any implementation or aspect thereof described herein as “illustrative” is not necessarily to be constructed as preferred or advantageous over other implementations or aspects thereof.
As it is understood that embodiments other than the specific embodiments described above may be devised without departing from the spirit and scope of the appended claims, it is intended that the scope of the subject matter herein will be governed by the following claims.
This application is a continuation of U.S. Ser. No. 11/405,736 filed Apr. 18, 2006 which claims the benefit of provisional application No. 60/695,944, filed Jul. 1, 2005, which are incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 60695944 | Jul 2005 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11405736 | Apr 2006 | US |
| Child | 14258612 | US |
