Ölçüm ve standartlar5 dk okuma

TR 101 290 nedir? Öncelik 1, 2 ve 3 hatalarının Türkçe karşılığı

DVB dünyasının ölçüm sözlüğü olan ETSI TR 101 290'ı, hangi hatanın izleyicide neye dönüştüğünü ve hangilerine gerçekten alarm kurulması gerektiğini anlatıyoruz.

Yayın operasyonunda en sık dönen cümle şudur: "Bizde sorun yok, sizde bir şey var." Headend encoder'ı gösterir, dağıtımcı ağı gösterir, platform da yayıncıyı. Bu tartışmanın bitmesi için tarafların üzerinde anlaşacağı ortak bir dile ihtiyaç var — ETSI TR 101 290 tam olarak bu dildir.

Önce sık yapılan bir karışıklığı gidereyim: baştaki TR, Türkiye değil. ETSI'nin doküman türlerinden biri olan Technical Report kısaltması. Yani bu bir "uyulması zorunlu standart" da değil; DVB sistemlerinin nasıl ölçüleceğini tarif eden bir ölçüm rehberi. Bu ayrım pratikte önemli: TR 101 290 size "şu değer şu olmalı" demez, "şunu şöyle ölçersen herkes aynı şeyi anlar" der.

Üç öncelik seviyesinin mantığı

Standardın en akıllıca yanı, hataları ciddiyetine göre değil, izleyicide neye dönüştüğüne göre üçe ayırmasıdır. Sıralama şu soruların cevabıdır:

  1. Alıcı bu yayını çözebiliyor mu? Hayır ise → Öncelik 1
  2. Çözüyor ama görüntü/ses bozuluyor mu? Evet ise → Öncelik 2
  3. Görüntü iyi ama yan hizmetler (EPG, saat, servis adı) bozuk mu? → Öncelik 3

Bu yüzden "kaç hata var" sorusu yanlış sorudur. Doğru soru: hangi seviyede.

Öncelik 1 — yayın ya vardır ya yoktur

Bu gruptaki bir hata varsa izleyici siyah ekran, donma veya "sinyal yok" görür. Tartışmaya yer bırakmaz.

HataNe demekSahada görünüşü
TS_sync_lossArka arkaya birkaç paketin senkron baytı tutmuyorYayın tamamen gitti
Sync_byte_errorPaketin ilk baytı 0x47 değilBozuk taşıma; genelde ağ/uydu kaynaklı
PAT_errorProgram Association Table yok veya çok geç geliyorAlıcı hangi programlar var bilemez → hiçbir kanal açılmaz
PMT_errorProgram Map Table eksik/gecikmeliKanal listede var ama açılmıyor
PID_errorBeklenen bir PID belirlenen süre boyunca hiç gelmediGörüntü var ses yok, ya da altyazı hiç gelmiyor
Continuity_count_errorPaket sayacı atlamış veya tekrar etmişKare atlama, blok bozulma, ses cızırtısı

Zamanlama eşikleri de standardın kendisinde tanımlı: PAT ve PMT en geç 0,5 saniyede bir tekrarlanmalı. PID_error için süre kullanıcı tanımlıdır; pratikte 5 saniye makul bir başlangıçtır.

Öncelik 2 — yayın var ama kalitesi tartışmalı

Burası işin gri bölgesi ve operasyon ekiplerinin vaktinin çoğunu burada harcaması normaldir.

HataNe demekEşik
Transport_errorPaketin TEI biti işaretli: taşıma katmanı bu paketin bozuk olduğunu söylüyor0 olmalı
CRC_errorTablo (PAT/PMT/CAT/SDT…) sağlama toplamı tutmuyor0 olmalı
PCR_repetition_errorSaat referansı yeterince sık gelmiyor≤ 40 ms
PCR_accuracy_errorSaat referansı doğru ama sapması fazla±500 ns
PCR_discontinuity_indicator_errorSaatte işaretlenmemiş sıçrama> 100 ms sıçrama
PTS_errorSunum zaman damgası yeterince sık gelmiyor≤ 700 ms
CAT_errorŞifreli yayında Conditional Access Table sorunuŞifreli akışta zorunlu

Transport_error gördüğünüzde encoder'a bakmayın — TEI bitini genelde önceki bir cihaz veya ağ işaretler. Bu hata "bana bozuk geldi" demektir, "ben bozdum" değil.

Öncelik 3 — izleyici görmez, ama müşteri şikâyet eder

