Satu Input, Pelbagai Program Saluran FAST

Satu Input, Ratusan Program — Menjalankan Saluran FAST 24/7 di MediaLive

Saluran FAST 24/7 memainkan ratusan program unik setiap hari, selama-lamanya. AWS MediaLive mengehadkan sesebuah saluran kepada 20 lampiran input. Reka bentuk naif — satu input bagi setiap video — kehabisan slot sebelum tengah hari dan memaksa saluran dimulakan semula yang menyebabkan strim langsung terputus. Kami menyelesaikan masalah ini dengan satu input dinamik yang menyalurkan setiap program yang akan dimainkan oleh saluran, dan lapisan orkestrasi peringkat program di atas yang memastikan garis masa sembuh sendiri merentasi pelancaran, kegagalan separa, dan suntingan operator.

Ini adalah kisah kejuruteraan bagaimana orkestrasi tersebut sebenarnya berfungsi.

Gambaran ringkas

Masalah Perniagaan

Saluran FAST adalah perkhidmatan 24/7. Operator menjadualkan video unik seminggu penuh atau sebulan lebih awal, dan saluran tersebut perlu memainkan setiap satu pada saat yang tepat — menukar sumber dengan lancar, mengekalkan watermark stabil, mengeluarkan isyarat rehat iklan, mengisi sebarang jurang dengan slate berjenama stesen. Penonton tidak seharusnya melihat bingkai hitam, logo tersekat, atau program minggu lalu berulang.

Orkestrasi itu perlu bertahan terhadap semua yang dilakukan oleh operator: menyunting barisan program esok, menambah rehat iklan di tengah minggu, melancarkan semula selepas satu program gagal, berlumba dua klik Deploy. Sistem sama ada melaksanakan setiap perubahan secara atomik terhadap saluran langsung atau pulih dengan bersih. "Saluran kini berada dalam keadaan yang tiada siapa faham" bukanlah hasil yang boleh diterima pada infrastruktur yang bersiaran langsung.

Pengenalan Ringkas MediaLive 60 Saat

AWS MediaLive adalah pengekod awan yang berjalan lama. Anda memberikannya satu atau lebih input (strim sumber atau URL fail) dan jadual bagi tindakan bermasa — tukar kepada input ini, hidupkan overlay ini, masukkan isyarat ini. Pengekod berjalan selama-lamanya, melaksanakan tindakan pada cap masa yang dijadualkan dan mengeluarkan manifes HLS yang digunakan oleh pemain penonton.

Dua had AWS membentuk semua yang di hiliran:

• 20 lampiran input bagi setiap saluran. Had keras. Saluran "20 filem teratas" yang direka secara naif dengan satu input bagi setiap video memenuhi had pada filem ke-21.
• 1500 tindakan jadual bagi setiap saluran. Juga had keras. Setiap program adalah beberapa tindakan (penukaran input, watermark bagi setiap rendition, isyarat iklan, penukaran slate), jadi had sebenar adalah lebih kurang beberapa ratus program pada satu-satu masa.

Kedua-dua had ini penting untuk saluran 24/7 yang dijangka memainkan kandungan unik secara tidak terhingga.

Mengapa Pendekatan Naif Gagal

Laluan yang jelas masing-masing gagal dengan cara yang berbeza:

