Intel Media Transport Library (MTL) ile ST 2110: FFmpeg ve OBS Üzerinden Software-Based Media Transport

Özet

• Intel Media Transport Library (MTL): ST 2110 uyumlu media transport için COTS sunucular üzerinde çalışan software data-plane kütüphanesi
• Ana problem: ST 2110-20 gibi uncompressed media akışlarında packet pacing, PTP timing, jitter, throughput ve packet loss toleransı çok sıkıdır
• MTL yaklaşımı: DPDK PMD, AF_XDP veya kernel socket backend ile user-space packet processing ve düşük gecikmeli RTP/UDP media transport
• FFmpeg entegrasyonu: MTL plugin, FFmpeg’e mtl_st20p input/output device ekler; FFmpeg doğrudan ST 2110-20 raw video alıp gönderebilir
• OBS entegrasyonu: MTL ekosisteminde OBS Studio plugin desteği vardır; OBS tabanlı production/test workflow’ları ST 2110 dünyasına bağlanabilir
• Konumlandırma: MTL, NMOS control plane değildir; ST 2110 media packet TX/RX data plane katmanıdır

Not: Bu yazı ST 2110 kampüs, NMOS, MXL ve FFmpeg/GStreamer yazılarının data-plane tarafını tamamlar. Burada amaç MTL’i “bir medya uygulaması” değil, ST 2110 için software media transport katmanı olarak anlatmaktır.

1. ST 2110 neden software için zordur?

ST 2110’u anlamak kolay görünebilir: RTP paketleri var, multicast var, video/audio/data akıyor. Zor olan kısım bu akışın broadcast kalitesinde, real-time ve deterministik davranmasıdır.

Özellikle ST 2110-20 uncompressed video için:

• veri hızı çok yüksektir
• paketler belirli zaman aralıklarıyla çıkmalıdır
• ST 2110-21 pacing davranışı önemlidir
• PTP zamanına göre senkron kalmak gerekir
• multicast network drop ve jitter’a tolerans sınırlıdır
• CPU, memory, NIC ve PCIe yolu birlikte çalışmalıdır

Klasik Linux kernel network stack ile yüksek bitrate ST 2110 üretmek veya almak bazı senaryolarda mümkün olsa da deterministik pacing ve düşük jitter için yeterli olmayabilir. Bu yüzden broadcast ST 2110 dünyasında FPGA, SmartNIC veya özel donanım çözümleri uzun süre öne çıktı.

Intel MTL’in iddiası burada başlar: ST 2110 transport’u COTS server + uygun NIC + optimized software data plane ile yapılabilir hale getirmek.

2. Intel MTL nedir?

Media Transport Library (MTL), Intel/OpenVisualCloud ekosisteminde geliştirilen software tabanlı real-time media transport kütüphanesidir. Hedefi, managed IP network üzerinde ST 2110 uyumlu media stream’lerini yüksek throughput ve düşük latency ile göndermek/almak.

MTL’in önemli özellikleri:

• DPDK PMD backend
• AF_XDP + eBPF backend
• kernel socket backend
• user-space LibOS UDP stack
• PTP hardware timestamp offload
• ST 2110-20 video, ST 2110-30 audio, ST 2110-40 ANC
• ST 2110-21 pacing
• ST 2022-7 redundancy
• ST 2110-22 plugin interface
• FFmpeg plugin
• OBS Studio plugin
• Python/Rust bindings ve native C/C++ API
• lisans: BSD-3-Clause

Bu diyagramdaki kritik ayrım: MTL bir media application değildir. FFmpeg, OBS veya custom application medya üretir/tüketir; MTL bu medyanın ST 2110 uyumlu packet transport tarafını üstlenir.

2.1 NIC desteği: E810/E830 neden özellikle önemli?

MTL Ethernet desteğini üç backend üzerinden geniş tutar: DPDK PMD, AF_XDP ve kernel socket. Ancak pratikte her NIC aynı ST 2110 davranışını vermez.

Intel dokümantasyonundaki önemli ayrım şudur:

