Digital video is frequently described using a number of terms, such as video content, video media, audiovisual media, audiovisual content, multimedia, rich media and/or the like. In this description, video content should be understood to include any such content and/or media which may be embodied by, or which may otherwise comprise, video data, audio data or video data in combination with audio data. In some cases, video data and/or audio data may be grouped with other data, such as image data, metadata and/or the like. Unless otherwise indicated by the context, video content should be understood to potentially comprise such image data, metadata and/or the like. By way of non-limiting example, video content may be streamed or otherwise transmitted over the internet or some other type of data network (for example, via a host server or a peer device), cached (for example, cached by an ISP, a proxy server or some other intermediary), locally cached (for example, cached by a internet browser running on the user-computing device) or locally stored or otherwise locally accessible to a user computing device.
Currently, digital video content available on the internet (or otherwise) is encoded, transmitted and rendered using a wide variety of techniques and schemes. There are a number of drawbacks associated with the currently available video rendering technologies.
One drawback with using typical prior art digital video technologies to distribute and perform video content on a user-computing device is that a dedicated application program (typically referred to as a media player) must be downloaded and installed onto the user-computing device or must be pre-installed by the provider of the user-computing device platform (a user-computing device platform comprises the user-computing device hardware and operating system software). In this description, an application program refers to a compiled program (executable object code modules and/or other compiled code segments) capable of independently performing applications, functions or operations on its own and without the assistance of another application program. An application program contrasts with an add-on, described further below, because an add-on depends on a host application to provide its functionality, whereas an application program is capable of performing its functionalities independently. Also, not all independent programs are application programs. For example, virtual machines, such as the Java Virtual Machine, are not application programs, because such virtual machines merely provide virtual environments (such as virtual operating systems and virtual hardware) and do not perform an independent application, function or operation. Such virtual machines require application programs (such as compiled Java bytecode application programs) to perform any applications, functions or operations. Some users may be incapable of downloading or installing a separate media player. Some users may be reluctant to download a separate media player, given the security and/or privacy threats (for example, viruses, malware, local share object and/or the like) associated with downloading files generally, and executable application programs in particular.
In addition, a media player application program is typically downloaded and installed as a compiled object code module and therefore a different compilation target is required for each version of user-computing device platform that may exist in the market. Given the growth and variety of mobile smartphone platforms as well as the wide variety of personal computer platforms, the number of target platforms that have to be supported is burdensome because one compiled version of a media player will likely not operate on a hardware and/or operating system platform for which it was not targeted. The complexity is increased when the compatibility of a media player with a platform may be compromised by other installed application programs which may conflict with the media player.
Some user-computing device hardware and/or software platforms do not support some media player applications (or vice versa) and media player applications are unavailable for such hardware and software platforms. Further, a user who may want to download and install a media player will typically require some knowledge of their user-computing device hardware and/or software platform to download the correct player. In addition to the issues associated with downloading and installing the media player, rendering video content requires execution of a media player application, which typically consumes significant computing resources (for example, RAM, CPU time and the like), even where the particular player is already downloaded and installed.
Some video content rendering technologies use “hidden players” which refers to cases where a host application program (such as an internet browser or the like) operating on the user-computing device automatically downloads and installs a media player add-on. In this description, the term add-on should be understood to include add-ons, plug-ins, snap-ins, extensions, applets and/or the like. Add-ons are compiled programs (that is, executable object code modules, other compiled code segments and the like) which add specific functionalities (for example, video content rendering) to a “host” application program. While add-ons may perform some functionalities, they depend on their host application program for their operability. Examples of add-ons that may be used in connection with a host internet browser application program include: media player add-ons, PDF reader add-ons, Java Virtual Machine (JVM) add-ons and the like.
In some cases, a media player add-on (or instructions which cause the user-computing device to download and install a media player add-on) may be bundled with the video content file. In other cases, video distribution techniques cause the user-computing device's internet browser to separately download the media player add-on and the video content file. Since such media player add-ons must actually be downloaded and installed prior to execution, such media player add-ons suffer from similar drawbacks to those of their overt media player counterparts. Some application programs (for example, internet browsers, anti-virus programs and/or the like) or operating system software may have security and/or privacy settings (set by their users, their network administrators or the like) which block the automatic download of such media player add-ons. After download and installation of a media player add-on, execution of the media player add-on consumes significant processing resources. Being a compiled module, a different version of add-on must be created and tested for each possible destination a platform that it could be run on.
There is a general desire to render video content in a manner which avoids downloading and installing, pre-installing or compiling a separate media player or media player add-on on the user-computing device. There is a general desire to distribute and perform video content in a manner which is platform independent or that has relatively high degree of cross-platform operability.
Another drawback with the use of current technologies to distribute and perform content on a user-computing device occurs in the context of streaming video content, where current technologies typically use a streaming content server which performs some “handshaking” protocol with the user-computing device each time that the user-computing device requests a video content stream. A disadvantage associated with the use of a content server and the associated handshaking protocol is that they can preclude local (or downstream) caching of the video content. Such local or downstream caching can save bandwidth (and associated costs) and improve reliability of the stream (thereby increasing the video quality).
Another disadvantage with the use of current technologies to distribute and perform video content on a user-computing device occurs when it is desirable to update one or more CODECs. A CODEC is a scheme for encoding audio or video data to reduce the bandwidth necessary for its transmission and then decoding the data at the other side of the transmission. Typically, using a CODEC involves compressing the data on the transmitting side and decompressing the data on the receiving side. Decoding can also involve parsing and unpacking data as it arrives at the receiving computer device and/or reorganizing the data into a format that can be used by the receiving computer device. Prior art video rendering technologies typically involve the use of a compiled computer program module which, when executed, performs the decoding process. If video content is encoded with an updated CODEC at the transmission side, then typically the video content will not be capable of being decoded at the user-computing device unless the new updated decoding program for that CODEC is downloaded and installed at the user-computing device.
Various newer internet browser application programs are able to natively render videos embedded in webpages using the HTML5 <video> tag. Unfortunately, CODEC support is not, at present, uniform across all browsers. In the ongoing development of the HTML 5 standard, there continues to be debate over what video formats, if any, should be natively renderable by HTML 5 compliant browsers. Though multiple copies of video content may be provided for use with different CODECs, this typically requires transcoding video content from one CODEC to another. Though it is possible to transcode video content so that it is encoded according to different CODECs, this has drawbacks. For example:                transcoding takes time and effort;        transcoding is typically a computationally intensive process, so that providing real-time transcoding is, at present, technically difficult and/or relatively computationally expensive;        where video content is transcoded to be encoded according to different CODECs in advance, multiples copies of the video content (one for each different CODEC) must typically be stored, which may be onerous for large quantities of video content;        some CODECs are proprietary, and their lawful use is either restricted or requires payment of licensing fees; and        serving video content encoded according to different CODECs may require use of different streaming servers.        
There is accordingly a general desire for methods and systems for rendering video content which overcome or ameliorate some of these or other drawbacks with existing video content rendering technology.
The foregoing examples of the related art and limitations related thereto are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent to those of skill in the art upon a reading of the specification and a study of the drawings.
USPTO Backgrounds
USPTO Backgrounds