কন্ট্রিবিউশন প্রোটোকল

গল্পে বুঝি

সিলেটের সুনামগঞ্জে বন্যা। একটা টিভি চ্যানেলের রিপোর্টার কিন্দি একটা চরের স্কুলঘরের ছাদে দাঁড়িয়ে, ঢাকার স্টুডিওতে প্রযোজক মরিয়ম অপেক্ষা করছেন সন্ধ্যার খবরে তাকে সরাসরি নেওয়ার জন্য। কিন্দির হাতে তিনটা উপায়।

প্রথমটা স্কুলের পুরনো ল্যান্ডফোন, যেটা এখনো কোনোভাবে চালু। এই লাইনে প্রতিটা শব্দ নিখুঁতভাবে পৌঁছায়, কারণ লাইনটা নিশ্চিত করে কোনো কিছু হারাবে না: কোনো শব্দ না পৌঁছালে সেটা আবার পাঠায়, আর ততক্ষণ পরের শব্দ আটকে রাখে। ঝড়ের বাতাসে তার একটু নড়লেই মরিয়ম শুনতে পান কিন্দি থেমে গেছেন, তারপর হঠাৎ একসাথে অনেকগুলো শব্দ, আর পুরো কথোপকথন ক্রমশ আরও পিছিয়ে যায়। কিছুই হারায় না, কিন্তু দেরিটা জমতে থাকে, আর কখনো কমে না।

দ্বিতীয়টা কিন্দির মোবাইল ফোন। এখানে নেটওয়ার্ক দুর্বল, কিন্তু কিন্দি আর মরিয়ম একটা নিয়ম ঠিক করে নিয়েছেন: “আমি একটা কথা না শুনলে আধা সেকেন্ডের মধ্যে বলব ‘আবার বলো’, তুমি আবার বলবে। আধা সেকেন্ডের বেশি দেরি হলে বাদ দাও, সামনে এগোও।” ফলে বেশিরভাগ হারানো কথা ফিরে আসে, যেগুলো আসে না সেগুলো ছোট একটা ফাঁক হয়ে থাকে, আর মোট দেরি কখনো আধা সেকেন্ডের বেশি জমে না। তৃতীয়টা একটা স্যাটেলাইট ফোন, যেটা স্টুডিও ধার দিয়েছে; এটা প্রায় তাৎক্ষণিক, কিন্তু হারানো শব্দ কেউ আবার চায় না, শুধু পরের শব্দে চলে যায়, আর এটা চালাতে বিশেষ যন্ত্র আর খরচ লাগে। শেষে মরিয়ম একটা কাজের কথা মনে করিয়ে দেন: “যে লাইনেই আসো, আগে স্টুডিওর পাসওয়ার্ডটা বলবে, নাহলে অন্য কেউ আমাদের খবরে ঢুকে পড়বে।”

মিলিয়ে নিই: ল্যান্ডফোন হলো RTMP, যা চলে TCP-র উপর; কিছু হারায় না, কিন্তু খারাপ নেটওয়ার্কে দেরি জমতে থাকে। মোবাইলের “আধা সেকেন্ডের মধ্যে আবার বলো” নিয়ম হলো SRT: UDP আর ARQ (হারানো প্যাকেট আবার চাওয়া), কিন্তু একটা নির্দিষ্ট latency window-র মধ্যে, তাই দেরি সীমাবদ্ধ থাকে। স্যাটেলাইট ফোন হলো WebRTC / WHIP: প্রায় তাৎক্ষণিক, হারানো জিনিস বেশিরভাগ ক্ষেত্রে বাদ, আর পুরো ব্যবস্থা বেশি জটিল। আর স্টুডিওর পাসওয়ার্ড হলো stream key। বাস্তবে একটা লাইভ প্ল্যাটফর্ম প্রায়ই তিনটাই গ্রহণ করে: সাধারণ স্ট্রিমারদের জন্য RTMP, মাঠ থেকে খারাপ নেটওয়ার্কে SRT, আর ব্রাউজার থেকে সরাসরি লাইভে WHIP।

Contribution প্রোটোকল কী সমস্যা সমাধান করে

