TECHNICAL FIELD

This disclosure relates in general to the field of video and, more particularly, to video coding in a dynamic environment.

BACKGROUND

Video architectures have grown in complexity in recent times. The encoding and decoding of video can be important to the delivery of high quality video data. Real-time video coding systems that are connected to a video camera often encounter scene dynamics due to environmental variations and/or camera adjustments (e.g., change of exposure, color balance, and focus). Coding such dynamics with the toolset offered by existing video coding standards/systems is inherently flawed. As a result, the resulting video quality may be degraded considerably due to a budgeted bit rate. The ability to properly manage video coding activities and, further, to efficiently address problematic video conferencing scenarios presents a significant challenge to system designers, component manufacturers, and service providers alike.

BRIEF DESCRIPTION OF THE DRAWINGS

To provide a more complete understanding of the present disclosure and features and advantages thereof, reference is made to the following description, taken in conjunction with the accompanying figures, wherein like reference numerals represent like parts, in which:

FIG. 1A is a simplified schematic diagram illustrating a system for video transmission in accordance with one embodiment of the present disclosure;

FIG. 1B is a simplified schematic diagram illustrating a system in accordance with one embodiment of the present disclosure;

FIG. 2 is a simplified block diagram illustrating the development of reference transform parameters in accordance with one embodiment of the present disclosure;

FIG. 3A is a simplified block diagram illustrating the flow of video data within a video encoder in accordance with one embodiment of the present disclosure;

FIG. 3B is a simplified block diagram illustrating the flow of video data within a video decoder in accordance with one embodiment of the present disclosure; and

FIG. 4 is a simplified flowchart illustrating example operations associated with one embodiment of the present disclosure.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

A method is provided in one example embodiment and includes receiving a camera dynamic parameter; determining a reference transform parameter based on the camera dynamic parameter; applying the reference transform parameter to generate a video image; and encoding the reference transform parameter in a bitstream for transmission with the video image. The camera dynamic parameter can be any number of possible characteristics such as a pan-tilt-zoom characteristic of the video camera; an exposure characteristic of the video camera; a white balance characteristic of the video camera; a focus characteristic of the video camera, or any other characteristic relevant to the associated video platform.

In specific implementations, the receiving of the camera dynamic parameter further includes capturing the video image with a video camera; and determining the camera dynamic parameter by analysis of adjustments made by the video camera during capturing of video images. The reference transform parameter can be related to any number of possible parameters such as an affine transformation, a multiplicative modeling, an exponential modeling, a point-spread function, or any other suitable parameter particular to the video architecture.

In other instances, the method may include applying motion estimation and compensation to a reference transformed video signal. Additionally, the method may include decoding a particular video image; decoding a particular reference transform parameter; and applying a particular reference transform parameter to the particular video image. The entropy-decoded data can undergo inverse quantization and transformation such that reference transformed data is combined with the entropy-decoded data. Additionally, the entropy-decoded data can be subjected to filtering before decoded video images are rendered on a display. Additionally, encoding the reference transform parameter in the bitstream can include encoding one or more indications, such as which previously-processed video image is transformed with the reference transform parameter, and which video image is encoded using a transformed previously processed image.

EXAMPLE EMBODIMENTS

Turning to FIG. 1A, FIG. 1A is a simplified schematic diagram illustrating a system 10 for video transmission in accordance with one embodiment of the present disclosure. In this particular implementation, system 10 is representative of an architecture for encoding/decoding a video image over a network utilizing camera dynamics modeling. System 10 includes a camera 11, a camera dynamics modeler 15, a video encoder 19, a network 18, and a video decoder 21.

In accordance with the teachings of the present disclosure, data encoding/decoding technology of system 10 can utilize camera dynamics modeling in order to increase the efficiency of the data encoding/decoding operations. System 10 can be configured to offer a reference picture transform to the video coding toolset in order to improve compression under camera dynamics. The proposed transform can be applied to one (or a plurality) of reference pictures to obtain a new reference. The parameters that describe the transform can be coded and transmitted (along with the bitstream) to the decoder (regulated by rate-distortion optimization). More specifically, system 10 allows for a model-based manipulation on pixels in the reference picture to order to obtain a new reference, which provides a better prediction to the coded picture. Such a solution could be especially beneficial for certain video conferencing systems associated with coding scene dynamics due to camera adjustments.

