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.
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.
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:
Software development is more responsive to the ongoing change in requirements such as different directions for the project, re-evaluation of various milestones/features and so on;
The management and end-user demographics are able to experience new features and adjust/refine their functional specifications at a more rapid rate in an ongoing fashion;
The management and engineering processes are allowed to be more responsive to changing technological environments (e.g. new technologies/solutions becoming more available/affordable for any of the outstanding issues).
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):
Users are already familiar with the software's interface (which is not altered in newer versions for the sake of improved functionality as there is no "re-writing from scratch" and the issues of functionality do not result in explicit changes in interface). In other words, there is no need for a given user to learn a new way to achieve the same (albeit of better quality) process such as transmitting video streams between two venues;
Easier integration with the existing AccessGrid services which already deploy VIC software (this reduces the overhead associated with additional system and business process re-engineering as compared with integration of a completely new/different/disparate software);
Gradual “phasing out” of the old mechanisms and codecs without generating any of the immediate threats and deployment re-engineering requirements for the user-base (i.e. new versions will support interoperability with the sites running older/previous versions).
As of this moment, the backwards compatibility goals may be expressed as:
Old versions may be used to stream video to new versions which will be able to receive and display the images without any additional configuration required on behalf of the transmitting side;
New versions must retain the codecs present in the older versions;
New versions must be able to stream the video to the older versions without any additional configuration required on behalf of the older versions for as long as the transmitted video is encoded with any of the codecs present in the older versions;
New versions must be able to render images encoded by all codecs via any of the new or old rendering mechanisms. This translates into the following required combinations of interoperability that are to be implemented in the newer versions:
Old codecs being readable by old rendering mechanisms;
Old codecs being readable by any of the new rendering mechanisms;
New codecs being render able by any of the new rendering mechanisms;
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:
Non-certified systems (e.g. without Xvideo hardware-accelerated rendering support) shall still have the ability to provide basic functionality of the software in question;
Configuration of the software (e.g. command-line options, environment variables, etc.) shall have many options in order to customize (e.g. enable or disable new features at a "feature-specific" level) the running on non-ideal systems (e.g. systems with low refresh-rate of the underlying kernel, image-tearing due to lack of system's support for OpenGl extensions, multi-screen display layout without Xvideo rendering support across the virtual display, etc.);
Likewise, the configuration of software shall allow the "certified" systems to take full advantage of their processing power (parallel processing on multi-threading/multi-core machines, lip-sync for presentation modes, low latency for interaction modes, presence of hardware accelerated rendering and hardware accelerated encoding of video signals).
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:
High-fidelity capable encoding and decoding mechanisms (codecs such as H263, DV, MPEG2) with support for multi-threaded/multi-core computing environments;
Rendering/displaying of high-fidelity images (Xvideo hardware acceleration coupled with Imlib2 software rendering mechanisms);
Upgraded network transmission layer (fixed burst management of the data flow, provided new implementation for global lip-sync environment, improved streaming mechanisms for long sequences of data packets);
New and improved video capture architecture capable of high-dimensions/high-frame-rates video streaming (DV and HDV capture over firewire; improved video4linux grabber code);
User interface improvements (inclusive of “auto display sizing” features, new command line options, diagnostics/scan output of available video capturing devices, auto-naming of firewire devices, unique/persistent naming for the firewire devices based on their serial numbers).
Testing, optimisation and formalisation (intermixed with any necessary re-factoring) are to follow.
Emergency and tactical response environments;
Remote education and accreditation;
Farming (e.g. animal care);
Robotics;
Data collection in hazard environments;
Surveillance;
Virtual meetings.