লাইভ এনকোডার সেটিংস

গল্পে বুঝি

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

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

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

মিলিয়ে নিই: খোয়ারিজমির স্থির তাল হলো CBR (constant bitrate), আর একা মঞ্চে ইচ্ছামতো বাজানো হলো VOD-এর CRF / VBR। সরু রাস্তা হলো এনকোডারের আপলিংক। প্রতি চার কদমে নির্দিষ্ট জায়গায় “ধা” হলো নির্দিষ্ট keyframe interval, আর শুধু “ধা”-তে মাঝপথে যোগ দেওয়া হলো প্লেয়ারের ABR সুইচ বা নতুন দর্শকের শুরু, যা শুধু keyframe-এ সম্ভব। পরের বোল আগে ভেবে নেওয়া হলো lookahead আর B-frame, যা মান বাড়ায় কিন্তু দেরি যোগ করে, তাই লাইভে কম বা বন্ধ (tune zerolatency)। আর ফারাবির “পুরো রাস্তা ভরো না” হলো আপলোড স্পিডের হেডরুম। বাস্তবে একটা লাইভ এনকোডার ঠিকমতো সেট করা মানে ঠিক এই চারটা সিদ্ধান্ত নেওয়া।

লাইভ এনকোডার কেন আলাদা

ভিডিও ট্র্যাকে কোডেক আর rate control কীভাবে কাজ করে তা আছে। লাইভে একই এনকোডার ব্যবহার হয়, কিন্তু প্রায় প্রতিটা সিদ্ধান্ত উল্টে যায়, কারণ তিনটা বাধ্যবাধকতা:

1. রিয়েল-টাইম: এনকোডারকে প্রতি সেকেন্ডে এক সেকেন্ডের ভিডিও বানাতেই হবে, প্রতিটা সেকেন্ডে।
2. সীমিত আপলিংক: এনকোডারের আউটপুট একটা নির্দিষ্ট আপলোড পাইপ দিয়ে যায়, যা হঠাৎ বেশি ডেটা নিতে পারে না।
3. পরের ধাপের ছন্দ: ট্রান্সকোডার আর প্যাকেজার keyframe ধরে সেগমেন্ট কাটে, তাই keyframe নির্দিষ্ট ছন্দে আসতে হবে।

সেটিং	VOD-এ সাধারণত	লাইভে সাধারণত	কেন
Rate control	CRF বা 2-pass VBR	CBR বা কড়া সীমার VBR	আপলিংক হঠাৎ বেশি নিতে পারে না
Keyframe	scene change-এ, লম্বা GOP	নির্দিষ্ট, সাধারণত ২ সেকেন্ড পরপর	সেগমেন্ট আর ABR সুইচ keyframe-এ
Preset	slow, veryslow	veryfast, faster বা হার্ডওয়্যার	রিয়েল-টাইমের নিচে থাকতে হবে
Lookahead	বড়	ছোট বা বন্ধ	প্রতিটা lookahead ফ্রেম দেরি যোগ করে
B-frame	অনেক	কম (০-২)	দেরি আর WebRTC সামঞ্জস্য
Pass	2-pass	1-pass	পুরো ভিডিও আগে দেখার সুযোগ নেই

Rate control: কেন CBR

VOD-এ CRF প্রায় সবসময় সেরা পছন্দ: আপনি একটা মান ঠিক করেন, এনকোডার যতটা বিটরেট লাগে নেয়। সহজ দৃশ্যে কম, কঠিন দৃশ্যে বেশি। লাইভে ঠিক এই “কঠিন দৃশ্যে বেশি” জিনিসটাই সমস্যা।

এটা নিজে মেপে দেখেছি। একটা ১০ সেকেন্ডের টেস্ট ভিডিও, যার ৪ থেকে ৭ সেকেন্ডে ভারী নয়েজ (ভিড়, বৃষ্টি, পাতার নড়াচড়া, কনফেটি, যেকোনো জটিল দৃশ্যের মতো), একবার CRF দিয়ে আর একবার CBR দিয়ে এনকোড করে প্রতি সেকেন্ডের বিটরেট:

