২০২৬ সালে MP4 বনাম WebM: সঠিক ভিডিও ফরম্যাট, কোডেক ও কমপ্রেশনের মান বেছে নেওয়া

আপনি ভিডিও তৈরি করুন, পুরোনো ফাইল রূপান্তর করুন কিংবা ওয়েবসাইটের জন্য ভিডিও প্রস্তুত করুন—সব ক্ষেত্রেই সঠিক ফরম্যাট ও কমপ্রেশন সেটিংস বেছে নেওয়া গুরুত্বপূর্ণ। সবচেয়ে ছোট ফাইলই যে সবচেয়ে ভালো, তা নয়। ভিডিওটি ব্রাউজারে নির্ভরযোগ্যভাবে চলতে হবে, স্মার্টফোনে কাজ করতে হবে, সহজে ডিকোড হতে হবে এবং ব্যবহারের উদ্দেশ্য অনুযায়ী যথেষ্ট ভালো দৃশ্যমান মান বজায় রাখতে হবে।

আমি MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, x264 এনকোডারের প্রিসেট, ব্রাউজার সামঞ্জস্য, মোবাইলে হার্ডওয়্যার ডিকোডিং এবং ভিডিওর মান পরিমাপ নিয়ে অনুসন্ধান করেছি। একই মূল ভিডিও বিভিন্ন CRF মানে এনকোড করে দৃশ্যত ও বস্তুনিষ্ঠ মেট্রিকের সাহায্যে ফলাফল তুলনা করার বাস্তব পরীক্ষাও করেছি।

আমার চূড়ান্ত সিদ্ধান্ত ছিল H.264-সহ MP4-কে অগ্রাধিকার দেওয়া, যখন একটি মাত্র ভিডিও ফাইলকে যত বেশি সম্ভব ব্রাউজার, ফোন ও বাইরের অ্যাপ্লিকেশনে চালাতে হয়।

মূলত মোবাইলে দেখার ছোট ভিডিওর ক্ষেত্রে, যেখানে সূক্ষ্মতম সব বিবরণ ধরে রাখার চেয়ে দ্রুত লোড হওয়া ও ছোট ফাইল বেশি জরুরি, আমি x264 CRF 30 বেছে নিয়েছি। কারণ বড় ডেস্কটপ মনিটরেও স্বাভাবিক প্লেব্যাকের সময় CRF 22 ও 30-এর মধ্যে উল্লেখযোগ্য দৃশ্যমান পার্থক্য বুঝতে পারিনি।

তবে এই সিদ্ধান্তের একটি গুরুত্বপূর্ণ সীমা আছে: সিনেমা, উচ্চমানের ভিডিও প্রযোজনা কিংবা যেখানে সর্বোচ্চ দৃশ্যমান বিশ্বস্ততা জরুরি, সেখানে CRF 30 আমার সুপারিশ নয়। সেসব ক্ষেত্রে অনেক সতর্ক একটি মান—প্রায়ই CRF 20-এর আশপাশে—পরীক্ষা শুরু করার ভালো ভিত্তি হতে পারে। পূর্ণদৈর্ঘ্য চলচ্চিত্র বা উচ্চমানের সিনেমাটিক ফুটেজ নিয়ে আমি একই ধরনের পরীক্ষা করিনি; তাই ওই সেটিংসকে আলাদাভাবে পরীক্ষা করার প্রাথমিক প্রস্তাব হিসেবেই ধরতে হবে।

এই লেখায় আমি প্রযুক্তিগত যুক্তি, কমপ্রেশনের প্রকৃত ফলাফল, সেই ফলাফলের সীমাবদ্ধতা এবং আপনার নিজের প্রকল্পের জন্য উপযুক্ত ভিডিও ফরম্যাট ও মানের সেটিংস বেছে নেওয়ার উপায় ব্যাখ্যা করেছি।

1. ভিডিও কনটেইনার ও কোডেক এক জিনিস নয়

MP4 ও WebM তুলনা করার আগে কনটেইনার এবং কোডেকের পার্থক্য বোঝা দরকার।

একটি কনটেইনার একই ফাইলে ভিডিও, অডিও, টাইমস্ট্যাম্প ও মেটাডেটা রাখে। অন্যদিকে ভিডিও কোডেক নির্ধারণ করে ভিডিওর ফ্রেম কীভাবে কমপ্রেস ও ডিকোড হবে।

যেমন, MP4-এর ভেতরে H.264, HEVC অথবা AV1 ভিডিও থাকতে পারে। ফাইলের এক্সটেনশন একই হলেও এসব সমন্বয়ের কমপ্রেশনের বৈশিষ্ট্য ও ডিভাইসের চাহিদা আলাদা।

উপাদান	উদাহরণ	কাজ
ভিডিও কনটেইনার	MP4, WebM, MOV, MKV	ভিডিও, অডিও ও সময়সংক্রান্ত তথ্য একসঙ্গে রাখে
ভিডিও কোডেক	H.264, HEVC, VP9, AV1	ভিডিও ফ্রেম কমপ্রেস ও ডিকোড করে
অডিও কোডেক	AAC, Opus, MP3	অডিও কমপ্রেস ও ডিকোড করে
ভিডিও এনকোডার	x264, x265, SVT-AV1, libvpx-vp9	ভিডিও কমপ্রেশন বাস্তবায়ন করে

ফাইলের নামের .webm বদলে .mp4 করলেই ভিডিও কোডেক রূপান্তর হয় না। একইভাবে, MP4-এর মধ্যে AV1 রাখলেও AV1 ডিকোড করার সুবিধা নেই এমন ডিভাইসে ভিডিওটি চলবে না।

ভিডিওর সামঞ্জস্য নিয়ে আলোচনা করার সময় সব সময় পুরো সমন্বয়টি বিবেচনা করুন: কনটেইনার, ভিডিও কোডেক, অডিও কোডেক, কোডেক প্রোফাইল, বিট ডেপথ ও প্লেব্যাক পরিবেশ।

2. MP4 বনাম WebM: ওয়েব ভিডিওর জন্য কোনটি ভালো?

MP4 ও WebM—দুটিই আধুনিক ভিডিও কনটেইনার। কোনোটিই সব পরিস্থিতিতে শ্রেষ্ঠ নয়, কারণ ব্যবহারিক বৈশিষ্ট্য নির্ভর করে ভেতরে কোন কোডেক ব্যবহার করা হয়েছে তার ওপর।

H.264-সহ MP4: ব্যবহারিকভাবে সর্বাধিক সামঞ্জস্য

H.264 ভিডিও ও AAC অডিও-সহ MP4 বহুদিন ধরে বিস্তৃত সমর্থন পেয়ে আসছে। প্রধান ডেস্কটপ ও মোবাইল ব্রাউজার, অপারেটিং সিস্টেমের ভিডিও প্লেয়ার এবং অনেক তৃতীয় পক্ষের অ্যাপ্লিকেশনে এটি চলে।

স্মার্টফোন ও কম্পিউটারের হার্ডওয়্যার ভিডিও ডিকোডারও সাধারণত এটি সমর্থন করে। সফটওয়্যার ডিকোডিংয়ের তুলনায় হার্ডওয়্যার ডিকোডিং CPU-এর ব্যবহার কমাতে, প্লেব্যাক আরও দক্ষ করতে এবং বিদ্যুৎ খরচ কমাতে পারে।

এর প্রধান দুর্বলতা হলো কমপ্রেশন দক্ষতা। নতুন কোডেকগুলো প্রায়ই কম বিটরেটেই কাছাকাছি দৃশ্যমান মান দিতে পারে।

তবু সবচেয়ে ছোট ফাইল পাওয়ার চেয়ে নির্ভরযোগ্য প্লেব্যাক বেশি জরুরি হলে H.264 এখনও চমৎকার একটি পছন্দ।

VP9-সহ WebM: দক্ষ ও ব্রাউজারবান্ধব