• günlük geliştirme ve doğrulama ağırlıklı olarak Intel E810 ve Intel E830 serisi kartlarda yapılır
• DPDK’nin desteklediği başka NIC’ler teorik olarak kullanılabilir, ancak durumları aynı seviyede garanti edilmez
• narrow pacing TX için Intel E810/E830 + DPDK PMD kombinasyonu özellikle önemlidir; diğer kullanım şekilleri genelde TSC tabanlı pacing ile wide/broad pacing seviyesinde kalır
• E810 için ICE driver/DDP package ve firmware sürümü kritik olabilir
• X710/CVL gibi daha eski veya farklı Intel NIC’ler bazı test/benchmark bağlamlarında görülebilir, fakat yeni ST 2110 narrow pacing hedefinde E810/E830 daha doğru başlangıç noktasıdır

Bu yüzden production POC için “Intel NIC var” demek yeterli değildir. Şu bilgileri en baştan netleştirmek gerekir:

2.2 DPDK, AF_XDP ve kernel socket nasıl seçilir?

MTL üç ana data path sunar ama bunlar eşdeğer değildir.

Kural olarak:

• ST 2110-20 high-bitrate TX/RX ve production POC: E810/E830 + DPDK PMD ile başlayın.
• Deneme/lab ve kernel entegrasyonu önemliyse: AF_XDP değerlendirilebilir.
• Sadece konsept kanıtı veya NIC uyumsuzluğu varsa: kernel socket fallback kullanılabilir.

2.3 Sistem gereksinimleri: tek bir minimum yok

MTL için “şu CPU yeter” gibi evrensel bir minimum vermek yanıltıcı olur. 1080p50 tek flow, çoklu 4K flow ve 8K çok farklı sistem ister. Intel’in compliance/benchmark dokümanlarında örnek referans sistem olarak çift soketli Intel Xeon Platinum 8358, 64 core, 512 GB RAM ve 100G NIC gibi güçlü konfigürasyonlar görülür. Bu bir “minimum” değil, ölçüm yapılan referans platformdur.

Pratik başlangıç olarak, tek bir 1080i50/1080p50 ST 2110-20 flow için modern bir 8 çekirdekli sunucu, Intel E810/E830 sınıfı NIC, doğru driver/firmware/DDP paketi, hugepages ve izole edilmiş birkaç CPU core makul bir lab başlangıcı olabilir. Ancak bunu production kapasite varsayımı gibi okumamak gerekir; ikinci flow, 4K, ST 2022-7 veya encode/decode eklediğiniz anda ölçüm zorunludur.

Pratik başlangıç checklist’i:

Yani COTS sunucu kullanmak “herhangi bir sunucu olur” anlamına gelmez. COTS burada doğru NIC, doğru CPU/NUMA yerleşimi ve doğru network tuning ile anlam kazanır.

3. MTL ST 2110 zincirinde nereye oturur?

ST 2110 sistemini üç düzlemde düşünmek faydalıdır:

MTL bu tabloda media data plane tarafındadır.

Yani MTL şu soruya cevap verir:

Bu raw video/audio frame’lerini ST 2110 paketleri olarak doğru hızda, doğru zamanlamayla ve doğru NIC üzerinden nasıl gönderip alırım?

Şu sorulara doğrudan cevap vermez:

• Cihazlar birbirini nasıl keşfeder? → NMOS IS-04
• Hangi sender hangi receiver’a bağlanacak? → NMOS IS-05 / orchestration
• Switch multicast flow’u nasıl kuracak? → IS-06 / SDN
• Production graph nasıl yönetilecek? → control/orchestration layer

4. FFmpeg ile MTL çıkışı: mtl_st20p

MTL ekosistemindeki en pratik entegrasyonlardan biri FFmpeg plugin’idir. Bu plugin FFmpeg’e ST 2110-20 progressive/raw video için bir input/output device ekler:

1

-f mtl_st20p

Bu şu anlama gelir:

• FFmpeg bir ST 2110-20 stream’i input olarak okuyabilir
• FFmpeg raw video frame’lerini ST 2110-20 output olarak gönderebilir
• video pipeline içinde decode/filter/encode/remux işlemleriyle birlikte kullanılabilir

