Real-time আর streaming — WebSocket, VoIP আর ভিডিও স্ট্রিমিং

১ · তিন ধরনের মাল্টিমিডিয়া অ্যাপ — কে কতটা দেরি সইতে পারে

আগের পর্বগুলোতে যত অ্যাপ দেখেছেন — ওয়েবপাতা (পর্ব ৩৬), ইমেইল (পর্ব ৩৯) — সেখানে মূল চাওয়া ছিল প্রতিটি বাইট নির্ভুলভাবে পৌঁছানো; একটু দেরি হলে কেউ টেরও পায় না। মাল্টিমিডিয়ায় হিসাব উল্টো। একটি ভিডিও-কলে দুই-একটি packet হারালে কানে প্রায় ধরা পড়ে না, কিন্তু আধা সেকেন্ড দেরি হলে দুজনেই একসাথে কথা বলে ফেলেন। তাই আগে বুঝতে হবে কোন অ্যাপ কতটা দেরি সইতে পারে। মাল্টিমিডিয়া অ্যাপ মোটামুটি তিন ধরনের:

কথোপকথনের সংখ্যাটি আসে ITU-T-র সুপারিশ G.114 থেকে: সেখানে বলা হয়েছে, বেশিরভাগ ব্যবহারে একদিকের মোট দেরি মোটামুটি ১৫০ মিলিসেকেন্ডের মধ্যে থাকলে অধিকাংশ ব্যবহারকারী সন্তুষ্ট থাকেন, আর ৪০০ মিলিসেকেন্ডের বেশি সাধারণ নেটওয়ার্ক-পরিকল্পনায় গ্রহণযোগ্য নয়। এগুলো কঠোর আইন নয়, নির্দেশিকা — কিছু মানুষ ২০০-তেও খুশি, প্রতিধ্বনি (echo) থাকলে কম দেরিতেও বিরক্ত। এই “বাজেট”-এর মধ্যে সব ধরতে হয়: codec-এর কাজ, packet বানানোর অপেক্ষা, পথের propagation আর queuing delay (পর্ব ৫), আর প্রাপকের jitter buffer.

২ · মিডিয়ার ভিত্তি — sampling, codec, frame আর bitrate

অডিও: প্রতি সেকেন্ডে কত bit

পর্ব ৭-এ দেখেছেন analog কণ্ঠ কীভাবে digital হয়: নির্দিষ্ট সময় পরপর মান মাপা (sampling), প্রতিটি মান নির্দিষ্ট স্তরে গোল করা (quantization), তারপর bit-এ লেখা — একসাথে PCM. টেলিফোনের কণ্ঠ মোটামুটি ৪ kHz পর্যন্ত ধরা হয়, তাই Nyquist অনুযায়ী প্রতি সেকেন্ডে ৮,০০০টি sample; প্রতিটি ৮ bit. ফলে:

Codec (coder-decoder) হলো সেই পদ্ধতি যা এই কাঁচা ডেটা সংকুচিত করে আর আবার খোলে। G.711 সংকোচন প্রায় করে না, তাই মান ভালো কিন্তু ৬৪ kbps খায়। আধুনিক Opus codec (IETF, RFC 6716, ২০১২) কণ্ঠের জন্য সাধারণত ১৬–৩২ kbps-এ খুব ভালো মান দেয়, প্রয়োজনে ৬ kbps থেকে ৫১০ kbps পর্যন্ত যেতে পারে, আর গান-বাজনাও ভালো সামলায়। WebRTC-তে Opus আর G.711 দুটোই বাধ্যতামূলক codec. সংকোচন বিনামূল্যে নয়: codec-কে কয়েক মিলিসেকেন্ড কণ্ঠ জমিয়ে তারপর কাজ করতে হয়, আর এই অপেক্ষা delay বাজেট থেকে কাটা যায়।

ভিডিও: ছবির সারি আর সংকোচন

ভিডিও আসলে দ্রুত পরপর দেখানো ছবি — প্রতিটি একটি frame, সাধারণত প্রতি সেকেন্ডে ২৪–৬০টি। সংকোচন না করলে ১০৮০p-র (১৯২০ × ১০৮০ pixel) প্রতি pixel-এ ২৪ bit, ৩০ frame/সেকেন্ডে ১৯২০ × ১০৮০ × ২৪ × ৩০ ≈ ১.৪৯ Gbps লাগত! তাই ভিডিও codec দুই ধরনের অপচয় কাটে:

• Spatial (একই ছবির ভেতরে): নীল আকাশের হাজারটি প্রায় একই pixel আলাদা করে না লিখে একসাথে বর্ণনা করা — JPEG ছবির মতো।
• Temporal (পরপর ছবির মধ্যে): সংবাদ-পাঠকের পেছনের দেয়াল frame থেকে frame-এ বদলায় না; শুধু যা নড়েছে তা পাঠানো।

এজন্য frame তিন রকম। I-frame (key frame) নিজে নিজেই সম্পূর্ণ ছবি — বড়, কিন্তু অন্য কারও ওপর নির্ভর করে না। P-frame শুধু আগের ছবির তুলনায় পার্থক্য রাখে, B-frame আগের আর পরের দুটো ছবির সাহায্য নেয় — সবচেয়ে ছোট। একটি I-frame থেকে পরের I-frame পর্যন্ত দলটিকে GOP (group of pictures) বলে। এর নেটওয়ার্ক-ফল গুরুত্বপূর্ণ: একটি P-frame-এর packet হারালে ভুল পরের I-frame পর্যন্ত ছড়ায়; আর streaming-এর প্রতিটি segment সাধারণত I-frame দিয়ে শুরু হয়, যাতে player যেকোনো segment থেকে দেখা শুরু করতে বা অন্য মানে লাফ দিতে পারে।

প্রচলিত ভিডিও codec-এর প্রজন্ম: H.264/AVC (২০০৩) — প্রায় সব যন্ত্রে hardware সমর্থন, আজও সবচেয়ে সর্বজনীন; H.265/HEVC (২০১৩) — মোটামুটি একই মানে কম bitrate, তবে লাইসেন্সের জটিলতা; Google-এর VP9 — YouTube-এ ব্যাপক; আর Alliance for Open Media-র রয়্যালটি-মুক্ত AV1 (২০১৮) — আরও দক্ষ, কিন্তু encode-এ বেশি CPU. নতুন প্রজন্মের লাভ বিষয়বস্তু আর encoder-এর ওপর অনেক নির্ভর করে।

এগুলো শুধু রুক্ষ পরিসর — কার্টুন কম bit-এ চলে, বৃষ্টির মধ্যে ফুটবল ম্যাচ অনেক বেশি চায়। মনে রাখার কথা: এক ধাপ রেজোলিউশন বাড়লে bitrate মোটামুটি দ্বিগুণ বা তার বেশি, আর তাই একই ভিডিওর কয়েকটি মান রেখে দেওয়া যায় (অংশ ৪)।