WebM-এ সাধারণত VP8, VP9 বা AV1 ভিডিও থাকে; অডিওর জন্য প্রায়ই Opus বা Vorbis ব্যবহৃত হয়।

সমতুল্য দৃশ্যমান মানে VP9 প্রায়ই H.264-এর চেয়ে বেশি দক্ষতার সঙ্গে কমপ্রেস করে। Safari-র আধুনিক সংস্করণসহ বর্তমান ব্রাউজারগুলোতে এটি ব্যাপকভাবে সমর্থিত।

Safari একেবারেই WebM বা VP9 সমর্থন করে না—এমন দাবি ভুল হবে। সময়ের সঙ্গে ব্রাউজারের সামঞ্জস্য উল্লেখযোগ্যভাবে উন্নত হয়েছে।

বড় সীমাবদ্ধতাটি আসলে ব্রাউজারের বাইরে। অপারেটিং সিস্টেমের নিজস্ব অ্যাপ, পুরোনো ডিভাইস ও তৃতীয় পক্ষের সফটওয়্যার প্রচলিত H.264 MP4-এর মতো ধারাবাহিকভাবে WebM সামলাতে নাও পারে।

শুধু ব্রাউজারের জন্য তৈরি অ্যাপে, যেখানে প্লেব্যাকের সক্ষমতা নিয়ন্ত্রণ করা যায়, WebM ভালো বিকল্প। কিন্তু দর্শক যদি ভিডিও ডাউনলোড করে যেকোনো সফটওয়্যারে খোলেন, তাহলে MP4/H.264-এর আচরণ বেশি অনুমানযোগ্য।

ব্যবহারিক পার্থক্য

প্রয়োজন	MP4 + H.264	WebM + VP9
আধুনিক ব্রাউজারে প্লেব্যাক	চমৎকার	খুব ভালো
পুরোনো ব্রাউজার ও ডিভাইসে সমর্থন	সাধারণত বেশি বিস্তৃত	পরিবেশের ওপর বেশি নির্ভরশীল
ডাউনলোড করা ফাইলের সামঞ্জস্য	সাধারণত বেশি ভালো	নিজস্ব অ্যাপভেদে কম অনুমানযোগ্য
কমপ্রেশন দক্ষতা	ভালো	প্রায়ই আরও ভালো
হার্ডওয়্যার ডিকোডিং	অত্যন্ত বিস্তৃত	সাধারণ, তবে ডিভাইসভেদে ভিন্ন
সবচেয়ে উপযুক্ত ব্যবহার	একটি ফাইল, বিস্তৃত সামঞ্জস্য	পরিচিত ক্লায়েন্টে দক্ষ ওয়েব ডেলিভারি

মূল প্রশ্ন WebM ভালো ফরম্যাট কি না, তা নয়। আপনার নির্দিষ্ট পরিবেশে কমপ্রেশনের সুবিধা পাওয়ার জন্য সামঞ্জস্যের সীমাবদ্ধতা মেনে নেওয়া যুক্তিযুক্ত কি না, সেটাই আসল।

3. H.264 বনাম H.265 বনাম VP9 বনাম AV1: কোন কোডেক বেছে নেবেন?

প্রধান ভিডিও কোডেকগুলোর প্রতিটির কমপ্রেশন দক্ষতা, এনকোডিংয়ের খরচ, হার্ডওয়্যার সমর্থন, সফটওয়্যার সামঞ্জস্য ও লাইসেন্সিংয়ের মধ্যে ভারসাম্য আলাদা।

কোডেক	কমপ্রেশন দক্ষতা	ব্যবহারিক সামঞ্জস্য	সাধারণ ব্যবহার
H.264 / AVC	ভালো	চমৎকার	সাধারণ ওয়েব ভিডিও, মোবাইল প্লেব্যাক, ডাউনলোড
H.265 / HEVC	সাধারণত H.264-এর চেয়ে ভালো	পরিবেশভেদে ভিন্ন	সামঞ্জস্যপূর্ণ Apple ডিভাইস, নিয়ন্ত্রিত পরিবেশ, উচ্চ রেজোলিউশনের ভিডিও
VP9	সাধারণত H.264-এর চেয়ে ভালো	আধুনিক ব্রাউজারে খুব ভালো	ব্রাউজারভিত্তিক ভিডিও পরিবেশন
AV1	অত্যন্ত উচ্চ দক্ষতার সম্ভাবনা	সমর্থন বাড়ছে, তবে পুরোনো ডিভাইসে সীমাবদ্ধতা আছে	আধুনিক স্ট্রিমিং ও সামঞ্জস্যপূর্ণ ডিভাইস

এগুলো গুণগত তুলনা, সব ভিডিওর জন্য প্রযোজ্য কোনো বিটরেট র‌্যাঙ্কিং নয়। প্রকৃত দক্ষতা নির্ভর করে ভিডিওর বিষয়বস্তু, এনকোডারের বাস্তবায়ন, লক্ষ্য মান, এনকোডিং প্রিসেট ও পরিমাপপদ্ধতির ওপর।

H.264: পরিণত প্রযুক্তি, দ্রুত ডিকোডিং ও বিস্তৃত সমর্থন

H.264 অত্যন্ত অপ্টিমাইজড এবং বিপুলসংখ্যক হার্ডওয়্যার ও সফটওয়্যারে সমর্থিত। বিশেষ প্লেব্যাক অ্যাপ ছাড়াই ভিডিও নির্ভরযোগ্যভাবে চালাতে হলে এর দীর্ঘদিনের পরিপক্বতা বড় সুবিধা।

এর দুর্বলতা হলো, নতুন কোডেকগুলো প্রায়ই আরও দক্ষতার সঙ্গে ভিডিও কমপ্রেস করতে পারে। H.264-এর পেটেন্ট ও লাইসেন্সসংক্রান্ত বিষয়ও আছে; প্রাসঙ্গিক বাণিজ্যিক বিতরণের ক্ষেত্রে সেগুলো পর্যালোচনা করা উচিত।

H.265 / HEVC: ভালো কমপ্রেশন, তবে সামঞ্জস্যে কিছু ছাড়

একই রকম মানে HEVC, H.264-এর তুলনায় বিটরেট উল্লেখযোগ্যভাবে কমাতে পারে। উচ্চ রেজোলিউশনের ভিডিও এবং ডিভাইসের সামঞ্জস্য নিয়ন্ত্রণ করা যায় এমন পরিবেশে এটি বিশেষভাবে আকর্ষণীয়।

Apple-এর অনেক ডিভাইসে HEVC খুব ভালো চলে। তবে অপারেটিং সিস্টেম ও ইনস্টল করা ডিকোডিং উপাদানভেদে ব্রাউজার ও বাইরের অ্যাপ্লিকেশনের সমর্থন বদলে যায়। লাইসেন্সিংও বিবেচনার বিষয়।

HEVC খুব ভালো পছন্দ হতে পারে, কিন্তু সাধারণ ওয়েবসাইটে ডাউনলোডের জন্য আমি এটিকে স্বয়ংক্রিয়ভাবে একমাত্র ভিডিও ফরম্যাট করতাম না।

VP9: ব্যবহারিক উন্মুক্ত বিকল্প

VP9 ভালো কমপ্রেশন ও আধুনিক ব্রাউজারে বিস্তৃত সামঞ্জস্য দেয়। ভিডিও যদি ব্রাউজারেই দেখা হয় এবং প্লেব্যাক পরিবেশ অনুমানযোগ্য থাকে, তবে এটি আকর্ষণীয় বিকল্প।

আমার ক্ষেত্রে এর প্রধান অসুবিধা ছিল অনিশ্চয়তা: ব্যবহারকারী ভিডিও ডাউনলোড করে এমন নিজস্ব অ্যাপে খুলতে পারেন, যেগুলো ধারাবাহিকভাবে WebM বা VP9 সমর্থন করে না।

AV1: চমৎকার দক্ষতা, তবে হার্ডওয়্যারের সমর্থন সর্বজনীন নয়

