H.264 ব্যবহার করে বাস্তব ব্যবহারের একটি ভিডিওকে ~280 MB থেকে ~50 MB-এ নামিয়েছি যেভাবে

এই অপ্টিমাইজেশনকে বাস্তব করে তোলা সংখ্যাটি ছিল খুব সহজ: আমি যে বাস্তব ব্যবহারের ভিডিওটির ওপর নজর রাখছিলাম, নতুন H.264 নীতি প্রয়োগের পরে সেটি প্রায় 280 MB থেকে 50 MB-এ নেমে আসে। অর্থাৎ ফাইলটি প্রায় 5.6× ছোট হয়, প্রায় 230 MB বা মূল আকারের প্রায় 82% বাঁচে।

এই ফল পেতে আমি AV1, HEVC বা VP9-এ যাইনি। বাস্তব ব্যবহার ফলাফল ছিল MP4-এর ভিতরে H.264। বদলেছিল কোডেক-এর চারপাশের নীতি: অপ্রয়োজনীয় পিক্সেল কমানো, অপ্রয়োজনীয় সময়গত নমুনা কমানো, অনেক কম রক্ষণশীল মানের লক্ষ্য, এনকোডিং-এ একবার বেশি CPU খরচ করা, এবং ডিকোডারের চাহিদা ইচ্ছাকৃতভাবে সীমিত রাখা।

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

পুরোনো ও নতুন নীতি মোটামুটি এমন ছিল:

আগের বিন্যাস
H.264 Main @ Level 4.0
CRF 19
পূর্বনির্ধারিত মান slow
সর্বোচ্চ 1920x1080 / 1080x1920
30 fps
refs = 3
B-ফ্রেম = 3
GOP ≈ 2 সেকেন্ড
VBV ≈ 10M / 20M

নতুন বিন্যাস
H.264 Main @ Level 3.1
CRF 28
পূর্বনির্ধারিত মান veryslow
720p-শ্রেণির সর্বোচ্চ সীমা, বড় করা নয়
কার্যকর CFR, সাধারণত <= 30 fps
refs = 4
B-ফ্রেম = 5
GOP ≈ 5 সেকেন্ড
VBV ≈ 4M / 8M
yuv420p / avc1 / faststart

মাপা ফলাফল: প্রায় 280 MB থেকে প্রায় 50 MB

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

পরিমাপ	আগে	পরে	হ্রাস
একই নির্দিষ্ট ভিডিও	~280 MB	~50 MB	~5.6× ছোট / ~82% কম
একই ফাইলের আগের ধাপ	~350 MB	~238 MB	~1.47× ছোট / 32% কম

প্রথম সারিটিই শিরোনামের সবচেয়ে পরিষ্কার প্রমাণ। একই নির্দিষ্ট ভিডিও নতুন নীতির আগে ও পরে: প্রায় 280 MB থেকে প্রায় 50 MB। সেই ঠিক সেই জোড়ার বিট হার/সময়কাল লাইন পুরোনো লগ থেকে উদ্ধার করতে পারিনি, তাই সেটা বানিয়ে বলছি না। আকারের পরিবর্তনটাই যথেষ্ট: নির্দিষ্ট এই ফাইল প্রায় 5.6 গুণ ছোট হয়েছে।

~350→238 MB উদাহরণ ছিল একই ফাইলের প্রক্রিয়াকরণ ধারার আগের এক অপ্টিমাইজেশন ধাপ। ফলস্বরূপ ভিডিও ছিল প্রায় 1264×720, 30 fps, প্রায় 500 সেকেন্ড, শব্দ ছাড়া এবং প্রায় 3.8 Mbps। হিসাব পর্যবেক্ষিত আকারের সঙ্গে মেলে: 3.8 Mbps × প্রায় 500 সেকেন্ড ≈ 238 MB। ~350 MB থেকে এটি ইতিমধ্যেই 32% সাশ্রয় ছিল, কিন্তু আমার ব্যান্ডউইথ লক্ষ্যের জন্য তখনও অনেক বড়।