Kritik uyarı: Bu, apt install ffmpeg veya Homebrew ile gelen standart upstream FFmpeg özelliği değildir. MTL dokümantasyonundaki plugin, FFmpeg’in MTL patch’leri ve --enable-mtl ile özel build edilmesini gerektirir. Production runbook’ta FFmpeg binary’sinin hangi commit/tag, hangi MTL release ve hangi build flags ile üretildiği açıkça yazılmalıdır.

4.1 FFmpeg ile ST 2110-20 alma

Kavramsal örnek:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

ffmpeg \
  -p_port 0000:af:01.0 \
  -p_sip 192.168.96.2 \
  -p_rx_ip 239.168.85.20 \
  -udp_port 20000 \
  -payload_type 96 \
  -fps 59.94 \
  -pix_fmt yuv422p10le \
  -video_size 1920x1080 \
  -f mtl_st20p -i "k" \
  -c:v libopenh264 out.264 -y

Burada FFmpeg, MTL device üzerinden ST 2110-20 video alır ve bunu örnekte H.264’e encode eder. Gerçek production’da codec, pixel format, NIC PCI address, multicast IP, port ve payload type ortamınıza göre değişir.

4.2 FFmpeg ile ST 2110-20 gönderme

Kavramsal output zinciri:

1
2
3
4
5
6
7
8
9

ffmpeg -re -i input.yuv \
  -pix_fmt yuv422p10le -s 1920x1080 -r 59.94 \
  -f mtl_st20p \
  -p_port 0000:af:01.0 \
  -p_sip 192.168.96.2 \
  -p_tx_ip 239.168.85.20 \
  -udp_port 20000 \
  -payload_type 96 \
  "k"

Bu model özellikle şu işler için değerli:

• test pattern veya file source’u ST 2110 fabric’e göndermek
• software playout prototipi yapmak
• ST 2110 receiver/analyzer geliştirmek
• cloud/edge node’dan ST 2110 çıkışı üretmek
• lab ortamında kamera veya gateway taklidi yapmak

4.3 FFmpeg plugin’i neden önemli?

FFmpeg broadcast ekipleri için zaten günlük araçtır. MTL plugin ile FFmpeg şu role gelir:

• ST 2110 test sender
• ST 2110 receiver + transcoder
• file-to-ST 2110 bridge
• ST 2110-to-file recorder
• ST 2110-to-HLS/SRT gateway prototipi

Bu, ST 2110 denemeleri için özel donanım beklemeden software tabanlı lab kurmayı kolaylaştırır. Ancak production’a geçerken timing compliance, NIC seçimi ve release tag çok dikkatli değerlendirilmelidir.

5. OBS Studio ve MTL desteği

MTL dokümantasyonu OBS Studio plugin desteğini de ekosistem parçası olarak listeler. Bu ilginçtir çünkü OBS normalde RTMP/SRT/NDI/screen capture gibi creator ve streaming dünyasına daha yakın bilinir. MTL plugin ile OBS, ST 2110 workflow’larında bir software source veya production tool olarak denenebilir.

OBS + MTL fikri şu senaryolarda anlamlı olabilir:

• ST 2110 lab ortamına OBS sahnesi göndermek
• grafik, browser source veya screen capture’ı ST 2110 fabric’e taşımak
• eğitim/demo ortamında software-defined production göstermek
• broadcast testlerinde hızlı source üretmek
• OBS kompozisyonunu MTL/FFmpeg tabanlı ST 2110 çıkış zincirine bağlamak

Burada dikkatli ifade etmek gerekir: OBS + MTL üretim sistemi yerine hemen konulacak olgun bir broadcast switcher değildir. Daha çok software-based production, lab, test, demo ve belirli grafik/source workflow’ları için ilginç bir köprüdür.

Production’a yaklaşmadan önce ayrıca şunlar kontrol edilmelidir:

• OBS plugin’i hangi MTL release ile test edilmiş?
• plugin aktif olarak bakılıyor mu, son commit/release ne zaman?
• OBS sürümü, plugin ABI’si ve işletim sistemi uyumlu mu?
• audio/video sync ve PTP ilişkisi nasıl doğrulanıyor?
• crash durumunda OBS mi, plugin mi, MTL process’i mi restart edilecek?