AV1 আধুনিক ভিডিও কোডেকগুলোর মধ্যে অন্যতম সম্ভাবনাময়। পুরোনো কোডেকের তুলনায় এটি উল্লেখযোগ্য বিটরেট সাশ্রয় করতে পারে, আর হার্ডওয়্যার ডিকোডিংয়ের সমর্থন ক্রমেই বাড়ছে।

তবু পুরোনো ডিভাইসে AV1 ডিকোডার নাও থাকতে পারে, কিংবা সফটওয়্যার দিয়ে ডিকোড করতে হতে পারে। উচ্চ রেজোলিউশনের ভিডিও সফটওয়্যারে ডিকোড করলে CPU ও ব্যাটারি বেশি খরচ হতে পারে এবং দুর্বল ডিভাইসে প্লেব্যাকের সমস্যা দেখা দিতে পারে।

আপনি যদি প্লেব্যাক পরিবেশ নিয়ন্ত্রণ করেন, AV1 গুরুত্ব দিয়ে বিবেচনার যোগ্য। কিন্তু একটি ফাইলকেই পুরোনো-নতুন সব ডিভাইস ও সাধারণ বাইরের ভিডিও প্লেয়ারে চালাতে হলে H.264 এখনও নিরাপদ প্রাথমিক পছন্দ।

MDN-এর ভিডিও কোডেক নির্দেশিকায় এসব কোডেক ও ব্রাউজারে সেগুলো চালানোর প্রয়োজনীয়তা সম্পর্কে বিস্তারিত তথ্য আছে।

4. একটি ভিডিও ফরম্যাট, নাকি একাধিক সংস্করণ?

ভিডিও পরিবেশনের ক্ষেত্রে এটি সবচেয়ে গুরুত্বপূর্ণ স্থাপত্যগত সিদ্ধান্তগুলোর একটি।

একাধিক সংস্করণ রাখা সম্ভব হলে ওয়েবসাইট সামঞ্জস্যপূর্ণ ডিভাইসে AV1 বা VP9 এবং অন্য পরিবেশে বিকল্প হিসেবে H.264 দিতে পারে। এতে ব্যাপক প্লেব্যাক সমর্থন বজায় রেখেও কমপ্রেশন দক্ষতা বাড়ানো সম্ভব।

কিন্তু একাধিক সংস্করণ রক্ষণাবেক্ষণ করলে এনকোডিং, স্টোরেজ, ক্যাশিং, যাচাই এবং প্লেব্যাকের জন্য সংস্করণ নির্বাচন—সবকিছুই বেশি জটিল হয়।

প্রতিটি মূল ভিডিওর জন্য যদি ঠিক একটি চূড়ান্ত ভিডিও ফাইল দরকার হয়, তাহলে সাধারণত সামঞ্জস্যকে অগ্রাধিকার দেওয়াই ভালো।

আমি MP4/H.264 বেছেছি, কারণ বিকল্প ফরম্যাটের ওপর নির্ভর না করে একই ফাইলকে প্রধান ব্রাউজার, স্মার্টফোন এবং সাধারণ ডাউনলোড-পরবর্তী প্লেব্যাকের কাজে চালাতে চেয়েছি।

এর অর্থ এই নয় যে MP4/H.264-তেই সবচেয়ে ভালো কমপ্রেশন হয়। এটি নতুন কোডেকের সম্ভাব্য ছোট ফাইলের সুবিধার চেয়ে নিশ্চিত প্লেব্যাককে গুরুত্ব দেওয়ার সিদ্ধান্ত।

5. মোবাইল ভিডিওর অগ্রাধিকার আলাদা কেন

ভিডিও কীভাবে দেখা হবে, কমপ্রেশনের সিদ্ধান্তে সেটাই প্রতিফলিত হওয়া উচিত।

মূলত স্মার্টফোনে দেখা ছোট ক্লিপের চাহিদা বড় টেলিভিশনে দেখা পূর্ণদৈর্ঘ্য চলচ্চিত্রের চেয়ে আলাদা। প্রথম ক্ষেত্রে সূক্ষ্ম দৃশ্যগত বিবরণ ধরে রাখার তুলনায় দ্রুত লোড হওয়া ও কম মোবাইল ডেটা ব্যবহার বেশি মূল্যবান হতে পারে। দ্বিতীয় ক্ষেত্রে ছবির মানই প্রধান লক্ষ্য হতে পারে।

মোবাইলের জন্য তৈরি ছোট ভিডিওতে ফাইল ছোট রাখার কয়েকটি সুবিধা আছে:

• প্লেব্যাক শুরুর আগে কম ডেটা পাঠাতে হয়।
• সীমিত গতির সংযোগে ডাউনলোড দ্রুত শেষ হতে পারে।
• ডিভাইসে কম স্টোরেজ লাগে।
• ব্যবহারকারীর কম মোবাইল ডেটা খরচ হয়।
• এনকোড করা ভিডিওর বিটরেট কম হলে সীমিত ডেটা পরিবহনগতিতেও প্লেব্যাক আরও স্থিতিশীল হতে পারে।

তবে ফাইল ছোট হলেই ভিডিও কখনো বাফার বা আটকে যাবে না, এমন নিশ্চয়তা নেই। নেটওয়ার্কের ওঠানামা, সর্বোচ্চ বিটরেট, সার্ভারের আচরণ, প্লেব্যাক বাফারিং এবং ডিভাইসের ডিকোডিং ক্ষমতাও গুরুত্বপূর্ণ।

মোবাইলে সামঞ্জস্য শুধু ফাইল এক্সটেনশনের ওপর নির্ভর করে না। হার্ডওয়্যার ডিকোডিং, কোডেক প্রোফাইল ও লেভেল, বিট ডেপথ, ক্রোমা সাবস্যাম্পলিং, রেজোলিউশন, ফ্রেমরেট এবং সর্বোচ্চ বিটরেট—সবই বিবেচ্য। 390 CSS পিক্সেল প্রস্থে দেখানো ভিডিও উচ্চ পিক্সেল-ঘনত্বের ফোনে বাস্তবে অনেক বেশি ফিজিক্যাল পিক্সেল জুড়ে থাকতে পারে। ফলে ফ্রেমকে 390 পিক্সেল প্রস্থে নামিয়ে পরীক্ষা করা আর ওই ফোনে আসল ভিডিও দেখা এক জিনিস নয়। বাস্তব ডিভাইস ও প্রকৃত প্লেব্যাক পরিস্থিতিতে পরীক্ষা করুন।

CRF সুনির্দিষ্ট সর্বোচ্চ বিটরেট বেঁধে দেয় না; এটি মান নিয়ন্ত্রণ করে। মোট ফাইল তুলনামূলক ছোট হলেও জটিল দৃশ্যের ভিডিওতে অনেক উঁচু বিটরেটের অংশ থাকতে পারে। বিশেষভাবে ধীর সংযোগেও নির্ভরযোগ্য প্লেব্যাক জরুরি হলে নির্দিষ্ট বিটরেট বা VBV সীমা, উপযুক্ত রেজোলিউশন সীমা এবং বাস্তব নেটওয়ার্ক পরিস্থিতিতে পরীক্ষা বিবেচনা করুন।

মূল নীতিটি সহজ: কাল্পনিক সর্বোচ্চ মানের লক্ষ্য নয়, দর্শক আসলে যেভাবে ভিডিওটি দেখবেন, সেই অভিজ্ঞতার জন্য অপ্টিমাইজ করুন।

6. x264-এর CRF বোঝা: কম মানে ভালো গুণমান, বেশি মানে ছোট ফাইল

H.264 বেছে নেওয়ার পরের চ্যালেঞ্জ হলো ভিডিও কতটা বেশি কমপ্রেস করা হবে, তা ঠিক করা।

x264-এ Constant Rate Factor বা CRF দৃশ্যগত বিবরণ কতটা থাকবে এবং ফাইল কত বড় হবে—এই দুইয়ের মধ্যে ভারসাম্য নিয়ন্ত্রণ করে।