পুরোনো সংগ্রহের পর্যালোচনাও দেখিয়েছিল অতিরিক্ত বড় H.264 কোনো একক অদ্ভুত ব্যতিক্রম ছিল না। এক পর্যালোচনায় বাস্তব ব্যবহারের 238টি ভিডিওর মোট আকার ছিল 6.37 GB: 117টি H.264 এবং 121টি AV1। 101টি ফাইল ছিল অন্তত 20 MB এবং 34টি অন্তত 50 MB। বড় H.264 ফাইলের কিছু উদাহরণ:

আকার	সময়কাল	গড় বিট হার
121.0 MB	4:25	3.83 Mbps
101.2 MB	5:19	2.659 Mbps
92.78 MB	4:44	2.735 Mbps
90.10 MB	3:55	3.206 Mbps
89.74 MB	4:41	2.676 Mbps

এগুলো ভিন্ন কনটেন্টের ফাইল, তাই টেবিলটি প্রেক্ষাপট দেয়; এটি সরাসরি আগে-পরে তুলনা নয়। তবে এতে বোঝা যায় পুরোনো 3.8 Mbps উদাহরণটি বিচ্ছিন্ন ব্যতিক্রম ছিল না—পুরোনো সংগ্রহের কয়েকটি বড় H.264 ফাইল সত্যিই প্রায় 2.6–3.8 Mbps সীমায় ছিল।

সবচেয়ে গুরুত্বপূর্ণ অপ্টিমাইজেশন কোনো FFmpeg অপশন ছিল না

সবচেয়ে বড় পরিবর্তন ছিল খরচকে আমি কীভাবে দেখি।

এনকোডিং একবার হয়। কেউ ফাইলটি চাইলে সেটি আবার পাঠানো হয়।

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

এই কারণেই -preset veryslow আমার জন্য যৌক্তিক। x264 যদি বেশি CPU ব্যবহার করে আরও দক্ষ উপস্থাপন খুঁজে পায়, আমি সেই খরচ একবার দিতে রাজি। ব্রাউজার এনকোডারের খোঁজার কাজ আবার করে না; সে শুধু তৈরি বিটস্ট্রিম ডিকোড করে।

নিয়মটা সহজ হয়ে গেল: যে ধাপ একবার হয় সেখানে কম্পিউটেশন খরচ করো, আর যে ধাপ বারবার হয় সেখানে বাইট বাঁচাও।

নতুন কোডেকের পেছনে না ছুটে কেন H.264-তেই থাকলাম

আমি বলছি না H.264 এখনকার সবচেয়ে দক্ষ কমপ্রেশন কোডেক। তা নয়। বিতরণ ব্যবস্থা যদি একাধিক সংস্করণ রাখতে পারে এবং প্রতিটি যন্ত্রের জন্য সঠিকটি বেছে নিতে পারে, তাহলে নতুন কোডেক খুবই আকর্ষণীয় হতে পারে।

আমার সীমাবদ্ধতা ছিল অন্য: এক URL, এক ফাইল, এক কোডেক, আর মোবাইল-প্রধান দর্শকের জন্য যতটা সম্ভব কম চালানোর ঝামেলা।

এই কাজের জন্য MP4-এর ভিতরে H.264 এখনও খুব নিরাপদ ভিত্তি। Apple বর্তমানে ওয়েবসাইট নির্মাতাদের Safari-তে স্থির ভিডিও ফাইলের জন্য H.264-এ এনকোড করা MP4 ফাইল ব্যবহার করতে বলে। Android-এর বর্তমান নথিতেও MP4-এ H.264 আছে এবং Android 6.0 ও পরের সংস্করণে Main প্রোফাইল ডিকোডার বাধ্যতামূলক; H.264 প্লেব্যাকের সুপারিশে HD-এর জন্য 1280×720 রেজোলিউশনে 30 fps-ও আছে, তবে নথিটি স্পষ্ট করে যে সব ডিভাইসে HD উপলভ্য নয়। দেখুন Android-এর সমর্থিত মিডিয়া ফরম্যাট।