SRC="testsrc2=size=1280x720:rate=30,noise=alls=60:allf=t+u:enable='between(t,4,7)'"

# VOD-style: constant quality
ffmpeg -f lavfi -i "$SRC" -t 10 -c:v libx264 -preset veryfast -crf 23 -f mpegts crf.ts

# Live-style: constant bitrate, fixed 2 s keyframes
ffmpeg -f lavfi -i "$SRC" -t 10 -c:v libx264 -preset veryfast -tune zerolatency \
  -b:v 3000k -maxrate 3000k -bufsize 3000k \
  -g 60 -keyint_min 60 -sc_threshold 0 -x264-params nal-hrd=cbr \
  -f mpegts cbr.ts

second:   0     1     2     3     4      5      6      7     8
CRF 23:  2.5M  2.7M  2.9M  2.9M  62.5M  67.2M  67.4M  9.4M  2.6M
CBR 3M:  3.2M  3.1M  3.2M  3.1M  4.2M   2.9M   3.0M   1.5M  2.6M

(আসল আউটপুট, ffprobe দিয়ে প্যাকেটের আকার যোগ করে।) কঠিন দৃশ্যে CRF তিন মেগাবিট থেকে লাফিয়ে ৬৭ মেগাবিট প্রতি সেকেন্ডে উঠেছে, বাইশ গুণ। VOD ফাইলে এটা কোনো সমস্যা নয়। কিন্তু যদি আপনার আপলোড স্পিড ১০ Mbps হয়, তাহলে লাইভে ওই তিন সেকেন্ডের ডেটা পাঠাতে প্রায় বিশ সেকেন্ড লাগবে, আর স্ট্রিম ততক্ষণে ভেঙে পড়েছে। CBR একই দৃশ্যে ৩ Mbps-এর কাছেই থেকেছে; মান সাময়িকভাবে খারাপ হয়েছে (নয়েজ ঝাপসা), কিন্তু স্ট্রিম চলেছে।

এটাই লাইভের ট্রেড-অফ: জটিল দৃশ্যে মান কমবে, কিন্তু বিটরেট নয়। দর্শক কয়েক সেকেন্ড ঝাপসা মেনে নেয়, থেমে যাওয়া মেনে নেয় না।

তিনটা প্যারামিটার একসাথে কাজ করে:

• -b:v: গড় লক্ষ্য বিটরেট।
• -maxrate: সর্বোচ্চ সীমা। CBR-এ -b:v-এর সমান।
• -bufsize: কতটা সময় জুড়ে গড় মাপা হবে (VBV বাফার)। -b:v-এর সমান মানে “যেকোনো এক সেকেন্ডে সীমা ছাড়াবে না”; বড় দিলে এনকোডার ছোট সময়ের জন্য বেশি নিতে পারে। লাইভে ১ থেকে ২ সেকেন্ডের সমান রাখা প্রচলিত।

Keyframe interval

বিটরেট ল্যাডার চ্যাপ্টারে দেখেছি সব রেন্ডিশনে keyframe একই জায়গায় থাকলে তবেই প্লেয়ার মসৃণভাবে কোয়ালিটি বদলাতে পারে। লাইভে আরও দুটো কারণ যোগ হয়:

• প্যাকেজার keyframe-এ সেগমেন্ট কাটে। ২ সেকেন্ডের সেগমেন্ট চাইলে কমপক্ষে প্রতি ২ সেকেন্ডে একটা keyframe লাগবে।
• নতুন দর্শক শুধু keyframe থেকে শুরু করতে পারে। keyframe ১০ সেকেন্ড পরপর হলে কেউ ঢুকলে প্রথম ছবি দেখতে গড়ে কয়েক সেকেন্ড অপেক্ষা।

প্রচলিত মান ২ সেকেন্ড। YouTube-এর লাইভ এনকোডার পেজও ২ সেকেন্ড সুপারিশ করে আর ৪ সেকেন্ডের বেশি না রাখতে বলে (২০২৬ সালের অক্টোবর অনুযায়ী)। ffmpeg-এ এটা ফ্রেমে দিতে হয়: ৩০ fps-এ ২ সেকেন্ড মানে -g 60।

