Abstract: Media processing methods, systems and application program interfaces (APIs) are described. In but one embodiment, a media engine component, also referred to as a media engine, provides a simple and unified way of rendering media from an origin to a destination of choice without requiring intimate knowledge about the underlying components, their connectivity and management. Clients of the media engine need not worry about how to render the particular media, but rather can simply focus on what media to render and where to render the media. In at least one embodiment, a media session is provided and is encapsulated by the media engine and provides a mechanism by which additional components are made transparent to the application and, in at least some embodiment, the media engine. In some embodiments, the media engine and media session provide a simple API for building, configuring, and manipulating a pipeline of components (e.g.

Abstract: A computing device has instantiated thereon a protected media path for delivering content from a source to a sink. In the protected media path, a media base provides a protected environment in the computing device and includes a common infrastructure of core components effectuating processing of content from any particular source and delivering the processed content to any particular sink, and also includes a policy engine enforcing policy on behalf of the source. The policy corresponds to the content from the source and includes rules and requirements for accessing and rendering the content, whereby the media base allows content to flow through the computing device in a protected fashion, and allows for arbitrary processing of the protected content in the computing device.

Abstract: In a protected media path for delivering content from a source to a sink, a source authority (SOTA) on behalf of the source decides with regard to a policy corresponding to the content that a particular type of action with the content is to be refused, and provides a particular enabler to an application. The provided enabler includes information and methods necessary for the application to obtain data necessary to respond to the refusal. The application receives the enabler at an interface thereof and the interface applies a common interaction procedure to run the enabler to obtain the data necessary to respond to the refusal.

Abstract: An image container file has at least first and second multimedia streams (MSs). The first MS includes first image data representing an image. The second MS includes arbitrary data, which can for example, correspond to: a different representation of the same image; annotations to the first image data; second image data that together with the first image data form a new image with greater dynamic range, resolution, field of view or other attributes that can be derived from processing two or more independent images; or an executable file related to the first MS. The image container file can also include an extensible metadata to hold information describing one or more multimedia streams of the image container file. Further, the image container file may include DRM information to provide information related to obtaining a license to access encrypted data or verifying the authenticity of encrypted or unencrypted data.

Abstract: A set of interfaces and data structures (i.e., a demultiplexer API) for representing a demultiplexer of multimedia data is presented. The data structure utilizes a number of fields, each containing an element of a command. In one embodiment, at least seven commands are formed for proper operation of the demultiplexer, including Initialize, SetPresentationDescriptor, GetPresentationDescriptor, GetPendingPresentationDescriptor, ProcessInput, ProcessOutput, and Flush commands. The demultiplexer API allows the consumer to use muxed stream data such as DV in a uniform manner to generate elementary stream data such as audio and video (compressed or uncompressed) and allows demultiplexers to be used as an independent component.

Abstract: A flexible interface that enables an application to communicate directly with processing modules to easily control the processing of streaming data. The interface provides basic commands for applications to use to communicate with processing modules and provides the flexibility to adapt to changing standards. The interface enables an application to set the type of input and output data formats of a processing module and control when the processing module processes input data and generates output data. The processing modules enumerate its capabilities by category, by media type, or by both category and media type. Processing modules are registered by class ID, category, whether the application needs a key, the number and types of input data types, and the number and type of output data types to register.