IPTV Yayın Analizi ve Hata Ayıklama Rehberi

Giriş

Kullanıcı "takılıyor", görüntüde bloklar veya ses‑görüntü uyuşmazlığı raporladığında; sorun ağda mı, içerikte mi yoksa oynatıcıda mı belli değildir. Bu rehber, yalnızca yasal yayınlar için uygulanabilecek, pratik ve ölçülebilir adımlarla IPTV akışlarını nasıl analiz edeceğinizi anlatır. Örnek komutlar, Wireshark/tshark filtreleri ve ffprobe kullanımı içerir.

Not: Yalnızca sahip olduğunuz veya analiz için açık izin aldığınız yayınları izleyin ve kaydedin.

Hangi semptom hangi katmanı işaret eder? (Kısa öncelik listesi)

• Anlık takılma / kısa donmalar → Ağ paket kaybı, segment gecikmesi veya oynatıcı buffer underrun.
• Sürekli artefakt (bloklaşma, mozaik) → Paket kaybı veya codec/bitrate uyuşmazlığı; dekoder zorlanması.
• Ses‑görüntü bozulması / lip‑sync → PTS/DTS veya oyuncu içi buffer yönetimi hatası.
• Kanal geçişlerinde uzun bekleme → CDN veya segment metadata (playlist) hatası.

Bu belirtileri gördüğünüzde önce ağ/transport, sonra container/codec, en sonda oynatıcı/cihaz kontrolü yapın.

Gerekli araçlar ve hızlı kullanım notları

• Wireshark / tshark: Paket yakalama ve filtreleme. (HTTP, UDP, RTP, MPEG‑TS)
• ffprobe (FFmpeg): Segment/TS içindeki PTS/DTS, frame tipi kontrolü.
• curl/wget: Playlist ve segment indirme testi.
• Oynatıcı logları: Ales Player gibi güçlü oynatıcıların hata kayıtları teşhiste kritik. Güçlü Oynatıcı sayfasındaki log alma yaklaşımlarını uygulayın.
• (Opsiyonel) tc/NetEm: Lokal testlerde gecikme/paket kaybı simülasyonu.

Örnek komutlar:

• Playlist indirme: curl -s -D - "https://cdn.example.com/stream/playlist.m3u8" -o playlist.m3u8
• Segment indirme: curl -s -O "https://cdn.example.com/stream/segment0001.ts"
• ffprobe ile paket/PTS kontrolü: ffprobe -v error -show_entries packet=pts_time,dts_time,flags -select_streams v:0 -of csv=p=0 segment0001.ts
• pcap içinden HLS trafiği: tshark -r capture.pcap -Y "http.request and http.request.uri contains "m3u8"" -T fields -e frame.time -e http.request.uri

HLS / MPEG‑TS seviyesinde adım adım inceleme

1) Playlist (m3u8) doğrulamaları

• Target duration ve segmentler: ext‑x‑targetduration çok düşükse oynatıcı buffer sıkışabilir. Playlist'i indirin ve sürelerin segmentle uyumlu olduğunu doğrulayın.
• Discontinuity etiketleri: ext‑x‑discontinuity, kodak değişiklikleri veya reklam enjeksiyonlarında doğru yerde olmalı.
• Byte‑range ve segment URL'leri: CDN yönlendirmeleri / 302 ler segment gecikmesine sebep olabilir.

Pratik kontrol: playlist.m3u8 içindeki her segmentin gerçekte sunucuda aynı süre ve sıra ile bulunup bulunmadığını curl ile doğrulayın.

2) Segment içeriği — MPEG‑TS kontrolleri

• Continuity counter: Her TS paketinde 4‑bit continuity_counter olmalıdır; atlama paket kaybı veya yeniden başlatma varsa bu sayacın beklenmedik şekilde sıçraması olur. Wireshark MPEG‑TS dissector ile continuity counter izlemesi yapın.
• PCR (Program Clock Reference): PCR jitter büyükse dekoderde buffer underrun olur; PCR frekansı genelde 27 MHz saatine göre planlanır. PCR adımlarını ffprobe veya özel TS analiz araçlarıyla raporlayın.
• PTS/DTS: ffprobe ile frame PTS/DTS’lerini çıkarın; PTS monoton değilse veya arada büyük boşluk varsa lip‑sync veya atlama oluşur.

Örnek ffprobe: ffprobe -v error -select_streams v:0 -show_entries frame=pkt_pts_time,pkt_dts_time,pict_type -of csv=p=0 segment0001.ts

3) Ağ seviyesinde paketler

• Paket kaybı: UDP taşıyan MPEG‑TS için udp.port==XYZ filter ile paket loss/IC packet reordering kontrolü yapın.
• TCP/HTTP gecikmesi: HLS segmentleri HTTP üzerinden gelirken TCP retransmission ve RTO sürelerini Wireshark’ta kontrol edin. HTTP 200 yerine 206 (range) dönüyorsa CDN/edge sorununu işaret eder.

