ভিডিও মাস্টারি — পর্ব ১: ভিডিও আসলে কী, আর প্লেয়ার কীভাবে চালায়
পিক্সেল আর ফ্রেম থেকে শুরু করে কোডেক, রেট কন্ট্রোল, কন্টেইনার, সেগমেন্ট, ABR আর প্লেয়ারের ভেতরের পাইপলাইন — পুরো গল্পটা, ধাপে ধাপে।
পিক্সেল আর ফ্রেম থেকে শুরু করে কোডেক, রেট কন্ট্রোল, কন্টেইনার, সেগমেন্ট, ABR আর প্লেয়ারের ভেতরের পাইপলাইন — পুরো গল্পটা, ধাপে ধাপে।
শুরুটা একটা প্রশ্ন দিয়ে
ধরো, সিনা তার ফোনে ৩০ সেকেন্ডের একটা ভিডিও করল। ফাইলটার সাইজ দেখাচ্ছে ৬০ মেগাবাইট। সে ভাবল — ৩০ সেকেন্ডে ৬০ এমবি? বেশ বড় তো।
আসলে ব্যাপারটা পুরো উল্টো। ওই ৩০ সেকেন্ড যদি কোনো রকম কারসাজি ছাড়া, একদম কাঁচা অবস্থায় সেভ হতো, তাহলে ফাইলটা হতো প্রায় সাড়ে পাঁচ গিগাবাইট।
মানে ফোনটা চুপচাপ ভিডিওটাকে প্রায় ১০০ গুণ ছোট করে ফেলেছে — আর তুমি চোখেও ধরতে পারোনি।
এই সিরিজটা মূলত ওই জাদুটার গল্প। আট পর্বে — প্রথম তিনটায় আমরা নিজেরা বানাই, পরের তিনটায় দেখি ইন্ডাস্ট্রি কীভাবে করে, শেষ দুটোয় বাকি দুই স্তম্ভ:
- পর্ব ১ (এইটা) — ভিডিও জিনিসটা আসলে কী, কম্প্রেশন কীভাবে কাজ করে, স্ট্রিমিং কীভাবে হয়, আর প্লেয়ার ভেতরে কী করে। কোনো কোড নেই, শুধু বোঝাপড়া।
- পর্ব ২ — নিজের ল্যাপটপে একটা ট্রান্সকোডার বানানো। ffmpeg, ল্যাডার, HLS, একটা ওয়ার্কার।
- পর্ব ৩ — সেই খেলনাটাকে প্রোডাকশন সিস্টেম বানানো। সারি, ওয়ার্কার, চাংকিং, CDN, খরচ, ব্যর্থতা।
- পর্ব ৪ — নেটফ্লিক্স — পার-শট এনকোডিং, VMAF, ডাইনামিক অপটিমাইজার, Cosmos পাইপলাইন, AV1, আর Open Connect।
- পর্ব ৫ — Vimeo — Falkor ইনফ্রা, স্পট ইনস্ট্যান্সে চাংকড এনকোডিং, চলার পথে প্রোগ্রেসিভ MP4, DRM, স্টোরেজের খরচ।
- পর্ব ৬ — Mux — জাস্ট-ইন-টাইম ট্রান্সকোডিং, নিউরাল নেটওয়ার্কে ল্যাডার অনুমান, QoE মাপা, আর তিনজনের তুলনা।
- পর্ব ৭ — লাইভ — RTMP/SRT/WHIP ingest, রিয়েল-টাইম এনকোডিংয়ের সীমা, LL-HLS, লেটেন্সির বাজেট, বিজ্ঞাপন, মাল্টি-CDN।
- পর্ব ৮ — প্লেয়ার — MSE আর Managed Media Source, বাফার, ABR অ্যালগরিদম, EME, ক্যাপশন, CMCD, ত্রুটি সামলানো।
লাইভ আর প্লেয়ার নিয়ে এই পর্বে যা আছে তা সংক্ষিপ্ত — পূর্ণ আলোচনা ওই দুই পর্বে।
সিরিজের বাইরে রাখা হয়েছে: WebRTC দিয়ে ভিডিও কল (আলাদা সমস্যা), ব্রডকাস্ট যন্ত্রপাতি (SDI, ST 2110), আর VR/৩৬০ ভিডিও।
এই পর্বটা লম্বা, কারণ এখানকার প্রতিটা ধারণা পরের দুই পর্বে ফিরে ফিরে আসবে। তাড়াহুড়ো করে পড়ার দরকার নেই — বরং যে অংশটা কাজে লাগবে, সেটায় ফিরে আসার মতো করে সাজানো।
১. ভিডিও মানে আসলে ছবির স্তূপ
ভিডিও কোনো আলাদা জাদুকরি জিনিস না। ভিডিও হলো — অনেকগুলো স্থির ছবি, খুব দ্রুত একটার পর একটা দেখানো।
প্রতিটা ছবিকে বলে ফ্রেম। এক সেকেন্ডে কয়টা ফ্রেম দেখানো হচ্ছে, তাকে বলে fps (frames per second)।
- সিনেমা: সেকেন্ডে ২৪টা ফ্রেম
- টিভি আর বেশিরভাগ ওয়েব ভিডিও: ৩০টা (আসলে ২৯.৯৭, কেন সেটা একটু পরে)
- গেমিং, খেলা, স্লো-মোশন: ৬০, ১২০, ২৪০টা
তোমার চোখ আর মস্তিষ্ক এই আলাদা ছবিগুলোকে জোড়া লাগিয়ে “চলমান” বানিয়ে দেয়। ভিডিও ইঞ্জিনিয়ারিংয়ের পুরো ব্যবসাটাই দাঁড়িয়ে আছে মানুষের চোখ কী কী ধরতে পারে না — তার উপর।
২৯.৯৭ কেন
ছোট্ট ঐতিহাসিক গল্প, কিন্তু এটা তোমাকে বাস্তবে কামড়াবে। সাদাকালো টিভি চলত ৩০ fps-এ। রঙিন টিভি আসার সময় রঙের সিগন্যালটা ঢোকাতে গিয়ে দেখা গেল শব্দের সাথে সামান্য সংঘর্ষ হচ্ছে। সমাধান হিসেবে ফ্রেমরেট ০.১% কমিয়ে ২৯.৯৭ করা হলো।
আজও ওই সংখ্যাটা রয়ে গেছে। ফলে তুমি যখন ৩০ fps ধরে হিসাব করবে অথচ ফাইলটা ২৯.৯৭, ঘণ্টাখানেক পর অডিও আর ভিডিওতে কয়েক ফ্রেম পার্থক্য জমে যাবে। ভিডিওতে বেশিরভাগ রহস্যময় বাগের গোড়ায় থাকে সময়ের হিসাব।
একটা ফ্রেমের ভেতরে কী
একটা ফ্রেম হলো পিক্সেলের গ্রিড। 1080p মানে ছবিটা ১৯২০ পিক্সেল চওড়া, ১০৮০ পিক্সেল উঁচু — প্রায় ২০ লাখ পিক্সেল, একটা ছবিতে।
প্রতিটা পিক্সেলের একটা রঙ আছে। সেই রঙ সাধারণত ৩ ভাগে রাখা হয় — লাল, সবুজ, নীল — প্রতিটার জন্য ১ বাইট (৮ বিট)। মানে এক পিক্সেল = ৩ বাইট।
হিসাবটা করি:
১ ফ্রেম = 1920 × 1080 × 3 বাইট ≈ ৬ MB
১ সেকেন্ড = ৬ MB × ৩০ ফ্রেম ≈ ১৮৬ MB
১ মিনিট = ১৮৬ MB × ৬০ ≈ ১১ GB
১ ঘণ্টা = ১১ GB × ৬০ ≈ ৬৭০ GBএক ঘণ্টার কাঁচা 1080p ভিডিও প্রায় ৬৭০ গিগাবাইট। 4K হলে চারগুণ। এই জন্যই কম্প্রেশন ছাড়া ইন্টারনেটে ভিডিও বলে কিছু থাকত না — ইউটিউব না, ভিডিও কল না, এমনকি হোয়াটসঅ্যাপে ভিডিও পাঠানোও না।
বিট ডেপথ: ৮ বিট বনাম ১০ বিট
প্রতিটা রঙের জন্য ৮ বিট মানে ২৫৬টা ধাপ। বেশিরভাগ সময় যথেষ্ট, কিন্তু আকাশের মতো ধীরে ধীরে বদলানো রঙে ২৫৬ ধাপ কম পড়ে যায় — তখন মসৃণ ঢালের বদলে ফিতার মতো দাগ দেখা যায়। একে বলে ব্যান্ডিং।
১০ বিট মানে ১০২৪টা ধাপ, ব্যান্ডিং কার্যত চলে যায়। মজার ব্যাপার — ৮ বিট সোর্সকেও ১০ বিটে এনকোড করলে প্রায়ই ফল ভালো আসে, কারণ এনকোডারের ভেতরের হিসাবগুলোয় গোল করার ভুল কমে।
HDR — সংক্ষেপে
HDR মানে আরও উজ্জ্বল সাদা আর আরও গভীর কালো, সাথে বড় রঙের পরিসর। প্রয়োজন হয় ১০ বিট, নতুন কালার স্পেস (Rec. 2020), আর আলাদা মেটাডেটা।
এখানে সবচেয়ে বেশি যে ভুলটা হয়: HDR ভিডিওকে সাধারণভাবে SDR-এ ট্রান্সকোড করলে ছবিটা ধূসর, ধোয়াটে হয়ে যায়। ঠিকভাবে করতে হলে টোন ম্যাপিং লাগে। প্রোডাকশনে HDR ইনপুট আলাদা করে চেনা আর আলাদা পথে পাঠানো — এটা পর্ব ৩-এর probe ধাপের একটা কাজ।
রঙের একটা ছোট চালাকি — ক্রোমা সাবস্যাম্পলিং
মানুষের চোখ আলো-অন্ধকারের পার্থক্য খুব ভালো ধরে, কিন্তু রঙের পার্থক্য তত ভালো ধরে না।
তাই ভিডিওতে ছবিটাকে RGB-তে না রেখে ভাগ করা হয় দুই ভাগে — উজ্জ্বলতা (luma, Y) আর রঙ (chroma, U ও V)। এরপর রঙের তথ্যটা ইচ্ছা করে কম রেজলিউশনে রাখা হয়:
| ধরন | মানে | কোথায় |
|---|---|---|
| 4:4:4 | রঙ পুরোটাই রাখা | মাস্টার ফাইল, গ্রাফিক্স কাজ |
| 4:2:2 | রঙ আধা রেজলিউশনে | ব্রডকাস্ট, প্রফেশনাল ক্যামেরা |
| 4:2:0 | রঙ চার ভাগের এক ভাগে | ওয়েবের প্রায় সব ভিডিও |
4:2:0-তে ডেটা অর্ধেক হয়ে যায় কম্প্রেশনের আগেই, আর তুমি পার্থক্য টেরই পাও না।
তবে একটা ফাঁদ আছে, যেটা পর্ব ২-এ কাজে লাগবে: অনেক ডিভাইস শুধু 4:2:0 চালাতে পারে। ভুল করে 4:4:4 এনকোড করে ফেললে ফাইলটা তোমার ল্যাপটপে চলবে, কিন্তু আইফোনে কালো স্ক্রিন দেখাবে। এই বাগটা খুঁজতে মানুষের অনেক ঘণ্টা যায়।
২. কম্প্রেশন: কীভাবে ১০০ গুণ ছোট হয়
এবার বড় চালাকিটা। কোডেক চারটা আলাদা কৌশল একসাথে ব্যবহার করে। একটা একটা করে দেখি।
কৌশল ১: পাশের ফ্রেম প্রায় একই
পরপর দুটো ফ্রেম চিন্তা করো — খোয়ারিজমি ক্যামেরার সামনে বসে কথা বলছে, বাগদাদের একটা ঘরে।
এক সেকেন্ডের ত্রিশ ভাগের এক ভাগ সময়ে ছবিটার কতটুকু বদলাল? দেয়াল একই, বইয়ের তাক একই, আলো একই, জামা একই। বদলাল শুধু ঠোঁট আর হাতের একটু নড়াচড়া। তাহলে পুরো ছবিটা আবার সেভ করার মানে কী?
কোডেক ফ্রেমগুলোকে তিন ভাগে ভাগ করে:
- I-frame — পুরো ছবি, নিজের ভেতরেই সম্পূর্ণ। জেপিইজি ছবির মতো। একে কি-ফ্রেমও বলে।
- P-frame — “আগের ফ্রেমটা মনে আছে? ওটার সাথে শুধু এই পার্থক্যগুলো যোগ করো।”
- B-frame — “আগের আর পরের ফ্রেম, দুটোই দেখে মাঝেরটা বানিয়ে নাও।”
আকারের পার্থক্যটা নাটকীয়। একটা সাধারণ ভিডিওতে I-frame হতে পারে ১০০ কিলোবাইট, P-frame ১০ কিলোবাইট, আর B-frame ৩ কিলোবাইট।
আর “পার্থক্য” মানে শুধু বিয়োগ না। কোডেক ছবিটাকে ছোট ছোট ব্লকে ভাগ করে খোঁজে — এই ব্লকটা আগের ফ্রেমে কোথায় ছিল? পেয়ে গেলে সে শুধু লিখে রাখে “এই ব্লকটা ৩ পিক্সেল ডানে সরেছে”। একে বলে মোশন ভেক্টর। ক্যামেরা প্যান করলে পুরো দৃশ্যটা এভাবে কয়েকটা তীর চিহ্ন দিয়েই বলে দেওয়া যায়।
এই কারণেই স্থির দৃশ্যের ভিডিও ছোট হয়, আর আতশবাজি বা বৃষ্টির দৃশ্য বিশাল — সেখানে প্রতিটা ফ্রেমে সবকিছু বদলাচ্ছে, চুরি করার মতো কিছু নেই।
GOP — ফ্রেমগুলোর দল
I-frame থেকে পরের I-frame পর্যন্ত অংশটাকে বলে GOP (Group of Pictures)। একটা সাধারণ কাঠামো:
GOP লম্বা হলে ফাইল ছোট হয় (কম I-frame মানে কম খরচ), কিন্তু সিক করা মোটা লাগে আর ভুল হলে সেই ভুল বেশিক্ষণ থাকে। GOP ছোট হলে উল্টোটা।
আরও একটা ভাগ আছে — ক্লোজড GOP মানে এই দলের কোনো ফ্রেম বাইরের ফ্রেমের উপর নির্ভর করে না। স্ট্রিমিংয়ের জন্য ক্লোজড GOP বাধ্যতামূলক, কারণ প্রতিটা সেগমেন্টকে নিজে নিজে সম্পূর্ণ হতে হয়।
কৌশল ২: একই ফ্রেমের ভেতরেও পুনরাবৃত্তি
I-frame-এও কম্প্রেশন হয়। নীল আকাশের একটা অংশ — পাশের ব্লকগুলোও প্রায় একই নীল। তাই কোডেক আগে ভবিষ্যদ্বাণী করে (“এই ব্লকটা সম্ভবত উপরের ব্লকের মতোই”), তারপর শুধু ভুলটুকু রাখে। একে বলে ইন্ট্রা প্রেডিকশন।
কৌশল ৩: চোখ যা দেখে না, ফেলে দাও
এটাই সবচেয়ে বড় সাশ্রয়ের জায়গা।
প্রতিটা ব্লককে একটা গাণিতিক রূপান্তর (DCT) দিয়ে ভেঙে ফেলা হয় — “মোটা দাগের আকৃতি” আর “সূক্ষ্ম খুঁটিনাটি” এই দুই ভাগে। মানুষের চোখ মোটা দাগের জিনিস ভালো দেখে, সূক্ষ্ম খুঁটিনাটি কম।
এরপর কোয়ান্টাইজেশন — সূক্ষ্ম অংশের হিসাবগুলোকে মোটা করে গোল করে ফেলা, বা একেবারে শূন্য বানিয়ে দেওয়া। এখানেই তথ্য চিরতরে হারায়, আর এখানেই ফাইল নাটকীয়ভাবে ছোট হয়।
তুমি যখন CRF বা কোয়ালিটির নব ঘোরাও, আসলে এই গোল করাটা কতটা মোটা হবে সেটাই ঠিক করো। বেশি চাপ দিলে ছবিতে চারকোনা ব্লক ভেসে ওঠে, ধারগুলোয় ছায়া পড়ে (রিংিং), মসৃণ ঢালে দাগ পড়ে।
কৌশল ৪: বাকিটুকু চতুরভাবে লেখা
শেষে যা থাকে, সেটাকে এনট্রপি কোডিং দিয়ে লেখা হয় — যে জিনিস বারবার আসে তাকে ছোট কোড, যা কম আসে তাকে বড় কোড। এই ধাপে কোনো তথ্য হারায় না, শুধু হিসাবটা আঁটসাঁট হয়।
মোট হিসাব
কাঁচা ১৮৬ MB/সেকেন্ড
4:2:0-তে নামানোর পর ৯৩ MB/সেকেন্ড
ফ্রেমের ভেতরের পুনরাবৃত্তি বাদ ~২০ MB/সেকেন্ড
ফ্রেমের মধ্যে পুনরাবৃত্তি বাদ ~২ MB/সেকেন্ড
চোখ যা দেখে না তা ফেলার পর ~০.৬ MB/সেকেন্ড১৮৬ থেকে ০.৬ — প্রায় ৩০০ গুণ। এর মধ্যে সবচেয়ে বড় অবদান শেষ দুটো ধাপের।
কি-ফ্রেমের গুরুত্ব — যেটা বারবার ফিরে আসবে
কি-ফ্রেম শুধু কম্প্রেশনের ব্যাপার না। প্লেয়ার শুধু কি-ফ্রেম থেকেই দেখা শুরু করতে পারে, কারণ ওটাই একমাত্র ফ্রেম যেটা নিজে নিজে সম্পূর্ণ।
তিন জায়গায় এটা সরাসরি প্রভাব ফেলে:
- সিক করা — মাঝখানে টেনে নিলে প্লেয়ার সবচেয়ে কাছের কি-ফ্রেমে যায়। কি-ফ্রেম ১০ সেকেন্ড পরপর হলে লাফ মোটা, ২ সেকেন্ড পরপর হলে মসৃণ।
- সেগমেন্ট কাটা — স্ট্রিমিংয়ের প্রতিটা টুকরো কি-ফ্রেম দিয়ে শুরু হতেই হবে।
- কোয়ালিটি বদলানো — এক ধাপ থেকে আরেক ধাপে লাফ দেওয়া যায় শুধু কি-ফ্রেমের সীমানায়।
এই তিনটার জন্যই পরের পর্বে আমরা কি-ফ্রেম জোর করে নির্দিষ্ট জায়গায় বসাব।
৩. কোডেক আর কন্টেইনার — দুটো আলাদা জিনিস
এই জায়গাটায় প্রায় সবাই গুলিয়ে ফেলে, তাই একটা উপমা দিই।
কোডেক হলো ভাষা। কন্টেইনার হলো খাম।
- কোডেক ঠিক করে ভিডিওটা কীভাবে সংকুচিত হবে: H.264, HEVC (H.265), VP9, AV1। অডিওর জন্য আলাদা: AAC, Opus, MP3।
- কন্টেইনার হলো ফাইলটা, যার ভেতরে সংকুচিত ভিডিও, অডিও, সাবটাইটেল, চ্যাপ্টার আর “কোন জিনিস কখন বাজবে” তার সময়সূচি একসাথে থাকে: MP4, MKV, WebM, MPEG-TS।
তাই “.mp4 ফাইল” কথাটা আসলে খুব কম তথ্য দেয়। একটা mp4-এর ভেতরে H.264 থাকতে পারে, HEVC থাকতে পারে, AV1-ও থাকতে পারে। খাম দেখে চিঠির ভাষা বোঝা যায় না।
কোডেকের তুলনা
| কোডেক | সাল | একই মানে সাইজ | কারা চালাতে পারে | এনকোড করতে |
|---|---|---|---|---|
| H.264 | ২০০৩ | ভিত্তি (১০০%) | কার্যত সব ডিভাইস | দ্রুত |
| VP9 | ২০১৩ | ~৬৫% | ক্রোম, অ্যান্ড্রয়েড, ফায়ারফক্স | ধীর |
| HEVC | ২০১৩ | ~৬৫% | অ্যাপল ডিভাইস, নতুন টিভি | ধীর |
| AV1 | ২০১৮ | ~৫০% | নতুন ব্রাউজার ও ফোন | অনেক ধীর |
দুটো জিনিস এই টেবিলে দেখা যায় না, অথচ সিদ্ধান্তে সবচেয়ে বড় ভূমিকা রাখে:
লাইসেন্স। H.264 আর HEVC-তে পেটেন্ট ফি লাগতে পারে, আর HEVC-র লাইসেন্সের কাঠামো এতটাই জটিল যে অনেক প্রতিষ্ঠান সেটা এড়িয়ে যায়। VP9 আর AV1 রয়্যালটি-মুক্ত — এটাই AV1-এর দ্রুত ছড়িয়ে পড়ার বড় কারণ।
পুরনো ডিভাইস। তোমার দর্শকদের একটা অংশ সবসময় পুরনো ফোনে থাকবে। H.264 বাদ দেওয়া মানে ওই অংশটাকে বাদ দেওয়া। তাই বাস্তবে বেশিরভাগ প্ল্যাটফর্ম H.264 রাখে সবার জন্য, আর পাশাপাশি AV1 বা HEVC দেয় যারা পারে তাদের জন্য — ব্যান্ডউইথ বাঁচাতে।
প্রোফাইল আর লেভেল
একই কোডেকের ভেতরেও ধাপ আছে। H.264-এর প্রোফাইল ঠিক করে কোন কোন কৌশল ব্যবহার করা যাবে (baseline সবচেয়ে সরল, high সবচেয়ে দক্ষ), আর লেভেল ঠিক করে সর্বোচ্চ রেজলিউশন, ফ্রেমরেট আর বিটরেটের সীমা।
পুরনো বা সস্তা ডিভাইস প্রায়ই বলে “আমি শুধু main profile, level 4.0 পর্যন্ত পারি”। এর বেশি হলে ভিডিও চলে না — বা আরও খারাপ, শুধু অডিও চলে আর স্ক্রিন কালো থাকে। তাই ল্যাডারের নিচের ধাপগুলোয় ইচ্ছা করে সহজ প্রোফাইল রাখা হয়, যাতে পুরনো ডিভাইসও অন্তত কিছু একটা পায়।
অডিওর দিকটা
ভিডিও নিয়ে সবাই কথা বলে, অডিও নিয়ে কেউ না — অথচ দর্শক ছবির ঝাপসা ভাব ক্ষমা করে, শব্দ কেটে গেলে করে না।
- স্যাম্পল রেট — সেকেন্ডে কতবার শব্দ মাপা হচ্ছে। ৪৮ kHz স্ট্যান্ডার্ড।
- চ্যানেল — মনো, স্টেরিও, বা 5.1।
- কোডেক — AAC সবখানে চলে; Opus ভালো, বিশেষ করে কম বিটরেটে, কিন্তু সব জায়গায় না।
- বিটরেট — কথা বলার জন্য ৬৪–৯৬ kbps যথেষ্ট, গান বা সিনেমার জন্য ১২৮–১৯২ kbps।
আর একটা জিনিস যেটা প্রায় সবাই ভুলে যায়: লাউডনেস। বিভিন্ন শিক্ষক বিভিন্ন মাইকে রেকর্ড করলে একেকটা ভিডিওর শব্দ একেক রকম হবে — একটায় কান ফাটবে, পরেরটায় কিছু শোনা যাবে না। তাই সব ভিডিওকে একটা নির্দিষ্ট লাউডনেস মানে এনে ফেলা হয়। এটা ট্রান্সকোডিং পাইপলাইনের কাজ, আর পর্ব ২-এ আমরা সেটা করব।
টাইমস্ট্যাম্প: PTS আর DTS
কন্টেইনারের ভেতরে প্রতিটা ফ্রেমের সাথে দুটো সময় লেখা থাকে:
- DTS (decode timestamp) — এই ফ্রেমটা কখন ডিকোড করতে হবে।
- PTS (presentation timestamp) — এই ফ্রেমটা কখন দেখাতে হবে।
দুটো আলাদা কেন? B-frame-এর জন্য। মাঝের একটা B-frame বানাতে হলে পরের P-frame আগে ডিকোড করতে হয়। মানে ডিকোডের ক্রম আর দেখানোর ক্রম আলাদা:
দেখানোর ক্রম: I B B P
ডিকোডের ক্রম: I P B Bএই দুটো সময় গোলমাল হলে যা হয় — অডিও-ভিডিও সরে যাওয়া, সিক করলে ভুল জায়গায় যাওয়া, ভিডিওর দৈর্ঘ্য ভুল দেখানো। ট্রান্সকোডিংয়ের সময় টাইমস্ট্যাম্প ঠিক রাখা একটা আলাদা যত্নের বিষয়।
VFR — ভেরিয়েবল ফ্রেমরেট
ফোনের ক্যামেরা প্রায়ই পরিবর্তনশীল ফ্রেমরেটে রেকর্ড করে — কম আলোতে fps কমিয়ে দেয়, বেশি আলোয় বাড়ায়। ফাইলটা দেখতে “৩০ fps” বললেও ভেতরে আসলে ২৪ থেকে ৩০-এর মধ্যে ওঠানামা করছে।
এই ফাইল ধরে নিয়ে যদি নির্দিষ্ট ৩০ fps ধরে ট্রান্সকোড করো, শুরুতে সব ঠিক থাকবে, আর ৪০ মিনিট পর ঠোঁট আর শব্দ আলাদা হয়ে যাবে। ভিডিও পাইপলাইনে সবচেয়ে বেশি রিপোর্ট হওয়া বাগগুলোর একটা এটাই। সমাধান আছে, পর্ব ২-এ আসছে।
৪. বিটরেট আর রেট কন্ট্রোল
রেজলিউশন নিয়ে সবাই কথা বলে (“1080p!”), কিন্তু ভিডিও কেমন দেখাবে সেটা ঠিক করে মূলত বিটরেট — প্রতি সেকেন্ডে কত ডেটা খরচ হচ্ছে।
খুব কম বিটরেটে 1080p মানে হলো — বড় ক্যানভাস, কিন্তু রঙ কেনার টাকা নেই। ছবিটা ঘোলা, চারকোনা দাগ ভেসে ওঠে। বরং ভালো বিটরেটের 720p অনেক পরিষ্কার লাগবে।
মোটা দাগে যা ধরা হয় (H.264, সাধারণ কনটেন্ট):
240p → ৩০০ Kbps
360p → ৬০০ Kbps
480p → ১ Mbps
720p → ২.৫ Mbps
1080p → ৫ Mbps
1440p → ৯ Mbps
4K → ১৫–২৫ Mbpsএগুলো নিয়ম না, শুরুর আন্দাজ। সাদা দেয়ালের সামনে কথা বলা মানুষ — ১ Mbps-এ 1080p-তেও দারুণ। সমুদ্রের ঢেউয়ের ড্রোন শট — ৮ Mbps-এও ঘোলা।
এনকোডারকে কী বলবে: চারটা পথ
এটাই “রেট কন্ট্রোল”, আর এখানকার সিদ্ধান্তটা পুরো পাইপলাইনের চরিত্র ঠিক করে দেয়।
১. CBR (নির্দিষ্ট বিটরেট) — সবসময় একই হারে ডেটা। সহজ দৃশ্যে বিট নষ্ট হয়, কঠিন দৃশ্যে কম পড়ে। ব্রডকাস্ট বা লাইভে দরকার হয়, কারণ সেখানে লাইনের ক্ষমতা নির্দিষ্ট।
২. VBR (পরিবর্তনশীল বিটরেট) — গড়ে একটা লক্ষ্য ধরে, কিন্তু দৃশ্যভেদে ওঠানামা করে। ফাইলের আকার মোটামুটি অনুমেয় থাকে।
৩. CRF (নির্দিষ্ট মান) — “এই মানটা ধরে রাখো, যত বিট লাগে নাও।” সহজ দৃশ্যে কম খরচ, কঠিন দৃশ্যে বেশি। ফলাফল সবচেয়ে সুন্দর, কিন্তু ফাইলের আকার আগে থেকে জানা যায় না।
৪. ক্যাপড CRF — CRF, কিন্তু একটা ছাদসহ: “মান ধরে রাখো, তবে এই সীমার উপরে যেও না।” স্ট্রিমিংয়ের জন্য এটাই সাধারণত সঠিক উত্তর, আর পর্ব ২-এ আমরা এটাই ব্যবহার করব।
কেন ছাদ দরকার? কারণ দর্শকের প্লেয়ার ধাপটা বেছেছিল “এটা ৩ Mbps” ধরে নিয়ে। মাঝখানে একটা কঠিন দৃশ্য এসে ৯ Mbps চাইলে তার নেট পারবে না, আর ভিডিও আটকে যাবে। স্ট্রিমিংয়ে অনুমানযোগ্যতা কাঁচা কোয়ালিটির চেয়ে দামি।
VBV — সেই ছাদের আসল মানে
ছাদটা শুধু গড় নিয়ে না, একটা কাল্পনিক বাফার নিয়েও। ধারণাটা এমন: প্লেয়ারের একটা নির্দিষ্ট আকারের পাত্র আছে, যেখানে ডেটা জমা হয় আর সেখান থেকে ডিকোডার খেতে থাকে। এনকোডারকে নিশ্চিত করতে হয় যে ওই পাত্র কখনো উপচে পড়বে না, আবার খালিও হবে না।
বাস্তবে এর মানে দুটো সংখ্যা — সর্বোচ্চ হার, আর পাত্রের আকার। পাত্র সাধারণত সর্বোচ্চ হারের দ্বিগুণ ধরা হয়, মানে “২ সেকেন্ড সমান জমা”। ছোট পাত্র মানে বেশি কড়াকড়ি আর দ্রুত শুরু, বড় পাত্র মানে ভালো কোয়ালিটি কিন্তু বেশি ঝুঁকি।
কোয়ালিটি মাপা: চোখ নয়, সংখ্যা
“ভালো দেখাচ্ছে” দিয়ে সিস্টেম চালানো যায় না। তাই মাপার যন্ত্র আছে:
- PSNR — পুরনো, সহজ, কিন্তু মানুষের চোখের সাথে মেলে না ভালোভাবে।
- SSIM — গঠন কতটা টিকে আছে দেখে, PSNR-এর চেয়ে ভালো।
- VMAF — নেটফ্লিক্সের বানানো, অনেকগুলো মাপ মিলিয়ে মানুষের রেটিং-এর কাছাকাছি ফল দেয়। ০ থেকে ১০০; ৯৩-এর উপরে হলে সাধারণ দর্শক পার্থক্য ধরতে পারে না।
VMAF কেন গুরুত্বপূর্ণ? কারণ এটা দিয়ে প্রশ্নটা উল্টে ফেলা যায়: “৫ Mbps-এ কেমন দেখাবে” না জিজ্ঞেস করে “VMAF ৯৩ পেতে কত Mbps লাগবে” জিজ্ঞেস করা যায়। প্রতিটা ভিডিওর উত্তর আলাদা — আর সেখান থেকেই আসে পর্ব ৩-এর পার-টাইটেল এনকোডিং।
৫. ফাইল ডাউনলোড বনাম স্ট্রিমিং
এখন প্রশ্ন — ভিডিওটা দর্শকের কাছে যাবে কীভাবে?
সহজ উপায়: প্রোগ্রেসিভ ডাউনলোড
একটা mp4 সার্ভারে রাখো, লিংক দাও। ব্রাউজার ফাইলটা নামাতে থাকে, আর নামানোর ফাঁকেই চালাতে থাকে। সিক করলে সে বলে “ফাইলের ৪২০ মেগাবাইট থেকে শুরু করো” — HTTP এটা সমর্থন করে।
ছোট ভিডিওর জন্য একদম ঠিক আছে। কিন্তু:
- দর্শকের নেট ভালো হোক বা খারাপ, তুমি একটাই কোয়ালিটি পাঠাচ্ছ।
- মাঝপথে কোয়ালিটি বদলানোর উপায় নেই।
- দর্শক ৩০ সেকেন্ড দেখে চলে গেলেও তুমি অনেকটা ডেটা পাঠিয়ে ফেলেছ।
- লাইভ করা যায় না।
একটা ফাঁদ: moov অ্যাটম
mp4 ফাইলে একটা সূচিপত্র থাকে (moov), যেখানে লেখা থাকে কোন ফ্রেম কোথায়। ffmpeg স্বাভাবিকভাবে এটা ফাইলের শেষে লেখে, কারণ সব লেখা শেষ না হলে সূচি বানানো যায় না।
ফল? ব্রাউজার ভিডিও চালানোর আগে পুরো ফাইলের শেষ পর্যন্ত পৌঁছাতে চায়। ২ গিগার ফাইলে এর মানে — প্লে চাপার পর দীর্ঘ অপেক্ষা।
সমাধান এক লাইনের: সূচিটাকে ফাইলের শুরুতে সরিয়ে আনা (faststart)। এটা পর্ব ২-এ আসছে, আর এটা সেইসব বাগের একটা যেটা “সার্ভার স্লো” বলে ভুল নির্ণয় হয় বছরের পর বছর।
আসল উপায়: টুকরো করে পাঠানো
বড় প্ল্যাটফর্মগুলো ভিডিওটাকে কেটে ফেলে ছোট ছোট টুকরোয় — সাধারণত ২ থেকে ৬ সেকেন্ডের — আর প্রতিটা টুকরো বানায় কয়েকটা আলাদা কোয়ালিটিতে। সাথে একটা তালিকার ফাইল, যেখানে লেখা থাকে কোথায় কী আছে।
এটাই HLS (অ্যাপলের, সবচেয়ে বেশি ব্যবহৃত) আর DASH (খোলা মান)। কাজের ধরন প্রায় এক।
মাস্টার প্লেলিস্ট — কী কী কোয়ালিটি আছে তার তালিকা:
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=628000,RESOLUTION=640x360,CODECS="avc1.4d401e,mp4a.40.2"
360p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1428000,RESOLUTION=854x480,CODECS="avc1.4d401f,mp4a.40.2"
480p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=3128000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2"
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=6128000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2"
1080p/index.m3u8খেয়াল করো CODECS অংশটা — এটা প্লেয়ারকে আগেই জানিয়ে দেয় কোন ধাপ চালানোর ক্ষমতা তার আছে। পুরনো ডিভাইস যে ধাপ চালাতে পারবে না, সেটা সে বেছেই নেবে না। এই তথ্যটা ভুল থাকলে প্লেয়ার এমন ধাপ বেছে নিয়ে কালো স্ক্রিন দেখাবে।
আর ভেতরের একটা প্লেলিস্ট:
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:4
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-INDEPENDENT-SEGMENTS
#EXTINF:4.000,
seg-000.ts
#EXTINF:4.000,
seg-001.ts
#EXTINF:3.360,
seg-002.ts
#EXT-X-ENDLISTসব মিলিয়ে জিনিসটা দাঁড়ায় একটা তাকের মতো:
ব্যস। কোনো বিশেষ ভিডিও সার্ভার লাগে না। এগুলো সাধারণ ফাইল, সাধারণ HTTP-তে যায়, CDN স্বাভাবিকভাবেই ক্যাশ করে। স্ট্রিমিংয়ের সবচেয়ে বড় আইডিয়াটা আসলে এত সাদামাটা: ভিডিওকে ফাইলের তাক বানিয়ে ফেলা।
সেগমেন্ট কত লম্বা হবে
এটা একটা আসল ট্রেডঅফ, আর প্রতিটা প্ল্যাটফর্ম আলাদা উত্তর বেছে নেয়:
| সেগমেন্টের দৈর্ঘ্য | ভালো দিক | খারাপ দিক |
|---|---|---|
| ২ সেকেন্ড | দ্রুত শুরু, দ্রুত ধাপ বদল, কম লেটেন্সি | বেশি ফাইল, বেশি রিকোয়েস্ট, একটু বড় মোট সাইজ |
| ৪ সেকেন্ড | ভারসাম্য — বেশিরভাগ VOD এখানে | — |
| ৬–১০ সেকেন্ড | কম রিকোয়েস্ট, ভালো কম্প্রেশন | ধীর শুরু, মোটা ধাপ বদল |
সেগমেন্ট ছোট করলে কম্প্রেশন একটু খারাপ হয় কেন? কারণ প্রতিটা সেগমেন্ট কি-ফ্রেম দিয়ে শুরু হতে হয়, আর কি-ফ্রেম ভারী। ২ সেকেন্ডের সেগমেন্ট মানে দ্বিগুণ কি-ফ্রেম।
TS নাকি fMP4 (CMAF)
পুরনো HLS ব্যবহার করত MPEG-TS টুকরো (.ts), DASH ব্যবহার করত খণ্ডিত MP4 (.m4s)। মানে একই ভিডিওর দুই সেট ফাইল — দ্বিগুণ স্টোরেজ, দ্বিগুণ CDN খরচ।
CMAF এই সমস্যাটা মিটিয়েছে: এখন একই fMP4 টুকরোগুলোই দুই প্রোটোকলে কাজে লাগে, শুধু তালিকার ফাইলটা আলাদা করে বানাতে হয়। নতুন কিছু বানালে CMAF দিয়েই শুরু করা উচিত।
৬. ল্যাডার — একই ভিডিওর কয়েকটা ধাপ
উপরের তালিকাটায় একই ভিডিও চারবার আছে, চার কোয়ালিটিতে। এই সিঁড়িটাকে বলে ল্যাডার।
মারিয়াম ফাইবার লাইনে ল্যাপটপে দেখলে 1080p পাবে। সে-ই বাসে উঠে মোবাইল ডেটায় গেলে প্লেয়ার নিজে থেকে নেমে আসবে 480p-তে। ভিডিও থামবে না, শুধু একটু নরম দেখাবে। থেমে যাওয়ার চেয়ে একটু ঘোলা ভালো — এটাই আধুনিক স্ট্রিমিংয়ের মূল কথা।
ল্যাডার বানানোর সময় যেসব নিয়ম কাজে লাগে:
ধাপগুলোর মধ্যে দূরত্ব থাকুক। পরপর দুই ধাপের বিটরেটে অন্তত ১.৫ গুণ পার্থক্য রাখো। খুব কাছাকাছি হলে প্লেয়ার অকারণে ওঠানামা করে, আর দর্শক ঝিকিমিকি দেখে।
সবচেয়ে নিচের ধাপটা সত্যিই নিচু হোক। এটাই সেই ধাপ যেটা দুর্বল নেটের দর্শককে ভিডিও দেখতে দেয় — অথবা দেয় না। ২৪০p/৩০০ Kbps একটা ধাপ থাকা মানে গ্রামের একজন দর্শক অন্তত দেখতে পাচ্ছে।
ইনপুটের চেয়ে বড় ধাপ বানিও না। 480p সোর্স থেকে 1080p ধাপ বানালে ফাইল বড় হবে, কোয়ালিটি বাড়বে না — শুধু টাকা পুড়বে।
সব ধাপে একই অডিও রাখো। ধাপ বদলানোর সময় অডিও যেন অক্ষত থাকে। অডিওকে আলাদা ট্র্যাক হিসেবে রাখলে এটা এমনিতেই ঠিক থাকে।
সব ধাপে কি-ফ্রেম একই সময়ে। এটা ছাড়া মসৃণ ধাপ বদল অসম্ভব। বারবার বলছি, কারণ এই এক জিনিস ভুল হলে সব ভালো কাজ নষ্ট।
৭. প্লেয়ারের ভেতরে কী হয়
এবার আসল রহস্য — প্লে বাটনে চাপ দিলে ভেতরে কী ঘটে। ধরো ফাতিমা একটা লেকচার চালাল।
১. তালিকাটা নামায়। প্লেয়ার প্রথমে মাস্টার প্লেলিস্ট আনে। এখন সে জানে কী কী ধাপ আছে, আর কোনগুলো তার ডিভাইস চালাতে পারবে।
২. একটা আন্দাজ করে শুরু করে। প্রথম টুকরোটা কোন ধাপে নেবে, সেটা প্লেয়ার জানে না — নেটের গতি এখনো মাপা হয়নি। বেশিরভাগ প্লেয়ার মাঝারি বা নিচু ধাপ থেকে শুরু করে, কারণ শুরুর দেরি মানুষ সবচেয়ে বেশি অপছন্দ করে। কেউ কেউ আগের সেশনের গতি মনে রাখে।
৩. বাফার ভরতে থাকে। প্লেয়ার একটার পর একটা টুকরো নামিয়ে জমা করে। এই জমানো সময়টুকুই বাফার। ৩০ সেকেন্ডের বাফার মানে — নেট ৩০ সেকেন্ড পুরো বন্ধ থাকলেও দর্শক কিছু টের পাবে না।
কিন্তু বাফার শুধু বাড়ালেই ভালো না। বেশি বাফার মানে বেশি ডেটা আগেভাগে নামানো — দর্শক যদি ১০ সেকেন্ড পর ভিডিও বন্ধ করে দেয়, ওই ডেটাটা পুরো নষ্ট। তাই প্লেয়ার শুরুতে দ্রুত কিছুটা জমায়, তারপর ধীরে ধীরে এগোয়।
৪. প্রতিটা টুকরোর পর হিসাব কষে। টুকরোটা নামতে কত সময় লাগল? ৪ সেকেন্ডের ভিডিও যদি ১ সেকেন্ডে নেমে আসে, নেট ভালো — উপরের ধাপে ওঠা যায়। যদি ৪ সেকেন্ডের টুকরো নামতে ৫ সেকেন্ড লাগে, বাফার শুকিয়ে আসছে — এখনই নিচে নামো।
ABR — সিদ্ধান্তের নিয়ম
এই সিদ্ধান্তের নিয়মটাকে বলে ABR (adaptive bitrate)। তিন ধরনের চিন্তা আছে:
গতিভিত্তিক — শেষ কয়েকটা টুকরোর গতির গড় দেখে সিদ্ধান্ত। সহজ, কিন্তু মোবাইল নেটে গতি এত ওঠানামা করে যে প্লেয়ার ঘন ঘন ধাপ বদলায়।
বাফারভিত্তিক — গতির বদলে দেখে “আমার হাতে কত সেকেন্ড জমা আছে”। বাফার ভরা থাকলে ঝুঁকি নিয়ে উপরে ওঠে, খালি হয়ে এলে নেমে আসে। ওঠানামা কম হয়।
মিশ্র — বাস্তবের সব ভালো প্লেয়ার দুটোই দেখে, সাথে আরও কিছু নিয়ম: খুব ঘন ঘন বদলাবে না, নিচে নামবে দ্রুত কিন্তু উপরে উঠবে ধীরে, আর সিক করার পর নতুন করে হিসাব শুরু করবে।
লক্ষ্যটা মনে রাখা দরকার: ABR সর্বোচ্চ কোয়ালিটি খোঁজে না। সে খোঁজে সর্বোচ্চ কোয়ালিটি যেটা থামবে না। একবার বাফারিং হওয়া মানে দর্শকের কাছে দশ মিনিটের ভালো কোয়ালিটির চেয়ে বেশি ক্ষতি।
৫. ডিকোড আর সিঙ্ক। নামানো টুকরো ডিকোড হয় ফ্রেমে — বেশিরভাগ ডিভাইসে ডেডিকেটেড হার্ডওয়্যার চিপে, এই জন্যই ফোনে ভিডিও চললে ব্যাটারি খুব দ্রুত শেষ হয় না।
অডিও আর ভিডিও আলাদা ট্র্যাক, তাই প্লেয়ার একটা ঘড়ি ধরে দুটোকে মেলায়। সাধারণত অডিওটাই ঘড়ি — কারণ অডিও এক মুহূর্তের জন্য আটকালে কানে সাথে সাথে ধরা পড়ে, আর ভিডিওর একটা ফ্রেম বাদ পড়লে চোখে পড়ে না। ভিডিও পিছিয়ে পড়লে প্লেয়ার চুপচাপ কয়েকটা ফ্রেম ফেলে দেয়।
৬. সিক করলে। টাইমলাইনে ক্লিক করলে প্লেয়ার জমানো বাফার ফেলে দেয়, ওই সময়ের টুকরোটা কোনটা হিসাব করে, নামায়, আর কাছের কি-ফ্রেম থেকে শুরু করে। কি-ফ্রেম যত ঘন, সিক তত মসৃণ — আবার সেই কথাটাই।
৭. ব্রাউজারে এসবের নাম MSE। ব্রাউজারের ভিডিও ট্যাগ নিজে HLS বোঝে না (সাফারি ছাড়া)। hls.js-এর মতো লাইব্রেরিগুলো তাই টুকরোগুলো নিজে নামিয়ে একটা বাফারে ঢুকিয়ে দেয়, আর ব্রাউজার সেখান থেকে চালায়। মানে ABR-এর পুরো বুদ্ধিটা জাভাস্ক্রিপ্টে চলে — এই জন্যই প্লেয়ার লাইব্রেরি বদলালে দর্শকের অভিজ্ঞতা বদলে যায়।
লাইভ ভিডিও — একই জিনিস, তাড়াহুড়োয়
লাইভে কাঠামোটা একই, শুধু প্লেলিস্টটা বারবার বদলায় — নতুন টুকরো যোগ হয়, পুরনোগুলো বাদ পড়ে। প্লেয়ার কয়েক সেকেন্ড পরপর নতুন তালিকা চায়।
লেটেন্সি (বাস্তব ঘটনা আর দর্শকের স্ক্রিনের মধ্যে দেরি) সাধারণত ১৫–৩০ সেকেন্ড, কারণ কয়েকটা টুকরো জমা রাখতে হয়। কম লেটেন্সির কৌশলগুলো (LL-HLS) টুকরোকে আরও ছোট অংশে ভেঙে আগেভাগে পাঠাতে শুরু করে — ২-৫ সেকেন্ডে নামানো যায়, তবে জটিলতা অনেক বাড়ে।
DRM — যেটা লুকানো থাকে
পয়সা দিয়ে দেখার কনটেন্ট হলে টুকরোগুলো এনক্রিপ্ট করা থাকে। প্লেয়ার একটা লাইসেন্স সার্ভার থেকে চাবি চায়, ডিভাইস সেই চাবি এমন জায়গায় রাখে যেখানে অ্যাপও হাত দিতে পারে না, আর ডিকোডিং হয় ওই সুরক্ষিত অংশে।
তিনটে ব্যবস্থা বাস্তবে চলে — Widevine (অ্যান্ড্রয়েড, ক্রোম), FairPlay (অ্যাপল), PlayReady (উইন্ডোজ, টিভি)। সবার জন্য কাজ করতে হলে তিনটেই লাগে। এটা নিজে বানানোর জিনিস না; তোমার কাজ শুধু প্যাকেজিংয়ের সময় ঠিক জায়গায় চাবিটা জুড়ে দেওয়া।
সব কনটেন্টে DRM লাগে না। অনেক ক্ষেত্রে সীমিত সময়ের সইসহ লিংকই যথেষ্ট — সেটা DRM-এর চেয়ে অনেক সহজ আর সস্তা।
সাবটাইটেল আর অ্যাক্সেসিবিলিটি
সাবটাইটেল দুইভাবে দেওয়া যায়:
- পাশে আলাদা ফাইল (WebVTT) — দর্শক চালু-বন্ধ করতে পারে, ভাষা বদলাতে পারে, সার্চ ইঞ্জিন পড়তে পারে। প্রায় সবসময় এটাই ঠিক।
- ছবির ভেতরে পুড়িয়ে দেওয়া — বন্ধ করা যায় না, কিন্তু নিশ্চিতভাবে সবখানে দেখা যায়। সোশ্যাল মিডিয়ার ক্লিপে কাজে লাগে।
এই সিদ্ধান্তটা ট্রান্সকোডিংয়ের সময় নিতে হয়, কারণ পুড়িয়ে দেওয়া মানে আলাদা করে আবার এনকোড করা।
৮. ভালো-খারাপ মাপা হয় কীভাবে
“ভিডিও ভালো চলছে” কথাটা মাপা যায়, আর প্রোডাকশনে এগুলোই আসল স্কোরবোর্ড:
| মাপ | মানে | ভালো কী |
|---|---|---|
| স্টার্টআপ টাইম | প্লে চাপার পর প্রথম ছবি | ১ সেকেন্ডের নিচে |
| রিবাফার রেশিও | মোট সময়ের কত ভাগ চাকা ঘুরেছে | ০.৫%-এর নিচে |
| রিবাফারের সংখ্যা | সেশনপ্রতি কতবার আটকাল | শূন্যের কাছাকাছি |
| গড় বিটরেট | দর্শক আসলে কোন ধাপে দেখল | যত উপরে তত ভালো |
| প্লে ফেইলিওর | কত শতাংশ প্লে শুরুই হলো না | ০.৫%-এর নিচে |
| ধাপ বদলের হার | কত ঘন ঘন কোয়ালিটি বদলাল | কম হলে ভালো |
এই সংখ্যাগুলো সবসময় ট্রান্সকোডিংয়ের সিদ্ধান্তে ফিরে যায়:
- স্টার্টআপ ধীর? সেগমেন্ট ছোট করো, নিচের ধাপ হালকা করো, faststart ঠিক আছে কিনা দেখো।
- রিবাফার বেশি? ল্যাডারের নিচের ধাপ যথেষ্ট নিচু কিনা দেখো, আর maxrate ঠিকমতো বাঁধা আছে কিনা।
- গড় বিটরেট কম? হয়তো ধাপগুলোর মধ্যে ফাঁক বেশি, বা ABR অতিরিক্ত সাবধানী।
- ধাপ বদল বেশি? ধাপগুলো একে অপরের খুব কাছাকাছি।
সব জোড়া লাগানো। এটাই সবচেয়ে বড় কথা — ভিডিও পাইপলাইনে কোনো সিদ্ধান্তই বিচ্ছিন্ন না।
৯. দ্রুত রেফারেন্স
| শব্দ | মানে |
|---|---|
| ফ্রেম | ভিডিওর একটা স্থির ছবি |
| fps | সেকেন্ডে কয়টা ফ্রেম |
| কি-ফ্রেম / I-frame | নিজে নিজে সম্পূর্ণ ফ্রেম |
| GOP | এক কি-ফ্রেম থেকে পরের কি-ফ্রেম পর্যন্ত |
| কোডেক | কম্প্রেশনের ভাষা (H.264, AV1) |
| কন্টেইনার | ফাইলের খাম (MP4, MKV) |
| বিটরেট | প্রতি সেকেন্ডে কত ডেটা |
| CRF | কোয়ালিটি লক্ষ্য করে এনকোড করার নব |
| VBV | বিটরেটের ছাদ আর বাফারের হিসাব |
| ল্যাডার | একই ভিডিওর কয়েকটা কোয়ালিটির ধাপ |
| সেগমেন্ট | ২-৬ সেকেন্ডের ছোট টুকরো |
| ম্যানিফেস্ট | কোথায় কী আছে তার তালিকা (m3u8, mpd) |
| ABR | নিজে থেকে ধাপ বদলানোর নিয়ম |
| CMAF | এক টুকরো, দুই প্রোটোকলে ব্যবহারের মান |
| VMAF | কোয়ালিটি মাপার সংখ্যা |
| QoE | দর্শকের আসল অভিজ্ঞতার মাপ |
এই পর্বের সারমর্ম
- ভিডিও = দ্রুত দেখানো ছবির স্তূপ। কাঁচা অবস্থায় এক ঘণ্টা প্রায় ৬৭০ গিগাবাইট।
- কম্প্রেশন চারটা কৌশল একসাথে চালায় — ফ্রেমের মধ্যে পুনরাবৃত্তি, ফ্রেমের ভেতরের পুনরাবৃত্তি, চোখ যা দেখে না তা ফেলা, আর চতুরভাবে লেখা।
- কি-ফ্রেম সিক, সেগমেন্ট আর ধাপ বদল — তিনটারই ভিত্তি।
- কোডেক হলো ভাষা, কন্টেইনার হলো খাম। প্রোফাইল/লেভেল ঠিক করে কে চালাতে পারবে।
- বিটরেট রেজলিউশনের চেয়ে বেশি গুরুত্বপূর্ণ; স্ট্রিমিংয়ের জন্য ক্যাপড CRF সাধারণত সঠিক উত্তর।
- আধুনিক স্ট্রিমিং = ভিডিওকে ছোট টুকরোয় কাটা, কয়েকটা ধাপে, সাথে একটা তালিকা। CMAF দিয়ে এক সেট ফাইলেই দুই প্রোটোকল।
- প্লেয়ার গতি আর বাফার দুটোই দেখে ধাপ ঠিক করে; তার লক্ষ্য সর্বোচ্চ কোয়ালিটি না, সর্বোচ্চ কোয়ালিটি যেটা থামবে না।
- দর্শকের অভিজ্ঞতা মাপার সংখ্যাগুলোই শেষ বিচারক।
পর্ব ২-এ আমরা এই পুরো জিনিসটা নিজের ল্যাপটপে বানাব — একটা কাঁচা ভিডিও ফাইল নেব, probe করব, ল্যাডার ঠিক করব, কি-ফ্রেম বেঁধে দেব, HLS-এ টুকরো করব, থাম্বনেইল বানাব, একটা ওয়ার্কার লিখব, আর ব্রাউজারে চালিয়ে ABR-কে চোখের সামনে কাজ করতে দেখব।