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 رکھنے سے ویڈیو کوڈیک تبدیل نہیں ہوتا۔ اسی طرح 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 سپورٹ نہیں کرتا۔ وقت کے ساتھ براؤزرز کی مطابقت میں نمایاں بہتری آئی ہے۔

زیادہ اہم پابندی براؤزر سے باہر کی مطابقت ہے۔ آپریٹنگ سسٹم کی مقامی ایپلی کیشنز، پرانی ڈیوائسز اور دیگر سافٹ ویئر 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 تک

میں جاننا چاہتا تھا کہ عام پلے بیک میں فرق نمایاں ہونے سے پہلے ویڈیو کو کتنی زیادہ کمپریس کیا جا سکتا ہے۔

میں نے پہلے سے کمپریس شدہ ایک مختصر ویڈیو لی اور اس کی H.264 تقابلی فائلیں CRF 22، 24، 26، 28، 29، 30، 31 اور 32 پر بنائیں۔

میں نے ویڈیو کی اہم خصوصیات، بشمول ریزولوشن، فریم ریٹ، دورانیہ اور فریموں کی تعداد، برقرار رکھیں۔ انکوڈر کی ترتیبات بھی یکساں رکھیں تاکہ 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 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 کو ترجیح دیتا ہوں اور متعلقہ مواد کے انکوڈنگ پروفائل کے حصے کے طور پر فائل کا حجم اور معیار جانچتا ہوں۔

انکوڈر کی tuning کو ہر صورت میں معیار بہتر کرنے کے طریقے کے بجائے مواد کے مطابق ایک تبدیلی سمجھنا چاہیے۔

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 کا بنیادی 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 قدر کو اندھا دھند اپنانے کے مقابلے میں یہ طریقہ زیادہ قابلِ اعتماد ہے کہ وہ نئی، زیادہ مؤثر یا عام طور پر تجویز کردہ ہے۔