আগের চ্যাপ্টারে দেখেছি contribution হলো এনকোডার থেকে আপনার ইনজেস্ট সার্ভার পর্যন্ত পথ। এই পথে একটা স্ট্রিম, একটা গন্তব্য, আর একটা অনিশ্চিত আপলিংক। প্রোটোকল বাছাই আসলে তিনটা প্রশ্নের উত্তর:

1. প্যাকেট হারালে কী হবে? আবার পাঠাবে (দেরি বাড়বে), নাকি বাদ দেবে (ছবিতে দাগ পড়বে)?
2. ব্যান্ডউইথ হঠাৎ কমলে কী হবে? দেরি অসীমভাবে জমবে, নাকি একটা সীমায় থামবে?
3. কোন এনকোডার এটা বলতে পারে, আর কোন ফায়ারওয়াল এটা যেতে দেবে?

ভিডিও ট্র্যাকের লো-লেটেন্সি চ্যাপ্টারে RTMP আর SRT-এর একটা ছোট তুলনা আছে। এই চ্যাপ্টার প্রতিটার ভেতরে যায়, আর প্রতিটা নিজে চালিয়ে দেখায়।

RTMP

RTMP (Real-Time Messaging Protocol) Flash যুগের প্রোটোকল, যা TCP-র উপর চলে আর ভেতরে FLV ফরম্যাটে অডিও-ভিডিও বহন করে। Flash অনেক আগে মারা গেছে, কিন্তু RTMP ingest এখনো সবচেয়ে প্রচলিত, কারণ প্রায় প্রতিটা এনকোডার (OBS, vMix, হার্ডওয়্যার বক্স, মোবাইল অ্যাপ) এটা বলতে পারে, আর প্রায় প্রতিটা প্ল্যাটফর্ম এটা গ্রহণ করে।

একটা RTMP URL-এর দুই অংশ: সার্ভার URL আর stream key।

rtmp://ingest.baytalhikma.org/live      ← server URL (app name "live")
sk_7f3a9c2e                              ← stream key (a secret, like a password)

এনকোডার দুটো জোড়া লাগিয়ে rtmp://ingest.baytalhikma.org/live/sk_7f3a9c2e-তে পাবলিশ করে। স্ট্রিম কী-ই বলে কোন চ্যানেলে যাবে আর এনকোডারকে অনুমতি দেওয়া হবে কিনা, তাই এটা পাসওয়ার্ডের মতো গোপন রাখতে হয়। কিছু সার্ভার (যেমন MediaMTX) কী-কে পাথে না রেখে query প্যারামিটারে নেয়, যেমন rtmp://host/baytalhikma?user=enc&pass=sk_7f3a9c2e; চার নম্বর চ্যাপ্টারে এটা নিজে বানাব।

খারাপ নেটওয়ার্কে RTMP কী করে। যেহেতু TCP, কোনো প্যাকেট হারালে TCP সেটা আবার পাঠায় আর পেছনের সব ডেটা আটকে রাখে (head-of-line blocking)। আর TCP congestion control ব্যান্ডউইথ কম দেখলে পাঠানোর গতি কমায়। এনকোডার কিন্তু একই হারে ভিডিও বানাতেই থাকে, তাই এনকোডারের আউটপুট বাফারে ডেটা জমতে থাকে। OBS তখন একটা সীমার পর ফ্রেম ফেলে দেয় (“dropped frames, network”), নাহলে দেরি অসীমভাবে বাড়ত। ফলাফল: হয় দেরি জমে, নয় ফ্রেম পড়ে, আর দুটো সিদ্ধান্তই এনকোডারের হাতে, সার্ভারের নয়।

RTMPS হলো TLS-এর ভেতরে RTMP, সাধারণত পোর্ট 443-এ। প্লেইন RTMP-তে স্ট্রিম কী নেটওয়ার্কে খোলা অবস্থায় যায়, তাই পাবলিক ইন্টারনেটে RTMPS ব্যবহার করুন। পোর্ট 443 হওয়ায় অফিস বা হোটেলের ফায়ারওয়ালও এটা প্রায়ই আটকায় না, যেখানে 1935 প্রায়ই বন্ধ থাকে।

Enhanced RTMP

