Multi-Channel Integrated playout solution and Compliance Recording

Belangrijkste functionele vereisten • Betrouwbare opname van alle playout-kanalen • Opnames van de playout-kanalen voldoen aan de wettelijke voorschriften in België Belangrijkste technische vereisten • Sterke systeemarchitectuur • Gedistribueerde software • Een combinatie van COTS en virtuele hardware • Mogelijkheid om eenvoudig uit te breiden • Mogelijkheid om in de toekomst over te gaan op UHD-opname • Intuïtieve gebruikersinterface Integratie met de VRT-omgeving De oplossing moet geïntegreerd worden in de bestaande uitzendinfrastructuur van de VRT, en moet in de toekomst ook volgende zaken kunnen integreren: • Het inputformaat van het systeem voor naleving moet via de uitzendinfrastructuur van de VRT kunnen worden aangeleverd. • Er is integratie met de VRT-opslag nodig, om back-ups van opnames te kunnen bewaren zo lang als wettelijk nodig, en voor historische bestanden.

Playout-oplossing voor meerdere kanalen Belangrijkste functionele vereisten De VRT is op zoek naar een playout-oplossing voor meerdere kanalen die gebruikt kan worden voor 3 usecases: playout voor een premiumkanaal (3 kanalen), playout voor een live radiokanaal (10 kanalen), en playout voor een eventkanaal (maximaal 20 kanalen). De usecase van het premiumkanaal is verplicht. De twee andere usecases moeten financieel gedifferentieerd worden: de grootte kan veranderen, afhankelijk van de kosten. De VRT zal tijdens de onderhandelingsfase beslissen of de twee andere usecases financieel haalbaar zijn en behoudt zich daarom het recht voor om te beslissen of ze in dit onderdeel besteld zullen worden. Binnen dit bestek is de VRT op zoek naar een systeem voor herstel na calamiteiten voor de usecase van het premiumkanaal, en naar een stagingsysteem waarmee alle usecases getest kunnen worden. De verschillende usecases en de systemen die nodig zijn voor het bestek, worden hieronder beschreven. Playout voor het premiumkanaal De VRT zendt momenteel drie lineaire kanalen uit via een traditioneel automatiseringssysteem en een transmissieketen. Deze kanalen zijn VRT 1, VRT Canvas en Ketnet. VRT 1 is het hoofdkanaal van de VRT, VRT Canvas focust op cultuur en Ketnet is een kanaal voor kinderen. De VRT heeft ook een offline TX-keten of reservekanaal, dat operatoren onder meer kunnen gebruiken om te testen. De afspeellijsten worden gemaakt in een planning- en trafficsysteem en geëxporteerd naar het automatiseringssysteem, waar ze worden geladen en afgespeeld, en waarbij de tijdsaanduiding voor de playout van de video en van live of andere events wordt vastgelegd. Secundaire events, zoals graphics, ondertiteling (zowel live als op basis van een bestand), SCTE-invoeging, audioresolutie, geluidssterkte, audio shuffle en het invoegen van de voice-over worden geïnitieerd via het automatiseringssysteem. Bovendien verwerken alle kanalen live playout met behulp van verschillende operationele strategieën. Het nieuwe systeem moet niet alleen aan deze vereisten voldoen, maar vereenvoudigt ook de bestaande werkwijze door gebruik te maken van een geïntegreerde, modulaire aanpak, waarbij er zo min mogelijk gebruik wordt gemaakt van systemen van derden of ingewikkelde workflows. Livekanalen van radiostudio’s De VRT wil 10 kanalen opnemen in de oplossing, die live-feeds kunnen hosten die gemaakt zijn door camera’s in de radiostudio’s van de VRT. Door deze kanalen te hosten binnen het automatiseringssysteem, kan de VRT flexibel kanaalbranding toevoegen aan de live-feeds en indien nodig content vanaf een server uitzenden, wat momenteel moeilijk is. De dagelijkse afspeellijsten zullen voornamelijk bestaan uit live-events van zes uur, die ruim van tevoren kunnen worden voorbereid. Deze kanalen zijn in feite vereenvoudigde pijplijnen, die niet zoveel functionaliteiten nodig hebben als de premiumkanalen. Playout voor pop-up- en eventkanalen De VRT vraagt ook om een specifieke usecase: de mogelijkheid om pop-up- en eventkanalen te gebruiken voor evenementen zoals de Olympische Spelen. Het concept moet een oplossing bieden waarbij binnenkomende clean feeds van omroeppartners naar het automatiseringssysteem kunnen worden gestuurd, en waar ze “opgeschoond” kunnen worden door bijvoorbeeld VRT-kanaalbranding toe te voegen. Deze streams worden daarna naar het VRT OTT-platform gestuurd, waar ze op aanvraag bekeken kunnen worden. Deze kanalen zijn niet permanent: de VRT wil dan ook gebruik maken van een systeem waarbij betaald wordt op basis van gebruik. De kandidaat moet de beste optie aanraden om deze usecase te hosten, rekening houdend met het SaaS/Cloud-bedrijfsmodel: de back-end-infrastructuur moet de opstart van deze kanalen op korte termijn kunnen ondersteunen. Er kunnen maximaal 20 kanalen tegelijkertijd opgestart worden: het systeem moet deze belasting aankunnen. De 20 evenementkanalen zullen alleen tijdens specifieke eventperiodes tegelijkertijd actief zijn. Op andere momenten zijn er geen of veel minder kanalen nodig. De kandidaat moet de beste manier voorstellen om met deze usecase om te gaan. Kunnen kanalen bijvoorbeeld een uitgang delen, zolang de zendschema’s niet overlappen – en hoe wordt dit aangepakt? Moeten kanaalconfiguraties vooraf worden opgeslagen, om dan, wanneer nodig, te worden geladen en uitgezonden? Hoelang zou het duren om een kanaal op te starten en een configuratie te laden? Voor de verdere toelichting verwijs ik naar de selectieleidraad.