সাধারণত CRF কম হলে মান ভালো হয় কিন্তু ফাইল বড় হয়। CRF বেশি হলে ফাইল ছোট হয়, তবে কমপ্রেশনের কারণে মান আরও কমে।

CRF সুনির্দিষ্ট বিটরেট বা আউটপুট ফাইলের আকার নির্ধারণ করে না। এনকোডার মূল ভিডিওর বৈশিষ্ট্য অনুযায়ী বিট বরাদ্দ করে। তাই একই CRF-এ সরল দৃশ্য এবং অনেক সূক্ষ্ম বিবরণযুক্ত দৃশ্যের ফাইলের আকার অনেক আলাদা হতে পারে।

CRF ডিকোডারের মৌলিক সামঞ্জস্যও নির্ধারণ করে না। CRF 22 ও CRF 30 দিয়ে সঠিকভাবে এনকোড করা দুটি H.264 ভিডিওর কোডেক, প্রোফাইল, লেভেল, পিক্সেল ফরম্যাট, মাত্রা ও ফ্রেমরেট একই থাকতে পারে।

মূল পার্থক্য থাকে কমপ্রেশনের মান ও বিটরেটের বৈশিষ্ট্যে।

গুরুত্বপূর্ণ বিষয় হলো, ভিন্ন কোডেকের এনকোডারে ব্যবহৃত CRF সংখ্যাগুলো সরাসরি তুলনাযোগ্য নয়। x264-এ CRF 30 হলে যে দৃশ্যমান মান পাওয়া যায়, AV1 এনকোডারে CRF 30-এ একই মান পাওয়া যাবে এমন নয়।

7. আমার বাস্তব কমপ্রেশন পরীক্ষা: CRF 22 থেকে 32

স্বাভাবিক প্লেব্যাকের সময় পার্থক্য চোখে পড়ার আগপর্যন্ত কতটা কমপ্রেশন করতে পারি, তা জানতে চেয়েছিলাম।

আগে থেকেই কমপ্রেস করা একটি ছোট ভিডিও নিয়ে CRF 22, 24, 26, 28, 29, 30, 31 ও 32-এ H.264 তুলনামূলক ফাইল তৈরি করেছি।

রেজোলিউশন, ফ্রেমরেট, সময়কাল ও মোট ফ্রেমসংখ্যাসহ ভিডিওর গুরুত্বপূর্ণ বৈশিষ্ট্য অপরিবর্তিত রেখেছি। এনকোডারের সেটিংসও একই রেখেছি, যাতে CRF পরিবর্তনের প্রভাব তুলনা করা যায়।

ফলাফলে ফাইলের আকারে বড় পার্থক্য দেখা গেছে।

CRF	মূল ফাইলের তুলনায় আনুমানিক আকার	এর অর্থ
22	63%	তুলনামূলক সতর্ক কমপ্রেশন, বেশি সূক্ষ্ম বিবরণ বজায় থাকে
24	49%	ফাইল ছোট হয়, মানের কিছু অতিরিক্ত ক্ষতি হয়
26	38%	যথেষ্ট বিবরণ রেখেও আরও সাশ্রয়
28	30%	মূল ভিডিওর সঙ্গে বেশ ভালো মিল রেখে ছোট আউটপুট
29	26%	আরও আক্রমণাত্মক কমপ্রেশন
30	23%	এই পরীক্ষিত ভিডিওর জন্য আমার পছন্দের ভারসাম্য
31	21%	মূল ভিডিওর প্রতি বিশ্বস্ততা কমিয়ে বাড়তি সাশ্রয়
32	19%	পরীক্ষার সবচেয়ে ছোট ফাইল এবং পরিমাপে সবচেয়ে বেশি মানের ক্ষতি

এই শতাংশগুলো পরীক্ষিত মূল ভিডিওর ওপর নির্ভরশীল; সব ভিডিওতে সাধারণত এমন সাশ্রয় হয় বলে ধরে নেওয়া যাবে না। টেবিলের প্রতিটি শতাংশ আলাদাভাবে পূর্ণসংখ্যায় প্রকাশ করা হয়েছে। নির্ভুল আপেক্ষিক সাশ্রয় জানতে গোল করা মানগুলোকে ভাগ না করে প্রকৃত ফাইলের আকার ব্যবহার করুন।

সবচেয়ে অবাক করা ফল ছিল, বড় ডেস্কটপ মনিটরেও স্বাভাবিক প্লেব্যাকের সময় CRF 22 ও CRF 30-এর মধ্যে অর্থপূর্ণ দৃশ্যগত পার্থক্য আমার চোখে পড়েনি।

CRF 32-সহ আরও বেশি কমপ্রেস করা সংস্করণও দেখেছি। নির্দিষ্ট ওই ক্লিপটি সাধারণভাবে চালানোর সময় তাতেও উল্লেখযোগ্য পার্থক্য বুঝতে পারিনি।

এটি গুরুত্বপূর্ণ ছিল, কারণ ওই ভিডিওগুলো মূলত ছোট মোবাইল স্ক্রিনে দেখার জন্য তৈরি। আমার ডেস্কটপ মনিটরে যদি মানের ক্ষতি বিরক্তিকর না হয়, তাহলে দর্শকের অভিজ্ঞতা উন্নত না করা বাড়তি বিবরণের জন্য ফাইল অনেক বড় রাখার তেমন যুক্তি দেখিনি।

তবে এটি এক ধরনের মূল ভিডিও নিয়ে আমার ব্যক্তিগত পর্যবেক্ষণ। সব ব্যবহারকারী, সব স্মার্টফোন বা সব ভিডিওতেই একই ফল হবে—এটি তার প্রমাণ নয়। ঘন পিক্সেলযুক্ত মোবাইল স্ক্রিনে কাছ থেকে দেখলে, বিশেষত সূক্ষ্ম বিবরণ বা গ্রেডিয়েন্টে, কমপ্রেশনের ত্রুটি ধরা পড়তে পারে।

8. বস্তুনিষ্ঠ পরিমাপে মানের প্রকৃত ক্ষতি নিশ্চিত হয়েছে

চালানোর সময় পার্থক্য চোখে না পড়ার অর্থ দুটি ভিডিও গাণিতিকভাবে অভিন্ন নয়।

আমি বস্তুনিষ্ঠ ছবির মানের মেট্রিক দিয়েও এনকোড করা আউটপুটগুলো তুলনা করেছি। CRF বাড়ার সঙ্গে মূল ভিডিওর মিল কমেছে।

উচ্চ পিক্সেল-ঘনত্বের মোবাইল ডিসপ্লের কাছাকাছি পরিস্থিতি বোঝাতে ধারাবাহিকভাবে আকার কমিয়ে করা তুলনায় কিছু প্রতিনিধিত্বমূলক SSIM পরিমাপ ছিল:

CRF	আনুমানিক SSIM	CRF 28-এর তুলনায় আউটপুটের আকার
22	0.9934	2.13×
28	0.9869	1.00×
30	0.9837	0.79×
32	0.9795	0.63×

প্রবণতাটি স্পষ্ট: বেশি কমপ্রেশন করলে পরিমাপে এনকোড করা ভিডিওর বিশ্বস্ততা কমেছে। ভালো করে দেখলে সূক্ষ্ম রেখা ও টেক্সচারেও সামান্য পার্থক্য দেখা গেছে।

তারপরও পরীক্ষিত ভিডিওটি সাধারণভাবে দেখার অভিজ্ঞতা প্রায় একই ছিল। ঠিক এই কারণেই বস্তুনিষ্ঠ পরিমাপের সঙ্গে ব্যক্তিগত দৃশ্যমান মূল্যায়নও ব্যবহার করা উচিত।