এর মানে আধুনিক ডিভাইস Main প্রোফাইল বা লেভেল 3.1-এ সীমাবদ্ধ নয়। উদাহরণ হিসেবে Apple-এর HLS নির্দেশিকা সাধারণত Main বা Baseline প্রোফাইলের চেয়ে High প্রোফাইল-কে অগ্রাধিকার দেয়। আমি Main@3.1 বেছে নিয়েছি কারণ একটি স্থির MP4-এর জন্য ইচ্ছাকৃতভাবে সংযত ডিকোডার চাহিদা রাখতে চেয়েছি, Apple এটি বাধ্যতামূলক করেছে বলে নয়।

যে পিক্সেল থাকার দরকার নেই, সেগুলো এনকোড করা বন্ধ করেছি

রেজোলিউশন ছিল সবচেয়ে বড় নিয়ামকগুলোর একটি। আমার সর্বোচ্চ সীমা হলো অনুভূমিক উপকরণে প্রায় 1280×720, উল্লম্ব উপকরণে 720×1280, আর বর্গাকার বা মিশ্র অভিমুখের উপকরণে প্রায় 960×960।

আরও গুরুত্বপূর্ণ নিয়ম: সীমায় পৌঁছানোর জন্য কখনও অকারণে বড় করো না।

সোর্স 900×600 হলে সেটিকে 1280×720 করলে হারানো ডিটেইল ফিরে আসে না। শুধু এনকোডারের বর্ণনা করার জন্য আরও নমুনা তৈরি হয়। 1920×1080 সোর্সকে 720p-শ্রেণিতে নামানো যেতে পারে, কিন্তু 900×600 সোর্স প্রায় 900×600-ই থাকতে পারে। সীমা সর্বোচ্চ মান, লক্ষ্য নয়।

এটা সহজ শোনায়, কিন্তু অপ্রয়োজনীয় পিক্সেল বাদ দেওয়া অনেক সূক্ষ্ম এনকোডারের সূক্ষ্ম সমন্বয়ের চেয়েও বেশি কাজে লাগতে পারে।

এই সর্বোচ্চ সীমা শুধু গোল সংখ্যা বলে বেছে নেওয়া নয়। 1920×1080 ফ্রেমে 2,073,600 পিক্সেল, আর 1280×720-এ 921,600। ফলে 1080p থেকে 720p-তে নামলেই সংকোচনের সিদ্ধান্ত শুরু হওয়ার আগে প্রায় 55.6% স্থানিক নমুনা বাদ পড়ে।

540p-কে সাধারণ নিয়ম করার কথাও ভেবেছিলাম। কিন্তু 960×540-এ মাত্র 518,400 পিক্সেল—1280×720-এর তুলনায় 43.75% কম—অর্থাৎ 720p-এর 56.25% নমুনা থাকে। আঁকা কনটেন্টে এই নমুনাগুলোই সূক্ষ্ম রেখা, চোখ, চুল, আঙুল, মুখ আর ধারালো প্রান্তের তথ্য বহন করে। আরও কম বাইট দরকার হলে আমি অন্ধভাবে আরও 43.75% স্থানিক তথ্য ফেলে দেওয়ার আগে সামান্য বেশি CRF পরীক্ষা করব। কোয়ান্টাইজেশন পরের সংকোচনে বদলানো যায়; রেজোলিউশন কমিয়ে যে বিস্তারিত মুছে গেছে তা আর ফেরে না।

তাই 720p-শ্রেণি আমার সতর্ক সাধারণ সর্বোচ্চ সীমা; 540p খারাপ—এমন দাবি নয়। নির্দিষ্ট একটি ফাইলে মাপা 540p সংস্করণই ভালো হতে পারে। শুধু তথ্য ছাড়া এই অপরিবর্তনীয় স্থানিক ক্ষতিকে পুরো সংগ্রহের নিয়ম বানাই না।

সোর্সে আসলে নেই এমন ফ্রেমের জন্য খরচ করা বন্ধ করেছি