6. MTL, MXL, FFmpeg ve NMOS birlikte nasıl düşünülür?

Önceki yazılardaki kavramlarla bağlayalım:

Bir software-defined broadcast node şöyle görünebilir:

Bu diyagramda MTL ve MXL karışmamalı:

• MTL: network edge’de ST 2110 RTP packet transport
• MXL: compute içinde media exchange

İkisi aynı mimaride birbirini tamamlayabilir.

7. Peki ses işini ne yapacağız?

ST 2110 dünyasında video ve ses aynı stream içinde taşınmaz. SDI’da birlikte akan yapı, IP tarafında ayrı essence akışlarına bölünür:

• video: ST 2110-20
• audio: ST 2110-30 (PCM audio) veya ST 2110-31 (AES3 transparent)
• ancillary data: ST 2110-40

Bu yüzden MTL/FFmpeg ile “video çıkışı verdim, ses de gelir” diye düşünmemek gerekir. Video için mtl_st20p, audio için ayrı ST 2110-30 flow gerekir.

MTL FFmpeg plugin tarafında audio için mtl_st30p desteği vardır. Dokümantasyondaki model şu şekildedir:

7.1 ST 2110-30 audio alma

Örnek: 2 kanal, PCM24, 1 ms packet time ile ST 2110-30 stream’i alıp WAV dosyasına yazmak:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

ffmpeg \
  -p_port 0000:af:01.0 \
  -p_sip 192.168.96.2 \
  -p_rx_ip 239.168.85.20 \
  -udp_port 30000 \
  -payload_type 97 \
  -pcm_fmt pcm24 \
  -ptime 1ms \
  -channels 2 \
  -f mtl_st30p -i "0" \
  dump.wav -y

7.2 ST 2110-30 audio gönderme

Örnek: WAV dosyasını loop ederek ST 2110-30 audio multicast olarak göndermek:

1
2
3
4
5
6
7
8

ffmpeg -stream_loop -1 -i test.wav \
  -p_port 0000:af:01.1 \
  -p_sip 192.168.96.3 \
  -p_tx_ip 239.168.85.20 \
  -udp_port 30000 \
  -payload_type 97 \
  -ptime 1ms \
  -f mtl_st30p -

PCM16 için plugin tarafında mtl_st30p_pcm16 muxer kullanılabilir; demux tarafında pcm_fmt pcm16 verilmelidir.

7.3 Ses tarafında kritik tasarım noktaları

Gerçek sistemlerde video ve audio flow’ları genelde SDP/NMOS metadata ile birlikte yönetilir. MTL packet transport’u sağlar; hangi audio flow’un hangi video ile ilişkilendirileceği control/orchestration katmanında çözülmelidir.

7.4 ST 2110-40 ANC ne olacak?

ST 2110-40; timecode, captions, AFD, SCTE-104 benzeri ancillary data dünyasını IP essence flow olarak taşır. MTL özellik listesinde ST 2110-40 desteği geçer, ancak FFmpeg plugin örnekleri ST20/ST22 video ve ST30 audio kadar doğrudan “hazır komut” seviyesinde görünmez.

Pratikte ST 2110-40 şu şekilde düşünülmelidir:

• video ve audio gibi ayrı multicast IP/port/payload type ile yönetilir
• receiver tarafında ANC payload parse edilmeden “paket geliyor” demek yeterli değildir
• caption/timecode gibi veriler application layer’da anlamlandırılmalıdır
• NMOS/SDP tarafında video/audio/ANC ilişkisi açık tutulmalıdır
• MTL ile ST40 kullanacaksanız C/C++ API ve sample app tarafındaki ST40 oturumlarını ayrıca incelemek gerekir

Bu yüzden bu yazı ST20 video ve ST30 audio için FFmpeg örneği verirken, ST40’ı production tasarım checklist’i olarak konumlandırıyor. ANC iş akışı olan sistemlerde ilk test sadece packet RX/TX değil, caption/timecode semantik doğrulaması olmalıdır.

7.5 ST 2110-22 / JPEG XS kısa notu

