2026 में 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 कर देने से उसका वीडियो कोडेक नहीं बदलता। इसी तरह AV1 को MP4 में रखने से वह उन डिवाइसों पर चलने नहीं लगेगा जिनमें 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 का समर्थन बिल्कुल नहीं है। समय के साथ ब्राउज़र संगतता काफ़ी बेहतर हुई है।

ज़्यादा महत्वपूर्ण सीमा ब्राउज़र के बाहर की संगतता है। ऑपरेटिंग सिस्टम के मूल ऐप्लिकेशन, पुराने डिवाइस और थर्ड-पार्टी सॉफ़्टवेयर संभव है कि WebM को पारंपरिक H.264 MP4 जितनी निरंतरता से न संभाल पाएँ।

अगर ऐप्लिकेशन केवल ब्राउज़र में चलता है और आप उसकी प्लेबैक क्षमताएँ नियंत्रित कर सकते हैं, तो 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 माप उपलब्ध नहीं थे। इसलिए मैंने VMAF के आधार पर यह दावा नहीं किया कि CRF 30 या 32 किसी सार्वभौमिक गुणवत्ता सीमा तक पहुँचते हैं।

व्यावहारिक निष्कर्ष इससे सीमित था: परीक्षण वाली छोटी वीडियो क्लिप ने सामान्य प्लेबैक में बहुत अधिक 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 ट्यून इस्तेमाल करता हूँ

स्रोत में हाथ से बनाई गई एनिमेशन या ऐनिमे जैसी चित्र शैली होने पर मैं x264 के साथ -tune animation इस्तेमाल करता हूँ।

यह CRF सेटिंग से अलग है। ट्यून, खास दृश्य विशेषताओं के अनुरूप एन्कोडर के कुछ फ़ैसले बदलता है। animation ट्यून बनाई गई रेखाओं, सपाट रंगों वाले क्षेत्रों और शैलीबद्ध गति वाले वीडियो के लिए है।

इसलिए मेरी पसंद यह है:

ऐनिमे या बनाई गई एनिमेशन: -preset veryslow -tune animation।
सामान्य वास्तविक कैमरा फ़ुटेज: animation ट्यून अपने आप चालू न करें; एन्कोडर की डिफ़ॉल्ट सेटिंग से शुरू करें या किसी उपयुक्त ट्यून की अलग जाँच करें।

ट्यून के काम को ग़लत नहीं समझना चाहिए। -tune animation से दिखाई देने वाली गुणवत्ता बेहतर या फ़ाइल छोटी होने की गारंटी नहीं मिलती। यह एन्कोडर का व्यवहार बदलता है और नतीजा सामग्री पर निर्भर होता है।

मैंने animation ट्यून के साथ स्थिर CRF पर अलग तुलना की। उस विशेष परीक्षण में ट्यून चालू करने से फ़ाइल लगभग 6% बड़ी हुई और छवि की मापी गई समानता थोड़ी बढ़ी। आँखों से दिखाई देने वाला अंतर छोटा था।

मुख्य CRF 22–32 आकार तुलना animation ट्यून के बिना की गई थी। इसलिए यह नहीं मानना चाहिए कि -tune animation चालू करने पर उस प्रयोग के सटीक फ़ाइल आकार और कम्प्रेशन अनुपात वैसे ही रहेंगे।

फिर भी ऐनिमे फ़ुटेज में मैं इसी एनिमेशन-विशेष ट्यून को पसंद करता हूँ और उससे बने आकार तथा गुणवत्ता को उस सामग्री की एन्कोडिंग प्रोफ़ाइल के हिस्से के रूप में जाँचता हूँ।

एन्कोडर ट्यूनिंग को हर बार गुणवत्ता बढ़ाने वाला सार्वभौमिक उपाय नहीं, बल्कि सामग्री के अनुसार किया जाने वाला समायोजन समझना चाहिए।

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 इस्तेमाल करना भी उचित होगा।

यह उच्च गुणवत्ता वाली प्रोफ़ाइल आज़माने की सिफ़ारिश है, न कि मेरी छोटी वीडियो वाली जाँच से प्रमाणित सेटिंग।

प्रीमियम वीडियो के लिए लगभग CRF 18, 20 और 22 आज़माएँ और दिखाई देने वाले परिणामों के आधार पर चुनें। मुश्किल फ़िल्म ग्रेन या गति के लिए दूसरी सेटिंग्स चाहिए हो सकती हैं; संग्रह के लिए रखी जाने वाली मास्टर कॉपी पर इससे बहुत हल्का कम्प्रेशन आवश्यक हो सकता है।

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 वीडियो एलिमेंट से एक 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 पर विचार करें
ऐनिमे या बनाई गई एनिमेशन	x264 के साथ `-tune animation` की जाँच करें
उच्च गुणवत्ता वाली फ़िल्में या प्रीमियम वीडियो	20 के आसपास अधिक सतर्क CRF से शुरू करके जाँचें
ऑफ़लाइन एन्कोडिंग जहाँ CPU समय कम महत्वपूर्ण है	x264 `slow` या `veryslow` पर विचार करें
तेज़ प्रोसेसिंग और सीमित CPU संसाधन	x264 `medium` या `slow` पर विचार करें
मौजूदा वीडियो पहले से आवश्यकताएँ पूरी करता है	उसी को रखें या दोबारा एन्कोड किए बिना कंटेनर बदलें
संग्रह या भविष्य में संपादन	उच्च गुणवत्ता वाली मास्टर कॉपी को डिलीवरी फ़ाइलों से अलग रखें