ফ্রেম রেটও একটি গুণক। কোনো অ্যানিমেশনে যদি প্রতি সেকেন্ডে বাস্তবে প্রায় 16টি দরকারি ভিজ্যুয়াল অবস্থা থাকে, সেটিকে 30 বা 60 fps-এ সংরক্ষণ করলেই গতি স্বয়ংক্রিয়ভাবে ভালো হয় না। প্রায়ই শুধু পুনরাবৃত্ত বা কৃত্রিম সময়গত নমুনা বাড়ে, যেগুলো তবুও এনকোড করতে হয়।

আমার নীতি হলো সোর্সের দরকারি ছন্দ বজায় রাখা এবং সাধারণত 30 fps বা তার নিচে থাকা। এই ধরনের উপকরণে 12, 15, 16, 18, 20, 24, 25 বা 30 fps—সবই যুক্তিসঙ্গত হতে পারে, যদি সেটি সত্যিই সোর্সকে ঠিকভাবে বর্ণনা করে।

তৈরি ফাইলে আমি পরিষ্কার স্থির ফ্রেম রেটও পছন্দ করি। VFR নিজে থেকে ভুল নয়; CFR আমার প্রক্রিয়ায় সময়চিহ্ন, ফ্রেম গণনা, সময়কাল যাচাই, অবস্থান বদল এবং পরের যাচাইগুলো সহজ করে।

একটি নির্দিষ্ট FPS-এর চেয়ে সাধারণ নীতিটা বেশি গুরুত্বপূর্ণ: সোর্সে নেই এমন সময়গত তথ্যের জন্য ব্যান্ডউইথ দিও না।

CRF 28 এই কাজের জন্য বেছে নেওয়া মান, কোনো জাদুর সংখ্যা নয়

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

তাই x264-এর CRF মোড ব্যবহার করি এবং এই ব্যান্ডউইথ-প্রধান ইলাস্ট্রেটেড কাজের জন্য প্রায় -crf 28-এ স্থির হয়েছি। FFmpeg libx264-এর CRF-কে স্থির-মানের গুণমান নিয়ন্ত্রণ হিসেবে নথিভুক্ত করে; দেখুন FFmpeg কোডেক নথি।

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

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

veryslow এনকোডারের জন্য ব্যয়বহুল, ডিকোডারের জন্য নিজে থেকেই নয়

আমার প্রিসেট -preset veryslow। ধীর প্রিসেট x264-কে আরও দক্ষ প্রেডিকশন ও কোডিং সিদ্ধান্ত খোঁজার বেশি সময় দেয়। এর দাম এনকোডিং CPU ও সময়।

গুরুত্বপূর্ণ পার্থক্য হলো: এনকোডারের পরিশ্রম আর ডিকোডারের জটিলতা এক জিনিস নয়।

x264-কে অনেক খুঁজতে দিতে পারি, আবার চূড়ান্ত বিটপ্রবাহকে আলাদাভাবে সীমাবদ্ধ রাখতে পারি। আমার সংযত ফলাফল-সীমা হলো:

H.264, Main প্রোফাইল
Level 3.1
8-বিট yuv420p
avc1
refs = 4
B-ফ্রেম = 5
B-pyramid = normal
খোলা GOP = বন্ধ

FFmpeg CRF, প্রিসেট, বিষয়ভিত্তিক সমন্বয়, প্রোফাইল সীমা, রেফারেন্স ফ্রেম এবং B-ফ্রেম আলাদাভাবে নিয়ন্ত্রণ করতে দেয়। আমি এগুলো ঠিক এভাবেই দেখি: এনকোডারকে যতটা দরকার খুঁজতে দাও, কিন্তু চালানোর দিকটা সাধারণ ও পূর্বানুমেয় রাখো।

GOP ও VBV সুরক্ষা সীমা, মূল গুণমান নিয়ন্ত্রণ নয়

এই ছোট ধাপে ধাপে লোড হওয়া ছোট ভিডিওগুলোর জন্য সর্বোচ্চ GOP প্রায় পাঁচ সেকেন্ড রাখি: 30 fps-এ প্রায় -g 150, 24 fps-এ -g 120, আর 16 fps-এ -g 80।

