A media playback and/or recording device, such as a set-top box (STB), a digital video recorder (DVR), and so on, may often include multiple tuners for receiving more than one stream of media, such as digital video content, digital audio content, or some combination thereof. More specifically, a tuner may include hardware configured to identify a data stream (e.g., a stream of media, such as digital video, digital audio, or any suitable combination thereof) within a multiplexed data stream (e.g., containing several streams of media) and extract the identified data stream from the multiplexed data stream. In some situations, a data stream is identified by its packet identifier (PID), and several data streams are multiplexed together into a transport stream (TS). In such cases, a tuner may be configured to access the TS, identify a data stream by its PID, and extract (e.g., parse) the data stream from the TS for further processing, such as encryption, decryption, transcoding (e.g., decoding from one data format and recoding into another data format), user presentation (e.g., playback), storage, or any suitable combination thereof.
In certain situations, two tuners of hardware (e.g., hardware tuners) may be accessed and controlled by software executing within the media device to allow a user to access more than one media stream simultaneously for current viewing, recording for subsequent viewing, and other uses. In some examples, the tuners, as well as other components of the media device or machine, are configured and controlled via “middleware,” which may be a type of software that provides one or more interfaces for other, higher-level software in the device to control various functional aspects, such as viewing and recording of the media streams, of the media machine.
In some examples, the middleware or other software may enforce one or more resource policies that inflexibly disallow the live playing or presentation of two data streams at the same time. In other words, within the media device or machine, multiple hardware tuners may be controlled by software that disallows (e.g., via one or more resource policies) the live playback or presentation to a user of multiple data streams simultaneously, despite the presence of multiple tuners. In such situations, the device may be configured to receive and extract the multiple streams (e.g., two data streams), and play one of the streams live (e.g., process a first stream in a live playing session) while recording one or more of the multiple streams (e.g., process a second stream in a recording session). In some implementations, such a policy is enforced as a result of the media device being configured to present the media to a user via a single output device, such as a television.
Example methods and systems discussed herein are directed to playing multiple media streams simultaneously or concurrently within a single-player software environment. Examples merely typify possible variations. Unless explicitly stated otherwise, components and functions are optional and may be combined or subdivided, and operations may vary in sequence or be combined or subdivided. In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of example embodiments. It will be evident to one skilled in the art, however, that the present subject matter may be practiced without these specific details.
According to some example embodiments, the methods and systems described herein may be implemented within a media set-top box (STB) (e.g., a television STB capable of receiving and decoding satellite or cable television signals for user presentation, storage, and so on), a media streamer (e.g., a video streaming device or machine configured to receive one or more streams of media, such as digital video, digital audio, or any suitable combination thereof, via a network, such as the Internet, and to present one or more of the streams for user presentation), a network gateway (e.g., a micro-gateway within a public or private network capable of receiving one or more streams of media via a network for user presentation, storage, and so on), or any other media device or machine that incorporates or accesses multiple media streams simultaneously, such as by way of multiple tuners.
By implementing the systems and methods discussed herein, a multi-tuner device or machine may be configured to perform live presentation or playing of multiple streams simultaneously or concurrently despite a software resource policy in the device that disallows simultaneous live playback of multiple data streams. For example, in software executing on the device, only one “live” player (e.g., “Player A”) associated with a device output to deliver live media content (e.g., media content that is currently being received at the device) may be allowed. In some implementations, a “player” is a software object or session provided in the media device that accesses or uses its associated tuner. Player A may also be designated with the property or attribute “LIVE” to indicate that Player A is delivering or presenting live content. To allow a second tuner to play or present a second live media stream, the software may create a second player (e.g. “Player B”) of a “phantom” type, “non-live” type, or some other alternative designation (as opposed to a “normal” type associated with Player A) associated with a second output of the device. Further, Player B may share the LIVE property of Player A with Player A. Playing or presentation of a media stream may include either or both of the presentation of the media stream via a direct output of the media device to an output device (e.g., a television), and the presentation of the media stream via a network coupled with the media device to an output device.
In addition, the second tuner associated with Player B may be denoted in the software with a property (e.g., NO_SHARE) that indicates the second tuner is not to be shared with other players or sessions so that requests for use of the second tuner from outside Player B are denied or ignored. Employing the NO_SHARE designation may thus prevent use of the second tuner by Player B as being interpreted in the software as a “channel zap,” in which the media stream being played by the second tuner is changed by Player B unexpectedly. Designating the second tuner NO_SHARE may thus be desirable in situations in which the software typically allows sharing of a tuner with multiple players, sessions, or “clients.”
Accordingly, based on the embodiments described above, from the perspective of the device software, Player A and Player B may be linked with separate clients for the tuners (e.g., player modules), and yet only one of the players is marked as a “live” player, thus comporting with the resource policy of the device software. From a hardware perspective, however, two separate live player sessions coexist simultaneously. In embodiments in which more than two tuners are available in the media device or machine, a first tuner may be associated with a normal player, and two or more other players may be designated as phantom players sharing the LIVE property of the first player.
In some examples, the media device may include a transcoder to transform the encoding of one or more media streams from one format to another, depending on the needs of a particular output device. As a result, the media device may employ both a main transport system-on-a-chip (SoC) containing one or more tuners and a separate transcoder SoC in some implementations. Typically, transmission of a stream from the main transport SoC and the transcoder SoC occurs via a standard input/output (I/O) connection, such as an Ethernet-over-USB (Universal Serial Bus), or “USB Ethernet,” connection between the two SoCs, in which Ethernet signaling protocols are employed over a USB-based hardware connection. However, when transferring at least two media streams between the two SoCs, the standard I/O connection may not provide the bandwidth typically consumed by more than one media stream. Thus, in one embodiment, each of the media transport streams may be transmitted from the main SoC to the transcoder SoC via a separate data link. After the transcoding operation, which generally results in a data rate reduction of the transcoded stream, each transcoded stream may then be transmitted back to the main SoC via a standard I/O connection, and then distributed to a network or output device via one or more outputs of the main SoC.
As shown in
In the particular example of
For each of Parser Band(2) and Parser Band(3), the extracted media stream (e.g., PidChannel[2] and PidChannel[3], respectively) may be encrypted by an encryption circuit or module (e.g., encryption block 214(2) and encryption block 214(3), respectively) before being provided to an associated re-multiplexer output (e.g., re-multiplexer output 216(2) and re-multiplexer output 216(3), respectively) for delivery as an encrypted transport stream (e.g., TSIN[0] and TSIN[1], respectively) containing the encrypted media stream to the transcoder block 104 via high-speed transform stream data link outputs provided in the transport block 102. In one example, the media stream is encrypted before being transmitted to another area of the media machine 100 to prevent piracy or alteration of the media stream prior to being output from the media machine 100.
Additionally, commands 110 and/or status between the transport block 102 and the transcoder block 104, such as, for example, the setting of the particular transcoding scheme to be employed in the transcoder block 104, may be transmitted over a standard I/O interface 330 (e.g., an Ethernet-over-USB, or USB Ethernet, interface) at the transcoder block 104 and a compatible standard I/O interface 230 at transport block 102. In the particular example of
Returning to
As discussed above, by employing the original, higher bit rate transport stream outputs (e.g., re-multiplexer output 216(2) and re-multiplexer output 216(3)) of the transport block 102 and the transport stream inputs of the transcoder block 104 to transfer the transport streams from the transport block 102 to the transcoder block 104, and only employing the USB Ethernet connection between the transport block 102 and the transcoder block 104 for the transcoded media streams, playing functionality for both tuners of the transport block 102 may be accomplished simultaneously.
As described in greater detail below in conjunction with
The first tuner 540 and the second tuner 550 may be, in one example, hardware tuners that parse a media stream from a transport stream carrying one or more media streams, as described above. In the example method described below, the first tuner 540 may be associated with, or assigned to, the first player module 510, and the second tuner 550 may be associated with, or assigned to, the second player module 520. In one example, the first tuner 540 and the second tuner 550 may be Tuner[0] and Tuner[1], or vice-versa, as described above in conjunction with
The resource manager 530, in one example, may be configured to manage one or more resources (e.g., the tuners 540, 550) of the media machine 100. More specifically, the resource manager 530 may assign the first tuner 540 to the first player module 510 (e.g., Player A) and may assign the second tuner 550 to the second player module 520 (e.g., Player B) according to the method described below in conjunction with
The management module 560 may be configured to implement a method of playing multiple media streams simultaneously or concurrently in a single-player software environment, such as the method described below in conjunction with
The management module 560 may then create one “live” player (e.g., Player A of the first player module 510) associated with one device output or network output of the media machine 100 and a second “phantom” or “non-live” player (e.g., Player B of the second player module 520) associated with a second device output or network output (operation 620), such as through a request to the resource manager 530. In one example, the phantom player is indicated in the creation request to be a player that will not be employed for live presentation of media content. In some implementations, each player may be a software object or session provided in the media machine 100 that is configured to access a tuner for the playing of a media stream.
The management module 560 may then present the players to the resource manager 530 (operation 630). Further, the management module 560 may associate Player A (e.g., the normal player) with a LIVE property or attribute that is shared with Player B (e.g., the phantom player) prior to presentation of Player A and Player B to the resource manager 530. In response, the resource manager 530 may associate or assign one of the tuners 540, 550 to each of the players. More specifically, the first tuner 540 may be assigned to Player A, while the second tuner 550 is assigned to Player B.
In addition, the management module 560 may denote or mark the second tuner 550 associated with Player B in the software with a property (e.g., NO_SHARE) that indicates the second tuner is not to be shared with other players or sessions (operation 640) to prevent “channel zap” conflicts between Player B and other sessions attempting to access the second tuner 550 as a resource.
The management module 560 may then initiate the playing or presentation of separate media streams using the first player module 510 (e.g., Player A) and the second player module 520 (e.g., Player B) in conjunction with their associated tuners (e.g., the first tuner 540 and the second tuner 550, respectively). Each of the streams may be transmitted over a network for consumption by a receiving device, or provided directly to an output device for user presentation.
Accordingly, based on the embodiments discussed herein, from the perspective of the device software, Player A and Player B may be linked with separate clients for the tuners (e.g., player modules), and yet only one of the players is marked as a “live” player, thus comporting with the resource policy of the software executing on the media machine 100. However, from a hardware perspective, two separate live player sessions coexist simultaneously. As discussed earlier, in other embodiments, more than two tuners may each play a media stream by associating a first tuner with a normal player, and designating two or more other players as phantom players sharing a LIVE property of the first player.
By employing various embodiments described above, changes to existing software or middleware of a media machine enforcing a single-player policy to facilitate the use of multiple players within the same software environment are, at the most, minimal. Further, a transport block in communication with a transcoder block via transport stream connections or links in the media machine may facilitate the transfer of high-data-rate multiple media streams concurrently or simultaneously.
The machine 700 includes a processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), or any suitable combination thereof), a main memory 704, and a static memory 706, which are configured to communicate with each other via a bus 708. The machine 700 may further include a graphics display 710 (e.g., a plasma display panel (PDP), a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)). The machine 700 may also include an alphanumeric input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or other pointing instrument), a storage unit 716, a signal generation device 718 (e.g., multiple hardware media tuners 540, 550, as described above in conjunction with
The storage unit 716 includes a machine-readable medium 722 on which is stored the instructions 724 (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions 724 may also reside, completely or at least partially, within the main memory 704, within the processor 702 (e.g., within the processor's cache memory), or both, during execution thereof by the machine 700. Accordingly, the main memory 704 and the processor 702 may be considered as machine-readable media. The instructions 724 may be transmitted or received over the network 726 (e.g., network 490 of
As used herein, the term “memory” refers to a machine-readable medium able to store data temporarily or permanently and may be taken to include, but not be limited to, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, and cache memory. While the machine-readable medium 722 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions (e.g., instructions 724). The term “machine-readable medium” shall also be taken to include any medium that is capable of storing instructions (e.g., software) for execution by the machine, such that the instructions, when executed by one or more processors of the machine (e.g., processor 702), cause the machine to perform any one or more of the methodologies described herein. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, a data repository in the form of a solid-state memory, an optical medium, a magnetic medium, or any suitable combination thereof.
Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.
Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A “hardware module” is a tangible unit capable of performing certain operations and may be configured or arranged in a certain physical manner. In various example embodiments, one or more computer systems (e.g., a standalone computer system, a client computer system, or a server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.
In some embodiments, a hardware module may be implemented mechanically, electronically, or any suitable combination thereof. For example, a hardware module may include dedicated circuitry or logic that is permanently configured to perform certain operations. For example, a hardware module may be a special-purpose processor, such as a field programmable gate array (FPGA) or an ASIC. A hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. For example, a hardware module may include software encompassed within a general-purpose processor or other programmable processor. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
Accordingly, the term “hardware module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. As used herein, “hardware-implemented module” refers to a hardware module. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured by software to become a special-purpose processor, the general-purpose processor may be configured as respectively different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) between or among two or more of the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions described herein. As used herein, “processor-implemented module” refers to a hardware module implemented using one or more processors.
Similarly, the methods described herein may be at least partially processor-implemented, a processor being an example of hardware. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. Moreover, the one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), with these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., an application program interface (API)).
The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example embodiments, the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.
Some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory (e.g., a computer memory). These algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an “algorithm” is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as “data,” “content,” “bits,” “values,” “elements,” “symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like. These words, however, are merely convenient labels and are to be associated with appropriate physical quantities.
Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or any suitable combination thereof), registers, or other machine components that receive, store, transmit, or display information. Furthermore, unless specifically stated otherwise, the terms “a” or “an” are herein used, as is common in patent documents, to include one or more than one instance. Finally, as used herein, the conjunction “or” refers to a non-exclusive “or,” unless specifically stated otherwise.
The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. The Abstract is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
Although an embodiment of the present invention has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
Such embodiments of the inventive subject matter may be referred to herein, individually and/or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.
This application claims the benefit of priority of U.S. Provisional Application No. 61/697,674, titled “PLAYING OF MULTIPLE MEDIA STREAMS IN A SINGLE-PLAYER SOFTWARE ENVIRONMENT,” filed Sep. 6, 2012, which is hereby incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
61697674 | Sep 2012 | US |