৩ · জমা ভিডিও streaming — buffer আর playout-এর হিসাব

সবচেয়ে সরল পদ্ধতি progressive download: ভিডিওটি একটি সাধারণ ফাইল, ব্রাউজার HTTP GET দিয়ে আনতে থাকে (পর্ব ৩৬), আর কিছুটা জমা হলেই চালানো শুরু করে। দর্শক সামনে লাফ দিলে HTTP-র Range header দিয়ে ফাইলের মাঝখান থেকে আনা যায়। Server-এর কোনো বিশেষ বুদ্ধি লাগে না — যেকোনো ওয়েব সার্ভার বা CDN কাজ করে। মূল যন্ত্রটি তাই client-এর playout buffer: নেটওয়ার্ক যে হারে ডেটা আনে (fill rate, x) আর ভিডিও যে হারে খরচ হয় (playback rate, r) — দুইয়ের পার্থক্য এই buffer শোষণ করে।

গাণিতিক মডেল — পরীক্ষার ধাঁচের হিসাব

ধরুন ভিডিওর playback rate r bps, নেটওয়ার্ক স্থির x bps হারে আনছে, আর player চালানো শুরু করে buffer-এ Q bit জমলে। সময় t = ০-তে অনুরোধ।

• শুরুর দেরি: Q bit জমতে লাগে t_p = Q / x.
• x ≥ r হলে: buffer কখনো কমে না — কোনো stall নেই।
• x < r হলে: চালানো শুরুর পর buffer-এ থাকে Q − (r − x)·τ, যেখানে τ = চালানো শুরুর পর থেকে সময়। এটি শূন্য হয় τ = Q / (r − x)-এ — অর্থাৎ মোট সময় t_p + Q / (r − x)-এ প্রথম stall.

যাচাই: ১৬ সেকেন্ডে নামানো হয়েছে ১.৫ × ১৬ = ২৪ Mb, আর ১২ সেকেন্ড চালাতে খরচ হয়েছে ২ × ১২ = ২৪ Mb — হিসাব মিলছে। এবার প্রশ্ন উল্টো: ১০ মিনিটের (৬০০ সেকেন্ড) পুরো ভিডিও একবারও না থামিয়ে চালাতে Q কত লাগবে? দরকার Q / (r − x) ≥ ৬০০, অর্থাৎ Q ≥ ৬০০ × ০.৫ = ৩০০ Mb — আর শুরুর দেরি ৩০০ ÷ ১.৫ = ২০০ সেকেন্ড! কোনো দর্শক তিন মিনিট অপেক্ষা করবেন না। তাই সমাধান buffer বড় করা নয় — bitrate কমানো: ভিডিও যদি ১.২ Mbps-এর একটি সংস্করণে থাকে, তাহলে x > r, আর কোনো stall নেই। এই চিন্তা থেকেই adaptive bitrate.

৪ · Adaptive bitrate — DASH, HLS আর CDN

Adaptive bitrate (ABR) streaming-এ একটি ভিডিও আগে থেকেই কয়েকটি মানে encode করা থাকে — যেমন ২৪০p, ৪৮০p, ৭২০p, ১০৮০p. প্রতিটি সংস্করণকে (representation) ২ থেকে ১০ সেকেন্ডের ছোট ছোট segment-এ কাটা হয়, আর সব সংস্করণের segment সময়ের হিসাবে একই সীমানায় শুরু হয় (প্রত্যেকটির শুরুতে I-frame). Player প্রথমে একটি manifest ফাইল আনে, যেখানে লেখা কোন কোন মান আছে, প্রতিটির bitrate কত, আর segment-গুলোর URL কী। তারপর প্রতিটি segment-এর আগে player নিজেই ঠিক করে কোন মানেরটা আনবে। সার্ভার বোকা থাকে — শুধু ফাইল দেয়; বুদ্ধি থাকে client-এ।

দুটোরই segment একই ফরম্যাটে রাখার জন্য এসেছে CMAF (Common Media Application Format) — একই fMP4 segment একবার বানিয়ে DASH আর HLS দুই manifest-ই দেখাতে পারে, ফলে CDN-এ দ্বিগুণ জায়গা লাগে না। একটি ছোট HLS master playlist দেখতে এমন:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=854x480
480p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/index.m3u8

Player কীভাবে মান বাছে — দুই ধরনের ABR

• Throughput-ভিত্তিক: শেষ কয়েকটি segment কত দ্রুত এল তা মেপে, তার একটি নিরাপদ অংশের (যেমন ৮০%) মধ্যে সবচেয়ে বড় bitrate. সহজ, কিন্তু গতি হঠাৎ নামলে মাপ পিছিয়ে থাকে।
• Buffer-ভিত্তিক: buffer-এ কত সেকেন্ড জমা আছে সেটাই মূল সংকেত — buffer কম হলে নিচু মান, ভরা থাকলে উঁচু। ২০১৪ সালে Netflix-এর সাথে কাজ করা গবেষকেরা (BBA নামের পদ্ধতি) দেখিয়েছিলেন এতে stall কমে। BOLA-র মতো পরের পদ্ধতি আর আধুনিক player দুই সংকেত মিলিয়ে ব্যবহার করে।

নিচের stepper-এ একজন দর্শক ১০টি segment-এর একটি ভিডিও দেখছেন, প্রতি segment ৪ সেকেন্ডের। ৮ সেকেন্ড জমলে চালানো শুরু। নিয়ম throughput-ভিত্তিক: আগের segment-এ মাপা গতির ৮০%-এর মধ্যে সবচেয়ে বড় মান। মাঝপথে Wi-Fi থেকে বেরিয়ে দুর্বল মোবাইল সংকেতে গেলে গতি ৮ Mbps থেকে নেমে ৯০০ kbps হয়।

// DASH-style player: 4-second segments, 4 representations, throughput-based ABR.
// ABR rule: highest bitrate <= 0.8 x throughput measured on the previous segment.
const SEG = 4, START = 8;                        // s of video per segment; play after 8 s buffered
const reps = [["240p", 400], ["480p", 1000], ["720p", 2500], ["1080p", 5000]];   // kbps
const bw = [8000, 8000, 8000, 3000, 1500, 900, 900, 2000, 8000, 8000]; // kbps while fetching seg i