• "Satu input bagi setiap program." memenuhi had 20 lampiran pada hari pertama. Menambah lebih banyak memerlukan penciptaan semula saluran — dan penciptaan semula saluran mengambil masa 60–90 saat di mana strim langsung akan terputus. Tidak boleh diterima pada perkhidmatan 24/7.
• "Cipta semula saluran bagi setiap pelancaran." Masalah yang sama, setiap pelancaran. Penonton mengalami gangguan setiap kali pengaturcaraan berubah. Ini bukan pilihan sebenar untuk saluran yang sepatutnya bersiaran langsung.
• "Prakodkan seluruh minggu menjadi satu fail gelung gergasi." Membunuh model penyuntingan. Mahu menyusun semula esok? Kodkan semula seluruh minggu. Mahu memasukkan iklan? Kodkan semula. Seluruh sebab saluran FAST berfungsi sebagai perniagaan adalah pengaturcaraan dinamik dan penyisipan iklan setiap rehat — membakar segala-galanya ke dalam satu fail menutup kedua-duanya.
• "Jalankan berbilang saluran secara selari." Memerlukan pemain untuk bertukar antara mereka, menggandakan kos AWS, dan memecahkan saluran audio, MediaPackage, dan CDN. Tidak begitu menyelesaikan masalah malah menggandakannya.

Lever yang kami ada ialah satu ciri yang didokumentasikan oleh AWS — pemegang tempat $urlPath$ pada input dinamik — dan kebebasan untuk membina apa sahaja orkestrasi yang kami mahukan di atasnya.

Mengapa ini penting. Tipnya bukan menggunakan $urlPath$. AWS mendokumentasikannya. Tipnya adalah membina lapisan orkestrasi pemulihan kendiri di atasnya yang bertahan daripada pelancaran separa, suntingan operator, dan percubaan semula serentak — tanpa pernah meletakkan saluran langsung ke dalam keadaan yang tiada siapa dapat gambarkan daripada UI.

Penyelesaian Kami

Satu saluran MediaLive. Satu input dinamik yang dipautkan ke URL $urlPath$ yang tepat. Satu input slate untuk mengisi jurang. Pada setiap sempadan program, tindakan InputSwitchScheduleActionSettings mengatasi URL input dinamik dengan laluan S3 sebenar program tersebut. Saluran itu tidak pernah memerlukan lampiran input baharu, tidak pernah memerlukan permulaan semula, tidak pernah terputus talian.

Kerja yang menarik ialah lapisan orkestrasi yang berjalan di atas satu input itu — menamakan setiap tindakan dengan ID program supaya tindakan yatim boleh dibersihkan selepas kegagalan, mengisi jurang ≥ 6 saat dengan slate supaya penonton tidak pernah melihat bingkai beku, mengaktifkan watermark pada masa yang diukur selepas setiap penukaran input supaya overlay tidak berkelip melalui bingkai penimbal, dan membuat pra-semakan terhadap had 1500 tindakan supaya pelancaran gagal di UI dan bukannya di tengah-tengah penerbangan di AWS.

Rajah 1 · Seni Bina Saluran

Seni Bina

• Input slate — aset statik yang dilampirkan pada saluran untuk mengisi jurang antara program.
• Input dinamik — dicipta sekali dengan Sources: [{ Url: "$urlPath$" }], Type: MP4_FILE. URL adalah pemegang tempat; laluan sebenar dibekalkan bagi setiap program pada masa penjadualan.
• Orkestrator Lambda (fastChannel-lambda-fun/index.js) — memiliki setiap aktiviti yang muncul pada saluran. Menjana programId heks 8-bait bagi setiap program dan menandakan setiap tindakan yang berkaitan dengannya.
• Jadual MediaLive — senarai tindakan tunggal yang teratur, semuanya mengalir melalui satu BatchUpdateScheduleCommand. Dihadkan kepada 1500 tindakan oleh AWS.
• Pra-semakan backend (schedule.service.ts) — memanggil GET_SCHEDULE_COUNT Lambda sebelum setiap pelancaran dan enggan meneruskan jika tindakan baharu akan melebihi had.

• Pembersihan yatim (sweepIncompleteProgramGroups) — berjalan selepas setiap pelancaran. Mengumpulkan tindakan mengikut programId, memadam mana-mana kumpulan yang kehilangan tindakan input-switch utama.

   

Keputusan Kejuruteraan Utama

1. Satu input dinamik, satu penindihan URL bagi setiap program

