Recasting and Recording System (RRS): A case study by Fluendo

The request

Fluendo’s Consulting Services team was approached to develop a Recasting and Recording System (RRS). This RRS was required to function as a backend service integrated into the client’s product portfolio.

The client is a global leader in audio and video solutions, specializing in processing, analyzing, managing, and storing audio and video across various formats, including file-based, streaming, and live (TV). Their innovative systems integrate advanced third-party AI analytics and algorithms, serving industries like security, government and public administration, healthcare, and legal.

Features

The RRS was designed to enable the main application to:

• Add and remove media channels across various formats.
• Configure these channels for recasting, recording, or both.

Project constraints

A project based on the client solution with these features had already been committed to be delivered in the following quarter. The tight timeline meant the system had to be developed rapidly without compromising quality or functionality.

Delivery requirements

The solution had to be delivered as a containerized application that could integrate and be managed by the client’s infrastructure.

Priorities

Recasting was the top priority, regardless of the recasting method, because it was needed for the commitment above; then came the support of formats, and the recording came in last.

The Fluendo’s Solution

API-driven interaction

Fluendo proposed an API-based service enabling seamless interaction between the RRS and the client’s application.

The API included:

• Configuration management: Import and export configurations, such as snapshots or system states.
• CRUD operations: Create, read, update, and delete media channels.
• Asynchronous event handling: The caller can set up webhooks to notify the client’s application of events or results.

Modular architecture

The RRS was designed with a modular and decoupled architecture, able to support an initial set of protocols and formats in a modular and decoupled way so that adding support for additional elements would not impact the core functionality.

This process allows the application to be extended as new needs appear over time with limited overhead and a negligible impact on the current development, leading to more cost-effective improvement cycles for the client.

Testing for quality assurance

To maintain top-tier performance and reliability, Fluendo implemented a Behavior-Driven Development (BDD) Testing Architecture involving the following components:

• Feature Files: Define test scenarios.
• Behave Framework: Executes scenarios and steps in Python.
• HTTP Client (Python): Sends HTTP requests to the server.
• Third-party Components: Manage WebRTC signalling servers and VLC servers for video streaming and handle HTTP requests. It also facilitates testing of video downloads and WebRTC message verification.

The testing focuses on three areas:

• Channels: Verifies channel configurations via HTTP.
• Protocols: Tests communication protocols like WebRTC signalling, UDP and RTSP, and video storage features.
• Performance: Measures the HTTP latency and server throughput under load.

These components work together to ensure the system’s functionality is implemented according to the specifications and that the performance is within the expected values across different scenarios.

Efficient packaging and deployment

The Packaging and Testing Process implemented in the project ensures that Docker containers are built, tested, and deployed efficiently for different environments. It includes the following steps:

1. Build a Base Container Image: Create reusable container images.

2. Build, setup and pack the RRS and GStreamer: The applications are cloned, built, and prepared for both development and production environments.

3. Artifact management: Built artifacts (such as application and library files) are saved for later use.

4. Testing Environment: If tests are to be run, a testing environment is set up using a container image and end-to-end tests are executed. HTML reports are collected and sent to the host, where the packaging process is executed.

5. Deploy and Run: Finally, the container is started for testing or as a running HTTP server for production.

This process ensures a streamlined and automated way to package, test, and deploy the application in various environments.

Conclusion

Fluendo was able to design and develop a production-ready recasting and recording system tailored to the needs of the client that can be easily extended over time with reduced cost, thus fostering a mutually beneficial long-term collaboration relationship, in a limited time frame while keeping the utmost quality standards and providing the tools to ensure that that quality is kept over time.