میں نے 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% بچت پہلے ہی ہو چکی تھی، لیکن میرے بینڈوڈتھ ہدف کے لیے 238 MB اب بھی بہت بڑا تھا۔

پرانی لائبریری کے جائزے نے بھی دکھایا کہ ضرورت سے بڑی 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 ہے، اور فطری طور پر کم فریم ریٹ والی اینیمیشن کو صرف اس لیے 30 fps پر مجبور نہیں کرنا چاہیے کہ مثال میں -g 150 ہے۔

کمانڈ پالیسی کا نفاذ ہے، خود پالیسی نہیں۔

فائلیں کئی گنا چھوٹی کیوں ہوئیں

کوئی جادوئی فلیگ نہیں تھا۔

کمی کئی فیصلوں کو اکٹھا کرنے سے آئی، جن میں ہر ایک نے الگ قسم کا ضیاع ختم کیا: غیر ضروری پکسل، غیر ضروری فریم، حد سے زیادہ محتاط معیار کا ہدف، کارکردگی کے بجائے رفتار کو ترجیح دینے والی انکوڈر ترتیب، ضرورت سے زیادہ کلیدی فریم، اور وہ ڈیٹا اسٹریم جن کی مجھے ضرورت نہیں تھی۔

اسی لیے “یہ فائل H.264 ہے” کہنا اس کے سائز کے بارے میں حیرت انگیز طور پر کم بتاتا ہے۔ ایک ہی ماخذ کی دو H.264 انکوڈنگز میں بڑا فرق ہو سکتا ہے کیونکہ کوڈیک کا نام ریزولوشن، فریم ریٹ، شرح کنٹرول، پری سیٹ، GOP ساخت، پروفائل یا ماخذ کی تیاری نہیں بتاتا۔

میرے معاملے میں کوڈیک کے اردگرد یہ فیصلے بدلنا خود کوڈیک بدلنے سے زیادہ اہم تھا۔

یہ نتیجہ کیا ثابت نہیں کرتا

میں نے ہر سیٹنگ کو کنٹرول شدہ تجربہ میں الگ نہیں کیا، اس لیے دیانت داری سے نہیں بتا سکتا کہ بچت کا بالکل کتنا فیصد veryslow، CRF 28، ریزولوشن میں کمی یا فریم ریٹ میں کمی سے الگ الگ آیا۔

میں یہ بھی دعویٰ نہیں کر سکتا کہ ہر CRF 28 آؤٹ پٹ ادراکی طور پر شفاف ہے۔ “معیار میں واضح کمی نہیں” اس مصورانہ مواد کو عام سائز پر دیکھنے کا میرا مشاہدہ ہے، ہر قسم کی ویڈیو کے لیے سائنسی ضمانت نہیں۔

اور میں یہ نہیں کہتا کہ ایک H.264 فائل ہر ویب سائٹ کے لیے درست فن تعمیر ہے۔ متعدد ورژنز، مطابقت پذیر ترسیل، HDR، 4K اور کوڈیک کے انتخاب سے توازن بدل جاتا ہے۔

میں حقیقتاً اس سے محدود دعویٰ کر سکتا ہوں: مختصر مصورانہ اور متحرک کلپس کی ایسی لائبریری میں جہاں بینڈوڈتھ پہلی ترجیح ہو، زیادہ تر ناظرین موبائل پر ہوں، انکوڈنگ وقت سستا ہو اور قابل پیش گوئی پلے بیک اہم ہو، اس پروفائل نے میری فائلیں کئی گنا چھوٹی کیں جبکہ عام پلے بیک میں وہ معمول کے مطابق نظر آتی رہیں۔

اس نتیجے نے میری بہتری کی حکمتِ عملی کیسے بدلی

پہلے میں ویڈیو بہتری کو بنیادی طور پر انکوڈر ترتیبات کا مسئلہ سمجھتا تھا۔ اب میں اسے فائل کی پوری عمر کی لاگت کا مسئلہ سمجھتا ہوں۔

انکوڈر شاید ایک بار چلے۔ بائٹس نیٹ ورک سے ہزاروں یا لاکھوں بار گزر سکتے ہیں۔

یہ “مہنگا” ہونے کا مطلب بدل دیتا ہے۔

میں ایک بار CPU خرچ کرنے پر خوش ہوں۔ لیکن ہر آئندہ درخواست میں بڑا کرنے سے بنے پکسل، ایسی فریمیں جو مفید حرکت نہ بڑھائیں، یا وہ بٹ ریٹ جس کی مواد کو ضرورت نہیں، بھیجنے پر بہت کم آمادہ ہوں۔

کوڈیک سادہ ہی رہا: MP4 میں H.264۔ بہتری اس کے اردگرد ہوئی۔

اس استعمال کے لیے سبق کسی ایک FFmpeg فلیگ سے زیادہ واضح ہے: اس لاگت کو بہتر کرو جو بار بار ادا کرتے ہو، اس کو نہیں جو صرف ایک بار ادا ہوتی ہے۔