function play(fixed, show) {
  let t = 0, buf = 0, playing = false, est = 1500, stalls = 0, stallTime = 0;
  if (show) console.log("seg  bw    pick   dl(s)  t_end  buffer  event");
  bw.forEach((b, i) => {
    const [name, kbps] = fixed || [...reps].reverse().find(r => r[1] <= 0.8 * est) || reps[0];
    const dl = kbps * SEG / b;                   // seconds to download this segment
    let ev = "";
    if (playing) {                               // video keeps playing during the download
      if (buf >= dl) buf -= dl;
      else { stalls++; stallTime += dl - buf; ev = "STALL " + (dl - buf).toFixed(2) + " s"; buf = 0; }
    }
    t += dl; buf += SEG; est = b;                // segment arrives; remember its throughput
    if (!playing && buf >= START) { playing = true; ev = "playback starts"; }
    if (show) console.log(String(i + 1).padEnd(5) + String(b).padEnd(6) + name.padEnd(7) +
      dl.toFixed(2).padEnd(7) + t.toFixed(2).padEnd(7) + buf.toFixed(2).padEnd(8) + ev);
  });
  return `stalls ${stalls}, stall time ${stallTime.toFixed(2)} s`;
}
console.log("ABR       : " + play(null, true));
console.log("fixed 1080p: " + play(reps[3], false));
console.log("fixed 720p : " + play(reps[2], false));

seg  bw    pick   dl(s)  t_end  buffer  event
1    8000  480p   0.50   0.50   4.00
2    8000  1080p  2.50   3.00   8.00    playback starts
3    8000  1080p  2.50   5.50   9.50
4    3000  1080p  6.67   12.17  6.83
5    1500  480p   2.67   14.83  8.17
6    900   480p   4.44   19.28  7.72
7    900   240p   1.78   21.06  9.94
8    2000  240p   0.80   21.86  13.14
9    8000  480p   0.50   22.36  16.64
10   8000  1080p  2.50   24.86  18.14
ABR       : stalls 0, stall time 0.00 s
fixed 1080p: stalls 4, stall time 48.94 s
fixed 720p : stalls 3, stall time 10.47 s

CDN, live latency আর ছোট chunk

Segment যেহেতু সাধারণ HTTP ফাইল, সেগুলো CDN-এর edge server-এ cache হয় (পর্ব ৩৮) — হাজার দর্শক একই জনপ্রিয় নাটক দেখলে মূল সার্ভারে একবারই চাপ পড়ে, বাকিটা কাছের edge থেকে। HTTP/2 আর HTTP/3 (পর্ব ৩৭) একই সংযোগে পরপর segment আনা আরও সস্তা করেছে।

Live-এ একই কৌশল, কিন্তু segment তৈরি হয় চলতে চলতে। Encoder-কে একটি segment পুরো শেষ করতে হয়, তারপর CDN-এ যায়, আর player সাধারণত নিরাপত্তার জন্য ২–৩টি segment buffer-এ রাখে। ৬ সেকেন্ডের segment আর ৩টি buffer মানে শুধু এখানেই প্রায় ১৮ সেকেন্ড পিছিয়ে — তাই প্রচলিত HLS live প্রায়ই সম্প্রচারের চেয়ে বেশ কয়েক সেকেন্ড থেকে আধা মিনিট পিছিয়ে থাকে। ছোট segment দেরি কমায়, কিন্তু request-এর খরচ বাড়ায়। এর উত্তর Low-Latency HLS আর chunked CMAF: segment-কে ছোট “partial” টুকরোয় ভাগ করে তৈরি হতে হতেই পাঠানো — দেরি কয়েক সেকেন্ডে নামতে পারে, তবে প্রকৃত সংখ্যা CDN আর player-ভেদে আলাদা।

৫ · WebSocket — ব্রাউজার আর সার্ভারের দুই-দিকের স্থায়ী লাইন

এবার একটু ভিন্ন ধরনের “real-time”: ভিডিও নয়, ছোট ছোট বার্তা যা সঙ্গে সঙ্গে পৌঁছানো দরকার — চ্যাটের নতুন মেসেজ, ক্রিকেটের live স্কোর, শেয়ারবাজারের দাম, অনলাইন খেলায় প্রতিপক্ষের চাল। সাধারণ HTTP-তে সমস্যা হলো শুধু client প্রশ্ন করতে পারে; নতুন খবর এলে সার্ভার নিজে থেকে বলতে পারে না। পুরোনো সমাধানগুলো:

• Polling: প্রতি কয়েক সেকেন্ডে “নতুন কিছু আছে?” — বেশিরভাগ উত্তর “না”, প্রতিবার পুরো HTTP header.
• Long polling: সার্ভার উত্তর আটকে রাখে যতক্ষণ না খবর আসে; উত্তর পেলেই client আবার প্রশ্ন পাঠায় — প্রতিটি বার্তায় নতুন অনুরোধ।
• Server-Sent Events (SSE): একটি দীর্ঘস্থায়ী HTTP উত্তর (text/event-stream), যাতে সার্ভার একের পর এক ঘটনা লিখতে থাকে; ব্রাউজারের EventSource সংযোগ ভাঙলে নিজেই আবার জোড়ে। তবে শুধু সার্ভার থেকে client-এর দিকে, আর লেখা-ভিত্তিক।

WebSocket (RFC 6455, ডিসেম্বর ২০১১) এর পূর্ণ উত্তর: একটি TCP সংযোগের ওপর দুই দিকেই, যেকোনো সময়, ছোট frame-এ বার্তা — প্রতি বার্তায় মাত্র ২–১৪ বাইটের header. ঠিকানা ws:// (port 80) বা TLS-এর ওপর wss:// (port 443, পর্ব ৪৮); বাস্তবে প্রায় সবসময় wss://, কারণ এনক্রিপ্ট না করা সংযোগ মাঝপথের proxy প্রায়ই ভেঙে দেয়।

Handshake — HTTP দিয়ে শুরু, তারপর অন্য protocol

WebSocket আলাদা port চায় না; এটি সাধারণ HTTP/1.1 অনুরোধ হিসেবে শুরু হয়ে “Upgrade” চায়। সার্ভার রাজি হলে 101 Switching Protocols দেয়, আর সেই একই TCP সংযোগ তখন থেকে WebSocket frame বহন করে। RFC 6455-এর নিজের উদাহরণ:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: http://example.com

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Sec-WebSocket-Key হলো client-এর ১৬টি এলোমেলো বাইট, base64-এ লেখা। সার্ভার এর সাথে একটি নির্দিষ্ট GUID (258EAFA5-E914-47DA-95CA-C5AB0DC85B11) জোড়ে, SHA-1 hash নেয়, তারপর base64 করে Sec-WebSocket-Accept-এ ফেরত দেয়। এটি নিরাপত্তার জন্য নয় (কোনো গোপন চাবি নেই) — শুধু প্রমাণ যে সার্ভারটি সত্যিই WebSocket বোঝে। আসল নিরাপত্তা আসে wss://-এর TLS আর সার্ভারের Origin যাচাই থেকে।

Frame-এর গঠন আর masking