ক্লাসিক RTMP-তে কার্যত শুধু H.264 আর AAC যায়। Enhanced RTMP (E-RTMP) এই সীমা ভাঙতে বানানো একটা এক্সটেনশন, যা FLV-তে HEVC, AV1, VP9 আর পরের সংস্করণে Opus ও মাল্টিট্র্যাক যোগ করে। OBS-এর রিলিজ নোট অনুযায়ী 29.1-এ Enhanced RTMP দিয়ে AV1/HEVC স্ট্রিমিং আসে, আর 30.2-এ Enhanced RTMP মাল্টিট্র্যাক অডিও-ভিডিও, যেটা Twitch “Enhanced Broadcasting” নামে ব্যবহার করে (একটা কম্পিউটার থেকে একাধিক রেন্ডিশন পাঠানো)। YouTube-এর লাইভ এনকোডার পেজ RTMP/RTMPS-এ H.264, HEVC আর AV1 তিনটাই গ্রহণ করে বলে উল্লেখ করে। এগুলো ২০২৬ সালের অক্টোবর অনুযায়ী; প্ল্যাটফর্মের সাপোর্ট বদলায়, তাই নিজের টার্গেট প্ল্যাটফর্মের হেল্প পেজে মিলিয়ে নিন।

নিজে চালিয়ে দেখা: ffmpeg থেকে RTMP

ক্যামেরা না থাকলেও ffmpeg-এর testsrc2 দিয়ে একটা চলমান টেস্ট প্যাটার্ন আর sine দিয়ে একটা সুর বানিয়ে লাইভ স্ট্রিম পাঠানো যায়। -re ffmpeg-কে বলে ইনপুট রিয়েল-টাইম গতিতে পড়তে, নাহলে এটা যত দ্রুত পারে পাঠাবে, যা লাইভ নয়।

ffmpeg -re \
  -f lavfi -i testsrc2=size=1280x720:rate=30 \
  -f lavfi -i sine=frequency=440:sample_rate=48000 \
  -c:v libx264 -preset veryfast -tune zerolatency \
  -b:v 2500k -maxrate 2500k -bufsize 2500k \
  -g 60 -keyint_min 60 -sc_threshold 0 \
  -c:a aac -b:a 128k -ar 48000 \
  -f flv "rtmp://127.0.0.1/baytalhikma?user=enc&pass=sk_7f3a9c2e"

এই কমান্ডটা লোকাল একটা MediaMTX সার্ভারে চালিয়ে দেখেছি (সেটআপ চার নম্বর চ্যাপ্টারে)। সার্ভারের লগে স্ট্রিম গ্রহণ এভাবে দেখায়:

INF [RTMP] [conn 127.0.0.1:64686] opened
INF [RTMP] [conn 127.0.0.1:64686] is publishing to path 'baytalhikma', 2 tracks (H264, MPEG-4 Audio)

ভুল কী দিলে সার্ভার সংযোগ ফিরিয়ে দেয়:

INF [RTMP] [conn 127.0.0.1:64682] closed: authentication failed: server replied with code 401

SRT

SRT (Secure Reliable Transport) Haivision-এর বানানো একটা ওপেন-সোর্স প্রোটোকল, যা UDP-র উপর চলে আর নিজেই হারানো প্যাকেট উদ্ধার করে। এর মূল ধারণাটাই গল্পের মোবাইল নিয়ম: একটা নির্দিষ্ট latency-র মধ্যে যতটা সম্ভব উদ্ধার করো, তারপর ছেড়ে দাও।

এটা কীভাবে কাজ করে:

• প্রেরক প্রতিটা প্যাকেটে একটা সিকোয়েন্স নম্বর আর টাইমস্ট্যাম্প দেয়।
• গ্রাহক একটা ফাঁক দেখলে সাথে সাথে NAK (negative acknowledgement) পাঠায়: “৪৫১২ নম্বর পাইনি।”
• প্রেরক নিজের বাফার থেকে সেটা আবার পাঠায়।
• গ্রাহক প্রতিটা প্যাকেট ঠিক latency মিলিসেকেন্ড ধরে রাখে, তারপর সামনে দেয়। এই সময়ের মধ্যে যা উদ্ধার হয়নি, সেটা বাদ (“too late to play”)।

ফলে দেরি সবসময় মোটামুটি latency-র সমান থাকে, নেটওয়ার্ক খারাপ হলেও জমে না। দাম হলো: লস খুব বেশি হলে কিছু প্যাকেট হারায় আর ছবিতে দাগ বা ফ্রিজ দেখা দেয়, আর আবার পাঠানোর জন্য বাড়তি ব্যান্ডউইথ লাগে।