এটি আমার কাজের জন্য বেছে নেওয়া নিয়ম, সার্বজনীন নিয়ম নয়। অভিযোজিত স্ট্রিমিংয়ের সীমাবদ্ধতা আলাদা; Apple-এর HLS তৈরির নির্দেশিকা, যেমন, প্রতি দুই সেকেন্ডে IDR রাখার পরামর্শ দেয়। আমি সেই HLS নিয়ম ছোট স্থির প্রগ্রেসিভ MP4 ফাইলে অন্ধভাবে কপি করি না।

আমি আরও প্রায় এই মানগুলো ব্যবহার করি:

-maxrate:v 4M
-bufsize:v 8M

এগুলো অস্বাভাবিক বিট হারের অস্বাভাবিক উত্থান ঠেকানোর সর্বোচ্চ সীমা। এর মানে “সবকিছু 4 Mbps-এ এনকোড করো” নয়। স্বাভাবিক বিট বণ্টনের দায়িত্ব CRF-এরই থাকে, তাই সহজ ভিডিও খুব ছোট হতে পারে।

MP4 কনটেইনারকেও যতটা সম্ভব সাধারণ রেখেছি

আমি স্পষ্টভাবে avc1 ব্যবহার করি। Apple-এর বর্তমান HLS নথি avc3-এর বদলে avc1-এর মতো নমুনা বিন্যাস ব্যবহারের পরামর্শ দেয়। এতে ফাইল ছোট হয়নি, তবে প্রচলিত MP4-এ H.264 আউটপুট তৈরির লক্ষ্যটির সঙ্গে এটি মেলে।

আমি -movflags +faststart-ও ব্যবহার করি। FFmpeg-এর ফরম্যাট নথি অনুযায়ী faststart MP4-এর moov ইনডেক্স ফাইলের শুরুতে নিয়ে যায়। Android-এর HTTP-এ প্রবাহ সরবরাহের শর্তও MPEG-4-এ ftyp-এর পরে moov এবং তার পরে mdat চায়।

ftyp
moov
mdat

faststart সংকোচন উন্নত করে না। এটি HTTP-এ ধাপে ধাপে চালানোকে সহজ করে।

সাধারণ SDR আউটপুটে 8-বিট yuv420p ব্যবহার করি এবং BT.709-কে সীমিত ভিডিও পরিসর হিসেবে সিগন্যাল করি। ভিডিওতে শব্দ না থাকলে আলাদা শব্দের ট্র্যাক বানাই না। এই ইলাস্ট্রেটেড কনটেন্টে -tune animation-ও ব্যবহার করি; এটিকে নির্দিষ্ট কনটেন্টের জন্য বেছে নেওয়া সেটিং হিসেবে দেখি, সার্বজনীন সামঞ্জস্য চুক্তির অংশ হিসেবে নয়।

মূল FFmpeg প্রোফাইল

30 fps ইলাস্ট্রেটেড সোর্সের জন্য কমান্ডের মূল অংশ প্রায় এমন:

ffmpeg -i input \
  -c:v libx264 \
  -preset veryslow \
  -tune animation \
  -crf 28 \
  -profile:v main \
  -level:v 3.1 \
  -pix_fmt yuv420p \
  -tag:v avc1 \
  -refs 4 \
  -bf 5 \
  -g 150 \
  -maxrate:v 4M \
  -bufsize:v 8M \
  -x264-params "open-gop=0:b-pyramid=normal:nal-hrd=none" \
  -color_range tv \
  -color_primaries bt709 \
  -color_trc bt709 \
  -colorspace bt709 \
  -an \
  -movflags +faststart \
  output.mp4

আকার বদল ও ফ্রেম-হারের ধাপ এখানে ইচ্ছাকৃতভাবে স্থির করে দিইনি। 900×600 সোর্সকে শুধু 1280×720 সীমা আছে বলে বড় করা উচিত নয়, আর স্বাভাবিকভাবেই কম ফ্রেম রেটের অ্যানিমেশনকে উদাহরণে -g 150 আছে বলে 30 fps-এ ঠেলে দেওয়া উচিত নয়।

কমান্ডটি নীতির বাস্তবায়ন; নীতিটি নিজে নয়।