SSIM ছবির মিল পরিমাপ করে, মানুষের সম্পূর্ণ দেখার অভিজ্ঞতা নয়। সময়ের সঙ্গে বদলানো কমপ্রেশন-ত্রুটি, দৃশ্যমান তীক্ষ্ণতা, গতির আচরণ বা পৃথক বিবরণের ব্যক্তিগত গুরুত্ব—এসব পুরোপুরি ধরতে পারে না।

VMAF দৃশ্যমান মান পরিমাপের আরেকটি কার্যকর মেট্রিক। Netflix জুন 2026-এ VMAF v1 মডেলগুলো প্রকাশ করে; এর মধ্যে ফোনে দেখার পরিস্থিতির জন্য তৈরি একটি মডেলও আছে। এসব মডেল স্বীকার করে যে অনুভূত ছবির মান আংশিকভাবে পর্দার আকার ও দেখার আপেক্ষিক দূরত্বের ওপর নির্ভর করে।

গবেষণায় তুলনামূলক সতর্কভাবে এনকোড করা একটি নমুনার গড় VMAF প্রায় 95 বলে জানানো হয়েছিল, কিন্তু বেশি CRF-এ করা সব এনকোডের জন্য সামঞ্জস্যপূর্ণ VMAF ফলাফলের সারি ছিল না। তাই CRF 30 বা 32 কোনো সর্বজনীন মানের সীমা পূরণ করেছে—এমন দাবি করতে আমি VMAF ব্যবহার করিনি।

ব্যবহারিক সিদ্ধান্তটি আরও সীমিত: পরীক্ষিত ছোট ভিডিওটি স্বাভাবিক প্লেব্যাকের সময় H.264-এর আক্রমণাত্মক কমপ্রেশন খুব ভালোভাবে সহ্য করেছে।

9. ছোট মোবাইল ভিডিওর জন্য কেন CRF 30 বেছেছি

ফাইলগুলো তুলনা করার পর আমি মূলত মোবাইলে দেখা হয় এমন একই ধরনের ছোট ভিডিওর জন্য CRF 30 বেছে নিই।

কারণগুলো ছিল সহজ:

• ভিডিওগুলো ছোট; সিনেমার মতো ছবির মান দেওয়ার উদ্দেশ্য ছিল না।
• দ্রুত লোড হওয়া ও ছোট ডাউনলোড গুরুত্বপূর্ণ ছিল।
• বড় ডেস্কটপ মনিটরে CRF 22 ও 30-এর মধ্যে অর্থপূর্ণ পার্থক্য আমার চোখে পড়েনি।
• CRF 30-এ সতর্ক সেটিংসের তুলনায় অনেক ছোট ফাইল তৈরি হয়েছে।
• পরীক্ষিত নমুনায় CRF 32-ও দেখতে গ্রহণযোগ্য ছিল, কিন্তু আরও জটিল ভিডিওর ক্ষেত্রে তা কম ভরসা দিয়েছে।

CRF 28-এর তুলনায় CRF 30 পরীক্ষিত আউটপুটের আকার আনুমানিক 21% কমিয়েছে। CRF 22-এর তুলনায় তা 60%-এর বেশি কমিয়েছে।

ছোট মোবাইল ক্লিপে যদি লক্ষ্য হয় দেখতে ভালো ছবি, দ্রুত লোড হওয়া ও যুক্তিসংগত ব্যান্ডউইথ খরচ, তাহলে এই বিনিময় আমার কাছে সার্থক ছিল।

তবে শর্তটি অত্যন্ত গুরুত্বপূর্ণ: আমি 30 বেছেছি পরীক্ষিত ভিডিওর ফলাফল ও তা আসলে যেভাবে দেখা হবে তার ভিত্তিতে; স্মার্টফোনের জন্য 30 স্বভাবতই সেরা CRF বলে নয়।

মোবাইল ডিভাইসে CRF 30 ব্যবহার করতেই হবে, এমন নয়। সেটি অনেক বেশি বিশ্বস্ততার ভিডিওও ভালোভাবে দেখাতে পারে। মান কিছুটা কমিয়ে ফাইল ছোট করা গ্রহণযোগ্য হলে CRF 30 সেই বিনিময়ের একটি সচেতন সিদ্ধান্ত।

অনেক ভিন্ন ধরনের ভিডিওর সংগ্রহে এটি প্রয়োগ করার আগে জটিল গতিবিধি, অন্ধকার দৃশ্য, গ্রেডিয়েন্ট, লেখা ও সূক্ষ্ম টেক্সচার আছে—এমন কয়েকটি প্রতিনিধিত্বমূলক ক্লিপ পরীক্ষা করতাম।

10. সিনেমা বা উচ্চমানের ভিডিওর জন্য কেন আমি CRF 30 সুপারিশ করি না

এটাই পরীক্ষাটির সবচেয়ে গুরুত্বপূর্ণ সীমাবদ্ধতা।

আমার CRF 30-এর ফলাফল না ভেবে পূর্ণদৈর্ঘ্য চলচ্চিত্র, প্রিমিয়াম ভিডিও, পেশাদার ফুটেজ কিংবা বড় পর্দায় দেখার ভিডিওতে প্রয়োগ করবেন না।

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

সাধারণ উচ্চমানের 1080p ভিডিওর ক্ষেত্রে আমি x264-এর আরও সতর্ক সেটিং, প্রায় CRF 20 থেকে শুরু করে বিষয়বস্তু অনুযায়ী এর আশপাশের মানগুলো যাচাই করতাম।

দৃশ্যমান বিশ্বস্ততা গুরুত্বপূর্ণ হলে CRF 18–22 দিয়ে পরীক্ষা শুরু করা ব্যবহারিক হতে পারে। তবে রেজোলিউশন, বিষয়বস্তু ও চাহিদা অনুযায়ী উপযুক্ত মান এই সীমার বাইরেও যেতে পারে।

এই পরামর্শ প্রচলিত এনকোডিং নির্দেশিকার সঙ্গে সামঞ্জস্যপূর্ণ। যেমন, HandBrake-এর মানসংক্রান্ত নির্দেশিকায় অনেক 1080p x264 ব্যবহারের জন্য আনুমানিক RF 20–24 সুপারিশ করা হয়েছে।

পূর্ণদৈর্ঘ্য চলচ্চিত্র বা উচ্চমানের সিনেমাটিক ফুটেজে একই ধরনের নিয়ন্ত্রিত পরীক্ষা আমি করিনি। তাই CRF 20 সব ক্ষেত্রে সেরা, CRF 22 সব সময় যথেষ্ট, কিংবা কোনো নির্দিষ্ট চলচ্চিত্র CRF 30-এ দেখতে খারাপ হবেই—এমন দাবি করতে পারি না।

সঠিক পদ্ধতি হলো প্রতিনিধিত্বমূলক দৃশ্য বেছে নিয়ে কয়েকটি মানে এনকোড করা, উদ্দেশ্য অনুযায়ী ব্যবহৃত ডিসপ্লেতে তুলনা করা, তারপর কোথায় বেশি কমপ্রেশন স্পষ্টভাবে ক্ষতিকর হচ্ছে তা নির্ধারণ করা।

ভিডিওটি যদি আর্কাইভে রাখতে, আবার সম্পাদনা করতে বা ভবিষ্যতের এনকোডের উৎস হিসেবে ব্যবহার করতে হয়, তাহলে পরিবেশনের জন্য কমপ্রেস করা সংস্করণ থেকে আলাদা উচ্চমানের মূল মাস্টার সংরক্ষণ করা উচিত।

11. কেন x264-এর veryslow প্রিসেট ব্যবহার করেছি

CRF কমপ্রেশনের মানের একটি দিক নিয়ন্ত্রণ করে। আর x264 প্রিসেট নির্ধারণ করে আরও দক্ষভাবে এনকোড করার সিদ্ধান্ত খুঁজতে এনকোডার কতটা পরিশ্রম করবে।

x264-এ খুব দ্রুত থেকে খুব ধীর পর্যন্ত নানা প্রিসেট আছে। সাধারণভাবে ধীর প্রিসেট বেশি CPU সময় ব্যবহার করে এবং একই ধরনের দৃশ্যমান মানে আরও দক্ষ কমপ্রেশন দিতে পারে।