-g 60              keyframe at most every 60 frames
-keyint_min 60     and no sooner
-sc_threshold 0    never insert an extra keyframe on scene change

শেষেরটা গুরুত্বপূর্ণ। x264 নিজে থেকে দৃশ্য বদলালে একটা বাড়তি keyframe বসায় (scenecut)। VOD-এ এটা ভালো, লাইভে এটা ছন্দ ভাঙে: সেগমেন্টগুলো অসমান হয়, আর রেন্ডিশনগুলোর keyframe আর মেলে না। উপরের পরীক্ষায় keyframe কোথায় পড়েছে:

CRF (default x264): keyframes at 0.1 s, 7.1 s          ← scene change, irregular
CBR (-g 60, sc 0):  keyframes at 0.0, 2.0, 4.0, 6.0, 8.0 ← every 2 s exactly

নিজের স্ট্রিম যাচাই করতে:

ffprobe -v error -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 input.ts \
  | awk -F, '$2 ~ /K/ {print $1}'

OBS-এ এটা সেকেন্ডে দেওয়া হয়: Settings → Output → Streaming → Keyframe Interval: 2 s। ডিফল্ট 0 মানে “এনকোডার নিজে ঠিক করবে”, যা প্রায়ই অনেক লম্বা হয়; এটা অবশ্যই বদলান।

B-frame, lookahead আর tune zerolatency

B-frame আগের আর পরের ফ্রেম দুটো থেকেই prediction করে, তাই এনকোডারকে পরের ফ্রেম পর্যন্ত অপেক্ষা করতে হয়, আর ডিকোডারকে ফ্রেমগুলো ক্রম বদলে পেতে হয়। প্রতিটা B-frame মোটামুটি এক ফ্রেম দেরি যোগ করে। ২০-৩০ সেকেন্ডের HLS-এ এটা নগণ্য; সাব-সেকেন্ড WebRTC-তে এটা বড়, আর অনেক WebRTC ইমপ্লিমেন্টেশন B-frame গ্রহণই করে না।

Lookahead এনকোডারকে সামনের কয়েক ডজন ফ্রেম দেখে বিটরেট বণ্টন করতে দেয়। x264-এর ডিফল্ট rc-lookahead কয়েক ডজন ফ্রেম, যা ৩০ fps-এ এক সেকেন্ডের বেশি দেরি।

x264-এর -tune zerolatency একসাথে এগুলো বন্ধ বা ছোট করে: B-frame বন্ধ, lookahead বন্ধ, mbtree বন্ধ, আর sliced threads চালু (একটা ফ্রেম অনেক থ্রেডে ভাগ করে এনকোড, ফ্রেম জমিয়ে নয়)। দাম হলো একই বিটরেটে মান কিছুটা কম।

কোনটা কখন:

• স্ট্যান্ডার্ড HLS (১৫ সেকেন্ডের বেশি): zerolatency লাগবে না। ২টা B-frame রাখুন; YouTube-এর পেজও ২টা B-frame লেখে। মান ভালো হবে।
• লো লেটেন্সি (২-৫ সেকেন্ড): B-frame ০ থেকে ২, lookahead ছোট।
• WebRTC / WHIP: zerolatency, B-frame ০।

Preset ও হার্ডওয়্যার এনকোডার

x264-এর preset এনকোডারকে বলে প্রতি ফ্রেমে কতটা খাটবে। ধীর preset মানে একই বিটরেটে ভালো মান, কিন্তু বেশি CPU। লাইভে শর্ত একটাই: এনকোডিং গতি ১x-এর উপরে, যথেষ্ট হেডরুম সহ, যাতে ক্যামেরার একটা জটিল মুহূর্তে বা ব্যাকগ্রাউন্ডে অন্য কিছু চললে পিছিয়ে না পড়ে।

