Langkah Bedah Durasi Pada Sumber Rtp
Membedah durasi pada sumber RTP sering dianggap sebagai urusan teknis semata, padahal praktiknya menyentuh banyak hal: struktur data, cara menghitung waktu, sampai bagaimana kita menghindari salah tafsir terhadap “lama” dan “cepat”. Dalam konteks sistem yang memakai RTP sebagai aliran paket waktu-nyata, durasi bukan hanya angka di layar. Durasi adalah hasil dari rangkaian keputusan: timestamp mana yang dipakai, bagaimana sinkronisasi dilakukan, serta bagaimana jitter dan loss memengaruhi pembacaan. Artikel ini menyusun langkah bedah durasi pada sumber RTP dengan skema yang tidak biasa: bukan dari teori ke praktik, melainkan dari “gejala” ke “akar” sehingga lebih mudah diterapkan saat debugging.
Mulai dari Gejala: Durasi Terasa Tidak Masuk Akal
Langkah pertama adalah mengunci gejala yang terlihat. Contohnya: rekaman terlihat 2 menit, tetapi pemutar menampilkan 1 menit 30 detik; audio selesai lebih cepat dari video; atau grafik monitoring menunjukkan lonjakan durasi setiap beberapa detik. Catat di mana durasi dibaca: di player, di server, di dashboard, atau pada file hasil rekam. Perbedaan lokasi pembacaan ini penting karena sumber durasi bisa berasal dari timestamp RTP, clock lokal, atau metadata lain. Dengan menyebutkan gejala secara spesifik, Anda menghindari jebakan “memperbaiki” hal yang tidak rusak.
Peta Tiga Jam: Clock RTP, Clock Sistem, dan Clock Media
Bedah durasi membutuhkan peta tiga jam yang sering bercampur: (1) clock RTP dari timestamp paket, (2) clock sistem seperti NTP/monotonic time, dan (3) clock media yang terkait sample rate atau frame rate. Durasi yang benar biasanya adalah hasil konversi timestamp RTP ke satuan detik menggunakan rate dari payload (misalnya 90 kHz untuk video tertentu, 48 kHz untuk audio). Jika Anda menghitung selisih timestamp tanpa mengetahui rate yang tepat, durasi akan melenceng. Di titik ini, pastikan Anda tahu pasangan “payload type → clock rate” yang digunakan di sesi tersebut.
Langkah Bedah: Ambil Dua Titik, Bukan Semua Paket
Skema yang tidak biasa: jangan langsung menelan semua paket untuk menghitung durasi. Ambil dua titik yang paling bermakna, yaitu paket pertama yang valid dan paket terakhir yang valid untuk setiap SSRC. “Valid” berarti lolos pemeriksaan dasar: urutan tidak aneh, payload masuk akal, dan timestamp tidak meloncat ekstrem. Hitung selisih timestamp: Δts = ts_akhir - ts_awal. Setelah itu, ubah menjadi durasi: durasi_detik = Δts / clock_rate. Cara ini cepat mengungkap apakah masalah utama ada pada konversi rate atau pada kualitas aliran (misalnya timestamp yang reset).
SSRC, Reset Timestamp, dan Durasi yang Tiba-Tiba Nol
Jika durasi mendadak kecil atau menjadi nol, periksa apakah SSRC berubah di tengah sesi. Pergantian SSRC bisa membuat sistem mengira ada sesi baru, sehingga “awal” dihitung ulang. Selain itu, beberapa encoder atau bridge dapat me-reset timestamp saat re-init. Tanda reset terlihat dari timestamp yang tiba-tiba lebih kecil dari sebelumnya tanpa wrap yang wajar. Untuk mencegah durasi palsu, simpan state per SSRC: timestamp terakhir, urutan terakhir, dan indikator reset. Saat reset terdeteksi, buat segmen baru, bukan memaksa satu durasi kontinu.
Wrap-Around: Musuh Sunyi pada Durasi Panjang
Timestamp RTP umumnya 32-bit, sehingga bisa wrap-around. Pada aliran lama, selisih sederhana bisa menjadi negatif atau salah besar. Solusinya bukan menebak-nebak, tetapi menggunakan aritmetika modular: jika ts_akhir < ts_awal dan selisihnya mendekati batas, anggap terjadi wrap. Implementasi yang rapi akan melakukan “extended timestamp” dengan menambah counter wrap setiap kali mendeteksi lompatan besar ke belakang. Dengan begitu, durasi yang dihitung tetap stabil untuk sesi panjang.
Jitter, Reordering, dan Kenapa Durasi Terlihat Bergerigi
Durasi yang naik-turun pada monitoring sering berasal dari paket yang datang tidak berurutan. Jika Anda menghitung durasi berdasarkan paket terakhir yang diterima (arrival order), grafik akan bergerigi. Solusi praktis: hitung durasi dari timestamp maksimum yang sudah terlihat, bukan paket terakhir yang datang. Tambahkan buffer reordering kecil jika diperlukan, lalu gunakan “max_ts_seen” per SSRC untuk estimasi durasi berjalan. Ini membuat pembacaan durasi lebih halus tanpa mengubah data asli.
Validasi Silang: Bandingkan dengan RTCP dan Marker Bit
Untuk memastikan hasil bedah durasi tidak bias, lakukan validasi silang. Jika tersedia RTCP Sender Report, Anda bisa memetakan RTP timestamp ke waktu NTP sehingga durasi dapat dibandingkan dengan clock sistem. Untuk video, marker bit sering menandai akhir frame; menghitung jumlah frame dan membaginya dengan frame rate dapat menjadi pembanding kasar. Bila durasi dari timestamp dan durasi dari hitungan frame berbeda jauh, biasanya masalah ada pada clock rate yang salah, payload type yang keliru, atau transkoding yang mengubah rate tanpa memperbarui sinyal sesi.
Checklist Cepat Saat Durasi Salah: Apa yang Dicek Lebih Dulu
Mulai dari yang paling murah dicek: pastikan mapping payload ke clock rate benar, lalu pastikan perhitungan menggunakan timestamp maksimum (bukan urutan kedatangan). Setelah itu cek pergantian SSRC, reset timestamp, dan wrap-around. Terakhir, lakukan pembuktian dengan RTCP bila ada. Dengan urutan ini, Anda membedah durasi pada sumber RTP secara sistematis, bukan mengandalkan tebakan, dan Anda bisa menunjukkan “di paket mana” durasi mulai menyimpang ketika diminta bukti oleh tim lain.
Home
Bookmark
Bagikan
About
Chat