ST 2110-22, uncompressed ST 2110-20 yerine compressed video essence taşır. JPEG XS bu standardın en önemli pratik kullanım alanlarından biridir çünkü düşük gecikmeli, görsel olarak kayıpsıza yakın contribution hedefler.

MTL FFmpeg plugin tarafında mtl_st22 ve mtl_st22p akışları bulunur:

• mtl_st22: FFmpeg codec output’unu compressed ST 2110-22 RTP payload olarak taşır
• mtl_st22p: MTL’in built-in ST22 codec plugin yaklaşımıyla raw frame alıp/vermesini sağlar
• JPEG XS için FFmpeg’in MTL yanında SVT JPEG XS gibi ilgili codec desteğiyle build edilmesi gerekir

Basitleştirilmiş JPEG XS output fikri:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

ffmpeg -stream_loop -1 \
  -video_size 1920x1080 -f rawvideo -pix_fmt yuv422p10le -i input.yuv \
  -filter:v fps=59.94 \
  -c:v libsvt_jpegxs \
  -p_port 0000:af:01.1 \
  -p_sip 192.168.96.3 \
  -p_tx_ip 239.168.85.20 \
  -udp_port 20000 \
  -payload_type 98 \
  -f mtl_st22 -

ST 2110-22’yi yazıda yalnızca “deney” diye bırakmak eksik olurdu; doğru konumlandırma şu: yüksek bandwidth uncompressed ST20 yerine düşük gecikmeli compressed essence istediğinizde MTL + ST22 + JPEG XS ayrı bir değerlendirme başlığıdır.

Bu örneğin “basitleştirilmiş” diye işaretlenmesinin nedeni komutun tek başına yeterli olmamasıdır: FFmpeg’in hem MTL plugin’i hem de SVT JPEG XS codec desteğiyle build edilmesi, receiver’ın payload_type, st22_codec, frame rate ve SDP/NMOS metadata beklentilerinin eşleşmesi gerekir. Production testinde ayrıca latency, visual quality ve packet pacing ayrı ölçülmelidir.

8. Gerçek dünya senaryoları

MTL’i soyut bir library olarak değil, birkaç somut workflow içinde düşünmek daha doğru olur.

8.1 Software playout node

Bir dosya veya render output’u FFmpeg ile okunur, video ST 2110-20 olarak, audio ST 2110-30 olarak fabric’e gönderilir.

1
2
3
4
5

MXF/MOV/WAV assets
  -> FFmpeg decode/filter
  -> mtl_st20p video output
  -> mtl_st30p audio output
  -> ST 2110 fabric

Bu senaryoda dikkat: video/audio sync, PTP alignment, asset channel mapping ve receiver SDP/NMOS bilgisi doğru olmalıdır.

8.2 OBS graphics source to ST 2110

OBS sahnesi grafik, browser source, screen capture veya basit compositing için kullanılır. MTL plugin veya FFmpeg handoff ile ST 2110 fabric’e source üretir.

Bu, özellikle demo, eğitim, lab ve hızlı grafik source üretimi için mantıklıdır. Ana production switcher yerine değil, software source üretici olarak düşünmek daha güvenlidir.

8.3 ST 2110 receiver + recorder

MTL RX ile video/audio alınır, FFmpeg dosyaya yazar veya proxy formatına encode eder.

1
2
3
4

ST 2110-20 video + ST 2110-30 audio
  -> MTL RX
  -> FFmpeg encode/mux
  -> MP4/MOV/MXF/proxy file

Bu compliance kayıt, monitoring, proxy üretimi veya troubleshooting için faydalı olabilir.

8.4 Cloud/edge gateway

ST 2110 fabric’ten gelen video/audio software node’da alınır, SRT/HLS/DASH gibi çıkışlara dönüştürülür.

1
2
3
4

ST 2110 fabric
  -> MTL RX
  -> FFmpeg/GPU encode
  -> SRT contribution or HLS/DASH OTT output

Bu senaryo, ST 2110 tesisi ile OTT/cloud dünyası arasında software gateway kurmak için anlamlıdır.

8.5 Lab/test generator

Özel donanım beklemeden FFmpeg + MTL ile test sinyali üretilebilir:

• color bars veya test pattern
• PCM test tone
• farklı payload type ve packet time denemeleri
• receiver timing parser testleri
• ST 2022-7 path testleri