Input dinamik dicipta dengan Sources: [{ Url: "$urlPath$" }]. Pada setiap sempadan program, Lambda mengeluarkan tindakan InputSwitchScheduleActionSettings yang membekalkan UrlPath: [program.videoUrl] — URL S3 sebenar bagi MP4 program tersebut. MediaLive menggantikan pemegang tempat pada masa pelaksanaan dan menarik dari sumber sebenar.

Satu lampiran input kini menyalurkan setiap program yang akan dimainkan oleh saluran — secara berkesan video unik tanpa had sepanjang hayat saluran, dihadkan hanya oleh had tindakan-jadual bagi setiap pelancaran pada satu-satu masa. Had 20-input tidak lagi menjadi kekangan, dan saluran tidak pernah memerlukan permulaan semula untuk menambah kandungan baharu.

Rajah 2 · Penindihan URL Input Dinamik

Pertukaran yang kami sengaja lakukan. Input dinamik tidak mengesahkan URL terlebih dahulu — MediaLive hanya menyelesaikan pemegang tempat pada masa penukaran, jadi ralat 404 muncul sebagai ralat sisi strim dan bukannya penolakan pada masa pelancaran. Kami menerima kos tersebut sebagai pertukaran untuk kesederhanaan seni bina satu input. Pengesahan ffprobe backend yang berasingan menangkap sumber yang tidak teratur sebelum pelancaran.

2. Nama tindakan bertag program membolehkan pemulihan kendiri

Setiap tindakan yang dikeluarkan oleh Lambda membawa programId heks 8-bait program dalam namanya: input-switch-${programId}, watermark-on-${programId}-${rendition}, ad-break-start-${programId}-${i}, program-end-${programId}, slate-switch-${programId}.

Selepas setiap pelancaran, sweepIncompleteProgramGroups menyenaraikan setiap tindakan yang sedang berjalan di saluran, mengumpulkannya mengikut programId yang terbenam, dan memadam mana-mana kumpulan yang kehilangan tindakan input-switch utamanya. Itu adalah laluan pembersihan untuk pelancaran separa yang gagal, suntingan yang tergesa-gesa, dan sebarang keadaan lain yang boleh meninggalkan saluran dengan tindakan separuh program yang terdampar.

Pengekodan nama tindakan adalah keseluruhan mekanisme identiti. MediaLive itu sendiri tidak mempunyai konsep "program" — lapisan orkestrasi memprojeksikannya melalui konvensyen penamaan.

Mengapa ini penting. Tanpa ID program yang terbenam dalam setiap nama tindakan, pembersihan yatim tidak akan tahu tindakan mana yang berkaitan. Pembersihan peringkat tindakan sama ada akan memadam terlalu banyak (set semula keseluruhan saluran) atau terlalu sedikit (watermark yang terdampar yang tidak pernah padam). Konvensyen penamaan adalah model data.

3. Peraturan slate 6 saat

Program jarang sekali bersambung dengan sempurna — hampir selalu ada jurang beberapa saat antara penghujung satu MP4 dan permulaan program seterusnya yang dijadualkan. Orkestrasi mengeluarkan tindakan slate-switch apabila jurang tersebut ≥ 6 saat (MIN_SLATE_GAP_MS = 6000).

Ambang ini bukan sewenang-wenangnya. MediaLive menguatkuasakan jarak minimum 5 saat antara mana-mana dua tindakan jadual; mengeluarkan tindakan slate-switch yang lebih dekat daripada itu kepada input-switch program seterusnya akan menghasilkan penolakan. Peraturan 6 saat memberikan MediaLive jurang yang diperlukan dan meninggalkan lapisan orkestrasi satu saat margin keselamatan hanyut jam. Di bawah 6 saat, kami membiarkan bingkai terakhir program sebelumnya beku seketika daripada mengambil risiko penolakan pelancaran.

4. Watermark setiap rendition dengan kelewatan pengaktifan yang diukur

