Belajar FFmpeg - Streaming & Network Protocols

#Pendahuluan

Pada episode 12 kalian belajar memecah video menjadi segmen-segmen dan menyusun playlist-nya. Tapi seluruh pekerjaan itu masih terjadi di dalam satu komputer — file keluar dan masuk ke disk yang sama. Di episode 13 ini kita akan melangkah keluar: bagaimana kalian mengirim video dari satu mesin ke mesin lain, atau dari mesin kalian ke jutaan penonton.

Dunia streaming dipenuhi protokol, masing-masing dengan asal-usul dan kepentingannya sendiri. Memahami protokol mana yang cocok untuk kasus apa adalah keterampilan yang jauh lebih berharga daripada menghafal perintah. Karena itu episode ini dimulai dari anatomi protokol — RTSP, RTMP, SRT, dan UDP — kemudian membangun pipeline live streaming utuh dari capture, encode, hingga push, lalu menutup dengan seni tuning latensi rendah.

#Anatomi Protokol Streaming

Semua protokol streaming berbagi satu ide: mengirim bitstream video dari sumber ke tujuan, entah secara langsung (streaming live) atau bertahap (streaming on demand). Yang membedakannya adalah tiga hal: cara kontrol sesi, cara transportasi data, dan keandalan yang ditawarkan. Mari kita bedah satu per satu.

#RTSP: Protokol Kontrol Kamera dan Media

RTSP (Real Time Streaming Protocol) adalah remote control untuk media: ia mengatur sesi — play, pause, teardown — sementara data video sebenarnya berjalan di atas protokol lain, biasanya RTP. Kalian paling sering bertemu RTSP sebagai penonton: hampir semua kamera IP dan NVR mengekspos aliran RTSP yang bisa diambil FFmpeg.

Mengirim file sebagai stream RTSP memerlukan `-re{:bash}`, yang membuat FFmpeg membaca input sesuai kecepatan real-time alih-alih secepat mungkin:

ffmpeg -re -i input.mp4 -c copy -f rtsp rtsp://kameraserver.local/live/stream

Tanpa -re, FFmpeg akan menghabiskan file dalam hitungan detik lalu menutup koneksi — bukan live streaming, melainkan pengiriman kilat. -re adalah kata kunci yang akan kalian lihat di hampir semua pipeline live.

#RTMP: Warisan Flash yang Masih Hidup

RTMP (Real Time Messaging Protocol) lahir era Flash, dan walaupun Flash sudah lama mati, RTMP tetap menjadi standar de facto untuk ingest live streaming ke platform seperti YouTube, Twitch, dan media server seperti Nginx RTMP. Yang menarik: meski protokolnya bernama RTMP, format yang dikirim FFmpeg adalah FLV, karena bitstream RTMP pada dasarnya adalah FLV yang di-over TCP.

ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -c:a aac -f flv rtmp://ingest.example.com/live/kunci-stream

Struktur URL-nya rtmp://host/aplikasi/kunci-stream: bagian live adalah nama aplikasi di server, dan kunci-stream adalah key unik yang biasanya didapat dari platform saat membuat stream. Key ini adalah "alamat" penonton menghubungi kalian — simpan rahasia, karena siapa pun yang memegangnya bisa mengirim ke akun kalian.

#SRT: Video Reliabel di Atas Jaringan Buruk

SRT (Secure Reliable Transport) dibangun untuk satu masalah: mengirim video melalui jaringan yang tidak bisa diandalkan — internet antar benua, uplink satelit, atau wifi pinggiran. Ia memakai UDP sebagai pembawa tapi menambahkan mekanisme ARQ (retransmisi paket yang hilang) dan kontrol kemacetan. Hasilnya: kualitas gambar tidak berubah-ubah naik turun, hanya latensi yang naik ketika jaringan memburuk.

ffmpeg -re -i input.mp4 -c copy -f mpegts srt://192.168.50.10:9000?mode=caller

URL SRT diisi parameter query. mode=caller berarti mesin ini inisiatif menghubungi receiver; sisi penerima memakai mode=listen. Format yang diangkut biasanya MPEG-TS, karena SRT dianggap sebagai "pipa" yang andal dan format apa pun bisa melewatinya.

#UDP: Siaran Broadcast dan Multicast

Pada urutan terendah ada UDP — tidak ada koneksi, tidak ada pengakuan, tidak ada retransmisi. Konsekuensinya dua: latensi paling rendah, tapi paket yang hilang hilang selamanya. UDP mulanya tidak cocok untuk video, namun MPEG-TS dibuat bertahan dari kehilangan paket kecil, sehingga kombinasi keduanya adalah standar industri untuk siaran internal dan multicast.

ffmpeg -re -i input.mp4 -c copy -f mpegts udp://239.1.1.1:1234

Alamat 239.x.x.x adalah alamat multicast: paket dikirim sekali oleh sumber, lalu router menggandakannya untuk semua penerima yang bergabung ke grup tersebut. Satu encoder bisa melayani ribuan receiver dalam jaringan yang mendukung multicast — itulah mengapa UDP/multicast mendominasi distribusi video di dalam gedung broadcast dan stadium.

#Pipeline Live: Capture - Encode - Push

Kalian mungkin belum punya kamera profesional, tapi semua orang punya satu sumber video: webcam. Mari kita susun pipeline live streaming yang utuh menggunakan webcam (V4L2) dan mikrofon (ALSA) di Linux:

ffmpeg -f v4l2 -framerate 30 -video_size 1280x720 -i /dev/video0 \
  -f alsa -ac 2 -i default \
  -c:v libx264 -preset veryfast -tune zerolatency -b:v 2500k \
  -c:a aac -b:a 128k \
  -f flv rtmp://ingest.example.com/live/kunci-stream

