Evolution of the audiovisual streaming infrastructure for the interconnected collaborative environments within AccessGrid frameworks

Stimulus

With the advent of networking and computing technologies comes the capability for (and subsequent expectation of) high-fidelity multimedia services to be delivered in the contexts of virtual interaction, collaboration and generic media streaming scenarios.

The quality of video signals delivered over the Internet represents an integral part of the aforementioned multimedia services and requires specific attention from the software development community in order to ensure that existing and future computing networks are used to their out-most potential resulting in continuously improving quality of the audiovisual communications between interconnected users and organisations.

As the quality of communicated video data improves, so does the range of applications capable of utilising streamed video signals. Namely, the "video deployment" spectrum begins to evolve from a set of simple “virtual meetings” to more elaborate environments of remote-instrumentation and data acquisition, accelerated convergence of emergency response services and so on.

For instance, when dealing with emergency situations which require immediate expert analysis (e.g. miners' rescue efforts, collapsing bridge structure reconstruction or identification of live explosive devices) the provisioning of high-definition video streams generated "on site" by remote instrumentation and simultaneously streamed to a group of geographically disparate experts would facilitate more rapid and informed decision making process. The acceleration of such a process is ensured via the reduction of delay, “downtime” and "loss of relevance" factors commonly associated with transportation of all of the needed experts to a single physical location. In other words, one of the benefits of the improved fidelity in AccessGrid multimedia streaming infrastructure is the acceleration of tactical and expert-driven response processes.

Development goals

Evolve existing AccessGrid multimedia streaming infrastructure to a level of sophistication where it is practically feasible to interactively communicate high-definition video with the content-refresh rate of television broadcasting standards.

In more immediate and specific terms, the existing AccessGrid video multi-casting software (i.e. VIC) is to be appropriated for the deployment of advanced encoding standards (e.g. H263, Mpeg2 and DV) which are capable of high-resolution (e.g. 1408X1152, 1440x1080, etc.) imaging. Moreover, the VIC is to be expanded with capabilities for capturing, transmission and rendering of high-definition digital video standards such as DV and HDV.

Generally speaking, the aforementioned development goals will expand the capabilities of existing VIC to a level of video communications characterised by large dimensions (e.g. 1920x1080) and high refresh rates (e.g. 30 frames per second). For instance, the following diagram informally depicts the difference between image dimensions of the currently deployed and the proposed VICs.

Click here to see a comparison of full-size, 1:1 images from the aforementioned illustration.

Governing principles

Product development shall progress in an incremental and iterative fashion.

Incremental nature of the development process is represented by more frequent (yet with smaller number of new features) release cycles. Such a process exhibits the following advantages:

In other words, given that software-development projects usually take a long time to complete in their entirety, there is a need to ensure that the development processes do not "run away on a tangent" due to a significant delay between the establishment of project's goals and the time when such goals are delivered (e.g. by delivery date the solutions specified many months ago may no longer be relevant and simply become outdated).

An iterative characteristic of the software development is exemplified by recursive refinement of the required features during subsequent incremental release cycles. For instance, when a new feature is being specified for the first time, its implementation in the following release cycle may only be of "proof of concept" or "sketch-like" quality and robustness. After the relevant stakeholders had a chance to practically evaluate the general nature of implemented feature and, if necessary, make changes to feature's specifications (e.g. by answering questions such as "is the whole thing moving in the right direction?" or "perhaps some of the originally intended behaviour should be changed?") the "hardening" and optimisation of the feature may take place which shall be evident in the next release cycle. The whole process may then continue its iteration by performing any of the additional code re-factoring processes perpetuated by testing and formalisation (e.g. documentation) of the feature in question.

As the result of the aforementioned governing principles, the development of VIC shall be done under the banner of "Evolution, not revolution". By not re-writing the whole application (VIC) “from scratch at once” but rather gradually re-factoring it's various portions, one is able to address any of the immediately-pending issues thus making the software more reliable and feature-full but without the penalties of long delays, loss of relevance, "reinventing the wheel" and "repeating the old mistakes".

Such a development is incremental in nature because writing smaller portions/subsections of the "already existing and functional" application allows one to make the necessary feature release at a far more rapid rate (as compared to waiting for the much larger set of supporting infrastructure to be implemented when re-writing the program “from scratch”). Moreover, the "evolutionary" development process is also iterative because each development cycle improves on the previous state of a given feature (e.g. from "proof-of-concept" to optimisation, testing, re-factoring and formalisation).

On the whole, the VIC application may be conceptualised into a number of different layers of functionality:

The evolutionary development of VIC is envisaged to start with augmentation of the codecs layer (as denoted by “Encode” and “Decode” blocks in the above diagram) with subsequent adaptation of rendering mechanisms in order to efficiently display large-dimension images. Next, the network transmission path is planned to be adapted for carrying high-bandwidth traffic required by the new codecs. Following the aforementioned steps, the development is expected to concentrate on adapting the capturing mechanisms in terms of fixing existing capturing code (for higher frame rate capturing) and the introduction of new capturing mechanisms for video standards such as DV and HDV. The interface re-factoring is expected to be of minor levels during the first iteration and shall concentrate on improving the integration of VIC with the AccessGrid deployment scenarios (e.g. selecting a particular camera to use when streaming video, ability to run VIC on systems with varying technical capabilities and so on).

Another characteristic of the development processes associated with this project is the emphasis on backwards compatibility with the previous (actively deployed in AccessGrid live-sites) versions of VIC. This has the following advantages in terms of easier transition processes for the existing user-base (which subsequently results in higher retention rates of the current customer-base):

As of this moment, the backwards compatibility goals may be expressed as:

  1. Old codecs being readable by old rendering mechanisms;

  2. Old codecs being readable by any of the new rendering mechanisms;

  3. New codecs being render able by any of the new rendering mechanisms;

  4. To the extent of not having to alter the code in old rendering mechanisms, the new codecs should be renderable by the old renderers (e.g. if image dimensions are of such values that old renderers would be capable of displaying such an image when it has been encoded with the old codec, then the image should also be renderable by the old renderer when it has been encoded with the new codec).

A certain level of importance may be attributed to variations in the systems' configurations within the end-user communities. To this extent, the development of project shall allow for the customisation of the software's runtime characteristics so as to better cater for different deployment scenarios. Presently, such customisation may be expressed in the following terms:

Progress

Each of the incremental release cycles may be though of as a bi-directional process. The first, upward, direction augments the project with new features, mechanisms and ideas. The "topmost" point of this development sub-cycle is a "feature-freeze" moment when all of the relevant ideas have been implemented "in raw". Afterwards, the direction changes to "formalisation" process where all of the features and ideas (implemented during the first stage) are being tested, bug-fixed, re-factored and documented. At the end of such a process, the software is ready for its incremental release and the circle of iteration for the next incremental release can take place.

Current development status is at the “feature-freeze” point (i.e. the first half of the first release cycle is nearing completion). Namely, the following deliverables have been implemented:

Testing, optimisation and formalisation (intermixed with any necessary re-factoring) are to follow.

Click here for more details on current status and software downloads.

Recommended System Characteristics for HDV/DV vic.

Applications