8.6 JPEG XS / ST 2110-22 contribution POC

Uncompressed ST 2110-20 bant genişliği yüksek geldiğinde, düşük gecikmeli compressed essence için ST 2110-22/JPEG XS ayrı bir test senaryosu olabilir.

1
2
3
4
5

Raw 4:2:2 10-bit source
  -> FFmpeg + SVT JPEG XS encode
  -> MTL mtl_st22 output
  -> ST 2110-22 multicast
  -> JPEG XS capable receiver

Bu workflow’da sadece paket akışı değil; JPEG XS encode latency, visual quality, payload type, st22_codec, SDP/NMOS metadata ve receiver uyumu birlikte doğrulanmalıdır.

9. Production checklist

MTL ile ST 2110 kurarken software’den çok sistem mühendisliği önemlidir.

Intel MTL GitHub sayfasındaki önemli uyarı da burada hatırlanmalı: main branch test/evaluation amaçlı olabilir; değerlendirilen kod release tag’leriyle takip edilmelidir.

PTP satırı özellikle hafife alınmamalıdır. ST 2110’da “PTP var” demek yeterli değildir; grandmaster seçimi, BMCA davranışı, boundary/transparent clock tasarımı, NIC PHC offset’i, ptp4l/phc2sys veya MTL’in built-in PTP yaklaşımı ve alarm eşikleri ayrı ayrı doğrulanmalıdır. Video/audio ayrı flow olduğu için PTP hatası çoğu zaman A/V sync problemi olarak görünür.

COTS sunucu tarafında da en sık sorunlar şunlardır:

• CPU scheduling jitter
• yanlış NUMA yerleşimi
• PCIe bandwidth veya slot topolojisi
• NIC firmware/driver/DDP uyuşmazlığı
• hugepage ve VFIO izinleri
• shared host üzerinde noisy neighbor etkisi
• container/VM içinde SR-IOV ve clock sync karmaşıklığı

10. Nerede kullanılır?

MTL’i özellikle şu işlerde düşünürdüm:

• ST 2110 software playout prototipi
• ST 2110 test signal generator
• ST 2110 receiver/analyzer
• FFmpeg mtl_st20p / mtl_st30p ile ST 2110-to-file recorder
• file-to-ST 2110 lab sender, video ve audio ayrı flow’lar halinde
• OBS scene-to-ST 2110 demo/source workflow
• edge/cloud ST 2110 gateway denemeleri
• JPEG XS / ST 2110-22 low-latency contribution POC
• ST 2110-40 ANC packet transport ve application-layer parsing testleri
• ST 2022-7 redundancy validation
• COTS server üzerinde broadcast data-plane POC

Nerede dikkatli olmak gerekir?

• full production router replacement
• PTP ve network kontrolü zayıf ortamlarda
• non-deterministic shared compute host’larda
• NIC/driver/firmware standardize edilmemiş sistemlerde
• NMOS/orchestration olmadan büyük kampüs operasyonunda
• FFmpeg/OBS plugin release ve build zinciri pin edilmemiş ortamlarda

MTL için ayrı bir kurulum makalesi mantıklı olur: E810/E830 NIC hazırlığı, DPDK binding, hugepages, patched FFmpeg build, SVT JPEG XS ve örnek sender/receiver testleri bu yazının kapsamını aşacak kadar detaylıdır.

11. SDP: ST 2110 stream nasıl tarif edilir?

MTL packet transport tarafını çözer, ama gerçek ST 2110 sistemlerinde receiver’ın “ne alacağını” bilmesi gerekir. Bu bilgi genellikle SDP (Session Description Protocol) ile tarif edilir ve NMOS IS-04/IS-05 gibi kontrol düzlemlerinde de bu metadata kullanılır.

FFmpeg/MTL komutundaki parametrelerin SDP karşılığı kabaca şöyledir:

Basitleştirilmiş ST 2110-20 SDP örneği:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