ফাইলগুলো কেন কয়েক গুণ ছোট হলো

কোনো একক জাদুর অপশন ছিল না।

আকার কমেছে কয়েকটি সিদ্ধান্ত একসঙ্গে কাজ করায়, যেগুলো আলাদা আলাদা অপচয় সরিয়েছে: অপ্রয়োজনীয় পিক্সেল, অপ্রয়োজনীয় ফ্রেম, অতিরিক্ত সতর্ক মান-লক্ষ্য, দক্ষতার চেয়ে গতিকে অগ্রাধিকার দেওয়া সংকোচন সেটিং, অতিরিক্ত ঘন মূল ফ্রেম এবং দরকার না থাকা ডেটা প্রবাহ।

এই কারণেই “ফাইলটি H.264” বলা তার আকার সম্পর্কে আশ্চর্যজনকভাবে কম তথ্য দেয়। একই সোর্সের দুই H.264 এনকোডের আকার অনেক আলাদা হতে পারে, কারণ কোডেকের নাম রেজোলিউশন, ফ্রেম রেট, বিট হার নিয়ন্ত্রণ, প্রিসেট, GOP গঠন, প্রোফাইল বা সোর্স প্রস্তুতি সম্পর্কে কিছু বলে না।

আমার ক্ষেত্রে কোডেক বদলানোর চেয়ে তার চারপাশের এই সিদ্ধান্তগুলো বদলানো বেশি গুরুত্বপূর্ণ ছিল।

এই ফলাফল কী প্রমাণ করে না

আমি নিয়ন্ত্রিত পরীক্ষায় প্রতিটি সেটিং আলাদা করে পরীক্ষা করিনি, তাই সাশ্রয়ের ঠিক কত শতাংশ veryslow, CRF 28, রেজোলিউশন কমানো বা ফ্রেম রেট কমানো থেকে এসেছে—সৎভাবে আলাদা করে বলতে পারি না।

প্রতিটি CRF 28 আউটপুট চোখে ধরা না পড়ার মতো—এ দাবিও করতে পারি না। “স্পষ্ট মানের অবনতি দেখিনি” হলো স্বাভাবিক দেখার আকারে এই ইলাস্ট্রেটেড কাজের জন্য আমার পর্যবেক্ষণ, যেকোনো ভিডিওর জন্য বৈজ্ঞানিক নিশ্চয়তা নয়।

একটি H.264 ফাইল সব সাইটের জন্য সঠিক কাঠামো—এ কথাও বলছি না। একাধিক সংস্করণ, অভিযোজিত স্ট্রিমিং, HDR, 4K এবং কোডেক নির্বাচন হিসাব বদলে দেয়।

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

এই ফলাফল আমার অপ্টিমাইজেশন পদ্ধতি কীভাবে বদলেছে

আগে ভিডিও অনুকূলনকে মূলত এনকোডার বিন্যাসের সমস্যা ভাবতাম। এখন এটিকে পুরো জীবনচক্রের খরচের সমস্যা হিসেবে দেখি।

এনকোডার হয়তো একবার চলবে। বাইট নেটওয়ার্ক দিয়ে হাজার বা লাখ বার যেতে পারে।

এতে “ব্যয়বহুল” শব্দটির মানে বদলে যায়।

একবার বেশি CPU খরচ করতে আমার সমস্যা নেই। কিন্তু প্রতিটি ভবিষ্যৎ অনুরোধে আকার বাড়িয়ে তৈরি পিক্সেল, কোনো দরকারি গতি যোগ না করা ফ্রেম, বা কনটেন্টের প্রয়োজনের চেয়ে বেশি বিট হার পাঠাতে আমি অনেক কম রাজি।

কোডেকটি সাধারণই রইল: MP4-এ H.264। অনুকূলন ঘটেছে তার চারপাশে।

এই কাজের জন্য শিক্ষা কোনো একক FFmpeg অপশনের চেয়ে পরিষ্কার: যে খরচ বারবার দাও সেটি অনুকূল করো, যে খরচ একবার দাও সেটি নয়।