Note that scene dynamics introduced by environment variation and camera adjustment are structured (and, therefore, can be modeled), while current coding tools fail in leveraging this framework. This causes a degradation of video quality (e.g., under a constant bit rate scenario (CBR)). System 10 offers a model-based transform that mimics the variation occurring within the camera, and that can be applied to the reference picture to improve coding. The parameters of the transform can be determined with aid from the camera logic.

In operational terms, camera 11 can be configured to capture images, where the images along with camera dynamics parameters are transmitted to camera dynamics modeler 15. Camera dynamics modeler 15 utilizes the camera dynamics parameters to create reference transform parameters, which are subsequently transmitted to video encoder 19. Video encoder 19 then applies the reference transform parameters to the video images, encodes images, and transmits them along with reference transform parameters via network 18 to video decoder 21. Hence, the reference transform parameters are applied to previously processed video images, and the transformed image is used as a prediction reference for encoding the current image. Transformed video images are then decoded utilizing the reference transform parameters, and the decoded images can be displayed as a video.

Semantically, parameters that describe the transform can be coded and transmitted along with the bitstream to the decoder. Rate-distortion optimization can be extended to regulate the bit rate savings against the overhead for coding the transform parameters. In one example embodiment associated with a Telepresence videoconferencing platform, a real-time video encoder can be connected to a video camera having auto adjustment capabilities. Additionally, the architecture may be performing CBR encoding in this scenario.

In one instance, where scene dynamics are caused by a change of environment lighting and/or the camera's adjustment of exposure/color balance in response to an environment change, the change of pixel values due to exposure/color balance variation may be approximated by a linear (or a polynomial model), and as a function of pixel coordinates. For example, the closer to the light source, the more significant the pixel variation. To encode the video frame produced with the exposure/color balance variation, the approximated transform model is first applied to the previously-coded picture (i.e., the reference picture). The output can then be used for motion compensated prediction (MCP). By doing so, fewer or less significant prediction residuals would need to be encoded after the MCP. Because this model-based reference transform occurs within the decoding loop, it can be replicated at the decoder side (e.g., provided by the transform parameters). Note that it is not necessary to have only one transform for the entire picture. Depending on the exact exposure/color balance adjustment being performed at the camera, multiple transforms may be used to approximate the pixel variation in different regions.

In another embodiment, picture changes due to a camera focus adjustment may be modeled by one (or multiple) point spreading functions: each applying to objects at a certain depth. Note that certain cameras may perform pan-tilt-zoom (PTZ) along with the aforementioned adjustments, in which case a global affine transform may be used to model the PTZ, and the reference transforms may be cascaded.