একটা Apple M-সিরিজ ল্যাপটপে ১০৮০p৩০, ৬ Mbps, শুধু এনকোডিংয়ের গতি (আসল মাপ, -f null দিয়ে; আপনার মেশিনে আলাদা হবে):

libx264 -preset veryfast     speed=15.3x
libx264 -preset slow         speed=4.03x
h264_videotoolbox            speed=6.21x

একটা স্ট্রিমের জন্য তিনটাই যথেষ্ট দ্রুত। কিন্তু OBS একই সময়ে সিন কম্পোজ করছে, ক্যামেরা ডিকোড করছে, হয়তো একটা গেম চলছে; আর একটা পুরনো ল্যাপটপে slow সহজেই ১x-এর নিচে নামে। নিয়ম: যে preset-এ CPU ব্যবহার মোটামুটি অর্ধেকের নিচে থাকে, সেটা নিন।

হার্ডওয়্যার এনকোডার CPU-কে মুক্ত রাখে:

এনকোডার	কোথায়	ffmpeg-এ	OBS-এ
NVENC	NVIDIA GPU	h264_nvenc, hevc_nvenc, av1_nvenc	NVIDIA NVENC H.264 / HEVC / AV1
Quick Sync (QSV)	Intel CPU-র ভেতরের GPU	h264_qsv, hevc_qsv	QuickSync H.264
AMF	AMD GPU	h264_amf	AMD HW H.264
VideoToolbox	macOS (Apple Silicon/Intel)	h264_videotoolbox, hevc_videotoolbox	Apple VT H264 Hardware Encoder

নতুন প্রজন্মের হার্ডওয়্যার এনকোডার (বিশেষত সাম্প্রতিক NVENC) অনেক ক্ষেত্রে x264 veryfast-এর কাছাকাছি বা ভালো মান দেয়, কোনো CPU খরচ ছাড়া। কোন জেনারেশন কতটা ভালো, সেটা দ্রুত বদলায়; নিজের কনটেন্টে পাশাপাশি এনকোড করে চোখে বা VMAF দিয়ে তুলনা করুন (কোয়ালিটি চ্যাপ্টার)।

রেজোলিউশন, ফ্রেম রেট ও অডিও

রেজোলিউশন বিটরেটের সাথে মিলিয়ে। কম বিটরেটে বেশি রেজোলিউশন দিলে প্রতিটা পিক্সেলের জন্য কম বিট থাকে, ছবি ব্লকি হয়। ৩ Mbps-এ ১০৮০p৩০-এর চেয়ে ৭২০p৩০ সাধারণত পরিষ্কার দেখায়।

ফ্রেম রেট বিষয় অনুযায়ী। ওয়াজ, আলোচনা, ক্লাসে ৩০ fps যথেষ্ট; খেলা আর গেমে ৬০ fps মসৃণ, কিন্তু একই রেজোলিউশনে উল্লেখযোগ্য বেশি বিটরেট লাগে। বাংলাদেশে বিদ্যুতের ফ্রিকোয়েন্সি ৫০ Hz, তাই ঘরের ভেতরে টিউবলাইট বা LED-এর নিচে ৩০ বা ৬০ fps-এ কখনো আলো ঝিকমিক (flicker) করে; ক্যামেরায় শাটার ১/৫০ বা ১/১০০ করলে বা ২৫/৫০ fps-এ গেলে কমে।

অডিও কখনো অবহেলা করবেন না। দর্শক খারাপ ছবি অনেকক্ষণ সহ্য করে, খারাপ শব্দ কয়েক সেকেন্ডও না। প্রচলিত সেটিং AAC-LC, স্টেরিও, ১২৮ থেকে ১৬০ kbps। YouTube-এর পেজ স্টেরিওর জন্য ৪৪.১ kHz আর ১২৮ kbps লেখে; অনেক প্ল্যাটফর্ম ও ভিডিও পাইপলাইন ৪৮ kHz ব্যবহার করে। যেটাই নিন, পুরো চেইনে একই রাখুন, নাহলে মাঝপথে রিস্যাম্পলিং হয় আর কখনো ধীরে ধীরে অডিও-ভিডিও সিঙ্ক সরে যায়। WebRTC/WHIP হলে অডিও Opus।