Wireshark filtre örnekleri:

• HLS playlist istekleri: http.request.uri contains "m3u8"
• TS/segment trafiği: http.request.uri contains ".ts"
• UDP TS (örnek port 1234): udp.port == 1234

Yaygın sorunlar, tespit metodu ve çözüm önerileri (Tablo)

Bu tabloyu referans alarak önce hangi katmanda (Ağ, Container, Codec, Oynatıcı) olduğuna karar verin.

Örnek vaka: HLS segmentlerinin tekrar istenmesi (kısa kesinti)

Senaryo: Kullanıcılar kanal değişiminde 5–8 saniye bekliyor. Playlist doğru ama geçişlerde delay. Adımlar:

1. Oynatıcı loglarını al: kanal geçiş zaman damgası, playlist/segment URL'leri. (Ales Player için log yapısı Güçlü Oynatıcı sayfasında açıklanmıştır.)
2. Wireshark ile seçim anındaki HTTP isteklerini yakala: playlist → yeni segment istekleri → 200/206 kodları ve transfer süreleri.
3. Eğer segmentler sunucu tarafından gecikmeli geliyorsa CDN edge’leri kontrol et; pcap'de TCP handshake→GET→first byte delay ölç. Çözüm: Segment sürelerini (ör. 2s→4s) yeniden değerlendirme, önceden fetch/playing strategy (prefetch next playlist) uygulama, çoklu kaynak (multi‑CDN) kullanımı.

Bu noktada platformun sunduğu Çoklu Kaynak Desteği ve akıllı önbellekleme yaklaşımlarını değerlendirmek faydalı olur.

Oynatıcı logları nasıl paketleyip destek ekibine gönderirsiniz?

Destek isteği oluştururken şu verileri ekleyin:

• Problem zamanları (timestamp) ve TCKN gibi gizliliğe aykırı olmayan metadata.
• İlgili playlist URL ve problem olan segment URL listesi.
• Oynatıcı logları (verbose), cihaz modeli, işletim sistemi ve uygulama sürümü. Ales Player için Canlı TV ve EPG veya Film ve Dizi (VOD) özelliklerinden hangisini kullanıyorsanız belirtin.
• Eğer mümkünse küçük bir pcap (sadece ilgili 30–60s aralığı) ekleyin.

Destek ekibi, bu verilerle continuity counter hatası, PCR jitter ve CDN gecikmesi gibi sorunları hızla tespit edebilir.

İleri seviye ipuçları

• Sürekli üretim ortamında monitoring: segment fetch latency, first‑byte time, HTTP 5xx sayıları ve oynatıcı reported stalls metriklerini toplayın.
• Otomatik uyarılar: PCR jitter veya continuity counter anomalisi tespit edildiğinde alarm üretilsin.
• Test ortamında NetEm ile gecikme/paket kaybı simülasyonu yaparak uygulama toleransını ölçün.

Sonuç — Hızlı kontrol listesi (5 adım)

1. Semptomları ve zaman damgalarını kaydetin.
2. Playlist ve segment metadata'sını curl/ffprobe ile doğrulayın.
3. Ağ trafiğini pcap ile yakalayın; Wireshark filtreleriyle retransmission/packet loss analizi yapın.
4. TS/PTS/PCR değerlerini ffprobe ve araçlarla kontrol edin.
5. Oynatıcı loglarını, segment örneklerini ve pcap dosyasını birleştirip destek ekibine gönderin.

Sorunun kaynağını katman katman daraltmak, tekrar eden vakalarda kalıcı ağ/CDN/segment yapılandırması değişiklikleriyle maliyeti düşürür. Operasyonel süreçte Güçlü Oynatıcı, Çoklu Kaynak Desteği ve Canlı TV ve EPG özelliklerinin sunduğu telemetri ve fallback mekanizmalarını entegre etmek uzun vadede stabilite sağlar.

Öneri

Canlı yayınlarda 2–4 saniyelik segment süreleri yaygın olsa da, kritik spor veya düşük gecikme senaryolarında altyapınızı PCR doğruluğu, CDN önbellek stratejisi ve oynatıcı ön‑fetch mekanizmaları açısından test edin. İlk adım olarak bir günlüğüne segment fetch ve player stall metriklerini izlemeye alın — hızlı görünen küçük iyileştirmeler büyük kullanıcı deneyimi farkı yaratır.

İlgili kaynaklar

• Güçlü Oynatıcı
• Çoklu Kaynak Desteği
• Canlı TV ve EPG
• Ayrıntılı artefakt teşhisi için örnek vaka: IPTV Görüntü Artefaktları: Nedenleri, Tanılama ve Pratik Çözümler