বাইট 0 : FIN(1) RSV1-3(3) opcode(4)    0x1 text, 0x2 binary, 0x8 close, 0x9 ping, 0xA pong
বাইট 1 : MASK(1) payload len(7)        0–125 = সরাসরি দৈর্ঘ্য
                                       126 = পরের 2 বাইটে দৈর্ঘ্য, 127 = পরের 8 বাইটে
তারপর  : masking key (4 বাইট, MASK=1 হলে) → payload

FIN = ১ মানে বার্তার শেষ টুকরো; বড় বার্তা কয়েকটি frame-এ ভাগ হলে পরেরগুলোর opcode ০ (continuation). সবচেয়ে অদ্ভুত নিয়ম: client থেকে সার্ভারের প্রতিটি frame mask করা বাধ্যতামূলক, সার্ভার থেকে client-এরগুলো mask করা হয় না। Client প্রতিটি frame-এর জন্য ৪ বাইটের নতুন এলোমেলো key বাছে, আর payload-এর i-তম বাইট key-এর (i mod ৪)-তম বাইটের সাথে XOR হয়। কারণটি এনক্রিপশন নয় — key তো frame-এই লেখা! ২০১০–১১ সালে গবেষকেরা দেখিয়েছিলেন, WebSocket না বোঝা কিছু পুরোনো transparent proxy-কে ক্ষতিকর ওয়েবপাতার JavaScript দিয়ে এমন বাইট পাঠানো যায় যা proxy নতুন HTTP অনুরোধ ভেবে ভুল উত্তর cache করে ফেলে (cache poisoning). এলোমেলো mask থাকলে আক্রমণকারী তারের ওপর ঠিক কোন বাইট যাবে তা নিয়ন্ত্রণ করতে পারে না।

নিচের প্রোগ্রাম পুরো হিসাবটি নিজে করে — একটি ছোট SHA-1 লিখে RFC-র উদাহরণের accept মান বের করে, তারপর “Hello” লেখাটি RFC-র উদাহরণের mask দিয়ে একটি client frame বানায় আর আবার পড়ে।

// WebSocket (RFC 6455): Sec-WebSocket-Accept, then encode + decode one masked text frame.
function sha1(bytes) {                         // compact SHA-1 (FIPS 180-4), returns 20 bytes
  const m = [...bytes, 0x80]; while (m.length % 64 !== 56) m.push(0);
  const bits = bytes.length * 8; for (let s = 56; s >= 0; s -= 8) m.push(s >= 32 ? 0 : (bits >>> s) & 255);
  let h = [0x67452301, 0xEFCDAB89, 0x98BADCFE, 0x10325476, 0xC3D2E1F0];
  const rol = (x, n) => (x << n) | (x >>> (32 - n));
  for (let o = 0; o < m.length; o += 64) {
    const w = []; for (let i = 0; i < 16; i++) w[i] = (m[o+4*i] << 24) | (m[o+4*i+1] << 16) | (m[o+4*i+2] << 8) | m[o+4*i+3];
    for (let i = 16; i < 80; i++) w[i] = rol(w[i-3] ^ w[i-8] ^ w[i-14] ^ w[i-16], 1);
    let [a, b, c, d, e] = h;
    for (let i = 0; i < 80; i++) {
      const f = i < 20 ? (b & c) | (~b & d) : i < 40 ? b ^ c ^ d : i < 60 ? (b & c) | (b & d) | (c & d) : b ^ c ^ d;
      const k = [0x5A827999, 0x6ED9EBA1, 0x8F1BBCDC, 0xCA62C1D6][Math.floor(i / 20)];
      [e, d, c, b, a] = [d, c, rol(b, 30), a, (rol(a, 5) + f + e + k + w[i]) | 0];
    }
    h = h.map((x, i) => (x + [a, b, c, d, e][i]) | 0);
  }
  return h.flatMap(x => [x >>> 24, (x >>> 16) & 255, (x >>> 8) & 255, x & 255]);
}
const key = "dGhlIHNhbXBsZSBub25jZQ==", GUID = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";
const accept = btoa(String.fromCharCode(...sha1(new TextEncoder().encode(key + GUID))));
console.log("Sec-WebSocket-Accept: " + accept);

const hex = a => a.map(x => x.toString(16).padStart(2, "0")).join(" ");
const mask = [0x37, 0xfa, 0x21, 0x3d], text = [...new TextEncoder().encode("Hello")];
const frame = [0x80 | 0x1, 0x80 | text.length, ...mask, ...text.map((x, i) => x ^ mask[i % 4])];
console.log("client frame: " + hex(frame));        // FIN=1 opcode=1(text) MASK=1 len=5
const fin = frame[0] >> 7, op = frame[0] & 15, masked = frame[1] >> 7, len = frame[1] & 127;
const k = frame.slice(2, 6), data = frame.slice(6).map((x, i) => x ^ k[i % 4]);
console.log(`decoded: FIN=${fin} opcode=${op} MASK=${masked} len=${len} -> "${String.fromCharCode(...data)}"`);
console.log("server frame (no mask): " + hex([0x81, text.length, ...text]));

Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
client frame: 81 85 37 fa 21 3d 7f 9f 4d 51 58
decoded: FIN=1 opcode=1 MASK=1 len=5 -> "Hello"
server frame (no mask): 81 05 48 65 6c 6c 6f

Ping/pong, বন্ধ করা আর HTTP/2

Control frame (close, ping, pong) ১২৫ বাইটের বেশি হয় না আর ভাগ হয় না। যেকোনো পক্ষ ping পাঠালে অন্যপক্ষ একই ডেটা দিয়ে pong ফেরায় — সংযোগ বেঁচে আছে কি না দেখা, আর পথের NAT বা load balancer যেন নীরবতার কারণে সংযোগ মুছে না ফেলে (keepalive, পর্ব ১৯)। বন্ধ করতে close frame-এ একটি ২ বাইটের কোড: ১০০০ স্বাভাবিক, ১০০১ চলে যাচ্ছে (যেমন পাতা বন্ধ), ১০০২ protocol ভুল, ১০০৮ নীতি-লঙ্ঘন, ১০০৯ বার্তা খুব বড়, ১০১১ সার্ভারের ভেতরের ত্রুটি; ১০০৬ (অস্বাভাবিকভাবে ভাঙা) তারে কখনো পাঠানো হয় না — শুধু অ্যাপকে জানানো হয় যে close frame ছাড়াই সংযোগ গেছে। HTTP/2-এর একটি সংযোগের ভেতরে একটি stream হিসেবে WebSocket চালানোর পদ্ধতি এসেছে RFC 8441 (২০১৮)-এ, “extended CONNECT” দিয়ে; HTTP/3-এর জন্য একই ধারণার আলাদা মান আছে।