একই মূল ভিডিওতে medium ও veryslow প্রিসেট তুলনা করেছি। পরীক্ষিত মানের সেটিংসে veryslow ছোট ফাইল তৈরি করেছে।

যে ভিডিও একবার অফলাইনে এনকোড করে বহুবার ব্যবহার করা হবে, সেখানে অতিরিক্ত প্রসেসিংয়ের সময়টি সার্থক হতে পারে।

তাই আমি -preset veryslow বেছে নিয়েছি।

তবে এটি সব ক্ষেত্রেই সেরা নয়। ভিডিও সঙ্গে সঙ্গে প্রসেস করতে হলে, CPU ব্যয়বহুল হলে বা বিপুল পরিমাণ বাকি কাজ থাকলে slow কিংবা medium পরিচালনাগতভাবে বেশি ভারসাম্যপূর্ণ হতে পারে।

প্রিসেট মূলত এনকোডিংয়ের জটিলতা ও কমপ্রেশন দক্ষতা বদলায়। এতে H.264 অন্য কোডেকে পরিণত হয় না, কিংবা তৈরি ফাইলটি স্বভাবতই মোবাইলে অসামঞ্জস্যপূর্ণ হয়ে যায় না।

12. অ্যানিমে ভিডিওর জন্য আমি x264-এর animation tune ব্যবহার করি

মূল ভিডিওতে আঁকা অ্যানিমেশন বা অ্যানিমে-ধাঁচের ছবি থাকলে আমি x264-এর সঙ্গে -tune animation ব্যবহার করি।

এটি CRF সেটিং থেকে আলাদা। নির্দিষ্ট দৃশ্যগত বৈশিষ্ট্যের সঙ্গে মানিয়ে নিতে tune এনকোডারের কিছু সিদ্ধান্ত বদলায়। animation tune আঁকা রেখার প্রান্ত, সমতল রঙের অংশ ও স্টাইলাইজড গতিবিধি আছে এমন ভিডিওর জন্য তৈরি।

তাই আমার পছন্দ হলো:

• অ্যানিমে বা আঁকা অ্যানিমেটেড ভিডিও: -preset veryslow -tune animation।
• সাধারণ বাস্তব দৃশ্যের ফুটেজ: স্বয়ংক্রিয়ভাবে animation tune চালু করবেন না; এনকোডারের ডিফল্ট সেটিংস দিয়ে শুরু করুন অথবা অন্য উপযুক্ত tune আলাদাভাবে পরীক্ষা করুন।

tune-এর কাজ ভুলভাবে বোঝা উচিত নয়। -tune animation দৃশ্যমান মান নিশ্চিতভাবে ভালো করবে বা ফাইল ছোট করবে—এমন নিশ্চয়তা নেই। এটি এনকোডারের আচরণ বদলায়; ফল ভিডিওর বৈশিষ্ট্যের ওপর নির্ভর করে।

আমি একই CRF রেখে animation tune-সহ একটি পৃথক তুলনা করেছি। ওই নির্দিষ্ট তুলনায় tune চালু করলে ফাইল আনুমানিক 6% বড় হয় এবং পরিমাপে ছবির মিল সামান্য বাড়ে। চোখে দেখা পার্থক্য খুব কম ছিল।

CRF 22–32-এর মূল ফাইল-আকারের তুলনাটি animation tune ছাড়াই করা হয়েছে। ফলে -tune animation চালু করলেও সেই পরীক্ষার ফাইলের নির্দিষ্ট আকার ও কমপ্রেশন অনুপাত অপরিবর্তিত থাকবে, এমন ধরে নেওয়া যাবে না।

তারপরও অ্যানিমে ফুটেজের জন্য আমি animation-নির্দিষ্ট tune পছন্দ করি এবং ওই বিষয়বস্তুর এনকোডিং প্রোফাইলের অংশ হিসেবে তার ফাইলের আকার ও মান মূল্যায়ন করি।

এনকোডারের tune-কে সব ক্ষেত্রের মানোন্নয়ন না ভেবে বিষয়বস্তু অনুযায়ী সমন্বয় হিসেবে দেখা উচিত।

13. মোবাইলে দেখার ছোট অ্যানিমে ভিডিওর জন্য আমার প্রস্তাবিত FFmpeg সেটিংস

প্রচলিত SDR অ্যানিমে ভিডিও সত্যিই ট্রান্সকোড করার প্রয়োজন হলে, শুরুতে আমি এই কমান্ডের প্রোফাইলটি ব্যবহার করতাম:

ffmpeg -i input.mp4 \
  -map 0:v:0 -map '0:a:0?' \
  -c:v libx264 \
  -preset veryslow \
  -tune animation \
  -crf 30 \
  -profile:v high \
  -pix_fmt yuv420p \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output.mp4

এই কমান্ডে মূল সিদ্ধান্তগুলো স্পষ্ট করা হয়েছে:

• -c:v libx264 সফটওয়্যার H.264 এনকোডার ব্যবহার করে।
• -preset veryslow এনকোডিংয়ের গতির চেয়ে কমপ্রেশন দক্ষতাকে অগ্রাধিকার দেয়।
• -tune animation অ্যানিমেশনের উপযোগী এনকোডার সমন্বয় চালু করে।
• -crf 30 এ ধরনের ছোট ভিডিওর জন্য নির্বাচিত আক্রমণাত্মক স্থির-মানের লক্ষ্য প্রয়োগ করে।
• -profile:v high আধুনিক ডিভাইসে সাধারণত সমর্থিত H.264 প্রোফাইল নির্বাচন করে।
• -pix_fmt yuv420p 8-বিট 4:2:0 ভিডিও আউটপুট দেয়।
• -map 0:v:0 প্রথম ভিডিও স্ট্রিম নির্বাচন করে।
• -map '0:a:0?' প্রথম অডিও স্ট্রিমটি থাকলে তা নির্বাচন করে।
• -c:a aac -b:a 128k অডিও থাকলে সেটি প্রচলিত AAC ফরম্যাটে এনকোড করে।
• -movflags +faststart MP4-এর প্রাথমিক মেটাডেটা ফাইলের শুরুর দিকে সরিয়ে দেয়।

এটি একটি উদাহরণ, সব ইনপুটের জন্য সর্বজনীন কমান্ড নয়। আপনার মূল ভিডিওর নির্দিষ্ট বৈশিষ্ট্যের জন্য অতিরিক্ত ব্যবস্থা লাগতে পারে।

বিশেষ করে HDR ও 10-বিট ভিডিওকে যথাযথ রঙ ব্যবস্থাপনা ছাড়া অন্ধভাবে 8-বিট SDR-এ রূপান্তর করবেন না। তাতে রঙ ভুল হতে পারে, উজ্জ্বল অংশের বিবরণ হারাতে পারে বা দৃশ্যমান ব্যান্ডিং তৈরি হতে পারে। ঘোরানোর মেটাডেটা, পরিবর্তনশীল ফ্রেমরেট, নমুনা পিক্সেলের অনুপাত, ইন্টারলেসড ভিডিও, অস্বাভাবিক অডিও বিন্যাস এবং অসামঞ্জস্যপূর্ণ রেজোলিউশন সীমার দিকেও নজর দিতে হবে।