প্ল্যাটফর্মের সুপারিশ

YouTube-এর লাইভ এনকোডার পেজের H.264 টেবিল থেকে কয়েকটা সারি (২০২৬ সালের অক্টোবর অনুযায়ী; পেজটা নিয়মিত বদলায়, স্ট্রিম করার আগে সেখানে মিলিয়ে নিন):

ইনজেস্ট	সর্বনিম্ন	সুপারিশকৃত
১০৮০p, ৬০ fps	৬ Mbps	১৭ Mbps
১০৮০p, ৩০ fps	৫ Mbps	১৪ Mbps
৭২০p, ৬০ fps	৩ Mbps	৮ Mbps
৭২০p, ৩০ fps	৩ Mbps	৮ Mbps
৪৮০p, ৩০ fps	০.৪ Mbps	৪ Mbps

একই পেজ CBR, ২ সেকেন্ডের keyframe, ২টা B-frame আর Rec. 709 রঙ লেখে। Twitch-এর নিজস্ব সীমা আর সুপারিশ আছে, যা Twitch-এর হেল্প সেন্টারের “Broadcasting Guidelines” পেজে দেখুন; সেটা এই লেখার সময় যাচাই করা যায়নি, তাই এখানে সংখ্যা দেওয়া হলো না। নিজের প্ল্যাটফর্মে আপনার ট্রান্সকোডার যতটা বিটরেট থেকে ভালো ল্যাডার বানাতে পারে, সেটাই আসল সীমা।

আপলোড স্পিড থেকে বিটরেট

সব কিছুর উপরে আসল সীমা হলো এনকোডারের আপলোড স্পিড। একটা প্রচলিত রুল অফ থাম্ব: মোট বিটরেট (ভিডিও আর অডিও মিলে) মাপা আপলোড স্পিডের মোটামুটি ৭০ ভাগের বেশি নয়। বাকিটা হেডরুম, কারণ আপলোড স্পিড স্থির থাকে না, আর একই লাইনে অন্য কেউ কিছু আপলোড করলে, বা কেউ ভিডিও কল করলে, সেটা মুহূর্তেই কমে।

একটা উদাহরণ (হিসাবটা ব্যাখ্যার জন্য):

measured upload (median of several tests)   8.0 Mbps
× 0.7 headroom                              5.6 Mbps budget
− audio 160 kbps                            5.4 Mbps for video
→ 720p30 at about 4.5 to 5 Mbps is comfortable; 1080p30 at 5.4 Mbps is borderline

বাংলাদেশে এই হিসাব বিশেষ জরুরি, কয়েকটা বাস্তব কারণে:

• অনেক ব্রডব্যান্ড প্যাকেজে আপলোড আর ডাউনলোড আলাদা হতে পারে। প্যাকেজের “৫০ Mbps” দেখে আপলোড ধরবেন না; নিজে মাপুন।
• সন্ধ্যার পিক আওয়ারে স্পিড কমে। স্পিড টেস্ট দুপুরে করে রাতের ওয়াজ লাইভ করলে হিসাব মিলবে না; যে সময়ে লাইভ হবে, সেই সময়ে কয়েক দিন মাপুন।
• মোবাইল হটস্পটে আপলোড কয়েক সেকেন্ডের মধ্যে অনেক ওঠানামা করে, আর ভিড়ের জায়গায় (মাহফিল, খেলার মাঠ, মেলা) টাওয়ার ভরে গেলে প্রায় শূন্যে নামতে পারে। সেখানে বিটরেট কম রাখুন, SRT ব্যবহার করুন (আগের চ্যাপ্টার), আর সম্ভব হলে দুটো আলাদা অপারেটরের সংযোগ রাখুন (চ্যাপ্টার ৯)।
• Wi-Fi নয়, তার। একই রাউটারে ল্যাপটপ তার দিয়ে লাগালে আপলোড অনেক বেশি স্থির হয়।