WebSocket TCP-র ওপর, তাই একটি packet হারালে পরের সব বার্তা অপেক্ষা করে (head-of-line blocking, পর্ব ৩৩) — চ্যাটে সমস্যা নয়, কিন্তু ভিডিও-কলের জন্য অনুপযুক্ত। QUIC-এর ওপর WebTransport এই ফাঁক পূরণ করতে চায় (পর্ব ৩৩-এ উল্লেখ)। ভিডিও-কলের জন্য এবার UDP-র জগতে যাওয়া যাক।

৬ · VoIP — packet বানানো, jitter buffer আর হারানো packet সামলানো

VoIP-এ প্রেরক কণ্ঠকে নির্দিষ্ট মাপের টুকরোয় কাটে — সাধারণত ২০ মিলিসেকেন্ড — আর প্রতিটি টুকরো একটি packet. এই কাটাকে বলে packetization. G.711-এ ২০ মিলিসেকেন্ডে কণ্ঠের বাইট = ৬৪,০০০ ÷ ৮ × ০.০২ = ১৬০ বাইট. প্রতিটি packet-এর সামনে বসে RTP header (১২ বাইট), UDP header (৮), IPv4 header (২০) — মোট ৪০ বাইট। অর্থাৎ ১৬০ বাইটের কণ্ঠের জন্য তারে যায় ২০০ বাইট, সেকেন্ডে ৫০ বার:

Packet বড় করলে (যেমন ৩০ মিলিসেকেন্ড) header-এর ভাগ কমে, কিন্তু packet ভরা পর্যন্ত অপেক্ষায় delay বাড়ে, আর একটি packet হারালে বেশি কণ্ঠ হারায়। ২০ মিলিসেকেন্ড জনপ্রিয় সমঝোতা। নিচের ক্যালকুলেটর G.711 আর Opus-এর হিসাব করে, সাথে দলের ভিডিও কলের bandwidth (অংশ ৮)। Opus-এর frame ২.৫ থেকে ৬০ মিলিসেকেন্ডের কয়েকটি নির্দিষ্ট মাপে হয় (৩০ তাদের মধ্যে নেই), তাই Opus-এর জন্য ২০, ৪০ আর ৬০।

// (a) Bandwidth of one voice stream including RTP(12) + UDP(8) + IPv4(20) = 40 header bytes.
const HDR = 12 + 8 + 20;
const cases = [["G.711", 64, 10], ["G.711", 64, 20], ["G.711", 64, 30],
               ["Opus", 24, 20], ["Opus", 24, 40], ["Opus", 24, 60]];
console.log("codec   kbps  ms  payload(B)  packet(B)  pkts/s  IP-kbps  overhead");
for (const [c, kbps, ms] of cases) {
  const pay = kbps * 1000 / 8 * ms / 1000;            // bytes of voice per packet
  const pps = 1000 / ms, ip = (pay + HDR) * 8 * pps / 1000;
  console.log(c.padEnd(8) + String(kbps).padEnd(6) + String(ms).padEnd(4) + String(pay).padEnd(12) +
    String(pay + HDR).padEnd(11) + pps.toFixed(1).padEnd(8) + ip.toFixed(1).padEnd(9) +
    (100 * HDR / (pay + HDR)).toFixed(0) + "%");
}
// (b) Group video call, every participant sends one 1.5 Mbps stream.
const B = 1.5;
console.log("\nN   mesh up/down (Mbps)   SFU up/down   MCU up/down   SFU server in/out");
for (const N of [2, 3, 4, 6, 10]) {
  const mesh = (N - 1) * B, sfuDown = (N - 1) * B;
  console.log(String(N).padEnd(4) + `${mesh} / ${mesh}`.padEnd(22) + `${B} / ${sfuDown}`.padEnd(14) +
    `${B} / ${B}`.padEnd(14) + `${N * B} / ${N * (N - 1) * B}`);
}

codec   kbps  ms  payload(B)  packet(B)  pkts/s  IP-kbps  overhead
G.711   64    10  80          120        100.0   96.0     33%
G.711   64    20  160         200        50.0    80.0     20%
G.711   64    30  240         280        33.3    74.7     14%
Opus    24    20  60          100        50.0    40.0     40%
Opus    24    40  120         160        25.0    32.0     25%
Opus    24    60  180         220        16.7    29.3     18%

N   mesh up/down (Mbps)   SFU up/down   MCU up/down   SFU server in/out
2   1.5 / 1.5             1.5 / 1.5     1.5 / 1.5     3 / 3
3   3 / 3                 1.5 / 3       1.5 / 1.5     4.5 / 9
4   4.5 / 4.5             1.5 / 4.5     1.5 / 1.5     6 / 18
6   7.5 / 7.5             1.5 / 7.5     1.5 / 1.5     9 / 45
10  13.5 / 13.5           1.5 / 13.5    1.5 / 1.5     15 / 135

Jitter আর playout delay

প্রেরক প্রতি ২০ মিলিসেকেন্ডে নিখুঁত তালে packet পাঠায়, কিন্তু পথের queue-তে প্রতিটি আলাদা সময় অপেক্ষা করে — একটি ৫৫ মিলিসেকেন্ডে পৌঁছায়, পরেরটি ৬২-তে, আরেকটি ১৪০-এ। এই ওঠানামাই jitter. আসামাত্র বাজালে কণ্ঠ কাঁপবে আর ফাঁক পড়বে। তাই প্রাপক প্রতিটি packet একটি নির্দিষ্ট playout delay q পরে বাজায়: যে packet সময় t-তে তৈরি হয়েছিল (RTP timestamp থেকে জানা), সেটি বাজবে t + q-তে। তার আগে এলে buffer-এ অপেক্ষা করে; পরে এলে বাজানোর সময় পেরিয়ে গেছে — সেটি দেরির কারণে হারানো (late loss) হিসেবে ফেলে দেওয়া হয়। q বড় মানে কম ক্ষতি কিন্তু বেশি দেরি; q ছোট মানে উল্টো।

Adaptive playout: একটি স্থির q সব নেটওয়ার্কে খাটে না। Kurose-Ross-এর পাঠ্যবইয়ের পদ্ধতিতে প্রাপক প্রতিটি packet-এর delay দেখে চলমান গড় (EWMA) রাখে — dᵢ = (১ − u)·dᵢ₋₁ + u·(rᵢ − tᵢ) — আর বিচ্যুতির গড় vᵢ = (১ − u)·vᵢ₋₁ + u·|rᵢ − tᵢ − dᵢ|, যেখানে rᵢ পৌঁছানোর সময়। কথার প্রতিটি নতুন অংশের (talk spurt, নীরবতার পরে) শুরুতে playout delay ঠিক হয় d + ৪v; নীরবতা একটু লম্বা বা ছোট হলে কেউ টের পায় না। বইয়ে u = ০.০১; এখানে বদল চোখে পড়ার জন্য u = ০.১. মিলটি TCP-র RTO হিসাবের (পর্ব ৩০) সাথে।

