Elemental Statmux

<< Return to My Work

Early iteration of an MPTS runtime graph.
Early wireframe iteration of an Elemental Statmux runtime graph.

Case Study 1     |    Case Study 2 


Company: Elemental Technologies

Product: Elemental Statmux is a software solution to manage video muxing across multiple channels and encoding systems.

User Info: Elemental Statmux was designed with a focus on Elemental’s persona of Operator – the person responsible for managing multi-program transport streams (MPTS).

History: Prior to the introduction of Statmux, Elemental had no support for multi-program transport streams, or MPTS. Video data for cable television operations is traditionally packaged in the the form of an MPTS, providing a set of ‘programs’ (think of them as constant TV channels) that combine into a single stream. The stream relies on a product like Statmux to manage bitrate allocation (file size management), considering issues of quality and resolution, within each stream. The process is known as ‘muxing’.

Mission: Design two parallel workflow models to support MPTS transport streams: One where the same machine that encodes video can also mux its video in one machine, and another where a single Elemental Statmux machine (with a backup) can mux encodes from other machines across the network. Support the management of relevant encodes and muxes within the Conductor Live ecosystem.

Roles: UX Designer, UX Researcher, Information Architect, Business Analyst, Program Manager, Release Manager

UX Design Process: I worked with a team of engineers familiar with the muxing process to ideate on user controls and feedback mechanisms. I then made wireframe and workflow diagrams to document the plan, and tested them with users representing the engineer and operator personas (mentioned in the Elemental Conductor Live overview). After a few iterations, we had a plan to move forward.

Program Management: The release of Elemental Statmux was intertwined with the release of Elemental Conductor Live, as Conductor Live was built to manage multiple installations of Elemental Statmux. I found it valuable to separate the topics as much as possible when reviewing scope and product requirements, to keep stakeholders on track. However, the Agile development process for the two products overlapped considerably, with many of the same team members (including myself as the Program Manager) serving both projects.

Case Study 1: Design the workflow for Packet Identifier (PID) Management

Context: As part of configuring for video encoding, Elemental Live gave users the ability to specify unique PID values within a channel configuration. These values can represent many packet types, including audio, captions, etc. Users combine many tools into their workflows, and use PID values to track packets across their network. Channels were being combined into multi-program transport streams, which also specified various PIDs per channel.

Problem: Since quality and identification settings were being combined in common configuration files, users relying on consistent configuration settings would often end up with unspecific PID values across channels. For example, users may want multiple channels to have the same caption settings, and wanted to manage this through common profiles. (See “Common Profile Design for Conductor Live” in a separate case study.) A common result of a user workflow would be that they also share common PID values. But when channels are ‘muxed’ into a single MPTS stream, it was necessary to have unique PIDs for every setting, on every channel.

Key Challenges: Attempting to skip workflow analysis and gathering of user input, the team’s default solution involved asking users to edit channels in order to create unique PIDs. In managing 1000s of channels, that was highly impractical for users for many reasons. The more channels were edited, the more risk was introduced. And the only way to know whether a PID value would be unique would be to compare it to other channels in the context of the MPTS.

Process: I spent time with users and user configurations to get real world examples and the reasoning behind particular workflow actions. I documented what the challenges were, and met with stakeholders in order to clearly define the problem, and properly question the default solution of user edits per channel. Once defined, I sketched flow diagrams and carefully walked through stories of editing and managing PID values across many channels, and multiple MPTS instances. I sketched out low fidelity, and increasingly higher fidelity prototypes, as I reviewed the proposed workflow solution with engineers, stakeholders, and users. For users, I sketched out very granular steps, and walked through the proposed management process. Their feedback helped validate and further shape the solution, leading to a simple organization of PIDs that facilitated unique values.

Solution: By having the workflows drawn out and reviewed with users, I was able to see another place in the workflow where PIDs could be managed – at the MPTS, as a channel is added to it. Further, I discovered that editing the PID at the channel itself was unnecessary, as long as its representation in the MPTS had unique values that users could track. So in this solution, the MPTS would ignore PIDs specified at the channel, and use its own PID creation/management system based on the channels within it.

Wireframe for Statmux Pid Allocation
Wireframe used to document and test plans for PID allocations.

Outcomes: The team developed a channel addition tool for the MPTS that involved providing unique PID values within each channel listing, while giving users the ability to manually override any value as desired. If user provided values were not unique, we would represent the conflict in red, and prevent saving until validation conflicts were resolved. This made a complex topic easy to manage for our users by providing values, while still allowing for user-generated values when needed.

top of page

Case Study 2: Represent Allocated Bitrate Values for Multi-Program Transport Streams

Context: When muxing, an MPTS (mult-program transport stream) distributes bitrate values across multiple channels, so that the sum bitrate of those channels is fixed, and they have the highest shared quality possible. For instance, a channel showing active sports requires a higher bitrate (data through the network, per second) than a channel showing people seated in a studio. Within a mux, the system can take bitrate from one channel and increase the bitrate for another, presenting a consistent level of quality.

Problem: A solution was needed to allow users to monitor bitrate allocation efficiently and easily, beyond the listing of values as digits, over time.

Process: After solidifying the problem statement, I researched solutions for representing data through graphs over time. I ideated on presenting both charts of data along with graphical representation. Reviewed rough sketches with stakeholders, developers, and end users. Iterated on solutions, adhering to technical constraints of platform and information flow.

Solution: I worked with UI developers to create a dynamic graph, with settings for different readout speeds, a legend for colors, and a corresponding chart representing configuration settings. Introduced developers to a color palette designed to serve those with the broadest prevailing form of color blindness, in order to improve accessibility needs.

Statmux annotated wireframes
Statmux annotated wireframes used to review workflow plans with users.

Outcomes:The graph became the go-to view for our operator persona users, and a key functional benefit to using our product suite. At this point, the MPTS paradigm (used in Elemental Live) became its own product exclusively for muxing – Elemental Statmux.

top of page