Сучасні канали — це VBR з високим бітрейтом. У фіксований CBR-мультиплекс їх влазить хіба три, поки не почнеться переповнення — тож Ви розкидаєте десятки мультиплексів по всій смузі, продавлюєте QAM-256 усюди, і раптом уся мережа має бути ідеальною: лінійність підсилювачів, нахил, узгодження, стан кабелю на сотнях МГц. Одне слабке місце будь-де — і абоненти бачать артефакти, обриви, а Ви збираєте виїзди монтерів.

TSC statmux пакує всі ці VBR-канали у жменю мультиплексів — піки одного каналу заповнюють западини іншого. Ви займаєте невеликий неперервний шматок спектра замість усієї смуги, а вивільнений спектр витрачаєте на стійкість, а не на втрамбовування.

Ви задаєте пул; TSC розподіляє біти. Вказуєте, скільки каналів, загальний бітрейт MPTS і для кожного каналу мінімум, максимум і пріоритет. TSC розподіляє бітрейт у реальному часі за складністю сцени — активний рух отримує більше, статичні плани віддають біти назад — тож сума завжди лишається у Вашому фіксованому транспортному бюджеті з мінімальним null-заповненням.

Найбільше це важить там, де спектра мало від початку. Ліцензія MMDS дає Вам щонайбільше дванадцять несучих — а смугу часто ділять між двома операторами із захисним каналом посередині, тож одному дістається шість, іншому п'ять. Або у Вас три мультиплекси DVB-T2 — і все. За п'яти несучих, а тим паче за трьох, statmux — не оптимізація, а єдиний спосіб вивести в ефір пакет, за який хтось заплатить.

Це той самий клас динамічного, чутливого до сцени керування бітрейтом, що й AWS Elemental Statmux — постачений як програмне забезпечення на твоєму власному GPU, інтегрований у ту саму машину, що й транскодування, playout, доставка та білінг, без ліцензування broadcast-енкодера на вузол.