// VoIP receiver: one packet every 20 ms (timestamp t). Network delay varies (jitter).
// Fixed playout: packet i is played at t_i + q; if it arrives after that it is LATE (= lost).
const delay = [55, 62, 48, 95, 70, 140, 66, 58, 105, 72];   // one-way delay of each packet, ms
const pk = delay.map((d, i) => ({ seq: i + 1, t: 20 * i, arr: 20 * i + d }));
console.log("seq  sent  arrives  " + [60, 100, 150].map(q => ("q=" + q).padEnd(7)).join(""));
for (const p of pk)
  console.log(String(p.seq).padEnd(5) + String(p.t).padEnd(6) + String(p.arr).padEnd(9) +
    [60, 100, 150].map(q => (p.arr <= p.t + q ? "play" : "LATE").padEnd(7)).join(""));
for (const q of [60, 100, 150]) {
  const late = pk.filter(p => p.arr > p.t + q).length;
  console.log(`q=${q} ms: ${late} of ${pk.length} late (${(100 * late / pk.length).toFixed(0)}% loss)`);
}
// Adaptive playout (Kurose-Ross style): EWMA of delay d and of deviation v, u = 0.1 here.
// The delay used for the NEXT talk spurt = d + 4v.
const u = 0.1; let d = delay[0], v = 0;
console.log("\nseq  delay  d(avg)  v(dev)  d+4v");
pk.forEach((p, i) => {
  const r = p.arr - p.t;                          // measured network delay of this packet
  if (i > 0) { d = (1 - u) * d + u * r; v = (1 - u) * v + u * Math.abs(r - d); }
  console.log(String(p.seq).padEnd(5) + String(r).padEnd(7) + d.toFixed(1).padEnd(8) +
    v.toFixed(1).padEnd(8) + (d + 4 * v).toFixed(1));
});

seq  sent  arrives  q=60   q=100  q=150
1    0     55       play   play   play
2    20    82       LATE   play   play
3    40    88       play   play   play
4    60    155      LATE   play   play
5    80    150      LATE   play   play
6    100   240      LATE   LATE   play
7    120   186      LATE   play   play
8    140   198      play   play   play
9    160   265      LATE   LATE   play
10   180   252      LATE   play   play
q=60 ms: 7 of 10 late (70% loss)
q=100 ms: 2 of 10 late (20% loss)
q=150 ms: 0 of 10 late (0% loss)

seq  delay  d(avg)  v(dev)  d+4v
1    55     55.0    0.0     55.0
2    62     55.7    0.6     58.2
3    48     54.9    1.3     60.0
4    95     58.9    4.7     77.9
5    70     60.0    5.3     81.1
6    140    68.0    11.9    115.8
7    66     67.8    10.9    111.5
8    58     66.9    10.7    109.7
9    105    70.7    13.1    123.0
10   72     70.8    11.9    118.4

হারানো packet সামলানো — FEC, interleaving আর আন্দাজ

দেরিতে আসা বা পথে হারানো packet আবার চাওয়ার সময় নেই — একটি RTT-ই হয়তো ১০০ মিলিসেকেন্ড। তাই তিনটি কৌশল:

• FEC (আগেভাগে বাড়তি পাঠানো): (ক) প্রতি n টি packet-এর পর তাদের XOR-এর একটি বাড়তি packet — n+১টির যেকোনো একটি হারালে বাকিগুলো থেকে পুনর্গঠন; খরচ ১/n বাড়তি bandwidth আর n টি packet-এর অপেক্ষা। (খ) পিঠে চড়ানো কম-মানের কপি: packet n-এ থাকে টুকরো n পুরো মানে আর টুকরো n−১ খুব কম bitrate-এ (পাঠ্যবইয়ের উদাহরণ ৬৪ kbps PCM-এর সাথে ১৩ kbps GSM). n−১ হারালে প্রাপক কম-মানের কপিটি বাজায় — কণ্ঠ মুহূর্তের জন্য একটু ভোঁতা, কিন্তু ফাঁক নেই। Opus-এর ভেতরে এমন একটি in-band FEC আছে।
• Interleaving: ২০ মিলিসেকেন্ডের টুকরোকে ৫ মিলিসেকেন্ডের চারটি ছোট অংশে ভাগ করে বিভিন্ন packet-এ ছড়িয়ে দেওয়া — packet ১-এ অংশ ১, ৫, ৯, ১৩; packet ২-এ ২, ৬, ১০, ১৪ ইত্যাদি। একটি packet হারালে ২০ মিলিসেকেন্ডের এক বড় ফাঁকের বদলে চারটি ৫ মিলিসেকেন্ডের ছোট ফাঁক, যা কান প্রায় ধরে না। দাম: পুরো দল আসা পর্যন্ত অপেক্ষা, অর্থাৎ বাড়তি delay.
• Loss concealment (প্রাপকের আন্দাজ): আগের টুকরো আবার বাজানো বা আগে-পরের শব্দ থেকে মাঝখানটা বানিয়ে নেওয়া। কণ্ঠ ছোট সময়ে প্রায় একই থাকে বলে অল্প ক্ষতিতে ভালো কাজ করে।

৭ · RTP, RTCP আর SIP — কথার খাম, রিপোর্ট আর ঘণ্টা বাজানো

RTP (RFC 3550, ২০০৩; প্রথম সংস্করণ RFC 1889, ১৯৯৬) নিজে কোনো নিশ্চয়তা দেয় না — না পৌঁছানো, না সময়। এটি শুধু একটি মানসম্মত খাম, যাতে প্রাপক জানে কোন packet কোনটার পরে, কোন মুহূর্তের কণ্ঠ, কোন উৎসের আর কোন codec-এর। Header-এর প্রথম ১২ বাইট:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌───┬─┬─┬───────┬─┬─────────────┬───────────────────────────────┐
│V=2│P│X│  CC   │M│     PT      │        sequence number        │
├───┴─┴─┴───────┴─┴─────────────┴───────────────────────────────┤
│                           timestamp                           │
├───────────────────────────────────────────────────────────────┤
│                 SSRC (synchronization source)                 │
└───────────────────────────────────────────────────────────────┘