আপলোড স্পিড মাপতে ব্রাউজারের স্পিড টেস্ট যথেষ্ট, কিন্তু যে সার্ভারে ইনজেস্ট করবেন তার কাছাকাছি একটা সার্ভার বেছে নিন। নিজের VPS থাকলে iperf3 দিয়ে সরাসরি সেখানে মাপুন:

# On the ingest VPS
iperf3 -s

# On the encoder machine: send for 30 s, report each second
iperf3 -c ingest.baytalhikma.org -t 30 -i 1

গড় নয়, সবচেয়ে খারাপ কয়েক সেকেন্ড দেখুন; লাইভ ভাঙে সেখানেই।

OBS-এর stats প্যানেল পড়া

OBS-এর View → Stats (বা Docks → Stats) লাইভ চলাকালীন এনকোডারের সবচেয়ে সৎ রিপোর্ট। তিন ধরনের ড্রপ আলাদা করে দেখায়, আর প্রতিটার কারণ আলাদা:

কাউন্টার	মানে	সমাধান
Frames missed due to rendering lag	GPU সিন সময়মতো বানাতে পারছে না	সিনে সোর্স কমান, ব্রাউজার সোর্স বা ফিল্টার কমান, গেমের FPS সীমা দিন
Skipped frames due to encoding lag	এনকোডার রিয়েল-টাইমের সাথে তাল রাখতে পারছে না	দ্রুত preset, হার্ডওয়্যার এনকোডার, কম রেজোলিউশন বা FPS
Dropped frames (network)	আপলিংক বিটরেট নিতে পারছে না	বিটরেট কমান, তার লাগান, SRT-এ যান

একটা উদাহরণ যেখানে সমস্যা স্পষ্টভাবে নেটওয়ার্কে (মানগুলো ব্যাখ্যার জন্য):

CPU usage                          22%
Missed frames (rendering lag)      0 / 54210 (0.0%)
Skipped frames (encoding lag)      0 / 54210 (0.0%)
Dropped frames (network)           1842 / 54210 (3.4%)
Total data output                  1.21 GB
Bitrate                            3820 kb/s  (target 6000)

বিটরেট লক্ষ্যের অনেক নিচে আর নেটওয়ার্ক ড্রপ ৩ ভাগের বেশি: আপলিংক ৬ Mbps নিতে পারছে না। এনকোডার বা GPU-র কোনো দোষ নেই।

একটা ভালো শুরুর সেটিং

৭২০p৩০, স্থির ব্রডব্যান্ড, স্ট্যান্ডার্ড বা লো লেটেন্সি HLS-এর জন্য ffmpeg-এ:

ffmpeg -re -i input \
  -c:v libx264 -preset veryfast -profile:v high \
  -b:v 3500k -maxrate 3500k -bufsize 3500k -x264-params nal-hrd=cbr \
  -g 60 -keyint_min 60 -sc_threshold 0 -bf 2 \
  -pix_fmt yuv420p \
  -c:a aac -b:a 128k -ar 48000 -ac 2 \
  -f flv "rtmps://ingest.baytalhikma.org/live/sk_7f3a9c2e"

WebRTC বা সাব-সেকেন্ড হলে -tune zerolatency -bf 0 যোগ করুন আর অডিও -c:a libopus করুন। OBS-এ একই জিনিস: Rate Control CBR, Bitrate 3500, Keyframe Interval 2 s, Preset veryfast (বা হার্ডওয়্যার এনকোডার), Profile high, Audio Bitrate 128 বা 160।

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