latency প্যারামিটার কীভাবে বেছে নেবেন

latency হলো SRT-এর সবচেয়ে গুরুত্বপূর্ণ সেটিং। প্রচলিত নিয়ম হলো এটা পথের RTT-র কয়েক গুণ রাখা, যাতে একটা প্যাকেট হারালে NAK যেতে আর আবার পাঠানো প্যাকেট আসতে একাধিক সুযোগ থাকে। Haivision-এর গাইড RTT আর প্যাকেট লসের উপর ভিত্তি করে একটা গুণক সুপারিশ করে; সঠিক টেবিলটা ভেন্ডারের ডকসে দেখুন, কারণ মান নেটওয়ার্ক অনুযায়ী আলাদা। একটা আনুমানিক ধারণা:

পথ (উদাহরণ)	RTT মোটামুটি	latency শুরু করার মতো (আনুমানিক)
একই শহরে ফাইবার থেকে VPS	১০-২০ ms	১২০-২০০ ms
ঢাকা থেকে সিঙ্গাপুরের VPS	৫০-৮০ ms	২৫০-৪০০ ms
মোবাইল হটস্পট থেকে বিদেশের সার্ভার	১০০-২৫০ ms	৮০০ ms থেকে কয়েক সেকেন্ড

RTT নিজে মাপুন (ping ingest.baytalhikma.org), তারপর SRT-এর stats দেখে লস আর আবার পাঠানো প্যাকেটের সংখ্যা অনুযায়ী বাড়ান-কমান।

caller, listener, rendezvous

SRT সংযোগে একপক্ষ অপেক্ষা করে, অন্যপক্ষ কল করে:

• listener: একটা পোর্টে অপেক্ষা করে (সাধারণত সার্ভার)।
• caller: listener-এর ঠিকানায় কল করে (সাধারণত এনকোডার)।
• rendezvous: দুই পক্ষই একসাথে একে অন্যকে কল করে; দুই দিকেই NAT থাকলে কাজে লাগে।

সবচেয়ে প্রচলিত বিন্যাস হলো এনকোডার caller, ইনজেস্ট সার্ভার listener, কারণ এনকোডার প্রায় সবসময় কোনো রাউটারের পেছনে থাকে আর সার্ভারের একটা পাবলিক IP থাকে।

streamid আর passphrase

SRT URL-এ RTMP-এর মতো “পাথ” নেই, তাই কোন চ্যানেলে যাবে সেটা যায় streamid প্যারামিটারে। সার্ভার অনুযায়ী এর ফরম্যাট আলাদা। MediaMTX-এর ডকস অনুযায়ী পাবলিশের ফরম্যাট publish:path, আর ইউজারনেম-পাসওয়ার্ড লাগলে publish:path:user:pass:

# Illustrative: this ffmpeg build lacked libsrt, so this exact command was not run here.
ffmpeg -re \
  -f lavfi -i testsrc2=size=1280x720:rate=30 \
  -f lavfi -i sine=frequency=440:sample_rate=48000 \
  -c:v libx264 -preset veryfast -tune zerolatency -b:v 2500k -g 60 \
  -c:a aac -b:a 128k -ar 48000 \
  -f mpegts "srt://ingest.baytalhikma.org:8890?streamid=publish:baytalhikma:enc:sk_7f3a9c2e&pkt_size=1316&latency=400000"

তিনটা জিনিস লক্ষ্য করুন। SRT সাধারণত MPEG-TS বহন করে, FLV নয়। pkt_size=1316 হলো সাতটা 188-বাইটের TS প্যাকেট, যা একটা UDP প্যাকেটে আরামে আঁটে। আর ffmpeg-এর SRT প্রোটোকলে latency মাইক্রোসেকেন্ডে দেওয়া হয় (তাই 400000 মানে 400 ms), যেখানে OBS আর বেশিরভাগ টুলে মিলিসেকেন্ডে; এই একক গুলিয়ে ফেলা খুব সাধারণ ভুল। আপনার ffmpeg বিল্ডে SRT আছে কিনা দেখতে ffmpeg -protocols | grep srt চালান; Homebrew-এর ডিফল্ট বিল্ডসহ অনেক বিল্ডে libsrt থাকে না।