• Payload type (PT, ৭ bit): কোন codec — যেমন ০ মানে G.711 μ-law, ৮ মানে A-law; ৯৬–১২৭ “dynamic”, যার অর্থ SDP-তে ঠিক হয় (Opus সাধারণত এখানে)।
• Sequence number (১৬ bit): প্রতি packet-এ ১ বাড়ে — হারানো বা ক্রমভঙ্গ ধরার জন্য।
• Timestamp (৩২ bit): sampling-ঘড়ির একক, সময় নয়। G.711-এ ঘড়ি ৮,০০০ Hz, তাই ২০ মিলিসেকেন্ডের packet-এ timestamp ১৬০ করে বাড়ে; নীরবতায় packet না গেলেও ঘড়ি চলতে থাকে, তাই jitter buffer ঠিক জানে কখন বাজাতে হবে। ভিডিওতে সাধারণত ৯০,০০০ Hz ঘড়ি, আর একটি frame-এর সব packet-এর timestamp একই।
• SSRC (৩২ bit): stream-এর এলোমেলো পরিচয় — একটি কলে কণ্ঠ আর ভিডিও আলাদা SSRC.
• Marker (M): বিশেষ মুহূর্ত — অডিওতে নীরবতার পর নতুন talk spurt, ভিডিওতে একটি frame-এর শেষ packet.

সাথী protocol RTCP মাঝে মাঝে রিপোর্ট পাঠায় — মোট bandwidth-এর মোটামুটি ৫%-এর মধ্যে রাখার নিয়মে। Receiver report-এ থাকে কত শতাংশ packet হারাল, মোট হারানো, আর আগমনের jitter-এর হিসাব; sender report-এ RTP timestamp-এর সাথে প্রকৃত ঘড়ির সময় মেলানো, যা দিয়ে আলাদা SSRC-র কণ্ঠ আর ঠোঁট নড়া (lip-sync) মেলানো হয়। প্রেরক এই রিপোর্ট দেখে bitrate কমায়-বাড়ায়। RTP-র packet-কে আলাদা অগ্রাধিকার দেওয়া নেটওয়ার্কের কাজ — DSCP EF আর QoS (পর্ব ২৬)।

SIP — কল বাজানো আর কাটা

কণ্ঠ পাঠানোর আগে কাউকে খুঁজে পেতে হয়, রাজি করাতে হয়, আর codec মেলাতে হয়। এই signalling-এর প্রচলিত মান SIP (RFC 3261, ২০০২) — HTTP-র মতো লেখা-ভিত্তিক অনুরোধ-উত্তর, ঠিকানা দেখতে ইমেইলের মতো (sip:rina@example.com), সাধারণত port 5060 (UDP/TCP) আর TLS-এ 5061. ভেতরে codec আর ঠিকানার প্রস্তাব থাকে SDP-তে। একটি সাধারণ কল:

রিনা                     SIP proxy                    করিম
 │── INVITE (SDP offer) ──►│── INVITE ───────────────────►│
 │◄── 100 Trying ──────────│                              │
 │◄── 180 Ringing ─────────│◄── 180 Ringing ──────────────│  (ফোন বাজছে)
 │◄── 200 OK (SDP answer) ─│◄── 200 OK ───────────────────│  (করিম ধরলেন)
 │── ACK ────────────────────────────────────────────────►│
 │◄═════════════ RTP কণ্ঠ (সরাসরি, proxy ছাড়া) ═════════►│
 │── BYE ────────────────────────────────────────────────►│
 │◄── 200 OK ─────────────────────────────────────────────│

লক্ষ করুন, signalling proxy দিয়ে যায়, কিন্তু কণ্ঠ সরাসরি — রিসেপশন কল জুড়ে দেয়, তারপর কথা আর রিসেপশন দিয়ে যায় না। অফিসের IP-PBX আর মোবাইলের VoLTE-র signalling-এ SIP-এর বিভিন্ন রূপ চলে। SDP-র ভেতরে private ঠিকানা লেখা থাকে বলে NAT-এর পেছনে SIP-এর পুরোনো সমস্যা — পর্ব ১৯-এর NAT traversal দেখুন।

৮ · WebRTC — ব্রাউজারে ব্রাউজারে সরাসরি কল

WebRTC হলো W3C-র JavaScript API আর IETF-এর protocol-সমষ্টি, যা দিয়ে কোনো plugin ছাড়া ব্রাউজার বা অ্যাপ সরাসরি কণ্ঠ, ভিডিও আর ডেটা আদানপ্রদান করে। Google ২০১০ সালে GIPS নামের ভয়েস-প্রযুক্তি কোম্পানি কিনে ২০১১ সালে কোড উন্মুক্ত করে; W3C-র মূল স্পেসিফিকেশন আর IETF-এর মূল RFC-গুলো (RFC 8825 থেকে শুরু) ২০২১ সালে চূড়ান্ত হয়। তিনটি মূল API:

• getUserMedia() — অনুমতি নিয়ে ক্যামেরা আর মাইক্রোফোন খোলা।
• RTCPeerConnection — অন্য peer-এর সাথে সংযোগ: NAT পেরোনো, এনক্রিপশন, codec, jitter buffer, congestion control — সব ভেতরে।
• RTCDataChannel — যেকোনো ডেটা (চ্যাট, ফাইল, খেলার অবস্থা); নির্ভরযোগ্য বা অনির্ভরযোগ্য, ক্রমসহ বা ছাড়া — SCTP-এর ওপর, যা আবার DTLS আর UDP-র ভেতরে।

এনক্রিপশন WebRTC-তে ঐচ্ছিক নয়: মিডিয়া চলে SRTP-তে (RTP-র এনক্রিপ্টেড রূপ), যার চাবি আসে প্রতিটি সংযোগে একটি DTLS handshake থেকে (DTLS-SRTP, RFC 5764). DTLS হলো UDP-র জন্য TLS. প্রতিটি peer-এর certificate নিজের তৈরি — কোনো CA নেই; বিশ্বাস আসে SDP-তে লেখা certificate fingerprint থেকে, অর্থাৎ signalling সার্ভারের সততার ওপর। NAT পেরোতে ব্যবহার হয় ICE, STUN আর TURN — এগুলোর ভেতরের কাজ পর্ব ১৯-এ বিস্তারিত দেখেছেন; এখানে দেখি পুরো কলে তারা কোথায় বসে।

দলের কল — mesh, SFU না MCU

দুজনের কলে সরাসরি পথই সেরা। কিন্তু N জনের মিটিংয়ে? তিনটি নকশা — উপরের ক্যালকুলেটরের অংশ (b) দেখুন, প্রত্যেকে ১.৫ Mbps-এর একটি ভিডিও পাঠান:

• Mesh: প্রত্যেকে প্রত্যেকের সাথে সরাসরি। প্রত্যেককে N − ১টি কপি upload করতে হয় — ৬ জনে ৭.৫ Mbps upload, ১০ জনে ১৩.৫. বাসার সংযোগে upload সাধারণত download-এর চেয়ে কম, আর প্রতিটি কপি আলাদা encode করলে CPU-ও শেষ। ৩–৪ জনের বেশি হলে অচল।
• SFU (Selective Forwarding Unit): প্রত্যেকে একটিমাত্র stream সার্ভারে পাঠায় (upload ১.৫), সার্ভার decode না করে শুধু বেছে বেছে অন্যদের কাছে ফরোয়ার্ড করে (download N − ১ গুণ)। সার্ভারের দিকে ১০ জনে ঢোকে ১৫, বের হয় ১৩৫ Mbps. Simulcast-এ প্রত্যেকে একই ভিডিও ২–৩টি মানে পাঠায়, আর SFU যার সংযোগ দুর্বল তাকে নিচু মানটি দেয়; বাস্তবে শুধু যিনি কথা বলছেন বা পর্দায় দেখা যাচ্ছে তাদের ভিডিওই পাঠানো হয়।
• MCU (Multipoint Control Unit): সার্ভার সব ভিডিও decode করে একটি মিশ্র ছবি বানিয়ে আবার encode করে প্রত্যেককে একটি stream দেয় — client-এর upload আর download দুটোই কম, কিন্তু সার্ভারের CPU-খরচ বিশাল, দেরি বাড়ে, আর end-to-end এনক্রিপশন কঠিন।

মিডিয়ার congestion control

TCP-র loss-ভিত্তিক congestion control (পর্ব ৩২) ভিডিও-কলের জন্য ধীর আর রূঢ় — packet হারানো পর্যন্ত অপেক্ষা করলে ততক্ষণে router-এর queue ভরে delay বেড়ে গেছে। তাই WebRTC-র বাস্তবায়নগুলো delay-ভিত্তিক পদ্ধতি ব্যবহার করে: packet-এর পৌঁছানোর ফাঁক ক্রমে বাড়তে থাকলে queue জমছে ধরে নিয়ে bitrate কমায়। Google-এর প্রস্তাবিত GCC (Google Congestion Control) সবচেয়ে পরিচিত; এটি IETF-এ খসড়া হিসেবে প্রকাশিত হয়েছিল, পূর্ণ মান হয়নি, আর Chrome-এর বর্তমান বাস্তবায়ন সময়ের সাথে বদলেছে। মূল ধারণা মনে রাখুন: মিডিয়ার জন্য queue ভরার আগেই পিছু হটা, আর bitrate কমাতে encoder-কেই বলা — ছবির মান বা frame rate কমিয়ে।

৯ · Live streaming-এর পথ, বাংলাদেশের বাস্তবতা আর গভীরে

একটি live সম্প্রচারের দুই প্রান্ত। Ingest — ক্যামেরা বা encoder থেকে streaming প্ল্যাটফর্মে পাঠানো; Delivery — প্ল্যাটফর্ম থেকে লক্ষ দর্শকের কাছে, সাধারণত HLS/DASH আর CDN দিয়ে (অংশ ৪)।

• RTMP: Macromedia/Adobe-এর Flash যুগের TCP-ভিত্তিক protocol (সাধারণত port 1935). দর্শকের দিকে Flash বিদায় নিয়েছে, কিন্তু ingest-এ RTMP এখনো খুব প্রচলিত — অনেক প্ল্যাটফর্ম আর সম্প্রচার-সফটওয়্যার এটাই নেয়।
• SRT (Secure Reliable Transport): Haivision-এর তৈরি, ২০১৭ সালে উন্মুক্ত; UDP-র ওপর নিজস্ব দ্রুত পুনঃপ্রেরণ, এনক্রিপশন, আর একটি নির্দিষ্ট latency-সীমা — সীমার মধ্যে যা ফেরত আনা যায় আনে, না গেলে ছেড়ে দেয়। অস্থির ইন্টারনেট দিয়ে পেশাদার সম্প্রচারে জনপ্রিয়।
• WebRTC-ভিত্তিক live: নিলাম, অনলাইন খেলা বা দর্শকের সাথে কথোপকথনের অনুষ্ঠানে এক সেকেন্ডের কম দেরি দরকার হলে। Ingest-এর জন্য WHIP আর playback-এর জন্য WHEP নামে HTTP-ভিত্তিক সহজ signalling প্রমিত হয়েছে বা হচ্ছে। দাম: লক্ষ দর্শকের জন্য SFU-র শিকল বানাতে হয়, সাধারণ HTTP CDN-এর মতো সস্তা নয়।

বাংলাদেশের বাস্তবতা

বাংলাদেশে ইন্টারনেট ব্যবহারকারীর বড় অংশ মোবাইল ডেটায় — যেখানে গতি জায়গা ও সময়ভেদে অনেক ওঠানামা করে, আর ডেটা প্যাকের সীমা থাকে। তাই ABR এখানে বিলাসিতা নয়, মূল প্রয়োজন: বাসে চলতে চলতে নাটক দেখার সময় গতি বারবার নামলে নিচু মানে নেমে না থামাই ভালো অভিজ্ঞতা। অনেক অ্যাপ “ডেটা সাশ্রয়” বিকল্পে সর্বোচ্চ মান বেঁধে দেয় — ১০ মিনিট ১০৮০p (ধরুন ৫ Mbps) মানে প্রায় ৩৭৫ MB, আর ৪৮০p (১ Mbps) মানে প্রায় ৭৫ MB. ভয়েস-কলে Opus-এর মতো কম-bitrate codec আর FEC দুর্বল সংকেতে বড় পার্থক্য আনে। দেশের ভেতরের CDN cache আর BDIX-এর মতো স্থানীয় আদানপ্রদান (পর্ব ২৫) জনপ্রিয় ভিডিও কাছে আনতে সাহায্য করে; নির্দিষ্ট পরিসংখ্যান সময়ভেদে বদলায়।

১০ · AI-এর যুগে real-time আর streaming — শেখা আর যাচাই

“একটি ভিডিও-কল অ্যাপ বানিয়ে দিন” — AI কয়েক মিনিটে চলনসই WebRTC কোড দেয়। কিন্তু নেটওয়ার্কের খুঁটিনাটিতে চেনা ভুল আছে:

AI-এর উত্তর বিশ্বাস করার আগে — চেকলিস্ট

• Bandwidth আর buffer-এর হিসাব নিজে আবার করেছি (header-এর বাইট, packet/সেকেন্ড, Q / (r − x))
• RFC নম্বর rfc-editor.org-এ মিলিয়েছি; খসড়া আর পূর্ণ মান আলাদা করেছি (যেমন GCC)
• নিজের দুই যন্ত্রে, আলাদা নেটওয়ার্কে কল পরীক্ষা করেছি, webrtc-internals-এ jitter, loss আর candidate দেখেছি
• শুধু নিজের যন্ত্র আর নেটওয়ার্কের packet capture করেছি; wss:// আর TURN credential নিরাপদ রেখেছি
• Firewall-এ শুধু দরকারি port খুলেছি, আর UDP আটকালে TURN-over-TLS fallback কাজ করে কি না দেখেছি