v=0
o=- 0 0 IN IP4 192.168.96.2
s=MTL ST 2110-20 Video
t=0 0
m=video 20000 RTP/AVP 96
c=IN IP4 239.168.85.20/32
a=rtpmap:96 raw/90000
a=fmtp:96 sampling=YCbCr-4:2:2; width=1920; height=1080; depth=10; colorimetry=BT709
a=framerate:59.94
a=ts-refclk:ptp=IEEE1588-2008:00-1D-C1-FF-FE-12-34-56:0
a=mediaclk:direct=0

ST 2110-30 audio için ayrı SDP gerekir:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

v=0
o=- 0 0 IN IP4 192.168.96.2
s=MTL ST 2110-30 Audio
t=0 0
m=audio 30000 RTP/AVP 97
c=IN IP4 239.168.85.30/32
a=rtpmap:97 L24/48000/2
a=framecount:48
a=ptime:1
a=ts-refclk:ptp=IEEE1588-2008:00-1D-C1-FF-FE-12-34-56:0
a=mediaclk:direct=0

Bu örnekler production SDP template’i değildir; amaç MTL komut parametreleri ile ST 2110 metadata arasındaki bağı göstermektir. Gerçek sistemde SDP/NMOS metadata, receiver’ın pixel format, payload type, packet time, clock source ve multicast bilgilerini birebir karşılamalıdır.

12. ST 2110-21 pacing: narrow, narrow linear, wide

ST 2110-21, özellikle uncompressed video sender davranışı için kritiktir. Aynı ortalama bitrate’e sahip iki sender, paketleri tamamen farklı ritimlerle gönderebilir. Receiver açısından problem ortalama bitrate değil, microburst ve buffer davranışıdır.

Basit görsel:

1
2
3
4
5

Kernel veya bursty TX:
||||||||||||||||        ||||||||||||||||

ST 2110 paced TX:
| | | | | | | | | | | | | | | | | | |

Intel E810/E830’in önemi burada ortaya çıkar: narrow pacing TX için rate-limit/hardware pacing kabiliyeti DPDK PMD ile birlikte kritik hale gelir. TSC tabanlı software pacing bazı lab senaryolarında yeterli olabilir, ama production ST 2110-21 hedefinde NIC pacing davranışı ayrıca ölçülmelidir.

13. Minimal lab topology

MTL’i öğrenmek için küçük ama doğru kurulmuş bir lab, yanlış yapılandırılmış büyük sistemden daha değerlidir.

Başlangıç lab’ı için:

1. tek ST 2110-20 video flow ile başlayın
2. sonra ST 2110-30 audio ekleyin
3. SDP/NMOS metadata’yı doğrulayın
4. PTP offset ve RTP sequence kaybını izleyin
5. daha sonra ST 2022-7 veya ST 2110-22 gibi gelişmiş konulara geçin

14. Observability ve sık arıza senaryoları

Production ST 2110 sistemi “çalışıyor” diye bırakılmaz; sürekli ölçülür.

İzlenmesi gerekenler:

• RTP sequence gap / packet loss
• packet inter-arrival jitter
• ST 2110-21 pacing davranışı
• PTP offset ve grandmaster değişimi
• NIC RX/TX drops
• DPDK ring occupancy
• CPU core utilization ve scheduling jitter
• NUMA remote memory access
• audio level ve channel mapping
• SDP/NMOS metadata uyuşmazlığı

Kullanılabilecek araçlar:

• Wireshark RTP/ST 2110 analizleri
• ptp4l / phc2sys logları
• NIC driver counters
• MTL sample app logları ve RX timing parser
• EBU LIST / JT-NM test metodolojileri
• vendor ST 2110 analyzer cihazları

Sık görülen arızalar:

15. Wireshark filtreleri mini appendix

Sorun giderirken ilk bakılan yerlerden biri paket seviyesidir. Aşağıdaki filtreler hızlı başlangıç içindir; interface, VLAN ve multicast yapınıza göre daraltılmalıdır.

Pratik akış:

1. önce ptp ile clock mesajları geliyor mu bakın
2. sonra igmp ile receiver multicast group’a join oluyor mu kontrol edin
3. udp.port == 20000 veya udp.port == 30000 ile flow geliyor mu bakın
4. RTP stream analysis ile sequence gap ve jitter kontrol edin
5. SDP’deki payload type, multicast IP ve UDP port ile capture’ın eşleştiğini doğrulayın