মূল ভিডিওর ফ্রেমরেট ও মাত্রা উপযুক্ত থাকলে সেগুলো অপরিবর্তিত রাখলে সাধারণত তুলনা সহজ হয় এবং অপ্রয়োজনীয় স্কেলিং বা গতির পরিবর্তন এড়ানো যায়। বিশেষ প্রয়োজন না হলে পরিবর্তনশীল ফ্রেমরেটের ভিডিওতে জোর করে স্থির ফ্রেমরেট বসাবেন না: এতে ফ্রেম নকল বা বাদ পড়তে পারে। আকার বদলালে প্রদর্শনের আনুপাতিক মাত্রা বজায় রাখুন এবং নির্বাচিত 4:2:0 পিক্সেল ফরম্যাটের সঙ্গে মাত্রা সামঞ্জস্যপূর্ণ কি না নিশ্চিত করুন। খুব বেশি রেজোলিউশন, ফ্রেমরেট বা H.264 লেভেল পুরোনো ডিভাইসের ডিকোডিং সীমা ছাড়িয়ে যেতে পারে। তাই সামঞ্জস্যের জন্য কখনো ইচ্ছাকৃতভাবে রেজোলিউশন বা ফ্রেমরেট কমাতে হয়।

14. উচ্চমানের ভিডিওর জন্য FFmpeg-এর আরও সতর্ক প্রাথমিক সেটিংস

ফাইলের আকারের তুলনায় ভিডিওর বিশ্বস্ততা অনেক বেশি গুরুত্বপূর্ণ হলে কম CRF দিয়ে শুরু করে ফলাফল যাচাই করুন।

যেমন, প্রচলিত SDR-এ ধারণ করা বাস্তব দৃশ্যের ভিডিওর জন্য নিচেরটি পরীক্ষা শুরুর যুক্তিসংগত ভিত্তি:

ffmpeg -i input.mp4 \
  -map 0:v:0 -map '0:a:0?' \
  -c:v libx264 \
  -preset slow \
  -crf 20 \
  -profile:v high \
  -pix_fmt yuv420p \
  -c:a aac -b:a 192k \
  -movflags +faststart \
  output.mp4

এই উদাহরণে slow প্রিসেট সাধারণ কাজের উপযোগী একটি ব্যবহারিক সূচনা, veryslow-এর চেয়ে ভালো কাজ করে—এমন দাবি নয়। বাড়তি এনকোডিং সময় গ্রহণযোগ্য হলে veryslow ব্যবহারও যুক্তিসংগত।

উচ্চমানের এই প্রোফাইলটি পরীক্ষা করার পরামর্শ; আমার ছোট ভিডিওর পরীক্ষায় প্রমাণিত কোনো সেটিং নয়।

উচ্চমানের ভিডিওর ক্ষেত্রে 18, 20 ও 22-এর আশপাশের CRF পরীক্ষা করুন, তারপর দৃশ্যমান ফল অনুযায়ী বেছে নিন। জটিল ফিল্ম গ্রেইন বা গতিবিধিতে অন্য সেটিং লাগতে পারে, আর আর্কাইভের মূল মাস্টারের জন্য আরও অনেক কম আক্রমণাত্মক কমপ্রেশন প্রয়োজন হতে পারে।

15. কারণ ছাড়া ভিডিও আবার এনকোড করবেন না

মানের ক্ষতি করে এমন ভিডিও কমপ্রেশন বিনা মূল্যে হয় না। আগে কমপ্রেস করা ফাইল নতুন করে এনকোড করলে আরও ত্রুটি তৈরি হতে পারে, যদিও নতুন ভিডিও দেখতে মূলটির মতো লাগে।

ট্রান্সকোড করার আগে দেখুন, মূল ফাইলটি ইতিমধ্যেই আপনার সামঞ্জস্য, আকার ও মানের চাহিদা পূরণ করছে কি না।

ফাইলে ইতিমধ্যেই সামঞ্জস্যপূর্ণ H.264 ভিডিও ও AAC অডিও থাকলে এবং ছবিতে কোনো পরিবর্তন দরকার না হলে, আবার ক্ষয়যুক্ত এনকোড করার চেয়ে স্ট্রিম কপি করাই ভালো হতে পারে।

ffmpeg -i input.mp4 \
  -map 0:v:0 -map '0:a:0?' \
  -c copy \
  -movflags +faststart \
  output.mp4

এই প্রক্রিয়ায় আবার এনকোড না করে কমপ্রেস করা স্ট্রিমগুলো কপি করা হয়। এতে কনটেইনারের বিন্যাস বদলাতে পারে, কিন্তু পুনরায় ভিডিও কমপ্রেশনের কারণে মানের বাড়তি ক্ষতি এড়ানো যায়।

নতুন করে কম মানে এনকোড করে যে পরিমাণ ফাইল ছোট করা যায়, এতে সাধারণত ততটা ছোট হয় না।

বিদ্যমান ভিডিওটি যদি ইতিমধ্যেই ছোট, সামঞ্জস্যপূর্ণ ও দেখতে গ্রহণযোগ্য হয়, সেটি অপরিবর্তিত রাখাই হয়তো সবচেয়ে ভালো অপ্টিমাইজেশন।

16. শুধু ফাইলের আকার দেখে নয়, এনকোড করা ভিডিও যাচাই করুন

FFmpeg সফলভাবে শেষ হয়েছে মানেই ভিডিও সব শর্ত পূরণ করেছে, এমন নয়।

প্রথমে FFprobe দিয়ে আউটপুটের স্ট্রিমগুলো পরীক্ষা করুন:

ffprobe -v error \
  -show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
  -of json output.mp4

কোডেক, পিক্সেল ফরম্যাট, মাত্রা, ফ্রেমরেট, সময়কাল ও অডিও স্ট্রিম যাচাই করুন।

এরপর কিছু ধরনের ফাইল-ত্রুটি বা ডিকোডিং সমস্যা ধরতে সম্পূর্ণ আউটপুট ডিকোড করুন:

ffmpeg -v error -xerror -i output.mp4 -f null -

কমপ্রেশন পরীক্ষায় একই মূল ভিডিও থেকে তৈরি আউটপুট তুলনা করুন। গুরুত্বপূর্ণ চলকগুলো অপরিবর্তিত রেখে একবারে শুধু একটি প্রধান সেটিং বদলান।

ভিডিওটি চলতে থাকা অবস্থায় দেখুন, সূক্ষ্ম বিবরণ পরীক্ষা করুন এবং গ্রেডিয়েন্ট, অন্ধকার অংশ, চলমান বস্তু ও লেখার দিকে নজর দিন।

সম্ভব হলে চোখে দেখা তুলনার পাশাপাশি SSIM, PSNR বা VMAF-এর মতো বস্তুনিষ্ঠ মেট্রিক ব্যবহার করুন। একটি উচ্চ স্কোর দেখেই সব কমপ্রেশন-ত্রুটি অদৃশ্য—এমন সিদ্ধান্ত নেবেন না।

সবশেষে প্রতিনিধিত্বমূলক ডিভাইসে এবং ডাউনলোড করা ফাইল চালানোর প্রক্রিয়ায় ভিডিও পরীক্ষা করুন। ব্রাউজারের সমর্থনসংক্রান্ত তথ্য উপকারী, কিন্তু সামঞ্জস্য যখন প্রধান লক্ষ্য, বাস্তবে চালিয়ে দেখা বিশেষভাবে গুরুত্বপূর্ণ।

17. আপনার MP4 ফাইলগুলো সঠিকভাবে পরিবেশন হচ্ছে কি না নিশ্চিত করুন

ওয়েবে ভিডিও ঠিকভাবে সরবরাহ না হলে ভালো এনকোডিং সেটিংস দিয়েও সেই ঘাটতি পূরণ করা যায় না।

সাধারণ প্রগ্রেসিভ MP4 প্লেব্যাকের জন্য সঠিক Content-Type: video/mp4 হেডার দিন এবং আংশিক ডেটা আনা ও নির্দিষ্ট অবস্থান থেকে চালানোর প্রয়োজন হলে HTTP বাইট-রেঞ্জ অনুরোধের সমর্থন রাখুন।

FFmpeg-এর +faststart অপশন প্রচলিত MP4 ফাইলের প্রাথমিক তথ্য শুরুর দিকে নিয়ে আসে। এতে ধাপে ধাপে লোড হওয়া সহজ হয়, কিন্তু ছবির মান বাড়ে না কিংবা বিটরেট কমে না।