এনক্রিপশনের জন্য দুই পক্ষে একই passphrase (১০ থেকে ৭৯ অক্ষর) দিন; তখন সব প্যাকেট AES দিয়ে এনক্রিপ্টেড হয়। passphrase না মিললে সংযোগ হবেই না, আর অনেক এনকোডারে এররটা খুব অস্পষ্ট দেখায়।

SRT stats পড়া

SRT-এর বড় সুবিধা হলো এটা নিজের অবস্থা জানায়। srt-live-transmit বা সার্ভারের API থেকে যে সংখ্যাগুলো সবচেয়ে বেশি কাজে লাগে (নমুনা, মানগুলো ব্যাখ্যার জন্য):

msRTT:            62.4      round-trip time to the peer
mbpsSendRate:     2.71      what is actually leaving the encoder
pktSndLoss:       184       packets the receiver reported missing
pktRetrans:       181       packets sent again
pktSndDrop:       3         packets given up on (arrived too late to play)
msSndBuf:         395       how much is waiting in the send buffer

pktSndDrop শূন্য নয় মানে কিছু ডেটা চিরতরে হারিয়েছে, আর দর্শক সম্ভবত দাগ বা ফ্রিজ দেখেছে; latency বাড়ান বা বিটরেট কমান। msSndBuf ধীরে ধীরে latency-র কাছে পৌঁছালে আপলিংক বিটরেটের চেয়ে ছোট; বিটরেট কমান।

SRT প্রোটোকলের একটা IETF ইন্টারনেট-ড্রাফট লেখা হয়েছিল, কিন্তু datatracker অনুযায়ী সেটা মেয়াদোত্তীর্ণ, RFC হয়নি (২০২৬ সালের অক্টোবর অনুযায়ী)। মানে SRT একটা ব্যাপক প্রচলিত ওপেন-সোর্স প্রোটোকল, কিন্তু IETF মান নয়; আচরণের চূড়ান্ত সূত্র হলো libsrt-এর ডকস।

WHIP: WebRTC দিয়ে ইনজেস্ট

WebRTC ব্রাউজারের রিয়েল-টাইম অডিও-ভিডিও প্রযুক্তি। সমস্যা ছিল, WebRTC-তে সংযোগ শুরু করার (signaling) কোনো মান ছিল না; প্রতিটা প্ল্যাটফর্ম নিজের মতো WebSocket প্রোটোকল বানাত। WHIP (WebRTC-HTTP Ingestion Protocol) এটা ঠিক করে, আর এটা এখন RFC 9725 (মার্চ ২০২৫, Standards Track)।

পুরো signaling একটা HTTP রিকোয়েস্ট:

RFC অনুযায়ী: এনকোডার application/sdp টাইপে একটা SDP offer POST করে, সার্ভার 201 Created, SDP answer আর একটা Location হেডার (সেশনের URL) ফেরত দেয়। এরপর ICE আর DTLS হয়ে মিডিয়া এক দিকে চলে। নতুন ICE candidate পাঠানো যায় সেশন URL-এ PATCH দিয়ে, আর শেষ করতে সেশন URL-এ DELETE। অথেন্টিকেশনের জন্য প্রতিটা WHIP ইমপ্লিমেন্টেশনকে Bearer token সাপোর্ট করতেই হবে।

WHIP-এর দুটো বড় সুবিধা: ব্রাউজার থেকেই লাইভ (কোনো সফটওয়্যার ইনস্টল ছাড়া, শুধু একটা ওয়েব পেজ থেকে), আর সাব-সেকেন্ড contribution, যা রিমোট অতিথি বা ইন্টারঅ্যাক্টিভ শো-র জন্য জরুরি। দাম হলো: WebRTC-র কোডেক সীমিত (H.264, VP8, VP9, AV1, অডিওতে Opus; AAC নয়), B-frame সাধারণত বন্ধ রাখতে হয়, আর UDP পোর্ট খোলা লাগে।

নিজে চালিয়ে দেখা: ffmpeg থেকে WHIP

নতুন ffmpeg-এ একটা whip মাক্সার আছে (ffmpeg -h muxer=whip দিয়ে দেখুন আপনার বিল্ডে আছে কিনা)। এই কমান্ডটা লোকাল MediaMTX-এ আসলেই চালিয়েছি:

ffmpeg -re \
  -f lavfi -i testsrc2=size=1280x720:rate=30 \
  -f lavfi -i sine=frequency=440:sample_rate=48000 \
  -c:v libx264 -preset veryfast -tune zerolatency -bf 0 -g 60 -b:v 2500k \
  -c:a libopus -b:a 96k -ar 48000 -ac 2 \
  -authorization "enc:sk_7f3a9c2e" \
  -f whip "http://127.0.0.1:8889/baytalhikma/whip"

ffmpeg সংযোগের প্রতিটা ধাপের সময় জানায় (আসল আউটপুট, ছোট করা):

[WHIP muxer] Muxer state=10, ... elapsed=1037.29ms(init:13.06,offer:0.13,answer:11.47,udp:0.27,ice:11.90,dtls:1000.18,srtp:0.16)

আর সার্ভারের দিকে:

INF [WebRTC] [session 809355d4] created by 127.0.0.1:64902
INF [WebRTC] [session 809355d4] peer connection established, local candidate: host/udp/127.0.0.1/8189, ...
INF [WebRTC] [session 809355d4] is publishing to path 'baytalhikma', 2 tracks (Opus, H264)

লক্ষ্য করুন অডিও কোডেক libopus, AAC নয়, কারণ WebRTC AAC বহন করে না। আর -authorization-এর মান Bearer token হিসেবে যায়; MediaMTX-এর ডকস অনুযায়ী এটা user:pass আকারে দিলে সার্ভার সেটাকে ইউজারনেম-পাসওয়ার্ড হিসেবে পড়ে। একটা লোকাল পরীক্ষায় শুধু DTLS ধাপেই প্রায় এক সেকেন্ড গেছে; মানে WHIP সংযোগ শুরু হতে একটু সময় নেয়, কিন্তু একবার চালু হলে মিডিয়া প্রায় তাৎক্ষণিক যায়।

RIST ও RTSP, সংক্ষেপে

RIST (Reliable Internet Stream Transport) সম্প্রচার শিল্পের একটা খোলা মান (VSF), কাজের দিক থেকে SRT-এর মতো: UDP, ARQ, নির্দিষ্ট latency। টিভি চ্যানেল আর সম্প্রচার হার্ডওয়্যারে বেশি দেখা যায়; OBS 28 থেকে এর নেটিভ আউটপুট আছে। নিজের প্ল্যাটফর্মে শুরু করলে SRT-এর টুলিং বেশি সহজলভ্য।