Wireshark tek başına ST 2110 compliance analyzer değildir, ama “paket var mı, doğru flow mu, sequence kırılıyor mu, receiver join olmuş mu?” sorularına hızlı cevap verir.

16. FFmpeg + MTL build appendix

Bu bölüm copy-paste garantili build reçetesi değil; sürümler değiştiği için build guide her zaman resmi MTL dokümanından takip edilmelidir. Ama production runbook için kontrol listesi şu olmalıdır:

1. MTL release tag seçin.
2. Desteklenen DPDK sürümünü ve gerekiyorsa MTL patch’lerini uygulayın.
3. Hugepages ve VFIO/IOMMU ayarlarını hazırlayın.
4. NIC driver/firmware/DDP paketini sabitleyin.
5. FFmpeg’i MTL patch’leri ve --enable-mtl ile build edin.
6. ST 2110-22/JPEG XS gerekiyorsa SVT JPEG XS codec desteğini ekleyin.
7. Build artifact için commit hash, configure flags ve linked library sürümlerini kaydedin.

Örnek build notu şu bilgileri içermeli:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

MTL release/tag:
DPDK version:
NIC model:
NIC firmware:
ICE driver/DDP package:
FFmpeg commit:
FFmpeg configure flags:
SVT JPEG XS version:
Kernel version:
PTP configuration:

Bu bilgiler olmadan “aynı sistemi tekrar kurmak” veya production incident sonrası root cause yapmak çok zorlaşır.

17. Version pinning checklist

ST 2110 software data-plane sistemlerinde rastgele main branch ile production’a çıkmak kötü fikirdir.

Production runbook’ta bu liste yoksa sistem tekrarlanabilir değildir.

18. Sonuç

Intel Media Transport Library, ST 2110’u sadece özel hardware dünyasına ait olmaktan çıkarıp software-defined broadcast tarafına yaklaştıran önemli bir data-plane projesidir.

Kısa özet:

FFmpeg ve OBS medya üretir veya işler; MTL bu medyayı ST 2110 uyumlu RTP akışları olarak COTS sunucu ve NIC üzerinden gönderip almayı sağlar.

MTL’i doğru konumlandırmak gerekir:

• codec değildir
• NMOS değildir
• broadcast router değildir
• ST 2110 data-plane kütüphanesidir

FFmpeg mtl_st20p ve mtl_st30p device’ları sayesinde MTL, broadcast mühendislerinin zaten kullandığı en güçlü araçlardan birine bağlanır. OBS plugin desteği ise software-based production tarafında ilginç bir köprü açar. ST 2110-40 ANC ve ST 2110-22/JPEG XS tarafı da gösteriyor ki MTL yalnızca “raw video gönderme” projesi değildir; video, audio, ANC, compressed essence, timing ve NIC pacing birlikte düşünülmesi gereken bir data-plane katmanıdır.

Yine de doğru sonuç şudur: MTL’i production’a almak bir kütüphane eklemekten ibaret değildir. E810/E830 gibi doğru NIC seçimi, DPDK/AF_XDP/backend kararı, PTP/ST 2059 tasarımı, hugepages, NUMA, release tag, FFmpeg patched build ve observability birlikte ele alınmalıdır.

Bu yüzden MTL, ST 2110, MXL ve NMOS birlikte düşünüldüğünde yeni nesil broadcast mimarisi daha net görünür:

NMOS kontrol eder, MTL ST 2110 packet transport’u yapar, MXL compute içi media exchange’i çözer, FFmpeg/OBS/custom app ise medya işleme katmanında çalışır.

Kaynaklar

• Media Transport Library GitHub
• Media Transport Library Documentation
• MTL Design Guide
• MTL Plugin for FFmpeg
• Intel Media Transport Library White Paper
• Intel Tiber Broadcast Suite
• SMPTE ST 2110 Standards
• SMPTE ST 2110-21 Standard
• EBU LIST
• JT-NM Tested Program
• Wireshark RTP Analysis
• İlgili yazılar: ST 2110 kampüs, NMOS, MXL, FFmpeg/GStreamer