Tek Giriş, Birden Çok FAST Kanal Programı

Tek Giriş, Yüzlerce Program — MediaLive Üzerinde 7/24 FAST Kanalları Çalıştırma

7/24 bir FAST kanalı, her gün, sonsuza dek yüzlerce benzersiz program yayınlar. AWS MediaLive, bir kanalı 20 giriş eklentisiyle sınırlar. Naif tasarım — video başına bir giriş — öğle yemeğinden önce yuvaları tüketir ve canlı yayını çevrimdışı hale getiren bir kanal yeniden başlatmasını zorunlu kılar. Bu sorunu, kanalın yayınlayacağı her programı sunan tek bir dinamik giriş ve dağıtımlar, kısmi arızalar ve operatör düzenlemeleri arasında zaman çizelgesini kendi kendini onarır durumda tutan program düzeyinde bir orkestrasyon katmanıyla çözdük.

Bu, o orkestrasyonun gerçekte nasıl çalıştığının mühendislik hikayesidir.

Hızlı genel bakış

İş Problemi

Bir FAST kanalı 7/24 hizmettir. Operatörler, bir hafta veya bir ay boyunca benzersiz videoları önceden planlar ve kanalın her birini doğru saniyede oynatması gerekir — kaynakları temiz bir şekilde değiştirmesi, filigranı sabit tutması, reklam arası ipuçları göndermesi, boşlukları bir istasyon markalı slate ile doldurması gerekir. İzleyici asla siyah bir kare, takılı kalmış bir logo veya geçen haftanın programının döngüye girdiğini görmemelidir.

Bu orkestrasyon, operatörlerin ona yaptığı her şeye dayanmak zorundadır: yarının yayın akışını düzenleme, hafta ortasında reklam araları ekleme, tek bir başarısız programdan sonra yeniden dağıtma, Deploy düğmesine iki kez art arda basma. Sistem ya her değişikliği canlı kanala atomik olarak uygular ya da temiz bir şekilde kurtarılır. "Kanal şu anda kimsenin anlamadığı bir durumda" canlı yayın yapan altyapı için kabul edilebilir bir sonuç değildir.

60 Saniyede Bir MediaLive Başlangıç Kılavuzu