Pipeline ini punya tiga tahap yang jelas, dan memahami ketiganya membuat kalian bisa men-debug masalah apa pun:

1. Capture — -f v4l2 membaca /dev/video0 sebagai sumber video, dan -f alsa membaca default sebagai sumber audio. Perhatikan bahwa setiap sumber punya format tersendiri yang harus dideklarasikan di depan opsi -i masing-masing.
2. Encode — libx264 di preset veryfast dengan -tune zerolatency meng-encode video, aac meng-encode audio. Tuning di tahap ini menentukan latensi, dan kita bahas sebentar lagi.
3. Push — -f flv membungkus bitstream dan mengirimnya ke URL RTMP tujuan. Tahap ini hanya muxing dan pengiriman; semua kerja berat sudah dilakukan di tahap encode.

Analogi yang pas untuk pipeline ini adalah dapur restoran: sumber bahan baku (capture), koki yang memasak (encode), dan kurir yang mengantar pesanan (push). Masalah yang tampak di tahap akhir sering kali berakar di tahap sebelumnya.

#Mengapa Latensi Naik, dan Cara Menekannya

Latensi live streaming adalah total waktu dari frame tertangkap kamera sampai ditampilkan di layar penonton. Sumbernya bukan satu: buffer input, buffer encoder, buffer jaringan, dan buffer pemutar. Tiga kebocoran terbesar yang bisa kita kendalikan dari sisi FFmpeg adalah encoder, GOP, dan buffering.

Encoder. -tune zerolatency membuat libx264 tidak menunda frame untuk analisis lookahead — frame keluar secepat ia masuk. Ini mengorbankan sedikit efisiensi kompresi demi latensi. Untuk streaming dua arah seperti konferensi, prioritas ini benar.

GOP. Jarak antar keyframe menentukan seberapa cepat pemutar bisa bergabung dan seberapa cepat kalian pulih dari gangguan. Interval keyframe yang pendek menekan latensi bergabung tapi menaikkan bitrate. Aturan praktis yang sehat untuk live: GOP 2 detik.

ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -tune zerolatency \
  -g 60 -keyint_min 60 -sc_threshold 0 \
  -fflags nobuffer -flags low_delay -flush_packets 1 \
  -f flv rtmp://ingest.example.com/live/kunci-stream

• -g 60 memaksa keyframe setiap 60 frame (2 detik pada 30 fps), -keyint_min 60 mencegah keyframe muncul lebih cepat dari itu, dan -sc_threshold 0 mematikan deteksi perubahan scene yang bisa memicu keyframe tak terduga. Hasilnya: interval keyframe yang rapi dan prediktif — persis seperti yang kita tekankan di episode 12 untuk segmenting.
• -fflags nobuffer dan -flags low_delay mengurangi buffering input dan decoder.
• -flush_packets 1 menulis paket segera alih-alih menumpuknya — penting untuk output jaringan.

#Memilih Protokol: Panduan Keputusan

Dengan semua pilihan di tangan, bagaimana memutuskan? Tiga pertanyaan cepat:

1. Ke arah mana video mengalir? Jika menuju platform publik, RTMP adalah bahasa pergaulannya. Jika antar mesin internal atau antar site, SRT lebih tangguh. Jika dalam satu jaringan dengan dukungan multicast, UDP memberikan efisiensi tertinggi.
2. Seberapa buruk jaringannya? Jaringan internet antar benua yang tidak stabil adalah medan SRT. Jaringan LAN yang sehat dan terkendali bisa menggunakan RTMP atau UDP dengan aman.
3. Apakah sesi harus dikontrol? Jika kalian butuh play/pause/seek dari sisi penerima dan parameter sesi yang terstruktur, RTSP menyediakan itu.

Tidak ada protokol yang "paling benar" secara mutlak — yang ada hanyalah protokol yang paling cocok dengan karakteristik jaringan dan kebutuhan kalian.

#Penutup

Pada episode 13 ini kalian telah melangkah keluar dari dunia file menuju dunia jaringan: memahami RTSP sebagai protokol kontrol media, RTMP sebagai standar ingest live yang mengangkut FLV, SRT sebagai transportasi reliabel di atas jaringan buruk, dan UDP multicast sebagai jalur berlatensi terendah untuk distribusi internal. Kalian juga menyusun pipeline live streaming utuh dari capture V4L2, encode libx264, hingga push RTMP, beserta tuning latensi rendah lewat -tune zerolatency, kontrol GOP, dan pengurangan buffering.

Poin kunci yang perlu dibawa pulang:

• -re mengubah input menjadi laju real-time; tanpa itu, tidak ada live streaming.
• RTMP mengangkut FLV; SRT mengangkut MPEG-TS; keduanya memakai format yang berbeda.
• Pipeline live selalu punya tiga tahap: capture, encode, push — dan debugging dimulai dari pemahaman tiga tahap itu.
• Latensi adalah hasil bersama encoder, GOP, dan buffer, bukan satu saklar tunggal.

Kalau hanya mengirim stream mentah, protokol-protokol ini sudah cukup. Tapi penonton modern tidak hanya butuh video sampai ke perangkatnya — mereka butuh kualitas yang beradaptasi dengan bandwidth mereka, dan pemutar bisa melompat maju-mundur sepuasnya.

Di episode 14 berikutnya kita akan merangkai semua fondasi yang sudah kalian bangun sejak episode 12: HLS & Adaptive Streaming — bagaimana -f hls mengubah segmen dan playlist menjadi pengalaman streaming yang bisa menyesuaikan kualitas secara dinamis. Pastikan tetap semangat!