লক্ষণ	নিশ্চিত হবেন কীভাবে	সমাধান
জটিল দৃশ্যে স্ট্রিম আটকায়, সহজ দৃশ্যে ঠিক	এনকোডারের আউটপুট রেকর্ড করে প্রতি সেকেন্ডের বিটরেট দেখুন (উপরের ffprobe পদ্ধতি); লাফ দিলে rate control CRF বা খোলা VBR	CBR বা -maxrate/-bufsize দিয়ে বাঁধা VBR
প্লেয়ার কোয়ালিটি বদলালে ছবি ভাঙে বা লাফায়	প্রতিটা রেন্ডিশনের keyframe সময় ffprobe দিয়ে মেলান	-g নির্দিষ্ট, -sc_threshold 0, closed GOP
সেগমেন্টগুলো অসমান দৈর্ঘ্যের, কোনোটা ৭ সেকেন্ড	প্লেলিস্টে EXTINF দেখুন; keyframe interval সেগমেন্টের চেয়ে লম্বা বা অনিয়মিত	keyframe interval সেগমেন্ট দৈর্ঘ্যের সমান বা তার ভাগ করুন; OBS-এ 0 নয়, 2
নতুন দর্শক শুরু করতে অনেকক্ষণ কালো স্ক্রিন	keyframe কত সেকেন্ড পরপর	২ সেকেন্ডে আনুন
OBS-এ “encoding lag”	Stats প্যানেল	দ্রুত preset, হার্ডওয়্যার এনকোডার, কম রেজোলিউশন
OBS-এ “rendering lag”	Stats প্যানেল; GPU ব্যবহার	সিন সহজ করুন, গেমের FPS সীমা দিন
OBS-এ “dropped frames (network)”	Stats-এ বিটরেট লক্ষ্যের নিচে; iperf3 দিয়ে আপলোড মাপুন	বিটরেট আপলোডের ৭০ ভাগের নিচে আনুন, তার লাগান
WebRTC-তে ছবি আসে না বা ঝাঁকুনি	এনকোডারে B-frame আছে কিনা (ffprobe -show_frames দিয়ে pict_type=B)	-bf 0, -tune zerolatency
ঘরের ভেতরের লাইভে আলো ঝিকমিক করে	শুধু কৃত্রিম আলোর নিচে হয়, বাইরে হয় না	ক্যামেরার শাটার ১/৫০ বা ১/১০০, বা ২৫/৫০ fps
অডিও ধীরে ধীরে ভিডিও থেকে সরে যায়	স্ট্রিম চালু রেখে এক ঘণ্টা পর ঠোঁট মেলান; চেইনে কোথাও sample rate বদলাচ্ছে কিনা	পুরো চেইনে একই sample rate; ক্যামেরা আর অডিও ইন্টারফেস একই ক্লক

মূল শিক্ষা

1. লাইভে CBR বা কড়া সীমার VBR, কারণ আপলিংক হঠাৎ বেশি ডেটা নিতে পারে না। CRF একটা জটিল দৃশ্যে বিটরেট বাইশ গুণ বাড়াতে পারে, যা আমাদের পরীক্ষায় দেখা গেছে।
2. Keyframe নির্দিষ্ট ছন্দে, সাধারণত ২ সেকেন্ড পরপর, scene-change keyframe বন্ধ, closed GOP। OBS-এ ডিফল্ট 0 বদলাতেই হবে।
3. B-frame আর lookahead মান বাড়ায় কিন্তু দেরি যোগ করে। স্ট্যান্ডার্ড HLS-এ রাখুন, সাব-সেকেন্ডে বন্ধ করুন।
4. Preset এমন নিন যাতে এনকোডিং গতিতে যথেষ্ট হেডরুম থাকে; হার্ডওয়্যার এনকোডার CPU মুক্ত রাখে।
5. মোট বিটরেট মাপা আপলোডের মোটামুটি ৭০ ভাগের নিচে, আর মাপুন যে সময়ে লাইভ হবে সেই সময়ে, সবচেয়ে খারাপ সেকেন্ডগুলো দেখে।
6. OBS stats তিন ধরনের ড্রপ আলাদা করে দেখায়: rendering, encoding, network। প্রতিটার সমাধান আলাদা, তাই আগে কোনটা সেটা দেখুন।
7. প্ল্যাটফর্মের সুপারিশ বদলায়। স্ট্রিমের আগে তাদের নিজস্ব হেল্প পেজে মিলিয়ে নিন।