ভিডিও মাস্টারি — পর্ব ৪: নেটফ্লিক্স কীভাবে করে
পার-টাইটেল থেকে পার-শট, VMAF, ডাইনামিক অপটিমাইজার, Cosmos মাইক্রোসার্ভিস পাইপলাইন, AV1 আর ফিল্ম গ্রেইন সিনথেসিস, আর Open Connect — নেটফ্লিক্সের নিজের লেখা থেকে, সংখ্যাসহ।
পার-টাইটেল থেকে পার-শট, VMAF, ডাইনামিক অপটিমাইজার, Cosmos মাইক্রোসার্ভিস পাইপলাইন, AV1 আর ফিল্ম গ্রেইন সিনথেসিস, আর Open Connect — নেটফ্লিক্সের নিজের লেখা থেকে, সংখ্যাসহ।
এই তিনটা পর্ব কেন
প্রথম তিন পর্বে আমরা নিজেরা একটা সিস্টেম বানালাম — তত্ত্ব, তারপর একটা ট্রান্সকোডার, তারপর সেটাকে প্রোডাকশনে টেনে তোলা।
এবার প্রশ্নটা উল্টো দিক থেকে: যাদের কাজই এটা, তারা কী করে?
তিনটা কোম্পানি বেছে নিয়েছি, কারণ তিনজন তিন রকম সমস্যার সমাধান করছে:
- নেটফ্লিক্স (পর্ব ৪) — সীমিত সংখ্যক ভিডিও, কিন্তু প্রতিটা কোটি কোটি বার দেখা হয়। তাই এনকোডিংয়ে যত খুশি কম্পিউট ঢালা যায়, কারণ খরচটা কোটি ভিউয়ের উপর ভাগ হয়ে যায়। ওদের লড়াইটা ব্যান্ডউইথ আর পার্সেপচুয়াল কোয়ালিটি নিয়ে।
- Vimeo (পর্ব ৫) — অগণিত ভিডিও, প্রতিটার ভিউ তুলনায় কম। তাই এনকোডিং খরচ আর স্টোরেজ খরচই মূল শত্রু। ওদের লড়াইটা খরচ আর গতি নিয়ে।
- Mux (পর্ব ৬) — অন্য ডেভেলপারদের জন্য এই পুরো জিনিসটা একটা API বানিয়ে বিক্রি করে। ওদের লড়াইটা লেটেন্সি আর সরলতা নিয়ে।
এই পর্বের সব সংখ্যা আর নাম নেটফ্লিক্সের নিজের প্রকাশিত লেখা থেকে নেওয়া — শেষে সূত্রের তালিকা আছে।
১. যেখান থেকে শুরু: একটা স্থির ল্যাডার
২০১০ সালের শেষে নেটফ্লিক্স যখন H.264 এনকোড চালু করল, ওদের ইঞ্জিনিয়াররা হাতে-কলমে পরীক্ষা করে একটা স্থির ল্যাডার ঠিক করল — বিটরেট আর রেজলিউশনের একটা নির্দিষ্ট জোড়ার তালিকা, যেটা পুরো ক্যাটালগের জন্য একই।
পর্ব ১-এ আমরা যে ল্যাডারের কথা বলেছি, ঠিক সেটাই। সবচেয়ে উপরের ধাপ ছিল 1080p @ 5800 kbps।
এটা বেশিরভাগ ভিডিওর জন্য ভালোই কাজ করে। কিন্তু নেটফ্লিক্স নিজেই দুটো সমস্যা লিখে গেছে:
- ক্যামেরা নয়েজ বা ফিল্ম গ্রেইনওয়ালা দৃশ্যে 5800 kbps-এও ব্লকি দেখায়। ল্যাডারের সর্বোচ্চ ধাপেও ছবিটা খারাপ।
- কার্টুনের মতো সরল ভিডিওতে 5800 kbps অনেক বেশি — ওই বিটগুলো নষ্ট হচ্ছে।
আরও খারাপ: যে দর্শকের নেট ১৭৫০ kbps, স্থির ল্যাডার তাকে SD রেজলিউশন দেবে — অথচ কার্টুনটা ওই বিটরেটেই HD-তে দিব্যি চলত।
বৈচিত্র্যটা কতটা বড়
নেটফ্লিক্স ১০০টা এলোমেলো টাইটেল নিয়ে 1080p-তে স্থির QP দিয়ে এনকোড করে মেপেছিল। ফল:
- কিছু টাইটেল ২৫০০ kbps বা তার কমেই PSNR ৪৫ dB ছাড়িয়ে যায় (মানে চোখে ধরার মতো কোনো ক্ষতিই নেই)
- আবার কিছু টাইটেলের ৮০০০ kbps বা তার বেশি লাগে শুধু ৩৮ dB-তে পৌঁছাতে
একই ল্যাডার এই দুই প্রান্তের জন্য ঠিক হতে পারে না। এটাই পার-টাইটেল এনকোডিংয়ের গোটা যুক্তি।
২. পার-টাইটেল এনকোডিং (২০১৫)
মূল ধারণাটা এক লাইনে: প্রতিটা ভিডিও নিজের ল্যাডার পাবে, তার নিজের জটিলতা অনুযায়ী।
কনভেক্স হাল — জিনিসটা আসলে কী
একটা সোর্স ভিডিও নাও। কয়েকটা রেজলিউশনে, প্রতিটায় কয়েকটা বিটরেটে এনকোড করো। প্রতিটা এনকোডের জন্য দুটো সংখ্যা পাবে — বিটরেট আর কোয়ালিটি।
গ্রাফে বসালে দুটো জিনিস দেখা যায়:
- প্রতিটা রেজলিউশনের বক্ররেখা একসময় সমতল হয়ে যায়। কারণ প্রতিটা রেজলিউশনের একটা সর্বোচ্চ সীমা আছে — ছবিটা ছোট করে এনকোড করে আবার বড় করে দেখালে উঁচু ফ্রিকোয়েন্সির তথ্য চিরতরে হারিয়ে যায়। এরপর যত বিট দাও, লাভ নেই।
- খুব কম বিটরেটে বড় রেজলিউশন ছোট রেজলিউশনের চেয়ে খারাপ করে। কারণ বেশি পিক্সেলকে কম নিখুঁতভাবে এনকোড করার চেয়ে, কম পিক্সেলকে ভালোভাবে এনকোড করে পরে বড় করে নেওয়াই ভালো। তাছাড়া খুব কম বিটরেটে প্রতিটা ব্লকের নিজস্ব ওভারহেডই বেশিরভাগ বিট খেয়ে ফেলে।
তার মানে প্রতিটা রেজলিউশনের একটা এলাকা আছে যেখানে সে সেরা। সব রেজলিউশনের সেরা এলাকাগুলো জুড়ে যে সীমারেখাটা তৈরি হয়, তাকে বলে কনভেক্স হাল।
অর্থনীতির ভাষায় কনভেক্স হাল হলো Pareto-দক্ষ জায়গা: এর উপর দাঁড়ালে বিটরেট না বাড়িয়ে কোয়ালিটি বাড়ানো যায় না, আবার কোয়ালিটি না কমিয়ে বিটরেটও কমানো যায় না।
বাস্তবে কীভাবে করা হয়
পুরো ক্যাটালগের প্রতিটা টাইটেলের জন্য পুরো গ্রাফটা বানানো অসম্ভব। তাই নেটফ্লিক্স যা করে:
- একটা নির্দিষ্ট রেজলিউশনের তালিকা থেকে বেছে নেয় — 1920×1080, 1280×720, 720×480, 512×384, 384×288, 320×240। কারণ পুরনো সার্টিফায়েড ডিভাইসগুলোকেও চলতে হবে।
- প্রতিটা রেজলিউশনে কয়েকটা QP-তে ট্রায়াল এনকোড চালায়। QP-গুলো এমনভাবে বাছা, যাতে পাশাপাশি দুটোর পার্থক্য প্রায় এক JND (just-noticeable difference — চোখে সবে ধরা পড়ার মতো পার্থক্য)।
- মাপা বিন্দুগুলো থেকে ইন্টারপোলেট করে প্রতিটা রেজলিউশনের বক্ররেখা বানায়।
- কনভেক্স হালের সবচেয়ে কাছের বিন্দুগুলো নিয়ে চূড়ান্ত ল্যাডার বানায়। পাশাপাশি বিটরেটের ব্যবধান রাখা হয় প্রায় ৫%।
দুটো শর্ত মাথায় রাখা হয়:
- প্রতিটা ধাপ যেন দক্ষ হয় — ওই বিটরেটে যতটা কোয়ালিটি সম্ভব ততটা।
- পাশাপাশি দুটো ধাপের পার্থক্য যেন এক JND-এর সামান্য নিচে থাকে। এতে ধাপ বদলানোর সময় ঝাঁকুনি লাগে না, আবার অপ্রয়োজনীয় ধাপও তৈরি হয় না।
ফলাফল, নেটফ্লিক্সের নিজের উদাহরণে
- BoJack Horseman (সরল অ্যানিমেশন): স্থির ল্যাডারে ১৭৫০ kbps দিয়ে 480p হতো। পার-টাইটেলে ১৫৪০ kbps-এ পুরো 1080p — কম বিট, বড় ছবি, পরিষ্কার।
- Orange Is the New Black (মাঝারি জটিলতা): সর্বোচ্চ 1080p ধাপ ৫৮০০ থেকে নেমে ৪৬৪০ kbps — একই কোয়ালিটিতে ২০% বিট সাশ্রয়।
ডিভাইসের ফাঁদ
এখানে একটা সূক্ষ্ম সমস্যা আছে, যেটা আমাদের নিজেদের সিস্টেমেও ফিরে আসে।
ধরো অ্যানিমেশনটার হাল বলছে ২০০০ kbps-এ 1080p দাও। কিন্তু একটা ট্যাবলেটের হার্ডওয়্যার সর্বোচ্চ 720p ডিকোড করতে পারে। সে তখন ২০০০ kbps-এর ধাপটা ব্যবহারই করতে পারবে না — নেট ভালো থাকা সত্ত্বেও তাকে আরও নিচের ধাপে নামতে হবে।
সমাধান: নেটফ্লিক্স 480p-সীমিত আর 720p-সীমিত ডিভাইসের জন্য আলাদা পার-টাইটেল ল্যাডার বানায়। স্টোরেজ বাড়ে, কিন্তু ওই দর্শকদের অভিজ্ঞতা বাঁচে।
৩. VMAF — কোয়ালিটি মাপার সৎ যন্ত্র
উপরের পুরো পদ্ধতিটা একটা জিনিসের উপর দাঁড়িয়ে: কোয়ালিটি মাপার একটা সংখ্যা, যেটা মানুষের চোখের সাথে মেলে।
PSNR মেলে না। PSNR শুধু বলে পিক্সেলগুলো গাণিতিকভাবে কতটা বদলেছে — চোখ কোনটা ধরবে আর কোনটা ধরবে না, তার কোনো ধারণা তার নেই।
তাই নেটফ্লিক্স USC-এর গবেষকদের সাথে মিলে VMAF (Video Multi-method Assessment Fusion) বানিয়ে ২০১৬-তে ওপেন সোর্স করে দেয়। মূল বৈশিষ্ট্যগুলো:
- এটা full-reference — আসল আর নষ্ট হওয়া, দুটো ভিডিওই লাগে। তাই প্রোডাকশন এনকোডিংয়ে চলে, দর্শকের ডিভাইসে না।
- এটা শুধু কম্প্রেশন না, স্কেলিংয়ের ক্ষতিও ধরে — কারণ ডিকোড করা ফ্রেমগুলোকে আগে ১৯২০×১০৮০-তে আপস্যাম্পল করে তারপর তুলনা করে। এই কারণেই আলাদা রেজলিউশনের এনকোড একে অপরের সাথে তুলনা করা যায় — যেটা কনভেক্স হালের জন্য অপরিহার্য।
- ভেতরে VIF আর DLM নামের দুটো ইমেজ কোয়ালিটি মেট্রিক, সাথে ফ্রেমের মধ্যকার নড়াচড়ার পরিমাণ — এই ফিচারগুলো একটা SVM রিগ্রেসরে মিশিয়ে চূড়ান্ত স্কোর।
- ওজনগুলো আসল মানুষের দেওয়া রেটিং থেকে শেখানো।
মনে রাখার মতো মান: ৯৩ মোটামুটি ব্রডকাস্ট-মানের, ৯৫ সোর্স থেকে কার্যত আলাদা করা যায় না, ৭৫-এর নিচে চোখে লাগে।
৪. চাংক থেকে শট — ডাইনামিক অপটিমাইজার (২০১৮)
পার-টাইটেল একটা বড় লাফ। কিন্তু এতে একটা অনুমান লুকিয়ে আছে: পুরো সিনেমাটার জটিলতা একরকম।
সেটা তো সত্যি না। একই সিনেমায় অন্ধকার ঘরে দুজনের কথোপকথন আছে, আবার বিস্ফোরণ আর সমুদ্রের ঢেউও আছে। একটা ল্যাডার দুটোর জন্যই আপস।
শট কী, আর শট কেন
শট হলো একটানা এক ক্যামেরা-চালুর অংশ — একই আলো, একই দৃশ্য, একই ধরনের নড়াচড়া। শট-চেঞ্জ ডিটেকশন অ্যালগরিদম পাশাপাশি ফ্রেমের পার্থক্য মেপে সীমানাগুলো বের করে।
শটকে এনকোডিংয়ের একক বানালে কয়েকটা জিনিস একসাথে পাওয়া যায়, আর নেটফ্লিক্স সেগুলো স্পষ্ট করে লিখে গেছে:
- কি-ফ্রেম বসানো “নিয়মিতভাবে অনিয়মিত” হতে পারে। মানে I-frame বসবে ০, ২, ৫, ৭ সেকেন্ডে — সমান দূরত্বে না, বরং শটের সীমানায়। কিন্তু ওই একই জায়গাগুলোয় সব ল্যাডার ধাপের জন্যই। ফলে ধাপ বদলানো আগের মতোই কাজ করে।
- ওভারহেড কমে। I-frame সবচেয়ে খরচে ফ্রেম। শটের মাঝখানে জোর করে I-frame বসালে শটটা দুই টুকরো হয়ে যায়, আর পরের অংশ আগের অংশের পিক্সেল আর ব্যবহার করতে পারে না — বাড়তি বিট খরচ। শটের সীমানায় বসালে সেই ক্ষতি নেই, কারণ ওখানে তো ছবিটা এমনিতেই পুরো বদলে যাচ্ছে।
- সিক করা স্বাভাবিক জায়গায় নামে — দর্শক টেনে নিলে দৃশ্যের শুরুতে পড়ে।
- পাশাপাশি দুই শটে এনকোডিং সেটিং বদলালে চোখে ধরা পড়ে না, কারণ দৃশ্যটাই তো বদলে গেছে — ওই ধাক্কাটা সেটিংয়ের ধাক্কার চেয়ে অনেক বড়।
- রেট কন্ট্রোলের দরকার কমে যায়। একটা শটের ভেতরের ফ্রেমগুলো যেহেতু একরকম, স্থির QP দিলেই কোয়ালিটি সমান থাকে আর বিটরেটও খুব একটা ওঠানামা করে না।
অপটিমাইজেশনটা কীভাবে হয়
এবার আসল অংশ। প্রতিটা শটকে কয়েকটা রেজলিউশন আর QP-তে এনকোড করা হয়। প্রতিটা এনকোডের VMAF মাপা হয়। তাতে প্রতিটা শটের জন্য একগাদা (বিটরেট, ডিস্টরশন) বিন্দু পাওয়া যায়, আর তাদের নিজস্ব কনভেক্স হাল।
এখন প্রশ্ন: পুরো সিনেমার জন্য একটা নির্দিষ্ট গড় বিটরেট দেওয়া থাকলে, কোন শট কোন বিন্দু নেবে?
উত্তরটা ১৯৯৮ সালের Ortega ও Ramchandran-এর একটা ক্লাসিক ফলাফল থেকে আসে: প্রতিটা এককের নির্বাচিত বিন্দুর রেট-ডিস্টরশন ঢাল প্রায় সমান হতে হবে।
স্বজ্ঞাটা সোজা। ঢাল মানে “এক বিট বাড়ালে কতটা কোয়ালিটি বাড়ে”। যদি কোনো শটে এক বিটের বিনিময়ে অন্য শটের চেয়ে বেশি লাভ হয়, তাহলে দ্বিতীয় শট থেকে বিট কেড়ে প্রথম শটে দিলে মোট কোয়ালিটি বাড়বে। এভাবে সরাতে সরাতে যখন আর কোথাও লাভ নেই, তখন সব ঢাল সমান।
ঢালের মানটা বদলে বদলে বারবার এই কাজটা করলে পুরো ল্যাডারটা বেরিয়ে আসে — নিচু ঢাল মানে বেশি বিটরেটের ধাপ, খাড়া ঢাল মানে কম বিটরেটের ধাপ।
সংখ্যায় ফলাফল
নেটফ্লিক্সের নিজের পরীক্ষায়:
- ১০টা প্রতিনিধিত্বমূলক টাইটেলে, সবচেয়ে ভালো সম্ভাব্য স্থির-QP এনকোডিংয়ের তুলনায় ডাইনামিক অপটিমাইজার গড়ে ১৭.১% বিট বাঁচায় (HVMAF মেট্রিকে)। PSNR-এ হিসাব করলে ২২.৫%।
- বেসলাইন হিসেবে আরও প্রচলিত 2-pass VBR ধরলে সাশ্রয় ৫০%-এর বেশি।
- কোডেক-নিরপেক্ষ: x264, x265 আর libvpx — তিনটাতেই উন্নতি প্রায় ২৮–৩৮%।
আর প্রোডাকশনে যাওয়ার পরের হিসাবটা আরও নাটকীয়। VMAF=৮০ (ভালো কোয়ালিটি) ধরে:
- পার-টাইটেল AVCMain-এর তুলনায় অপটিমাইজড এনকোডের লাগে অর্ধেকেরও কম বিট
- VP9-Opt দিয়ে এক-তৃতীয়াংশেরও কম বিট
- মোবাইল পার-চাংক এনকোডের তুলনায় সাশ্রয় ১৭% (AVC) আর ৩০% (VP9)
আরেকভাবে দেখলে — গড় সেলুলার সংযোগ ২৫০ kbps ধরে একটা ফ্রেমে: AVCMain-এ VMAF ৫৮, AVCHi-Opt-এ ৭৩, VP9-Opt-এ ৭৯। একই ব্যান্ডউইথে।
৫. এই জিনিসটা চালানোর সিস্টেম-খরচ
এখানেই ব্যাপারটা আমাদের পর্ব ৩-এর সাথে সরাসরি মেলে।
নেটফ্লিক্স আগে চাংকড এনকোডিং করত — এক ঘণ্টার এপিসোড ২০টা ৩ মিনিটের চাংকে ভাগ, প্রতিটা আলাদা মেশিনে, শেষে জোড়া। কারণগুলো আমাদের পরিচিত: সমান্তরালতা, আর একটা মেশিন মরলে শুধু ওই চাংকটা আবার করা।
শট-ভিত্তিক এনকোডিংয়ে গিয়ে সংখ্যাটা বিস্ফোরিত হলো। ওদের নিজের উদাহরণ: Stranger Things-এর এক ঘণ্টার এপিসোড আগে ছিল ২০টা চাংক। গড় শট ৪ সেকেন্ড ধরলে সেটা দাঁড়ায় ৯০০টা শট — দুই অর্ডার অফ ম্যাগনিটিউড বেশি একক। তার উপর ডাইনামিক অপটিমাইজারের বিশ্লেষণ ধাপে প্রতিটা শটকে বহু রেজলিউশন × বহু QP-তে এনকোড করতে হয়।
মেশিনগুলোর মধ্যে মেসেজ চালাচালির সিস্টেমটাই বোতলঘাড় হয়ে গেল। দুটো সমাধান ওরা লিখে গেছে, দুটোই চমৎকার সরল:
Collation। মেসেজিং সিস্টেম নতুন করে লেখার বদলে ওরা পাশাপাশি কয়েকটা শটকে একটা চাংকে জড়ো করল — এমনভাবে যাতে চাংকের দৈর্ঘ্য আবার প্রায় ৩ মিনিট হয়। মেশিন প্রতি কাজের আকার আগের মতোই থাকল, রিসোর্স বরাদ্দও আগের মতো। চাংকের ভেতরে মেশিনটা শটগুলোকে আলাদা আলাদা প্যারামিটারে এনকোড করে।
Checkpoints। আগে মেশিন হারালে পুরো চাংক আবার এনকোড করতে হতো। এখন যেহেতু প্রতিটা শট স্বাধীন, প্রতিটা শট শেষ হওয়ামাত্র তার আউটপুট আর মেটাডেটা সাথে সাথে সংরক্ষণ করা হয়। মেশিন হারালে নতুন মেশিন যেখানে থেমেছিল সেখান থেকে শুরু করে।
পর্ব ৩-এ আমরা ঠিক এই দুটো জিনিসের কথাই অন্য নামে বলেছিলাম — কাজের একক এমন রাখা যাতে বিন-প্যাকিং সহজ হয়, আর আংশিক অগ্রগতি হারিয়ে না যায়। বড় স্কেলে সমস্যাগুলো একই থাকে, শুধু সংখ্যাগুলো বদলায়।
আর কম্পিউটটা আসে কোথা থেকে? নেটফ্লিক্সের বাকি মাইক্রোসার্ভিসগুলো অটোস্কেল করে বলে দিনের কিছু সময় প্রচুর মেশিন খালি পড়ে থাকে। এনকোডিং পাইপলাইন ওই খালি সময়টা ব্যবহার করে — নির্দিষ্ট সংখ্যক ডেডিকেটেড মেশিনের বদলে।
৬. Reloaded থেকে Cosmos — পাইপলাইনটা ভেঙে নতুন করে গড়া
২০১৪ থেকে নেটফ্লিক্সের ভিডিও পাইপলাইন চলত Reloaded নামের একটা প্ল্যাটফর্মে। স্থিতিশীল, স্কেলেবল, অনেক উদ্ভাবনের ভিত্তি। কিন্তু সময়ের সাথে তিনটা সমস্যা স্পষ্ট হলো — আর এগুলো যেকোনো বড় কোডবেসের চেনা রোগ:
- কাজগুলো জড়িয়ে গিয়েছিল। যেমন, কোয়ালিটি (VMAF) হিসাব করার কোডটা বসানো ছিল ভিডিও এনকোডার মডিউলের ভেতরে। ফলে শুধু কোয়ালিটি আবার মাপতে চাইলেও পুরোটা আবার এনকোড করতে হতো।
- মনোলিথ। মডিউলগুলো একই রিপোতে থাকায় সীমানা ভাঙা সহজ ছিল, আর অনিচ্ছাকৃত কোড শেয়ারিং টাইট কাপলিং তৈরি করেছিল। সব মডিউল একসাথে ডিপ্লয় করতে হতো।
- লম্বা রিলিজ চক্র। প্রতি দুই সপ্তাহে সব মডিউলের একটা “স্ন্যাপশট” নিয়ে রিলিজ ক্যান্ডিডেট বানানো হতো, তারপর দুই সপ্তাহ পরীক্ষা। কোড মার্জ থেকে প্রোডাকশন — দুই থেকে চার সপ্তাহ।
ফল: নতুন ফিচার আসার হার কমে গেল, আর কিছু ভালো আইডিয়া শুধু আর্কিটেকচারের বাধার কারণে বাদ দিতে হলো।
২০১৮ থেকে ওরা Cosmos বানাতে শুরু করে — মিডিয়া-কেন্দ্রিক, ওয়ার্কফ্লো-চালিত মাইক্রোসার্ভিসের প্ল্যাটফর্ম।
সার্ভিসের সীমানা কীভাবে টানা হলো
এই অংশটা আর্কিটেকচার শেখার জন্য দামি। Reloaded-এ ভিডিও এনকোডিং মডিউলটা পাঁচটা কাজ একসাথে করত:
- ইনপুটকে চাংকে ভাগ করা
- প্রতিটা চাংক আলাদা এনকোড করা
- প্রতিটা চাংকের VMAF হিসাব
- চাংকগুলো জোড়া লাগানো
- সব চাংকের কোয়ালিটি স্কোর একত্র করা
নেটফ্লিক্সের বিশ্লেষণ: সিস্টেমের দিক থেকে জোড়া লাগানো ভিডিওটাই আসল আউটপুট — ভেতরের চাংকিং শুধু লেটেন্সি আর রেজিলিয়েন্সের জন্য, ওটা ইমপ্লিমেন্টেশনের বিবরণ। আর কোয়ালিটি মাপা একটা সম্পূর্ণ আলাদা কাজ।
তাই দুটো স্বাধীন সার্ভিস হলো: VES (Video Encoding Service) আর VQS (Video Quality Service)। চাংকিং আর অ্যাসেম্বলিং VES-এর ভেতরে লুকিয়ে গেল।
একই যুক্তি বাকি পাইপলাইনে চালিয়ে যে সার্ভিসগুলো দাঁড়াল:
| সার্ভিস | কাজ |
|---|---|
| VIS — Video Inspection | মেজানিন ফাইল পরীক্ষা, মেটাডেটা বের করা, অদ্ভুত ইনপুট ধরিয়ে দেওয়া |
| CAS — Complexity Analysis | কনটেন্টের জটিলতা মাপা; এর জন্য VES-কে প্রি-এনকোডের আর VQS-কে কোয়ালিটির ডাক দেয়; ফল ডেটাবেসে জমা রাখে যাতে পুনর্ব্যবহার হয় |
| LGS — Ladder Generation | CAS-এর জটিলতার ডেটা নিয়ে অপটিমাইজেশন চালিয়ে পুরো ল্যাডার বানায় (H.264, AV1 — প্রতিটা ফ্যামিলির জন্য) |
| VES — Video Encoding | মেজানিন + রেসিপি → এনকোডেড ভিডিও |
| VVS — Video Validation | এনকোডেড ভিডিও রেসিপির শর্ত আর কোডেক স্পেক মানছে কিনা যাচাই |
| VQS — Video Quality | মেজানিন + এনকোড → VMAF স্কোর |
লক্ষ্য করো, CAS আর LGS আলাদা। জটিলতার ডেটা তৈরি ও সংরক্ষণ এক জিনিস, আর সেই ডেটা থেকে ল্যাডার বানানোর অ্যালগরিদম আরেক জিনিস। আলাদা রাখায় অ্যালগরিদম নিয়ে পরীক্ষা করা যায় ব্যয়বহুল বিশ্লেষণ আবার না চালিয়েই। পার-টাইটেল, মোবাইল এনকোড, পার-শট, অপটিমাইজড 4K — এই সব উদ্ভাবন এই দুটো সার্ভিসের ভেতরে।
দুটো অর্কেস্ট্রেটর, দুটো ব্যবসা
সার্ভিসগুলো এক, কিন্তু ব্যবহারকারী দুই রকম:
- Streaming Workflow Orchestrator — দর্শকের জন্য স্ট্রিম বানায়। প্রায় সব সার্ভিস ব্যবহার করে, কারণ এই আউটপুট কোটি বার দেখা হবে; কোয়ালিটির ডেটা আবার অ্যানালিটিক্স পাইপলাইনেও যায়।
- Studio Workflow Orchestrator — মার্কেটিং ক্লিপ, প্রোডাকশন প্রক্সি ইত্যাদি। এখানে লেটেন্সিই রাজা — শুটিংয়ের পরিকল্পনা করতে কেউ হয়তো ভিডিওটার জন্য বসে আছে। তাই এটা VIS দিয়ে মেটাডেটা নিয়ে সরাসরি পূর্বনির্ধারিত রেসিপিতে VES ডাকে। ফরেনসিক ওয়াটারমার্কিং বা টাইমকোড বার্ন-ইনের মতো ফিচার শুধু এই পথেই।
একই বিল্ডিং ব্লক, দুই রকম ট্রেড-অফ। এটাই মাইক্রোসার্ভিসে ভাঙার আসল লাভ।
VES-এর ভেতরে
Cosmos-এর প্রতিটা মাইক্রোসার্ভিসের তিনটা স্তর:
- Optimus — API স্তর, বাইরের জগতের একমাত্র দরজা
- Plato — ওয়ার্কফ্লো স্তর, মিডিয়া প্রসেসিংয়ের ধাপগুলো চালায়
- Stratum — সার্ভারলেস কম্পিউট স্তর, যেখানে আসল মিডিয়া স্যাম্পল ছোঁয়া হয়
তিনটা স্তর নিজেদের মধ্যে অ্যাসিনক্রোনাসভাবে কথা বলে Timestone নামের অগ্রাধিকার-ভিত্তিক মেসেজিং সিস্টেম দিয়ে, পেলোড ফরম্যাট Protobuf।
VES-এর ওয়ার্কফ্লোটা একটা DAG — পাঁচটা নোড:
Encoder নোডগুলো Map, Assembler Reduce — Reduce নোড তখনই চলে যখন সব Map শেষ। হালকা কাজ (Notifier) Plato-র ভেতরেই চলে; ভারী কাজ (এনকোড, অ্যাসেম্বল) Stratum-এ পাঠানো হয়।
তিনটা ছোট ডিটেইল, যেগুলো বাস্তবে গুরুত্বপূর্ণ:
কোডেক প্রতি আলাদা Stratum ফাংশন। H.264-এর এনকোডার ২০ বছরের পুরনো, স্থির। AV1 প্রতিনিয়ত বদলাচ্ছে, ঘন ঘন আপগ্রেড লাগে। তাই API আর ওয়ার্কফ্লো এক রেখে প্রতিটা কোডেকের জন্য আলাদা ফাংশন — একটা এনকোডার আপগ্রেড করলে অন্যগুলোর কিছু হয় না।
Container shaping আর bin-packing। এনকোডিংয়ে CPU আর RAM-এর চাহিদা কোডেক আর রেজলিউশন অনুযায়ী বদলায়। তাই কয়েকটা “কনটেইনার শেপ” সংজ্ঞায়িত করা আছে (যেমন ২ CPU / ৪ GB RAM), আর রাউটিং নিয়ম কাজকে উপযুক্ত শেপে পাঠায়। ফলে একটা ১৬-কোরের মেশিনে তিন রকম শেপের পাঁচটা এনকোডিং কনটেইনার সুন্দর করে বসে যায় — কম অপচয়।
রিলিজ। কোড মার্জ থেকে প্রোডাকশনে ফিচার — প্রায় ৩০ মিনিট। আগের প্ল্যাটফর্মে যেটা ছিল ২–৪ সপ্তাহ।
Reloaded থেকে Cosmos-এ পুরো স্থানান্তর শেষ হয় ২০২৩ সালের সেপ্টেম্বরে। ফলটা হাতে-নাতে পাওয়া গেল ২০২২-এর নভেম্বরে বিজ্ঞাপন-সমর্থিত প্ল্যান চালু করার সময় — বিজ্ঞাপনের মিডিয়া ফরম্যাট সিনেমার মেজানিন থেকে একেবারে আলাদা, আর নতুন প্ল্যাটফর্মে দ্রুত মানিয়ে নেওয়া গেছে।
দুটো শিক্ষা, যেগুলো নেটফ্লিক্স নিজেই স্বীকার করেছে
সার্ভিসের পরিধি ঠিক করা কঠিন। প্রথম চেষ্টায় ওরা প্রতিটা কোডেকের জন্য আলাদা এনকোডিং সার্ভিস বানিয়েছিল। তারপর কেউ ওয়াটারমার্কিং চাইল — একই কোড আর টেস্ট বারবার সব সার্ভিসে লিখতে হলো। দ্বিতীয় সংস্করণে সব কোডেক এক সার্ভিসে এল, শুধু Stratum ফাংশন আলাদা।
ডেটা মডেল নিয়ে বাড়াবাড়ি করেছিল। “শেয়ার করা মানেই কাপলিং” — এই বিশ্বাসে প্রতিটা সার্ভিসের, এমনকি একই সার্ভিসের প্রতিটা স্তরের আলাদা ডেটা মডেল আর কনভার্টার লেখা হয়েছিল। শেষে ওরা ফ্রেমরেট, স্ক্যান টাইপ, কালার স্পেসের মতো সাধারণ ও স্থিতিশীল ধারণাগুলোর জন্য একটা শেয়ার্ড লাইব্রেরি বানায়।
৭. কোডেক: AV1, ফিল্ম গ্রেইন, HDR
কোয়ালিটির অন্য দিকটা হলো কোডেক নিজে। নেটফ্লিক্সের ২০২৫ সালের হিসাব:
- AV1 এখন নেটফ্লিক্সের প্রায় ৩০% ভিউ চালায় — দ্বিতীয় সর্বাধিক ব্যবহৃত কোডেক
- AV1 সেশনের VMAF গড়ে AVC-র চেয়ে ৪.৩ পয়েন্ট আর HEVC-র চেয়ে ০.৯ পয়েন্ট বেশি
- একই সাথে এক-তৃতীয়াংশ কম ব্যান্ডউইথ, আর ৪৫% কম বাফারিং
টাইমলাইন: AV1 স্পেক ২০১৮, অ্যান্ড্রয়েডে ২০২০, টিভিতে ২০২১-এর শেষে, ব্রাউজারে ২০২২, অ্যাপলের M3/A17 Pro-তে ২০২৩। ২০২১–২০২৫ সালে সার্টিফিকেশনের জন্য আসা বড় স্ক্রিনের ডিভাইসের ৮৮% AV1 চালাতে পারে।
সফটওয়্যার ডিকোডিংয়ের জন্য dav1d ব্যবহার হয় — এটা ওদের ব্রাউজার প্লেব্যাকের প্রায় ৪০% চালায়, আর অ্যান্ড্রয়েডের ডিফল্ট সফটওয়্যার ডিকোডারও এটাই।
ফিল্ম গ্রেইন সিনথেসিস — সবচেয়ে সুন্দর কৌশলটা
ফিল্ম গ্রেইন এনকোডারের দুঃস্বপ্ন। গ্রেইন হলো এলোমেলো নয়েজ — প্রতিটা ফ্রেমে আলাদা, তাই মোশন কম্পেনসেশন কাজ করে না, আর কম্প্রেশনও করা যায় না। অথচ পরিচালক ওটা ইচ্ছা করে রেখেছেন; মুছে ফেললে ছবিটা প্লাস্টিকের মতো দেখায়।
AV1-এর সমাধান: গ্রেইনটা এনকোড করাই হয় না। এনকোড করার আগে গ্রেইন সরিয়ে ফেলা হয়, তার বদলে গ্রেইনের একটা গাণিতিক বর্ণনা বিটস্ট্রিমে মেটাডেটা হিসেবে পাঠানো হয়। ডিকোডার ছবিটা খোলার পর ওই বর্ণনা দেখে নিজে গ্রেইনটা বানিয়ে উপরে বসিয়ে দেয়।
নেটফ্লিক্স এটা প্রোডাকশনে আনে ২০২৫-এর জুলাইয়ে। ওদের দেওয়া উদাহরণে বিটরেট ৮২৭৪ kbps থেকে ২৮০৪ kbps — প্রায় ৬৬% কম, তবু ছবিটা স্পষ্টভাবে ভালো।
আর ২০২৫-এর মার্চে AV1 HDR10+ চালু হয়; ওদের HDR ক্যাটালগের ৮৫% ততদিনে ঢেকে গেছে।
AV1 আসলে কেন বানানো হলো — টাকার গল্প
একটা প্রশ্ন সাধারণত কেউ করে না: HEVC তো আগেই ছিল আর ভালোই কাজ করত। তাহলে ইন্ডাস্ট্রি বছরের পর বছর খরচ করে আরেকটা কোডেক বানাল কেন?
উত্তরটা কারিগরি না, লাইসেন্সিং।
H.264-এর পেটেন্ট লাইসেন্সিং মোটামুটি একটা জায়গা থেকেই হতো — অনুমানযোগ্য। HEVC-তে এসে ব্যবস্থাটা ভেঙে যায়: একাধিক পেটেন্ট পুল (MPEG LA, Access Advance) আর তার বাইরেও আলাদা আলাদা দাবিদার। ফল হলো — কেউ নিশ্চিতভাবে বলতেই পারত না HEVC ব্যবহারের মোট খরচ কত, বা ভবিষ্যতে কে এসে দাবি করবে।
বড় কোম্পানির জন্য এটা ব্যয়; ছোট প্রকাশকের জন্য এটা ঝুঁকি — অনির্দেশ্য রয়্যালটি বা মামলার ভয়।
তাই ২০১৫ সালে নেটফ্লিক্স, গুগল, অ্যামাজন, মজিলা, মাইক্রোসফট-সহ একদল কোম্পানি মিলে Alliance for Open Media (AOMedia) তৈরি করে, আর তার প্রথম প্রকল্পই ছিল AV1 — উদ্দেশ্য: রয়্যালটি-মুক্ত, যাতে যে কেউ ব্যবহার করতে পারে।
এখান থেকে একটা সাধারণ শিক্ষা আছে, যেটা ভিডিওর বাইরেও খাটে: একটা প্রযুক্তি টিকবে কিনা, সেটা প্রায়ই কারিগরি শ্রেষ্ঠত্বের চেয়ে লাইসেন্সিংয়ের সরলতা দিয়ে ঠিক হয়। HEVC কারিগরিভাবে ভালো ছিল; তবু ওয়েব AV1-এর দিকে গেছে।
(পুরোপুরি ঝামেলামুক্ত অবশ্য না — ২০২০ সালে Sisvel নামের একটা পুল দাবি করে AV1-এর জন্যও কিছু পেটেন্ট রয়্যালটি প্রযোজ্য। নেটফ্লিক্স আর গুগল প্রকাশ্যে দিতে অস্বীকার করেছে।)
এরপর কী: AV2, VVC, LCEVC
নেটফ্লিক্সের ২০২৫-এর লেখাটা শেষ হয়েছিল AV2-র অপেক্ষায়। সেটা এসে গেছে — AOMedia ২০২৬ সালের ৯ জুন AV2 প্রকাশের ঘোষণা দেয় (স্পেসিফিকেশন v1.0.0 তার কিছুদিন আগে, ২৯ মে)। AV1-এর মতোই AOMedia-র রয়্যালটি-মুক্ত পেটেন্ট নীতিতে।
AV2-তে কী আছে: প্রচলিত স্ট্রিমিং ও VOD ছাড়াও ভিডিও কনফারেন্সিং, স্টেরিওস্কোপিক ভিডিও, একাধিক ক্যামেরা অ্যাঙ্গেল, আর পেশাদার সিনেমা ও HDR-এর জন্য পরিকল্পিত ১২-বিট প্রোফাইল। রেফারেন্স সফটওয়্যার libavm, আর dav1d-এর দল একটা উচ্চ-ক্ষমতার সফটওয়্যার ডিকোডারের দিকে এগোচ্ছে।
তবে উত্তেজিত হওয়ার আগে পর্ব ১-এর নিয়মটা মনে করো — কোডেক তখনই কাজে লাগে যখন ডিভাইস সেটা চালাতে পারে। ২০২৬-এর মাঝামাঝি পর্যন্ত কোনো ফোন, টিভি বা সেট-টপ বক্সে AV2-র হার্ডওয়্যার ডিকোডার নেই; চালাতে হলে সফটওয়্যারে, আর সেটা AV1-এর চেয়ে অনেক ভারী। AV1-এর নিজের ইতিহাসই এখানে সবচেয়ে ভালো পথনির্দেশ: স্পেক ২০১৮, কিন্তু নেটফ্লিক্সের ৩০% ভিউতে পৌঁছাতে লেগেছে সাত বছর।
পাশে আরও দুটো নাম শোনা যাবে:
- VVC (H.266) — MPEG ধারার পরবর্তী কোডেক, কারিগরিভাবে শক্তিশালী, কিন্তু ওয়েবে গ্রহণযোগ্যতা সীমিত — আর কারণটা মূলত সেই একই লাইসেন্সিং প্রশ্ন।
- LCEVC — এটা প্রতিদ্বন্দ্বী কোডেক না, বরং একটা বাড়তি স্তর: নিচে একটা সাধারণ কোডেক (যেমন H.264) কম রেজলিউশনে চলে, আর তার উপরে একটা হালকা enhancement স্তর বিস্তারিত ফিরিয়ে আনে। পুরনো ডিভাইসের সাথে সামঞ্জস্য রেখেই কিছুটা লাভ পাওয়ার কৌশল।
ফরেনসিক ওয়াটারমার্কিং
পর্ব ৪-এর শুরুতে Cosmos-এর Studio Workflow-এর কথা বলতে গিয়ে “forensic watermarking” নামটা এসেছিল। জিনিসটা কী, সংক্ষেপে — কারণ প্রিমিয়াম কনটেন্টে এটা DRM-এর পরের ধাপ।
DRM আটকায় চুরি করা। কিন্তু কেউ যদি বৈধভাবে দেখে স্ক্রিন রেকর্ড করে ছড়িয়ে দেয়, DRM কিছুই করতে পারে না। ফরেনসিক ওয়াটারমার্কিং তখন অন্য প্রশ্নের উত্তর দেয়: ফাঁসটা কে করল?
কৌশলটা হলো প্রতিটা দর্শকের স্ট্রিমে একটা অদৃশ্য, ইউনিক চিহ্ন বসিয়ে দেওয়া — পিক্সেলের মান এমন সামান্য পরিমাণে বদলানো যা চোখে ধরা পড়ে না, কিন্তু বিশ্লেষণী সফটওয়্যার পড়তে পারে।
প্রতি দর্শকের জন্য আলাদা ভিডিও এনকোড করা তো অসম্ভব। তাই প্রচলিত পদ্ধতিটা চতুর: প্রতিটা সেগমেন্টের দুটো সংস্করণ বানানো হয় — ধরা যাক A আর B — যাদের ওয়াটারমার্ক আলাদা। এরপর প্রতিটা সেশনকে A আর B-এর একটা নিজস্ব ক্রম দেওয়া হয় (A-B-B-A-B-A…)। ফাঁস হওয়া ভিডিওতে ওই ক্রমটা পড়ে বলে দেওয়া যায় সেটা কোন সেশন থেকে এসেছিল।
এটা কেন গুরুত্বপূর্ণ: শাস্তিটা তখন পুরো প্ল্যাটফর্মে বিধিনিষেধ না হয়ে নির্দিষ্ট অ্যাকাউন্টে সীমিত থাকে।
৮. Open Connect — নেটফ্লিক্সের নিজের CDN
এনকোডিং যত ভালোই হোক, বিটগুলো দর্শকের কাছে পৌঁছাতে হবে। নেটফ্লিক্স ২০১১ সালে Open Connect শুরু করে — নিজের CDN, দুটো কারণে (ওদের নিজের ভাষায়):
- নেটফ্লিক্স ISP-দের নেটওয়ার্কে ট্রাফিকের বড় একটা অংশ হয়ে গিয়েছিল, তাই ওদের সাথে সরাসরি কাজ করা দরকার হলো।
- নিজেদের জন্য বানানো CDN-এ সক্রিয়, নির্দেশিত ক্যাশিং করা যায় — সাধারণ চাহিদা-ভিত্তিক CDN-এর চেয়ে অনেক বেশি দক্ষ, আর আপস্ট্রিম নেটওয়ার্কের উপর চাপ কয়েক অর্ডার অফ ম্যাগনিটিউড কমে যায়।
OCA — যন্ত্রটা
Open Connect Appliance (OCA) হলো বিশেষভাবে বানানো ক্যাশ সার্ভার। এর কাজ একটাই — এনকোড করা ভিডিও/ইমেজ ফাইল রেখে HTTP/HTTPS-এ ক্লায়েন্টকে দেওয়া। ব্যবহারকারীর কোনো ডেটা (ভিউয়িং হিস্ট্রি, DRM তথ্য, মেম্বার ডেটা) OCA-তে থাকে না।
স্থাপন করা হয় দুইভাবে:
- IXP-তে — ইন্টারনেট এক্সচেঞ্জ পয়েন্টে বসানো, ISP-দের সাথে settlement-free peering দিয়ে যুক্ত।
- ISP-র ভেতরে (embedded) — যোগ্য ISP-দের নেটফ্লিক্স বিনামূল্যে OCA দেয়। নেটফ্লিক্স দেয় হার্ডওয়্যার, ISP দেয় বিদ্যুৎ, জায়গা আর কানেক্টিভিটি। কোন গ্রাহক কোন OCA-তে যাবে, সেটা ISP নিজেই নিয়ন্ত্রণ করে।
কন্ট্রোল প্লেন AWS-এ
OCA শুধু দুটো কাজ করে: নিজের অবস্থা রিপোর্ট করে (health, BGP পিয়ার থেকে শেখা রুট, ডিস্কে কোন ফাইল আছে), আর কনটেন্ট সার্ভ করে। বাকি সব বুদ্ধি AWS-এ:
ধাপগুলো নেটফ্লিক্সের নিজের বর্ণনায়:
- OCA-রা নিয়মিত health, শেখা রুট আর ফাইলের তালিকা Cache Control Service (CCS)-কে জানায়।
- দর্শক প্লে চাপে।
- AWS-এর playback অ্যাপ অনুমতি আর লাইসেন্স যাচাই করে ঠিক করে কোন কোন ফাইল লাগবে — ডিভাইসের বৈশিষ্ট্য আর তখনকার নেটওয়ার্ক অবস্থা মাথায় রেখে।
- Steering Service (CODA) CCS-এর তথ্য দেখে ঠিক করে কোন OCA থেকে ফাইলগুলো দেওয়া হবে, আর সেই OCA-দের URL বানায়।
- URL-গুলো ডিভাইসে যায়, ডিভাইস সরাসরি OCA থেকে টানতে শুরু করে।
ফিল উইন্ডো — সবচেয়ে চতুর অংশ
সাধারণ CDN কাজ করে চাহিদা দেখে: কেউ চাইলে অরিজিন থেকে টেনে ক্যাশ করো। নেটফ্লিক্স এটা করে না, কারণ তারা আগে থেকেই জানে কী দেখা হবে।
তাই কনটেন্ট আর সফটওয়্যার আপডেট আগেভাগে, অফ-পিক “ফিল উইন্ডো”-তে পাঠানো হয় — যখন নেটওয়ার্ক খালি থাকে। আর OCA-রা একে অন্যের কাছ থেকেও আপডেট নিতে পারে, ফলে ব্যাকবোনের উপর চাপ আরও কমে।
কোন OCA-তে কী রাখা হবে, সেটা ঠিক করে কন্ট্রোল প্লেনের জনপ্রিয়তা-অ্যালগরিদম — লক্ষ্য দুটো: অফলোড দক্ষতা সর্বোচ্চ করা, আর ডিস্কের কনটেন্ট বারবার বদলানো (churn) কমানো।
এই দুটো লক্ষ্য একসাথে রাখাটাই আসল কারিগরি। শুধু জনপ্রিয়তা দেখলে প্রতি রাতে অর্ধেক ডিস্ক বদলে যাবে — যেটা নিজেই বিশাল ট্রাফিক।
হার্ডওয়্যার ডিজাইন আর সফটওয়্যার স্ট্যাকের অনেকটাই ওপেন সোর্স করা, আর কোনো OCA-র পারফরম্যান্স মান ছাড়িয়ে খারাপ হলে নেটফ্লিক্স সেটা বিনা খরচে বদলে দেয়।
৯. আমাদের জন্য নেওয়ার মতো কী
নেটফ্লিক্সের স্কেল আমাদের নেই, কিন্তু ধারণাগুলো স্কেল-নিরপেক্ষ:
কনভেক্স হালের যুক্তিটা যেকোনো আকারে খাটে। পুরো ক্যাটালগে ৩০০টা টেস্ট এনকোড চালানো লাগবে না — কয়েকটা প্রতিনিধি ক্লিপে চালিয়ে দেখো তোমার কনটেন্টে কোন বিটরেটে কোন রেজলিউশন জেতে। বেশিরভাগ প্ল্যাটফর্মে কনটেন্ট মোটামুটি একরকম হয় (স্ক্রিনকাস্ট, টকিং হেড, খেলা) — তাই একটা ভালো ল্যাডারই অনেক দূর নিয়ে যায়।
শটের সীমানায় কি-ফ্রেম বসানো সস্তা লাভ। ffmpeg-এ সিন-চেঞ্জ ডিটেকশন আছে; শর্ত শুধু একটাই — সব ল্যাডার ধাপে একই জায়গায় কি-ফ্রেম পড়তে হবে, নইলে ধাপ বদলানো ভাঙবে।
কোয়ালিটি মাপাকে এনকোডিং থেকে আলাদা রাখো। Reloaded-এর সবচেয়ে বড় শিক্ষা এটাই — VMAF হিসাবটা এনকোডারের ভেতরে থাকায় শুধু কোয়ালিটি আবার মাপতেও পুরোটা আবার এনকোড করতে হতো।
জটিলতার বিশ্লেষণ জমিয়ে রাখো। CAS-এর ফল ডেটাবেসে থাকে বলেই LGS-এর অ্যালগরিদম বদলে নতুন ল্যাডার বানানো সস্তা। তুমিও প্রতিটা ভিডিওর জটিলতার সংখ্যাগুলো জমিয়ে রাখলে ল্যাডার-সংস্করণ বদলানো অনেক কম যন্ত্রণার হবে।
ক্যাশ ভরার কাজটা চাহিদার আগে করা যায়। তোমার যদি জানা থাকে আগামীকাল কোন কোর্সটা রিলিজ হচ্ছে, সেটার সেগমেন্টগুলো আগেই CDN-এ গরম করে রাখা যায়। এটা Open Connect-এর মূল ধারণারই ছোট সংস্করণ।
সূত্র
সব সংখ্যা ও নাম নেটফ্লিক্সের নিজের প্রকাশনা থেকে:
- Per-Title Encode Optimization — ডিসেম্বর ২০১৫
- Dynamic optimizer — a perceptual video encoding optimization framework — মার্চ ২০১৮
- Optimized shot-based encodes: Now Streaming! — মার্চ ২০১৮
- Rebuilding Netflix Video Processing Pipeline with Microservices — জানুয়ারি ২০২৪
- The Making of VES: the Cosmos Microservice for Netflix Video Encoding — এপ্রিল ২০২৪
- AV1 — Now Powering 30% of Netflix Streaming — ডিসেম্বর ২০২৫
- Open Connect Overview — নেটফ্লিক্সের অফিসিয়াল ডকুমেন্ট
পরের পর্বে — Vimeo। সেখানে প্রশ্নটা উল্টো: যখন ভিডিওর সংখ্যা বিশাল আর প্রতিটার দর্শক কম, তখন এনকোডিং আর স্টোরেজের খরচটা কীভাবে সামলাবে?