Peer-to-Peer

Jika sudah familiar dengan kata "seeders" dan "peers", well, tidak perlu penjelasan lebih detail untuk ini :)

Jika belum, mari kita buat diagram. Umumnya di arsitektur client-server, diagramnya adalah seperti ini:

flowchart LR

p1((client)) --> P[server]

P --> p1

Client (penonton) meminta file, server memberi file. Dalam konteks disini, file tersebut adalah video.

Jika ada 3 client yang sedang terhubung bersamaan, gambarnya seperti ini:

flowchart LR

p1((client1)) --> P[server]

P --> p1

  

p2((client2)) --> P

P --> p2((client2))

  

p3((client3)) --> P

P --> p3((client3))

Sangat standar. Lihat bagaimana server terlihat overwhelming mengatur request masuk dan memberikan response kepada client. Pengukurnya adalah seberapa banyak server dapat meng-handle penonton dalam waktu bersamaan dan berbicara tentang skalabilitas, umumnya menggunakan pendekatan scale-out dengan cara menambahkan server lagi:

flowchart LR

p1((client1)) --> P[server]

P --> p1

  

p2((client2)) --> P

P --> p2((client2))

  

p3((client3)) --> P9[server2]

P9 --> p3((client3))

Di real-world case seperti ini:

flowchart LR

p1((client1)) --> LB[Load Balancer]

p2((client2)) --> LB

p3((client3)) --> LB

  

LB .-> server1

LB .-> server2

LB .-> server1

  

server1 .-> LB

server2 .-> LB

server1 .-> LB

  

LB --> p1

LB --> p2

LB --> p3

Terlihat bila beban "Load Balancer" menjadi overwhelming namun tenang itu memang sudah tugas doi.

Dengan teknologi peer-to-peer (p2p), hal seperti ini adalah hal yang mungkin:

flowchart LR

p1((client1)) --> P[server]

  

P --> p1

  

p2((client2)) --> P

P --> p2((client2))

  

p3((client3)) .-> p2

p2 .-> p3

  

p4((client4)) .-> p1

p1 .-> p4

Dengan catatan:

client1 dan client4 menonton video yang sama dengan resolusi yang sama
client2 dan client3 menonton video yang sama dengan resolusi yang sama
Timestamp client4 dibelakang timestamp client1
Timestamp client3 dibelakang timestamp client2

Dari diagram diatas, client1 dan client2 technically menjadi "seeder" yang mana client3 dan client4 menjadi "peer". Teknologi ini dapat mengurangi beban kerja server sekaligus mengurangi penggunaan bandwidth yang mahal itu.

Apa yang terjadi saat client1 atau client2 tidak dapat dihubungi (menjadi "leecher", sad)? Sederhana, client3 dan client2 akan terhubung langsung ke server and that's it.

Jika timestamp client4 lebih depan dari client1 seperti melakukan seeking, well, permintaan akan dijadikan ke server seperti ini:

flowchart LR

p1((client1)) --> P[server]

  

P --> p1

  

p2((client2)) --> P

P --> p2((client2))

  

p3((client3)) .-> p2

p2 .-> p3

  

p4((client4)) --> P

P --> p4

Dan tidak menutup kemungkinan kondisinya berubah menjadi seperti ini:

flowchart LR

p1((client1)) .-> p4

  

p4 .-> p1

  

p2((client2)) --> P

P --> p2((client2))

  

p3((client3)) .-> p2

p2 .-> p3

  

p4((client4)) --> P[server]

P --> p4

Yeah hidup kadang jadi seeder kadang jadi leecher.

Dalam dunia per-video-an, p2p bukanlah teknologi yang baru. Teknologi inilah yang digunakan dalam Real-time Communication (RTC) seperti panggilan suara dan video yang dilakukan melalui jaringan internet. Dalam penerapannya, tentu tidak mudah. Dan anggap saya sedang tidak mood membahas tentang Network Address Translation (NAT).

Teknologi p2p ini digunakan di platform berbagi video PeerTube, dan tidak hanya untuk VoD, melainkan untuk Live Video juga, which is nice.

Transcoding vs Transmuxing

Di awal kita sempat membahas tentang "Coding Format" yang umumnya digunakan bebarengan dengan istilah "Codecs" alias Compress/Decompress. Juga, tentang "Container Format", alias tentang "pembungkus" si video.

Membahas tentang kompatibilitas, lapisan nya adalah seperti ini:

Container berisi "video", "audio", dan "subtitle"
Server perlu tahu:
- Apakah si client/video player dapat "memulai langsung" si video yang ada di server, yang berarti, si client tersebut harus mendukung container dari video tersebut
- Apakah si client tersebut mendukung codecs yang digunakan. Video/audio bisa menggunakan codecs yang beragam, misal video menggunakan h.265 dan audio menggunakan DTS
- Apakah si client tersebut mampu meng-handle bitrate yang dimiliki melalui koneksi jaringan yang digunakan
Jika ketiga hal diatas terpenuhi, tidak ada hal rumit yang dilakukan alias "direct play" dapat terjadi
Jika si client mendukung container namun tidak mendukung codecs yang digunakan, maka transcoding akan terjadi
Jika si client mendukung codecs namun tidak dengan container, maka transmuxing (remux?) akan terjadi
Jika si client mendukung keduanya namun tidak dengan bitrate, maka transcoding akan terjadi (ke resolusi yang lebih rendah)

Proses transmuxing (hanya mengubah container, tanpa menyentuh video/audio) umumnya lebih ringan daripada transcoding. Transmuxing mungkin lebih berguna untuk Live Streaming kecuali bila berurusan dengan bitrate yang perlu melakukan transcoding.

On-the-fly vs On-demand transcoding

Di PeerTube, proses transcoding terjadi setelah pengguna mengunggah video (on-demand since selalu mengarah ke konfigurasi resolusi). Multiplier nya adalah daftar resolusi yang didukung, sehingga total penyimpanan untuk satu video akan selalu beberapa kali lebih besar tergantung berapa resolusi yang didukung oleh si admin dari instance tersebut.

Di beberapa tempat lain, terkadang transcoding dilakukan on-the-fly, Jellyfin salah satunya:

Disitu terlihat bahwa container—somehow dilaporin sebagai "mkv" dibagian container Original Media Info yang padahal aslinya "webm" alias vp9—dan video codec dan audio codec yang dimiliki si file tersebut tidak didukung oleh si player. Satu-satunya cara—per-paragraf ini ditulis—untuk direct play di Jellyfin iOS adalah:

Container: mp4/mov/ts
Video codec: h.264 8-bit
Audio codec: flac/mp3/aac

Jellyfin iOS pada dasarnya hanyalah a fucking webview. Gunakan Swiftin.

Berikut bila diakses melalui Mozilla Firefox yang berjalan di Steam Deck saya (GNU/Linux):

Terlihat bahwa "play method" nya Direct Playing karena Mozilla Firefox di tempat saya mendukung container webm dan video codec vp9 dan audio codec OPUS.

Video di-deliver as-is.

10 KiB Raw Blame History

Peer-to-Peer

Transcoding vs Transmuxing

On-the-fly vs On-demand transcoding

10 KiB

Raw Blame History