HTML-এর সাধারণ video এলিমেন্ট দিয়ে একটি H.264 MP4 দেখানো যায়:

<video controls playsinline preload="metadata">
  <source src="/media/video.mp4" type="video/mp4">
</video>

preload অ্যাট্রিবিউট ব্রাউজারের জন্য একটি ইঙ্গিত, ডাউনলোডের কঠোর সীমা নয়। ব্রাউজারের স্বয়ংক্রিয় প্লেব্যাক নীতির কারণে ভিডিও নিঃশব্দ বা শব্দবিহীন রাখাও লাগতে পারে।

কোনো পৃষ্ঠায় অনেক ভিডিও থাকলে সবগুলো একসঙ্গে ডাউনলোড শুরু করা এড়িয়ে চলুন। প্রয়োজন হলে তবেই ভিডিও লোড করলে মোবাইল ডেটা সাশ্রয় হয় এবং ব্যবহারকারীর কাছে পৃষ্ঠাটি আরও দ্রুত সাড়া দিচ্ছে বলে মনে হতে পারে।

ছোট মোবাইল ক্লিপে এনকোড করা ফাইল ছোট করার মতোই ডাউনলোড কখন শুরু হবে তা অপ্টিমাইজ করাও গুরুত্বপূর্ণ হতে পারে।

18. কোন ভিডিও ফরম্যাট ও মান বেছে নেবেন?

আপনি কোন বিষয়টিকে অগ্রাধিকার দিচ্ছেন, তার ওপর সঠিক উত্তর নির্ভর করে।

আপনার লক্ষ্য	সুপারিশকৃত প্রাথমিক পছন্দ
ওয়েব ও ডাউনলোড—দুই ক্ষেত্রেই বিস্তৃত সামঞ্জস্যের একটি ভিডিও	অডিও থাকলে MP4 + H.264 + AAC
একাধিক ফরম্যাটে আধুনিক ব্রাউজারে ভিডিও পরিবেশন	বিকল্প H.264 রেখে AV1 বা VP9
সমর্থিত ডিভাইসে সর্বোচ্চ কমপ্রেশন	AV1 পরীক্ষা করুন
নিয়ন্ত্রিত, HEVC-সমর্থিত প্লেব্যাক পরিবেশ	MP4 + HEVC বিবেচনা করুন
ছোট মোবাইল ক্লিপ, যেখানে ফাইলের আকার সবচেয়ে গুরুত্বপূর্ণ	প্রতিনিধিত্বমূলক পরীক্ষা শেষে x264 CRF 30 বিবেচনা করুন
অ্যানিমে বা আঁকা অ্যানিমেটেড ভিডিও	-tune animation-সহ x264 পরীক্ষা করুন
উচ্চমানের চলচ্চিত্র বা প্রিমিয়াম ভিডিও	প্রায় 20-এর কাছাকাছি আরও সতর্ক CRF দিয়ে শুরু করে পরীক্ষা করুন
অফলাইন এনকোডিং, যেখানে CPU সময় তুলনামূলক কম গুরুত্বপূর্ণ	x264 slow বা veryslow বিবেচনা করুন
দ্রুত প্রসেসিং ও সীমিত CPU সম্পদ	x264 medium বা slow বিবেচনা করুন
বিদ্যমান ভিডিও ইতিমধ্যেই চাহিদা পূরণ করে	ফাইলটি রাখুন অথবা নতুন করে এনকোড না করে রিমাক্স করুন
আর্কাইভ করা বা ভবিষ্যতে সম্পাদনা করা	পরিবেশনের ফাইল থেকে আলাদা করে উচ্চমানের মূল মাস্টার রাখুন

19. আমার চূড়ান্ত সিদ্ধান্ত এবং পরীক্ষায় সত্যিই কী প্রমাণিত হয়েছে

ভিডিও ফরম্যাট, সামঞ্জস্য, এনকোডিং দক্ষতা ও বাস্তব কমপ্রেশনের ফলাফল পর্যালোচনা করে আমি মোবাইলে দেখার ছোট ভিডিওর জন্য একটি ব্যবহারিক পরিবেশন প্রোফাইল বেছে নিয়েছি।

নির্বাচিত ফরম্যাট হলো H.264-সহ MP4, কারণ নতুন কোডেকে সবচেয়ে ছোট ফাইল পাওয়ার চেয়ে ব্রাউজার, ফোন, ডাউনলোড ও বাইরের অ্যাপ্লিকেশনে নির্ভরযোগ্য সামঞ্জস্য আমার কাছে বেশি গুরুত্বপূর্ণ ছিল।

নির্বাচিত এনকোডার হলো veryslow প্রিসেট-সহ libx264, কারণ ভিডিও অফলাইনে এনকোড করা সম্ভব ছিল এবং বাড়তি প্রসেসিং সময় গ্রহণযোগ্য ছিল।

অ্যানিমে ভিডিওর ক্ষেত্রে আমি animation tune ব্যবহার করি, যদিও জানি এটি এনকোডারের আচরণ বদলায় এবং ফাইল ছোট হবে বা সব অবস্থায় দৃশ্যগত ফল ভালো হবে—এমন নিশ্চয়তা দেয় না।

ছোট মোবাইল ভিডিওর জন্য আমি CRF 30 বেছে নিয়েছি, কারণ আমার তুলনায় ফাইলের আকার অনেক কমলেও স্বাভাবিক প্লেব্যাকের সময়, এমনকি বড় ডেস্কটপ মনিটরেও, অর্থপূর্ণ দৃশ্যমান পার্থক্য পাইনি।

এর অর্থ এই নয় যে CRF 30 সিনেমা বা উচ্চমানের ফুটেজের জন্য আদর্শ। যেখানে সূক্ষ্ম বিবরণ, গ্রেডিয়েন্ট, ফিল্ম গ্রেইন ও সামগ্রিক বিশ্বস্ততা বেশি গুরুত্বপূর্ণ, সেখানে আমি CRF 20 বা অন্য উপযুক্ত সতর্ক মানের আশপাশে পরীক্ষা শুরু করতাম। সিনেমাটিক ফুটেজে সমতুল্য নিয়ন্ত্রিত গবেষণা করিনি, তাই ওই সংখ্যাকে পরীক্ষায় প্রমাণিত সেরা মান হিসেবে তুলে ধরছি না।

সবচেয়ে গুরুত্বপূর্ণ সিদ্ধান্ত হলো সব ভিডিওর জন্য সর্বজনীনভাবে সেরা কোনো একক কোডেক, ফরম্যাট বা CRF মান নেই।

আপনার অগ্রাধিকার সর্বাধিক সামঞ্জস্য এবং একটি মাত্র ফাইল হলে MP4/H.264 শক্তিশালী প্রাথমিক পছন্দ। বিকল্প ফরম্যাট দিতে পারলে এবং আরও ভালো কমপ্রেশন চাইলে VP9 ও AV1 পরীক্ষা করুন। মূলত ফোনে দেখা ছোট ভিডিও এনকোড করলে বেশি CRF ব্যবহার করে উদ্দেশ্যপ্রণোদিত দেখার অভিজ্ঞতা নষ্ট না করেই যথেষ্ট ছোট ফাইল পাওয়া যায় কি না পরীক্ষা করুন। চলচ্চিত্র বা প্রিমিয়াম ফুটেজের জন্য মানের আরও সতর্ক সেটিংস ব্যবহার করে ভালোভাবে যাচাই করুন।

আগে প্লেব্যাকের চাহিদা ঠিক করুন, তারপর কোডেক, সবশেষে কমপ্রেশনের মান। এরপর গুরুত্বপূর্ণ ডিভাইস ও বাস্তব ব্যবহারের পরিস্থিতিতে ফলাফল পরীক্ষা করুন। শুধু নতুন, বেশি দক্ষ বা বহুল সুপারিশকৃত বলে কোনো কোডেক বা CRF মান অন্ধভাবে গ্রহণ করার চেয়ে এই পদ্ধতি বেশি নির্ভরযোগ্য।