RTSP সাধারণত ইনজেস্ট প্রোটোকল নয়, বরং IP ক্যামেরা আর CCTV-র ভাষা। ক্যামেরা নিজে একটা RTSP সার্ভার চালায় (rtsp://192.0.2.40:554/stream1), আর আপনার সার্ভার সেখান থেকে টেনে আনে (pull), এনকোডার যেমন ঠেলে পাঠায় (push) তার উল্টো। একটা মসজিদ বা দোকানের ক্যামেরা লাইভ করতে হলে সাধারণত এই পথ: ক্যামেরার RTSP থেকে MediaMTX টেনে আনে, তারপর HLS বা WebRTC-তে দর্শকের কাছে দেয়। ক্যামেরাকে পাবলিক ইন্টারনেটে খোলা রাখা ঝুঁকিপূর্ণ; সার্ভার আর ক্যামেরা একই প্রাইভেট নেটওয়ার্কে বা VPN-এ রাখুন।

তুলনা ও বাছাই

দিক	RTMP / RTMPS	SRT	WHIP (WebRTC)	RIST
ট্রান্সপোর্ট	TCP	UDP + ARQ	UDP (ICE, DTLS, SRTP)	UDP + ARQ
প্যাকেট লসে	আবার পাঠায়, দেরি জমে	latency-র মধ্যে উদ্ধার, বাকি বাদ	মূলত বাদ, কিছু উদ্ধার	SRT-এর মতো
সাধারণ contribution দেরি	কয়েক সেকেন্ড পর্যন্ত, ওঠানামা করে	যা latency দেবেন, মোটামুটি স্থির	এক সেকেন্ডের নিচে	কনফিগার অনুযায়ী
কোডেক	H.264/AAC; Enhanced হলে HEVC, AV1	কার্যত যেকোনো (MPEG-TS-এ যা আঁটে)	H.264, VP8, VP9, AV1; অডিও Opus	যেকোনো
এনক্রিপশন	RTMPS (TLS) হলে	passphrase দিলে AES	সবসময় (DTLS-SRTP)	ঐচ্ছিক
ফায়ারওয়াল	RTMPS 443-এ প্রায় সবখানে চলে	UDP পোর্ট খোলা লাগে	UDP খোলা লাগে, নাহলে TURN	UDP খোলা লাগে
এনকোডার সাপোর্ট	প্রায় সবখানে	OBS, vMix, অনেক হার্ডওয়্যার	OBS 30+, ব্রাউজার, নতুন ffmpeg	সম্প্রচার যন্ত্র, OBS

বাছাইয়ের একটা সহজ নিয়ম:

• সাধারণ স্ট্রিমার, স্থির ব্রডব্যান্ড: RTMPS। সব এনকোডারে চলে, ফায়ারওয়াল বন্ধুসুলভ।
• মাঠ, মোবাইল নেটওয়ার্ক, বিদেশের সার্ভার, প্যাকেট লস: SRT। দেরি নিয়ন্ত্রণে থাকে।
• ব্রাউজার থেকে লাইভ, রিমোট অতিথি, সাব-সেকেন্ড দরকার: WHIP।
• IP ক্যামেরা: RTSP pull।

একটা প্ল্যাটফর্ম সাধারণত সবগুলো গ্রহণ করে আর ভেতরে একটা অভিন্ন রূপে (যেমন একটা MediaMTX পাথ) নিয়ে আসে, যাতে পরের ধাপগুলো জানতেই না পারে স্ট্রিম কোন পথে এসেছে।

OBS-এ প্রতিটা সেট করা

OBS-এর রিলিজ নোট অনুযায়ী নেটিভ SRT ও RIST আউটপুট আসে 28-এ, Enhanced RTMP দিয়ে HEVC/AV1 29.1-এ, WHIP 30-এ, আর মাল্টিট্র্যাক ভিডিও 30.2-এ (২০২৬ সালের অক্টোবর অনুযায়ী সর্বশেষ রিলিজ 33.0)। মেনুর নাম ভার্সন অনুযায়ী একটু বদলায়।

RTMP / RTMPS: Settings → Stream → Service: Custom। Server-এ rtmps://ingest.baytalhikma.org/live, Stream Key-তে আপনার কী। Twitch বা YouTube হলে Service থেকে সেটা বেছে নিন, OBS নিজে সঠিক সার্ভার দেয়।

SRT: Service Custom, Server-এ পুরো SRT URL, Stream Key খালি:

srt://ingest.baytalhikma.org:8890?streamid=publish:baytalhikma:enc:sk_7f3a9c2e&latency=400000&pkt_size=1316

OBS এখানেও ffmpeg-এর SRT প্রোটোকল ব্যবহার করে, তাই latency মাইক্রোসেকেন্ডে; আপনার OBS ভার্সনের ডকসে একবার মিলিয়ে নিন।

WHIP: Service-এ WHIP বেছে নিন, Server-এ https://ingest.baytalhikma.org/baytalhikma/whip, আর Bearer Token-এ টোকেন। Settings → Output-এ এনকোডারে B-frame শূন্য রাখুন; অডিও OBS নিজে Opus-এ করে।

ডিবাগিং: এই চ্যাপ্টারের সমস্যাগুলো

লক্ষণ	নিশ্চিত হবেন কীভাবে	সমাধান
OBS “Failed to connect to server” (RTMP)	nc -vz ingest.baytalhikma.org 1935 বা 443; সার্ভারের লগে কোনো সংযোগ এসেছে কিনা	পোর্ট বন্ধ থাকলে RTMPS 443-এ যান; URL-এ app নাম (/live) আর কী আলাদা ঘরে দিয়েছেন কিনা দেখুন
এনকোডার “লাইভ” দেখায় কিন্তু প্লেয়ারে কিছু নেই	সার্ভারের লগ বা API-তে স্ট্রিম পাবলিশ হয়েছে কিনা দেখুন; ffmpeg exit code 0 ভরসা নয়	কী ভুল বা মেয়াদোত্তীর্ণ; সার্ভারের দিক থেকে “is publishing” লাইন দেখে নিশ্চিত হন
RTMP-তে দেরি সময়ের সাথে বাড়ে, তারপর OBS-এ dropped frames (network)	OBS stats-এ “Dropped Frames (Network)” বাড়ছে; ping দিয়ে RTT আর লস দেখুন	আপলিংক বিটরেটের চেয়ে ছোট; বিটরেট কমান বা SRT-এ যান (চ্যাপ্টার ৩)
SRT সংযোগ হয় না, এরর অস্পষ্ট	দুই পক্ষের passphrase আর mode (caller/listener) মেলান; সার্ভারে tcpdump -n udp port 8890 দিয়ে প্যাকেট আসছে কিনা	passphrase মেলান; UDP পোর্ট খুলুন; caller বনাম listener ঠিক করুন
SRT-এ ছবিতে দাগ বা থেমে যাওয়া	SRT stats-এ pktSndDrop বা গ্রাহকের দিকে too-late drop বাড়ছে	latency বাড়ান (RTT-র কয়েক গুণ), বা বিটরেট কমান
SRT latency খুব বেশি বা খুব কম মনে হচ্ছে	কমান্ডে latency=400 দিয়েছেন কিনা দেখুন; ffmpeg-এ এটা মাইক্রোসেকেন্ড	ffmpeg ও OBS-এ মাইক্রোসেকেন্ড (400000), অন্য টুলে মিলিসেকেন্ড; ডকস মিলিয়ে নিন
Protocol not found (srt)	ffmpeg -protocols \| grep srt	libsrt সহ ffmpeg বিল্ড ইনস্টল করুন
WHIP POST 401	curl -i -X POST -H "Content-Type: application/sdp" -H "Authorization: Bearer ..." URL দিয়ে রেসপন্স দেখুন	টোকেন বা user:pass ফরম্যাট ঠিক করুন
WHIP POST 201 কিন্তু মিডিয়া আসে না	সার্ভার লগে “peer connection established” আছে কিনা; ICE candidate কোন IP দেখাচ্ছে	সার্ভারের UDP পোর্ট খুলুন; NAT-এর পেছনে থাকলে সার্ভারে পাবলিক IP সেট করুন বা TURN দিন (চ্যাপ্টার ৪)
WHIP-এ অডিও নেই	এনকোডার AAC পাঠাচ্ছে কিনা	WebRTC-তে Opus লাগে
HEVC বা AV1 পাঠালে সার্ভার রিজেক্ট করে	সার্ভার লগে কোডেক এরর	সার্ভার Enhanced RTMP সাপোর্ট করে কিনা দেখুন, নাহলে H.264-এ ফিরুন

মূল শিক্ষা

1. RTMP সবখানে চলে, কিন্তু TCP-র কারণে খারাপ নেটওয়ার্কে দেরি জমে। পাবলিক ইন্টারনেটে RTMPS ব্যবহার করুন।
2. Enhanced RTMP পুরনো প্রোটোকলে HEVC, AV1 আর মাল্টিট্র্যাক আনে, তবে প্ল্যাটফর্ম আর সার্ভার দুটোকেই সাপোর্ট করতে হবে।
3. SRT একটা নির্দিষ্ট latency-র মধ্যে হারানো প্যাকেট উদ্ধার করে, তারপর ছেড়ে দেয়, তাই দেরি জমে না। latency RTT-র কয়েক গুণ রাখুন, আর এককটা খেয়াল করুন।
4. WHIP (RFC 9725) WebRTC ইনজেস্টকে একটা HTTP POST বানিয়েছে, যা ব্রাউজার থেকে সাব-সেকেন্ড লাইভ সম্ভব করে; অডিও Opus, B-frame বন্ধ।
5. RTSP ইনজেস্ট নয়, ক্যামেরা থেকে টেনে আনা। ক্যামেরাকে পাবলিক ইন্টারনেটে খোলা রাখবেন না।
6. স্ট্রিম কী একটা পাসওয়ার্ড। এনক্রিপ্টেড পথে পাঠান, আর পৌঁছেছে কিনা সবসময় সার্ভারের দিক থেকে যাচাই করুন।
7. একটা প্ল্যাটফর্ম সব প্রোটোকল গ্রহণ করে ভেতরে এক রূপে নিয়ে আসে, যাতে পরের ধাপগুলো উৎসের প্রোটোকল নিয়ে না ভাবে।