AWS MediaLive, uzun süre çalışan bir bulut kodlayıcısıdır. Ona bir veya daha fazla giriş (kaynak akışları veya dosya URL'leri) ve zamanlanmış eylemlerden oluşan bir zamanlama — bu girişe geç, bu yer paylaşımını aç, bu işareti ekle — verirsiniz. Kodlayıcı sonsuza dek çalışır, eylemleri zamanlanmış zaman damgalarında yürütür ve izleyicinin oynatıcısının tükettiği bir HLS manifesti yayınlar.

İki AWS sınırı, aşağı akıştaki her şeyi şekillendirir:

• Kanal başına 20 giriş eklentisi. Katı sınır. Video başına bir girişle naifçe tasarlanmış "En İyi 20 film" kanalı, 21. filmde sınırı doldurur.
• Kanal başına 1500 zamanlama eylemi. Bu da katı bir sınırdır. Her program birkaç eylemden (giriş değiştirme, gösterim başına filigran, reklam işaretleri, slate değiştirme) oluşur, bu nedenle gerçek tavan, herhangi bir zamanda birkaç yüz programa daha yakındır.

Her iki sınır da süresiz olarak benzersiz içerik oynatması beklenen 7/24 bir kanal için önemlidir.

Neden Naif Yaklaşımlar Başarısız Olur?

Açık yolların her biri farklı şekillerde başarısız olur:

• "Program başına bir giriş." ilk günün 20 eklenti sınırını doldurur. Daha fazlasını eklemek, kanalın yeniden oluşturulmasını gerektirir — ve kanalın yeniden oluşturulması, canlı yayının kesildiği 60–90 saniye sürer. 7/24 bir hizmette kabul edilemez.
• "Her dağıtım için kanalı yeniden oluştur." Her dağıtımda aynı sorun. Programlama her değiştiğinde izleyiciler bir kesinti yaşar. Bu, canlı olması beklenen bir kanal için gerçek bir seçenek değildir.
• "Tüm haftayı tek bir devasa döngüsel dosyada önceden kodla." Düzenleme modelini öldürür. Yarını yeniden mi sıralamak istiyorsunuz? Tüm haftayı yeniden kodlayın. Bir reklam mı eklemek istiyorsunuz? Yeniden kodlayın. FAST kanallarının iş olarak çalışmasının tüm nedeni dinamik programlama ve ara başına reklam eklemesidir — her şeyi tek bir dosyaya yazmak her ikisini de engeller.
• "Birden çok kanalı paralel çalıştır." Oynatıcının aralarında geçiş yapmasını gerektirir, AWS maliyetini katlar ve ses, MediaPackage ve CDN işlem hattını bozar. Sorunu çözmekten çok çarpar.

Sahip olduğumuz kaldıraç, tek bir AWS belgeli özellikti — dinamik bir giriş üzerindeki $urlPath$ yer tutucu — ve onun üzerine istediğimiz orkestrasyonu inşa etme özgürlüğü.

Bu neden önemli? Püf nokta $urlPath$ kullanmak değil. AWS bunu belgeliyor. Püf nokta, kısmi dağıtımlara, operatör düzenlemelerine ve eşzamanlı yeniden denemelere dayanabilen, canlı kanalı asla UI'dan kimsenin açıklayamayacağı bir duruma sokmadan, kendi kendini onaran bir orkestrasyon katmanı inşa etmektir.

Çözümümüz

Tek bir MediaLive kanalı. Tam URL $urlPath$'e bağlı tek bir dinamik giriş. Boşluk doldurmalar için tek bir slate girişi. Her program sınırında, bir InputSwitchScheduleActionSettings eylemi, dinamik girişin URL'sini o programın gerçek S3 yoluyla geçersiz kılar. Kanal asla yeni bir giriş eklentisine ihtiyaç duymaz, asla yeniden başlatılmaya ihtiyaç duymaz, asla çevrimdışı olmaz.

İlginç olan çalışma, o tek girişin üzerinde çalışan orkestrasyon katmanıdır — her eylemi bir program ID'si ile adlandırarak arızadan sonra yetimlerin temizlenmesini sağlamak, ≥ 6 saniyelik boşlukları bir slate ile doldurarak izleyicinin asla bir hold-frame görmemesini sağlamak, her giriş değişiminden ölçülü bir an sonra filigranı etkinleştirerek yer paylaşımının ara belleğe alma kareleri arasında titrememesini sağlamak ve 1500 eylem tavanına karşı ön kontrol yaparak dağıtımların AWS'de yolun ortasında başarısız olmak yerine UI'da başarısız olmasını sağlamaktır.

Diyagram 1 · Kanal Mimarisi

Mimari

• Slate girişi — programlar arasındaki boşlukları doldurmak için kanala bağlı statik bir varlık.
• Dinamik giriş — bir kez şu şekilde oluşturulur: Sources: [{ Url: "$urlPath$" }], Type: MP4_FILE. URL bir yer tutucudur; gerçek yol, zamanlama anında program başına sağlanır.
• Lambda orkestratörü (fastChannel-lambda-fun/index.js) — kanalda görünen her aktiviteyi yönetir. Program başına 8 baytlık onaltılık bir programId oluşturur ve ilgili her eylemi bununla etiketler.
• MediaLive zamanlaması — hepsi tek bir BatchUpdateScheduleCommand aracılığıyla akan, tek bir sıralı eylemler listesi. AWS tarafından 1500 eylemle sınırlıdır.
• Backend ön kontrolü (schedule.service.ts) — her dağıtımdan önce Lambda'nın GET_SCHEDULE_COUNT çağırır ve yeni eylemler sınırı aşarsa ilerlemeyi reddeder.

• Yetim temizliği (sweepIncompleteProgramGroups) — her dağıtımdan sonra çalışır. Eylemleri programId ile gruplandırır, ana input-switch eylemi eksik olan herhangi bir grubu siler.

   

Temel Mühendislik Kararları

1. Program başına bir dinamik giriş, bir URL geçersiz kılma

Dinamik giriş şu şekilde oluşturulur: Sources: [{ Url: "$urlPath$" }]. Her program sınırında, Lambda bir InputSwitchScheduleActionSettings eylemi yayınlar ve bu eylem UrlPath: [program.videoUrl] — o programın gerçek S3 MP4 URL'sini sağlar. MediaLive, yürütme sırasında yer tutucuyu değiştirir ve gerçek kaynaktan çeker.

Artık tek bir giriş eklentisi, kanalın yayınlayacağı her programı sunar — kanalın ömrü boyunca etkin bir şekilde sınırsız benzersiz video, herhangi bir zamanda dağıtım başına zamanlama-eylem sınırı ile kısıtlanmıştır. 20 giriş sınırı bir kısıtlama olmaktan çıkar ve kanal asla yeni içerik eklemek için yeniden başlatılmaya ihtiyaç duymaz.

Diyagram 2 · Dinamik Giriş URL'si Geçersiz Kılma

Bilerek yaptığımız bir ödünleşim. Dinamik bir giriş URL'yi önceden doğrulamaz — MediaLive yer tutucuyu yalnızca geçiş anında çözer, bu nedenle 404 hatası dağıtım zamanı reddi yerine akış tarafı hatası olarak ortaya çıkar. Tek bir girişin mimari basitliği karşılığında bu maliyeti kabul ediyoruz. Backend'in ayrı ffprobe doğrulaması, hatalı kaynakları dağıtımdan önce yakalar.

2. Program etiketli eylem adları kendi kendini onarmayı sağlar

Lambda tarafından yayılan her eylem, programın 8 baytlık onaltılık programId adında taşır: input-switch-${programId}, watermark-on-${programId}-${rendition}, ad-break-start-${programId}-${i}, program-end-${programId}, slate-switch-${programId}.

Her dağıtımdan sonra, sweepIncompleteProgramGroups, kanalda mevcut her eylemi listeler, onları gömülü programId ile gruplandırır ve ana input-switch eylemi eksik olan herhangi bir grubu siler. Bu, başarısız kısmi dağıtımlar, rekabetçi düzenlemeler ve kanalı bir programın yarım kalmış eylemleriyle bırakabilecek diğer tüm koşullar için temizleme yoludur.

Eylem adı kodlaması, kimlik mekanizmasının tamamıdır. MediaLive'ın kendisi bir "program" kavramına sahip değildir — orkestrasyon katmanı, adlandırma kuralları aracılığıyla bir programı üzerine yansıtır.

Bu neden önemli? Her eylem adına gömülü program ID'si olmadan, yetim temizliği hangi eylemlerin bir araya ait olduğunu bilemezdi. Eylem düzeyinde temizlik ya çok fazla şeyi (tüm kanal sıfırlaması) ya da çok az şeyi (asla kapanmayan takılı kalmış filigranlar) silerdi. Adlandırma kuralı veri modelidir.

3. 6 saniyelik slate kuralı

Programlar nadiren kusursuz bir şekilde bitişir — neredeyse her zaman bir MP4'ün sonu ile bir sonraki zamanlanmış programın başlangıcı arasında birkaç saniyelik bir boşluk vardır. Orkestrasyon, bu boşluk ≥ 6 saniye olduğunda (MIN_SLATE_GAP_MS = 6000) bir slate-switch eylemi yayınlar.

Eşik keyfi değildir. MediaLive, herhangi iki zamanlama eylemi arasında 5 saniyelik minimum boşluk uygular; bir slate-switch'i bir sonraki programın input-switch'ine bundan daha yakın bir zamanda yayınlamak bir reddetmeye neden olur. 6 saniyelik kural, MediaLive'a gerekli boşluğu sağlar ve orkestrasyon katmanına bir saniyelik saat kayması güvenlik marjı bırakır. 6 saniyenin altında, dağıtım reddini riske atmak yerine önceki programın son karesinin kısa bir süre donmasına izin veririz.

4. Ölçülü etkinleştirme gecikmeli gösterim başına filigran

Filigran, bir StaticImageOutputActivate eylemi olup, çıkış gösterimi (1080p, 720p, 480p, 360p) başına yayımlanır — program başına dört eylem. Her eylem, o programın input-switch'inden 1.500 ms sonra tetiklenir.

Gecikme, bir giriş değişiminden sonraki ilk karelerin hala ara belleğe alınması nedeniyle mevcuttur; yer paylaşımını tam değişim anında etkinleştirmek, yer paylaşımı henüz tam olarak işlenmemiş bir kareye boyanırken kısa bir titreşime neden olabilir. 1.500 ms, testlerde dört gösterimin tamamında sürekli olarak temiz bir etkinleştirme sağlayan değerdi. Bu, belgelenmiş bir MediaLive parametresi değil, ölçülmüş bir sabittir — ve kodda tek bir yerde bulunur, böylece gelecekteki ayarlamalar tek satırlık bir değişikliktir.

Bilerek yaptığımız bir ödünleşim. Gösterim başına yer paylaşımı eylemleri, tek bir küresel yer paylaşımına kıyasla eylem sayısının 4 katına mal olur. Bu maliyeti kabul ediyoruz çünkü gösterim başına yol, her çıktının piksel boyutlarına tam olarak uygun bir filigran almasını sağlar, MediaLive'ın tek bir yer paylaşımını dördü arasında küçültmesine izin vermek yerine. Sonuç, SD çıktılarda gözle görülür şekilde daha keskin bir logodur — ve 1500 sınırı önemli hale gelmeden önce yüzlerce program için yeterli eylem bütçesi bırakır.

5. 1500 eylem tavanı, UI'da ön kontrol edilmiş

AWS, bir MediaLive kanalını 1500 zamanlama eylemiyle sınırlar. Program başına ~7–8 eylemle (giriş değişimi + 4 filigran + 2 reklam işareti + ara sıra slate), kanal reklam yoğunluğuna ve slate sıklığına bağlı olarak yaklaşık 180–200 aktif program barındırır. Bu, uzun vadeli dağıtımlar için gerçek bir tavan olup, tam sayı program başına karmaşıklığa bağlıdır.

Her dağıtımdan önce, backend Lambda'nın GET_SCHEDULE_COUNT çağırır ve bu da DescribeScheduleCommand aracılığıyla kanaldaki canlı eylemleri sayar ve { liveCount, capacity: 1500 } döndürür. Eğer liveCount + (newPrograms × 8) 1500'ü aşarsa, backend SCHEDULE_ACTION_CAP_EXCEEDED hatasını tam boşluk sayısıyla birlikte fırlatır — MediaLive'a herhangi bir şey göndermeden önce. Operatör, önce geçmiş programları temizleme rehberliğiyle UI'da sınırı görür. Dağıtım asla yarı yolda duvara çarpmaz.

Diyagram 3 · Bir Programın Eylem Zaman Çizelgesi

Sonuçlar

• Tek bir MediaLive kanalı, ömrü boyunca etkin bir şekilde sınırsız benzersiz programı tek bir dinamik giriş eklentisiyle sunar. 20 giriş sınırı, etrafında plan yapmamız gereken bir kısıtlama olmaktan çıktı — herhangi bir zamandaki kapasite, giriş sınırıyla değil, zamanlama-eylem sınırıyla yönetilir.
• Kanal orkestrasyonu kendi kendini onarır: her dağıtım bir yetim temizliğiyle sona erer, bu nedenle başarısız kısmi dağıtımlar zamanlamayı tutarsız bir durumda bırakamaz.
• Zamanlama kapasitesi sınırlıdır ve görünürdür. Operatörler, 1500 eylem tavanını UI'da tıklamadan önce görür, dağıtımın ortasında opak bir AWS reddi olarak değil.
• Program-ID adlandırma kuralı, tüm kimlik katmanıdır — ve bir dizgidir. Yeni altyapı yok, ek depolama yok, bağımlılık yok. "Program" kavramının MediaLive'ın düz eylem listesine mümkün olan en basit yansıtılması.

Teknoloji Yığını: AWS MediaLive · AWS Lambda · NestJS · MongoDB · TypeScript · Node 18 · AWS SDK v3 (@aws-sdk/client-medialive)