Determination of the type of reference transform and its corresponding parameters can be an encoder task. In practice, a few representative transform types may be pre-defined between the encoder and the decoder, and the parameters may be determined with input from the camera logic (e.g., the camera's intrinsic and extrinsic parameters, gain settings (before and after adjustment), etc.). The type of the reference transform can be coded as an index in the bitstream, followed by the parameters. The use of one or multiple reference transforms and corresponding bit rate savings can be evaluated along with other coding modes (e.g., intra-prediction, towards improved overall rate-distortion performance).

Consider an example involving a home video conferencing platform. The camera quickly adapts its optical focus to the scene by performing constant (frame-by-frame) fine-scale adjustment: making an adjustment in one direction, performing measurement, moving one step further, or correcting to the other direction (depending on the measurement). Video encoders do not intelligently respond to such frame-to-frame variations and, further, fail to code them efficiently (i.e., simply treating them as motion). System 10 is configured to identify such dynamics from the actual object motion, appropriately model them, and then compensate for them by a parametric transform on the reference picture. This may be as simple as the somewhat limited weighted prediction (block-wise linear), or as sophisticated as a global, un-linear transformation (e.g., point spread function). One important capability of system 10 is that the architecture can leverage signals from the camera to determine when and how the transformation should be applied.

System 10 is configured to model camera dynamics by digital transformation and, subsequently, apply that to improve video coding. Such a transformation can be in either the spatial domain, in the range domain, or in both. PTZ represents the most intuitive example, where the camera dynamics can be modeled by an affine transform. In this case, applying a global, affine transform to the reference picture (prior to MCP) performs better than existing coding flows.

In certain example implementations, the result of the camera automatically adjusting exposure/white balance is reflected in the range domain, which is another form of dynamics that can be modeled by a parametric transformation and that can be applied to improve coding. An exponential or polynomial curve may well approximate such dynamics in the range domain. System 10 can consider parametric, global (or region-based) transforms that could be linear or nonlinear, and which could transform toward both lower and higher ranges, as camera dynamics can vary in both directions. Note that a camera may be performing multiple adjustments at the same time and, therefore, the transformation applied to the reference picture could be a combination of parametric transforms described herein. Additionally, the transform parameters can be derived or calibrated from camera mechanics/electronics.

Referring now to FIG. 1B, FIG. 1B is a simplified schematic illustrating a system 13 in accordance with the teachings of the present disclosure. In particular, system 13 can be configured to offer three significant transforms that can collectively address problems presented by large-scale scene changes. First, system 13 can efficiently adjust for movement of the camera, such as PTZ adjustments. Second, system 13 can adjust for exposure/white balance changes in the camera. Third, system 13 can adjust for focus changes in the camera, such as when a person in the camera moves closer to, or further from, the camera. Operating together, these coding components can be configured to determine which transforms to apply to each image that includes camera dynamic changes. By minimizing the amount of new data that has to be fully encoded and decoded, the architecture can minimize processing power and bandwidth consumption in the system. Before detailing additional operations associated with the present disclosure, some preliminary information is provided about the corresponding infrastructure of FIG. 1B.

System 13 includes two distinct communication systems that are represented as endpoints 23 and 25, which can be provisioned in different geographic locations. Endpoint 23 may include a display 14, a camera 12a, and a video processing unit 17. In this embodiment, video processing unit 17 is integrated into display 14; however, video processing unit 17 could readily be a stand-alone unit as well, or within the camera 12a itself.

Endpoint 25 may similarly include a display 24, a camera 12b, and a video processing unit 27. Additionally, endpoints 23 and 25 may be coupled to a server 20, 22 respectively, where the endpoints are connected to each other via network 18. Each video processing unit 17, 27 may further include a respective processor 30a, 30b, a respective memory element 32a, 32b, a respective video encoder 19a, 19b, a respective camera dynamics modeler 15a, 15b, and a respective decoder 21a, 21b. The function and operation of these elements is discussed in detail below. In the context of a conference involving a participant 41 (present at endpoint 23) and a participant 43 (present at endpoint 25), packet information may propagate over network 18 during the conference. As each participant 41 and 43 communicates, cameras 12a, 12b suitably capture the scene as a video signal. Each video processing unit 17, 27 evaluates this video signal and then determines which data to send to the other location for rendering on displays 14, 24.

Displays 14, 24 are screens at which video data can be rendered for one or more end users. Note that as used herein in this Specification, the term ‘display’ is meant to connote any element that is capable of delivering image data (inclusive of video information), text, sound, audiovisual data, etc. to an end user. This would necessarily be inclusive of any panel, plasma element, television, display, computer interface, screen, Telepresence devices (inclusive of Telepresence boards, panels, screens, walls, surfaces, etc.) or any other suitable element that is capable of delivering, rendering, or projecting such information.

Cameras 12a, 12b are generally mounted proximate to their respective displays 14, 24. Cameras 12a, 12b can be wireless cameras, high-definition cameras, or any other suitable camera device configured to capture image data. As can be seen in comparing the handheld camera 11 in FIG. 1A and the mounted cameras 12a, 12b of FIG. 1B, the term ‘camera’ as used herein is not limited to cameras of any one type or design. In terms of their physical deployment, in one particular implementation, cameras 12a, 12b are digital cameras, which are mounted on the top (and at the center of) displays 14, 24. One camera can be mounted on each respective display 14, 24. Other camera arrangements and camera positioning is certainly within the broad scope of the present disclosure.

A respective participant 41 and 43 may reside at each location for which a respective endpoint 23, 25 is provisioned. Endpoints 23 and 25 are representative of devices that can be used to facilitate data propagation. In one particular example, endpoints 23 and 25 are representative of video conferencing endpoints, which can be used by individuals for virtually any communication purpose. It should be noted however that the broad term ‘endpoint’ can be inclusive of devices used to initiate a communication, such as any type of computer, a personal digital assistant (PDA), a laptop or electronic notebook, a cellular telephone, an iPhone, an IP phone, an iPad, a Google Droid, or any other device, component, element, or object capable of initiating or facilitating voice, audio, video, media, or data exchanges within system 10 or system 13. Hence, video processing unit 17 can be readily provisioned in any such endpoint. Endpoints 23 and 25 may also be inclusive of a suitable interface to the human user, such as a microphone, a display, or a keyboard or other terminal equipment. Endpoints 23 and 25 may also be any device that seeks to initiate a communication on behalf of another entity or element, such as a program, a database, or any other component, device, element, or object capable of initiating an exchange within system 13 or system 10. Data, as used herein in this document, refers to any type of numeric, voice, video, media, or script data, or any type of source or object code, or any other suitable information in any appropriate format that may be communicated from one point to another.

Each endpoint 23, 25 can also be configured to include a receiving module, a transmitting module, a processor, a memory, a network interface, a call initiation and acceptance facility such as a dial pad, one or more speakers, one or more displays, etc. Any one or more of these items may be consolidated, combined, or eliminated entirely, or varied considerably, where those modifications may be made based on particular communication needs.

Note that in one example, each endpoint 23, 25 can have internal structures (e.g., a processor, a memory element, etc.) to facilitate the operations described herein. In other embodiments, these audio and/or video features may be provided externally to these elements or included in some other proprietary device to achieve their intended functionality. In still other embodiments, each endpoint 23, 25 may include any suitable algorithms, hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof.

Network 18 represents a series of points or nodes of interconnected communication paths for receiving and transmitting packets of information that propagate through system 13 or system 10. Network 18 offers a communicative interface between any of the nodes of FIG. 1B, and may be any local area network (LAN), wireless local area network (WLAN), metropolitan area network (MAN), wide area network (WAN), virtual private network (VPN), Intranet, Extranet, or any other appropriate architecture or system that facilitates communications in a network environment. Note that in using network 18, system 13 or system 10 may include a configuration capable of transmission control protocol/internet protocol (TCP/IP) communications for the transmission and/or reception of packets in a network. System 13 or system 10 may also operate in conjunction with a user datagram protocol/IP (UDP/IP) or any other suitable protocol, where appropriate and based on particular needs.

Each video processing unit 17, 27 is configured to evaluate video data and make determinations as to which data should be rendered, coded, skipped, manipulated, transformed, analyzed, or otherwise processed within system 13 or system 10. As used herein in this Specification, the term ‘video element’ is meant to encompass any suitable unit, module, software, hardware, server, program, application, application program interface (API), proxy, processor, field programmable gate array (FPGA), erasable programmable read only memory (EPROM), electrically erasable programmable ROM (EEPROM), application specific integrated circuit (ASIC), digital signal processor (DSP), or any other suitable device, component, element, or object configured to process video data. This video element may include any suitable hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange (reception and/or transmission) of data or information.

Note that each video processing unit 17, 27 may share (or coordinate) certain processing operations (e.g., with respective endpoints 23, 25). Using a similar rationale, their respective memory elements may store, maintain, and/or update data in any number of possible manners. Additionally, because some of these video elements can be readily combined into a single unit, device, or server (or certain aspects of these elements can be provided within each other), some of the illustrated processors may be removed, or otherwise consolidated such that a single processor and/or a single memory location could be responsible for certain activities associated with modeling camera dynamics controls. In a general sense, the arrangement depicted in FIG. 1B may be more logical in its representations, whereas a physical architecture may include various permutations/combinations/hybrids of these elements.

In one example implementation, video processing units 17, 27 include software (e.g., as part of camera dynamics modeler 15a-b, video encoder 19a-b, video decoder 21a-b, respectively) to achieve the intelligent modeling of camera dynamics operations, as outlined herein in this document. In other embodiments, this feature may be provided externally to any of the aforementioned elements, or included in some other video element or endpoint (either of which may be proprietary) to achieve this intended functionality. Alternatively, several elements may include software (or reciprocating software) that can coordinate in order to achieve the operations, as outlined herein. In still other embodiments, any of the devices of the illustrated FIGURES may include any suitable algorithms, hardware, software, components, modules, interfaces, or objects that facilitate these modeling camera dynamics management operations, as disclosed herein.

Video processing unit 17 is configured to receive information from camera 12a via some connection, which may attach to an integrated device (e.g., a set-top box, a proprietary box, etc.) that can sit atop a display. Video processing unit 17 may also be configured to control compression activities, or additional processing associated with data received from the cameras. Alternatively, a physically separate device can perform this additional processing before image data is sent to its next intended destination. Video processing unit 17 can also be configured to store, aggregate, process, export, and/or otherwise maintain image data and logs in any appropriate format, where these activities can involve processor 30a and memory element 32a. In certain example implementations, video processing units 17 and 27 are part of set-top box configurations. In other instances, video processing units 17, 27 are part of a server (e.g., servers 20 and 22). In yet other examples, video processing units 17, 27 are network elements that facilitate a data flow with their respective counterparty. As used herein in this Specification, the term ‘network element’ is meant to encompass routers, switches, gateways, bridges, loadbalancers, firewalls, servers, processors, modules, or any other suitable device, component, element, or object operable to exchange information in a network environment. This includes proprietary elements equally, which can be provisioned with particular features to satisfy a unique scenario or a distinct environment.

Video processing unit 17 may interface with camera 12a through a wireless connection, or via one or more cables or wires that allow for the propagation of signals between these two elements. These devices can also receive signals from an intermediary device, a remote control, etc., where the signals may leverage infrared, Bluetooth, WiFi, electromagnetic waves generally, or any other suitable transmission protocol for communicating data (e.g., potentially over a network) from one element to another. Virtually any control path can be leveraged in order to deliver information between video processing unit 17 and camera 12a. Transmissions between these two sets of devices can be bidirectional in certain embodiments such that the devices can interact with each other (e.g., dynamically, real-time, etc.). This would allow the devices to acknowledge transmissions from each other and offer feedback, where appropriate. Any of these devices can be consolidated with each other, or operate independently based on particular configuration needs. For example, a single box may encompass audio and video reception capabilities (e.g., a set-top box that includes video processing unit 17, along with camera and microphone components for capturing video and audio data).

Turning to FIG. 2, FIG. 2 is a simplified block diagram illustrating the development of reference transform parameters within the camera dynamics modeler in accordance with one embodiment of the present disclosure. In the camera dynamics modeler, different camera dynamics parameters 42 are examined and a transform 46 is developed for each property that is changing in the data.

For example, in operational terms for this embodiment, three parameters 42 are examined for dynamic changes: pan-tilt-zoom, exposure/white balance, and focus. When a change is detected within any of camera dynamics parameters 42, that parameter is fitted to a parametric model via real-time manipulation or a table look-up of known transforms at 44, and transform 46 is assigned to the parameter. In the present example, the pan-tilt-zoom parameter utilizes an affine transform; the exposure/white balance utilizes a multiplicative or exponential transform; and the focus utilizes one or more point-spread-functions. Once the transform has been applied, the reference transform parameters have been developed and can subsequently be utilized.

In practice, a few representative transform types may be pre-defined between the encoder and the decoder, and the parameters may be determined with input from the camera logic, e.g., the camera's intrinsic and extrinsic parameters, gain settings (before and after adjustment), etc. The type of the reference transform will be coded as an index in the bitstream, followed by the parameters. The use of one or multiple reference transforms and corresponding bit rate savings can be evaluated along with other coding modes to improve overall rate distortion performance.

Referring now to FIG. 3A, FIG. 3A is a simplified diagram illustrating an example flow of video data within video encoder 19a. In this representative embodiment, where scene dynamics are caused by a change of environment lighting and/or the camera's adjustment of exposure/white balance in response to an environment change, the change of pixel values due to exposure/white balance variation may be approximated by a linear or polynomial model and/or as a function of pixel coordinates (the closer to the light source, the more significant pixel variation, for example).

As the video images enter into the data flow of video encoder 19a, the image first undergoes a transformation and quantization at 54. As appropriate, the images either are sent toward an output bitstream multiplexer 70 (after undergoing an entropy coding 56) or propagate through an inverse quantization and transformation 60. This embodiment utilizes the H.264/AVC video coding standard, where the inverted images have an in-loop (or deblocking) filter 64 being applied.

To encode the video frame produced with the exposure/white balance variation, an approximated transform model is first applied to a previously coded picture (e.g., the reference picture) at reference transform 68. The output can then be used for MCP. This may include a motion estimation 74, a motion compensation 66, and an intra prediction 62. By doing so, fewer or less significant prediction residuals need to be encoded after the MCP. Because this model-based reference transform occurs within the decoding loop, it can be replicated at the decoder side. Note that it is not necessary to have only one transform for the entire picture. Depending on how exposure/white balance adjustment is performed at the camera, multiple transforms may be used to approximate the pixel variation in different regions of any video image.

Reference transform parameters that describe the transform are coded at parameter coding 72. These coded parameters are then combined with the coded video images to form a bitstream at bitstream multiplexer 70, and transmitted to decoder 21b. Accordingly, rate-distortion optimization can be extended to regulate the bit rate savings against the overhead for coding the transform parameters.

In another embodiment, picture changes due to a camera focus adjustment may be modeled by one or multiple point spreading functions, each applying to objects at certain depth. Alternatively, some cameras may perform PTZ along with the aforementioned adjustment, in which case a global affine transform may be used to model the PTZ and the reference transforms may be cascaded.

Referring now to FIG. 3B, FIG. 3B is a simplified diagram illustrating the flow of video data within video decoder 21b in accordance with one embodiment of the present disclosure. The bitstream enters the video decoder 21b at a bitstream demultiplexer 76, where the data is then transferred for an entropy decoding 78 or a reference transform parameter decoding 88 (depending on the activities that occurred at video encoder 19a). Once the reference transform parameters are decoded, a reference transform 84 is applied to the data, and then motion compensation 86 occurs. The entropy-decoded data undergoes inverse quantization and transformation at 80, and the reference transformed data can be combined with the entropy-decoded data and subjected to an in-loop filter 82. The then decoded images are ready to be displayed.

Referring now to FIG. 4, FIG. 4 is a simplified flowchart illustrating example operations associated with one embodiment of system 10. The operations begin at 110 when a video signal is captured. Camera dynamics parameters 112 are then compared to the captured video signal at 114, where the signal is analyzed to determine if there have been changes in the camera dynamics. If there are no changes currently in the camera dynamics, the video signal passes through to be encoded at 120.

If camera dynamics changes did occur, the type of change is determined and utilized to create reference transform parameters at 116. Reference transform parameters are then applied to the video signal at 118 to create the transformed video signal. A video signal is then encoded and meshed together with any video signal without dynamic changes as necessary at 120. Hence, the reference transform parameters are applied to previously-processed video images, and the transformed image is used as a prediction reference for encoding the current image. As the reference transform parameters are being applied at 118, the reference transform parameters are also being encoded at 122. The encoded video signal from 120 and the encoded reference transform parameters are then combined at 124 and transmitted at 126. In some embodiments, a similar process is occurring at the second location (i.e., the counterparty endpoint), where video data is also being sent from the second location to the first.

Note that in certain example implementations, the video processing functions outlined herein may be implemented by logic encoded in one or more tangible media (e.g., embedded logic provided in an application specific integrated circuit [ASIC], digital signal processor [DSP] instructions, software [potentially inclusive of object code and source code] to be executed by a processor, or other similar machine, etc.). In some of these instances, a memory element [as shown in FIG. 1B] can store data used for the operations described herein. This includes the memory element being able to store software, logic, code, or processor instructions that are executed to carry out the activities described in this Specification. A processor can execute any type of instructions associated with the data to achieve the operations detailed herein in this Specification. In one example, the processor [as shown in FIG. 1B] could transform an element or an article (e.g., data) from one state or thing to another state or thing. In another example, the activities outlined herein may be implemented with fixed logic or programmable logic (e.g., software/computer instructions executed by a processor) and the elements identified herein could be some type of a programmable processor, programmable digital logic (e.g., a field programmable gate array [FPGA], an erasable programmable read only memory (EPROM), an electrically erasable programmable ROM (EEPROM)) or an ASIC that includes digital logic, software, code, electronic instructions, or any suitable combination thereof.

In one example implementation, endpoints 23, 25 can include software in order to achieve the modeling camera dynamics coding outlined herein. This can be provided through instances of video processing units 17, 27 (which can be provisioned in cameras, and set-top boxes, or any other suitable location). Additionally, each of these endpoints may include a processor that can execute software or an algorithm to perform the modeling camera dynamics coding activities, as discussed in this Specification. These devices may further keep information in any suitable memory element [random access memory (RAM), ROM, EPROM, EEPROM, ASIC, etc.], software, hardware, or in any other suitable component, device, element, or object where appropriate and based on particular needs. Any of the memory items discussed herein (e.g., database, table, cache, key, etc.) should be construed as being encompassed within the broad term ‘memory element.’ Similarly, any of the potential processing elements, modules, and machines described in this Specification should be construed as being encompassed within the broad term ‘processor.’ Each endpoint 23, 25 can also include suitable interfaces for receiving, transmitting, and/or otherwise communicating data or information in a network environment.

It is also important to note that the steps in the preceding flow diagrams illustrate only some of the possible conferencing scenarios and patterns that may be executed by, or within, system 13 and system 10. Some of these steps may be deleted or removed where appropriate, or these steps may be modified or changed considerably without departing from the scope of the present disclosure. In addition, a number of these operations have been described as being executed concurrently with, or in parallel to, one or more additional operations. However, the timing of these operations may be altered considerably. The preceding operational flows have been offered for purposes of example and discussion. Substantial flexibility is provided by system 13 or system 10 in that any suitable arrangements, chronologies, configurations, and timing mechanisms may be used on conjunction with the architecture without departing from the teachings of the present disclosure.

Note that with the example provided above, as well as numerous other examples provided herein, interaction may be described in terms of two or three components. However, this has been done for purposes of clarity and example only. In certain cases, it may be easier to describe one or more of the functionalities of a given set of flows by only referencing a limited number of components. It should be appreciated that system 13 or system 10 (and its teachings) are readily scalable and can accommodate a large number of components, participants, rooms, endpoints, sites, etc., as well as more complicated/sophisticated arrangements and configurations. Accordingly, the examples provided should not limit the scope or inhibit the broad teachings of system 13 and system 10, as potentially applied to a myriad of other architectures. In other instances, system 13 and system 10 can be applied in video surveillance applications in order to appropriately offer modeling camera dynamics coding to improve system performance. Additionally, applications such as Skype (or any application associated with handheld devices) can readily utilize the teachings of the present disclosure.

Although the present disclosure has been described in detail with reference to particular embodiments, it should be understood that various other changes, substitutions, and alterations may be made hereto without departing from the spirit and scope of the present disclosure. For example, although the previous discussions have focused on videoconferencing associated with particular types of endpoints, handheld devices that employ video applications could readily adopt the teachings of the present disclosure. For example, iPhones, iPads, Google Droids, personal computing applications (i.e., desktop video solutions), etc. can readily adopt and use the modeling camera dynamics operations detailed above. Any communication system or device that encodes video data would be amenable to the modeling camera dynamics features discussed herein.

It is also imperative to note that system 13 or system 10 can be used in any type of video applications. This can include standard video rate transmissions, adaptive bit rate (ABR), variable bit rate (VBR), CBR, or any other video technology in which camera dynamics can be utilized. System 13 or system 10 can readily be used in any such video environments, as the teachings of the present disclosure are equally applicable to all such alternatives and permutations. Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained to one skilled in the art and it is intended that the present disclosure encompass all such changes, substitutions, variations, alterations, and modifications as falling within the scope of the appended claims.

In order to assist the United States Patent and Trademark Office (USPTO) and, additionally, any readers of any patent issued on this application in interpreting the claims appended hereto, Applicant wishes to note that the Applicant: (a) does not intend any of the appended claims to invoke paragraph six (6) of 35 U.S.C. section 112 as it exists on the date of the filing hereof unless the words “means for” or “step for” are specifically used in the particular claims; and (b) does not intend, by any statement in the specification, to limit this disclosure in any way that is not otherwise reflected in the appended claims.