Görüntü akar, ses gelir, ama EPG boştur ya da kanal adı yanlış görünür.

HataEtkisi
NIT_errorAğ bilgisi bozuk; otomatik kanal arama hatalı sonuç verir
SDT_errorServis adı/tipi görünmez → kanal listesinde "Bilinmeyen"
EIT_errorElektronik program rehberi boş veya yanlış
TDT_errorCihaz saati yanlış; kayıt zamanlamaları kayar (eşik: ≤ 30 s)
Unreferenced_PIDAkışta hiçbir tabloda tanımlanmayan PID var; genelde boşa bant genişliği

Bu grubu izlememek yaygın bir tercihtir ve çoğu zaman savunulabilir. Ancak DVB-T/S üzerinden yayın yapıyorsanız TDT_error ve EIT_error doğrudan abone şikâyetine dönüşür.

Asıl mesele: hangi hataya alarm kurmalı?

Standardı okumak kolay, onunla yaşanabilir bir alarm seti kurmak zor. Kendi alarm kurallarımızı yazarken öğrendiğimiz birkaç şey:

Continuity count error'a çıplak eşik koymayın. "CC error > 0 → alarm" kuralı ilk gece operasyon ekibine bildirimleri kapattırır. Anlamlı olan tek bir hata değil, belirli bir pencerede biriken oran. Biz bunu kayan pencere + histerezis ile ele alıyoruz: alarm bir eşikte açılıyor, ondan belirgin şekilde düşük bir eşikte kapanıyor. Aksi hâlde sınırda gezinen bir yayın dakikada bir alarm açıp kapatır.

CC hatası her zaman encoder'ın suçu değildir. Multicast (UDP) taşımada CC hatalarının büyük çoğunluğu ağ paket kaybıdır. Ayırt etmenin pratik yolu: aynı akışı iki farklı noktadan aynı anda ölçmek. İki noktada da aynı anda aynı CC sıçraması varsa kaynak bozuktur; yalnız birinde varsa o noktaya giden yol bozuktur. Tek noktadan bakarken bu ayrımı yapmak mümkün değildir — ölçüm size "bir sorun var" der ama "nerede" demez.

PCR_accuracy alarmı en çok yanlış pozitif üreten kuraldır. Özellikle akış bir IP ağından veya yeniden çoğullayıcıdan (remux) geçtiyse ±500 ns sınırında gezinmesi olağandır. Bunu tek başına alarma bağlamak yerine, eşlik eden bir belirti (kare atlama, buffer olayı) varken anlamlı kabul etmek daha sağlıklı.

Öncelik 1 hataları anlık, Öncelik 2 hataları süreli değerlendirilmeli. TS_sync_loss bir saniye bile sürse olaydır. PCR_repetition_error ise bir kez olduğunda değil, sürdüğünde olaydır.

HLS/DASH yayınlarında TR 101 290 geçerli mi?

Sık sorulan ve sık yanlış cevaplanan bir soru. Kısa cevap: taşıma biçimine bağlı.

  • Segmentleriniz MPEG-TS ise (klasik HLS, .ts segmentler) TR 101 290 ölçümleri segment içeriğine uygulanabilir. CC hataları, PCR analizi, PAT/PMT kontrolü hepsi anlamlıdır.
  • Segmentleriniz fMP4/CMAF ise (modern HLS ve DASH'in çoğu) TR 101 290 uygulanamaz. Orada transport stream yoktur; PCR, PAT, PMT gibi kavramların karşılığı yoktur.

CMAF tarafında karşılığı olan ölçümler farklıdır: segment sürekliliği, manifest tutarlılığı, zaman damgası boşlukları, indirme süresi ve çözüm bazlı QoE (donma, siyah kare, sessizlik). Bir tedarikçi size CMAF akışı için "TR 101 290 uyumlu" diyorsa, ne kastettiğini sormaya değer.

Özetle

TR 101 290'ın değeri, ölçtüğü şeylerden çok tarafların aynı kelimeleri kullanmasını sağlamasıdır. "Görüntü bozuk" öznel bir ifadedir; "son 15 dakikada 3 farklı noktada Continuity_count_error oranı %0,4'e çıktı, PCR düzenli" ise bir belgedir. Sözleşme tartışması, tedarikçi görüşmesi ve SLA raporu bu ikincisiyle yürür.

Kendi yayınlarınızda bu ölçümlerin nasıl göründüğünü merak ediyorsanız, kısa bir demoda gerçek akışınız üzerinden bakabiliriz.

← Tüm yazılar