Watermark adalah tindakan StaticImageOutputActivate yang dikeluarkan bagi setiap rendition output (1080p, 720p, 480p, 360p) — empat tindakan bagi setiap program. Setiap tindakan berlaku 1,500 ms selepas input-switch program tersebut.

Kelewatan wujud kerana bingkai pertama selepas penukaran input masih dalam penimbalan; mengaktifkan overlay pada masa penukaran yang tepat boleh menghasilkan kelipan seketika apabila overlay melukis pada bingkai yang belum dirender sepenuhnya. 1,500 ms adalah nilai yang secara konsisten menghasilkan pengaktifan yang bersih merentasi keempat-empat rendition dalam ujian. Ia adalah pemalar yang diukur, bukan parameter MediaLive yang didokumentasikan — dan ia berada di satu tempat dalam kod supaya penalaan masa depan adalah perubahan satu baris.

Pertukaran yang kami sengaja lakukan. Tindakan overlay setiap rendition menelan kos 4× kiraan tindakan berbanding overlay global tunggal. Kami menerima kos ini kerana laluan setiap rendition membolehkan setiap output mendapatkan watermark yang saiznya tepat untuk dimensi pikselnya, daripada membiarkan MediaLive menurunkan skala satu overlay merentasi keempat-empatnya. Hasilnya ialah logo yang kelihatan lebih tajam pada output SD — dan ia meninggalkan belanjawan tindakan yang cukup untuk ratusan program sebelum had 1500 menjadi penting.

5. Had 1500 tindakan, telah disemak dalam UI

AWS mengenakan had keras pada saluran MediaLive sebanyak 1500 tindakan jadual. Dengan ~7–8 tindakan bagi setiap program (input switch + 4 watermark + 2 isyarat iklan + slate sekali-sekala), saluran tersebut memegang kira-kira 180–200 program aktif bergantung pada kepadatan iklan dan kekerapan slate. Itu adalah had sebenar untuk pelancaran jangka panjang, dan nombor yang tepat bergantung pada kerumitan setiap program.

Sebelum setiap pelancaran, backend memanggil GET_SCHEDULE_COUNT Lambda, yang mengira tindakan langsung di saluran melalui DescribeScheduleCommand dan mengembalikan { liveCount, capacity: 1500 }. Jika liveCount + (newPrograms × 8) akan melebihi 1500, backend membuang SCHEDULE_ACTION_CAP_EXCEEDED dengan nombor ruang kepala yang tepat — sebelum ia menyerahkan apa-apa kepada MediaLive. Operator melihat had di UI dengan panduan untuk membersihkan program lalu terlebih dahulu. Pelancaran tidak pernah separuh berjalan menghadapi halangan.

Rajah 3 · Garis Masa Tindakan Satu Program

Hasil

• Satu saluran MediaLive menyalurkan program unik yang secara berkesan tidak terhad sepanjang hayatnya, pada satu lampiran input dinamik. Had 20-input tidak lagi menjadi kekangan yang perlu kami rancangkan — kapasiti pada satu-satu masa diuruskan oleh had tindakan-jadual, bukan had input.
• Orkestrasi saluran adalah pemulihan kendiri: setiap pelancaran berakhir dengan pembersihan yatim, jadi pelancaran separa yang gagal tidak dapat meninggalkan jadual dalam keadaan tidak konsisten.
• Kapasiti jadual adalah terhad dan kelihatan. Operator melihat had 1500 tindakan di UI sebelum mereka klik, bukan sebagai penolakan AWS yang tidak jelas di tengah-tengah pelancaran.
• Konvensyen penamaan ID program adalah keseluruhan lapisan identiti — dan ia adalah rentetan. Tiada infrastruktur baharu, tiada storan tambahan, tiada kebergantungan. Projeksi "program" yang paling mudah ke dalam senarai tindakan rata MediaLive.

Susunan Teknologi: AWS MediaLive · AWS Lambda · NestJS · MongoDB · TypeScript · Node 18 · AWS SDK v3 (@aws-sdk/client-medialive)