19. मेरा अंतिम फ़ैसला और प्रयोग से वास्तव में क्या साबित हुआ

वीडियो फ़ॉर्मैट, संगतता, एन्कोडिंग दक्षता और वास्तविक कम्प्रेशन परिणामों का अध्ययन करने के बाद मैंने छोटी, मोबाइल के लिए तैयार वीडियो के लिए एक व्यावहारिक डिलीवरी प्रोफ़ाइल चुनी।

मैंने H.264 के साथ MP4 फ़ॉर्मैट चुना, क्योंकि ब्राउज़र, फ़ोन, डाउनलोड की गई फ़ाइल और बाहरी ऐप्लिकेशन में भरोसेमंद संगतता, किसी नए कोडेक से सबसे छोटी फ़ाइल पाने से अधिक महत्वपूर्ण थी।

मैंने veryslow प्रीसेट के साथ libx264 एन्कोडर चुना, क्योंकि वीडियो को ऑफ़लाइन एन्कोड किया जा सकता था और अतिरिक्त प्रोसेसिंग समय स्वीकार्य था।

ऐनिमे वीडियो के लिए मैं animation ट्यून इस्तेमाल करता हूँ, लेकिन समझता हूँ कि वह एन्कोडर का व्यवहार बदलता है और छोटी फ़ाइल या हर परिस्थिति में बेहतर दृश्य परिणाम की गारंटी नहीं देता।

छोटी, मोबाइल के लिए बनाई गई वीडियो के लिए मैंने CRF 30 चुना, क्योंकि मेरी तुलना में फ़ाइल आकार काफ़ी कम हुआ और सामान्य प्लेबैक में कोई उल्लेखनीय दृश्य अंतर नहीं दिखा, बड़े डेस्कटॉप मॉनिटर पर भी नहीं।

इसका मतलब यह नहीं कि CRF 30 फ़िल्मों या उच्च गुणवत्ता वाले फ़ुटेज के लिए आदर्श है। जहाँ बारीक विवरण, धीरे-धीरे बदलते रंग, ग्रेन और कुल स्रोत-निष्ठा अधिक महत्वपूर्ण हैं, वहाँ मैं CRF 20 के आसपास या किसी दूसरे उचित सतर्क मान से परीक्षण शुरू करूँगा। मैंने सिनेमाई फ़ुटेज पर उसके अनुरूप नियंत्रित अध्ययन नहीं किया, इसलिए उस संख्या को प्रयोग से प्रमाणित सर्वोत्तम मान के रूप में प्रस्तुत नहीं करता।

सबसे महत्वपूर्ण निष्कर्ष है कि सभी वीडियो के लिए कोई एक ऐसा कोडेक, फ़ॉर्मैट या CRF मान नहीं है जो हर स्थिति में सबसे अच्छा हो।

यदि अधिकतम संगतता चाहिए और सिर्फ़ एक फ़ाइल रखनी है, तो MP4/H.264 अच्छा डिफ़ॉल्ट है। यदि फ़ॉलबैक फ़ॉर्मैट दे सकते हैं और बेहतर कम्प्रेशन चाहते हैं, तो VP9 तथा AV1 जाँचें। अगर मुख्यतः फ़ोन पर देखे जाने वाले छोटे वीडियो एन्कोड कर रहे हैं, तो परीक्षण करें कि क्या अधिक CRF इच्छित अनुभव बिगाड़े बिना पर्याप्त छोटी फ़ाइल देता है। फ़िल्में या प्रीमियम फ़ुटेज एन्कोड कर रहे हैं तो अधिक सतर्क गुणवत्ता सेटिंग्स इस्तेमाल करें और परिणाम अच्छी तरह जाँचें।

पहले प्लेबैक की आवश्यकताएँ तय करें, फिर कोडेक चुनें और अंत में कम्प्रेशन गुणवत्ता। उसके बाद उन्हीं डिवाइसों और परिस्थितियों में परिणाम जाँचें जो वास्तव में महत्वपूर्ण हैं। यह तरीका किसी कोडेक या CRF मान को केवल नया, अधिक कुशल या आम तौर पर सुझाया गया मानकर बिना जाँचे अपनाने से अधिक भरोसेमंद है।