متحرک WebP، GIF اور APNG کو فریم یا وقت خراب کیے بغیر H.264 MP4 میں کیسے بدلتا ہوں

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

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

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

اسی لیے میں تبدیلی کو ایک حکم نہیں بلکہ ایسی مستقل شرائط کی زنجیر سمجھتا ہوں جنہیں ہر مرحلے پر قائم رہنا چاہیے:

متحرک WebP / GIF / APNG
        ↓
حقیقت میں دکھائی دینے والی مکمل کینوس حالتیں دوبارہ بنانا
        ↓
سورس کا وقت بازیافت اور درست کرنا
        ↓
آخری سلسلے کے تمام سورسز کا تجزیہ
        ↓
آخری MP4 کے لیے ایک CFR منتخب کرنا
        ↓
تصویر بڑا کیے بغیر سب سے چھوٹا مشترک کینوس بنانا
        ↓
مطابق H.264 سیگمنٹس انکوڈ کرنا
        ↓
اسٹریم معاہدے کی جانچ
        ↓
اسٹریم کاپی سے جوڑنا
        ↓
پیکٹ ٹائم لائن کو معمول پر لا کر جانچنا
        ↓
HTTP ترسیل کی جانچ
        ↓
ایک ناقابلِ تقسیم محفوظ عمل میں شائع کرنا

کوڈیک اہم ہے، مگر اس سے بھی زیادہ اہم یہ ہے کہ اینیمیشن نے حقیقت میں جو کچھ دکھایا تھا وہ محفوظ رہے۔

حقیقی ناپا ہوا نتیجہ: 217 متحرک WebP ایک 78.49 MB MP4 بن گئے

ان پٹ 1.49 GB کی ایک ویڈیو نہیں تھا۔ یہ 217 الگ متحرک WebP فائلیں تھیں، جن میں مجموعی طور پر 10,633 نظر آنے والے فریم تھے۔ تمام سورس اینیمیشنز کا مجموعی حجم تقریباً 1.49 GB تھا۔

ان پٹ
217 متحرک WebP فائلیں
کل 1.49 GB
10,633 نظر آنے والے فریم

آؤٹ پٹ
1 H.264 MP4
78.49 MB
0.98 Mbps
1264×720
30 fps CFR
Main@3.1 / CRF 28 / veryslow

نتیجے میں H.264 فائل 78.49 MB اور تقریباً 0.98 Mbps تھی۔ سورس اینیمیشنز کے مجموعی بائٹس کے مقابلے میں یہ تقریباً 19 گنا چھوٹی، یعنی قریب 94.7% کم ڈیٹا تھی۔

یہ پورے نظام کا آغاز سے انجام تک ناپا ہوا نتیجہ ہے، “پرانا H.264 بمقابلہ نیا H.264” والا صاف A/B ٹیسٹ نہیں۔ نمائندگی سینکڑوں متحرک تصویری فائلوں سے بدل کر وقتی کمپریشن والی ایک ویڈیو بن گئی، اس لیے میں پورے 19 گنا فرق کو CRF 28، veryslow یا کسی ایک انکوڈر اختیار کا نتیجہ نہیں کہتا۔

سب سے پہلے وہ مکمل تصویر دوبارہ بناتا ہوں جو دیکھنے والے کو حقیقت میں نظر آتی ہے

سب سے خطرناک شارٹ کٹ یہ فرض کرنا ہے کہ اینیمیشن میں محفوظ ہر فریم ایک مکمل تصویر ہے جو پچھلی تصویر کو پوری طرح بدل دیتا ہے۔

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

اس لیے محفوظ فریم محض ایک چھوٹا سا ٹکڑا ہو سکتا ہے جس کا مطلب پچھلے فریموں سے بنے کینوس پر منحصر ہو۔ ایسے ٹکڑوں کو مکمل تصاویر سمجھ کر انکوڈ کرنے سے صحیح اینیمیشن کی چھوٹی نقل نہیں بنتی؛ غلط اینیمیشن بنتی ہے۔

میری نکالنے کی اکائی مکمل دکھائی گئی کینوس حالت ہے: وہ تمام مرکب پکسلز جو درست ناظر پچھلے فریم کے ہٹانے کے قاعدے اور موجودہ فریم کے امتزاج کے قاعدے کے بعد دکھائے گا۔

یہ پورے نظام کی پہلی درستگی کی ضمانت ہے۔ غلط جزوی فریم ایک بار H.264 میں مستقل ہو جائے تو بعد کا CRF، پری سیٹ یا مکس اختیار اسے درست نہیں کر سکتا۔

فریم کا وقت سورس کا ڈیٹا ہے، اندازے سے لیا ہوا FPS نہیں

اینیمیشن فارمیٹس وقت مختلف انداز میں محفوظ کرتے ہیں۔ متحرک WebP ہر فریم کا دورانیہ 1 ms کی اکائیوں میں رکھتا ہے۔ GIF تاخیر کو سیکنڈ کے سوویں حصوں میں رکھتا ہے۔ APNG ہر فریم کی تاخیر کے لیے صورت اور مخرج رکھتا ہے؛ مخرج صفر ہو تو PNG کی تفصیلات اسے 100 مانتی ہیں۔

یہی تاخیر اصل ٹائم لائن ہے۔ عام جانچ کے آلے کا نمایاں FPS صرف خلاصہ ہے اور گمراہ کر سکتا ہے۔

میرے نظام میں ایک حقیقی WebP، 1264×720 تھا اور اس میں 49 نظر آنے والے فریم تھے۔ تاخیر 62 اور 63 ms کے درمیان باری باری آتی تھی اور مجموعی دورانیہ 3.063 سیکنڈ تھا۔ عملی طور پر یہ 16 fps کی رفتار ہے کیونکہ 16 fps پر ہر فریم 62.5 ms رہتا ہے۔

ایک عام جانچ کے آلے نے اسی سورس کو 25 fps بتایا۔ اس عدد پر اعتماد کرنے سے سورس کا وقت بدل جاتا یا غیر ضروری دہرائی گئی تصاویر بنتیں۔

خراب یا مبہم تاخیر کے لیے بھی واضح پالیسی چاہیے۔ WebP صفر فریم دورانیہ، اور اکثر بہت چھوٹے دورانیوں، کی تعبیر عمل درآمد پر چھوڑتا ہے۔ GIF میں صفر تاخیر ہو سکتی ہے۔ APNG صورت کو صفر رکھنے دیتا ہے، یعنی اگلا فریم جتنی جلدی ممکن ہو دکھایا جائے، اگرچہ ناظر عملی کم از کم حد لگا سکتا ہے۔

میری معمول سازی کی پالیسی وقت کو ملی سیکنڈ کی درستگی پر رکھتی ہے، صفر یا غیر معقول حد تک چھوٹے فریم دورانیے کے لیے 10 ms کی کم از کم حد لگاتی ہے، اور 100 ms صرف تب استعمال کرتی ہے جب مفید وقت واقعی موجود نہ ہو۔ یہ میری عملی پالیسی ہے، کوئی عالمی معیار نہیں۔

پورے آخری MP4 کے لیے ایک CFR چنتا ہوں، 30 fps کو پہلے سے طے شدہ نہیں بناتا

نظر آنے والی حالتیں اور ان کے دورانیے دوبارہ بنانے کے بعد سورس ٹائم لائن کو ویڈیو ٹائم لائن پر نقش کرتا ہوں۔ ہر چیز کو آنکھ بند کرکے 30 fps پر انکوڈ نہیں کرتا۔

ایک ہی آخری MP4 میں آنے والے ہر سورس کے لیے یہ چھوٹا مجموعہ جانچتا ہوں:

10, 12, 15, 16, 18, 20, 24, 25, 30 fps

منتخب کنندہ وہ سب سے کم CFR لیتا ہے جو پورے آخری سلسلے کو قابل قبول انداز میں دکھا سکے۔ مختلف آخری MP4 مختلف شرح لے سکتے ہیں، مگر ایک ہی آخری MP4 میں آزادانہ انکوڈ کیے گئے تمام سیگمنٹس ایک ہی منتخب CFR استعمال کرتے ہیں۔

3.063 سیکنڈ کی مثال بچت واضح کرتی ہے۔ 16 fps پر تقریباً 49 نتیجہ فریم درکار ہیں، جبکہ 30 fps پر تقریباً 92۔ اگر اسی MP4 میں کوئی دوسرا سورس واقعی 30 fps مانگتا ہو تو پورا مجموعہ 30 استعمال کرتا ہے۔ ایک آخری اسٹریم میں مختلف سیگمنٹ فریم ریٹس نہیں ملاتا۔

ویڈیو ٹریک کے لیے 90,000 Hz ٹائم اسکیل استعمال کرتا ہوں کیونکہ ہر منظور شدہ CFR صحیح عدد میں فریم دورانیہ دیتا ہے:

10 fps → 9000 ticks
12 fps → 7500 ticks
15 fps → 6000 ticks
16 fps → 5625 ticks
18 fps → 5000 ticks
20 fps → 4500 ticks
24 fps → 3750 ticks
25 fps → 3600 ticks
30 fps → 3000 ticks

یہ ویڈیو ٹریک ٹائم اسکیل ہی درست فریم گرڈ بناتا ہے۔ یکسانیت کے لیے MP4 کا مووی ٹائم اسکیل بھی 90,000 رکھتا ہوں، مگر وہ کنٹینر کی الگ گھڑی ہے۔ ویلیڈیٹر گول کیے ہوئے اعشاری دورانیوں کے بجائے ویڈیو پیکٹس کو اسی صحیح عددی گرڈ پر جانچتا ہے۔

ریزولوشن کی حدیں صرف زیادہ سے زیادہ ہیں، لازمی کینوس نہیں

میری ترسیلی حد تقریباً افقی کے لیے 1280×720، عمودی کے لیے 720×1280، اور مخلوط سمت والے مواد کے لیے چوڑائی اور اونچائی دونوں زیادہ سے زیادہ 960 ہے۔

ناقابل سمجھوتا قاعدہ یہ ہے: کبھی تصویر بڑی نہ کرو۔ 900×600 سورس کو 1280×720 کرنے سے تفصیل واپس نہیں آتی؛ صرف اضافی انٹرپولیٹ شدہ پکسلز بنتے ہیں جنہیں انکوڈر کو بیان کرنا پڑتا ہے۔

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

پہلے ہر سورس کے صرف چھوٹا کیے گئے فعال ابعاد نکالتا ہوں۔ پھر آخری سلسلے کے لیے سب سے چھوٹا مشترک جفت-ابعاد کینوس بناتا ہوں جس میں وہ تمام پہلے سے چھوٹے کیے گئے فعال مستطیل سما جائیں۔

مثلاً آخری سلسلے میں 960×540 افقی تصویر اور 500×900 عمودی تصویر چاہیے تو مشترک کینوس 960×900 ہو سکتا ہے، 960×960 نہیں۔ تمام سیگمنٹس کے انکوڈ شدہ ابعاد پھر بھی ایک جیسے رہتے ہیں، اس لیے اسٹریم-کاپی جوڑ ممکن رہتا ہے، مگر بے فائدہ سیاہ حصہ انکوڈ نہیں کرنا پڑتا۔

میں نسبتِ ابعاد محفوظ رکھتا ہوں اور تصویر کھینچنے کے بجائے خالی جگہ بھرتا ہوں۔ اس نظام میں پیڈنگ سیاہ ہے۔ عام H.264/yuv420p سورس کا الفا چینل محفوظ نہیں کرتا، اس لیے شفافیت کو حادثاتی طور پر کھونے کے بجائے جان بوجھ کر اسی پس منظر پر ملا دیتا ہوں۔

اس ترسیلی مسئلے کے لیے H.264 MP4 کیوں موزوں ہے

GIF، APNG اور متحرک WebP سادہ یا بے وقوف فارمیٹس نہیں۔ وہ بدلے بغیر حصوں کو دوبارہ کھینچنے سے بچ سکتے ہیں، اس لیے “ویڈیو ہمیشہ چھوٹی ہوتی ہے” کہنا غلط ہوگا۔

لیکن H.264 تصاویر کے درمیان وقتی پیش گوئی کے لیے بنایا گیا ہے۔ جامد پس منظر اور چھوٹے حرکت والے حصوں پر مشتمل مختصر مصوری والے مختصر لوپس حوالہ تصاویر، بین فریم پیش گوئی، P فریمز اور B فریمز کے لیے موزوں مواد ہیں۔

Apple کی موجودہ Safari رہنمائی جامد ویڈیو کے لیے H.264 انکوڈ شدہ MP4 تجویز کرتی ہے اور بتاتی ہے کہ متحرک GIF جدید ویڈیو کوڈیک کے مقابلے میں بینڈوڈتھ میں 12 گنا تک اور توانائی میں تقریباً دو گنا مہنگا ہو سکتا ہے۔ یہ 12× Apple کی مثال ہے، میری تقابلی پیمائش نہیں۔

اس لیے میرا ناپا ہوا 19× نتیجہ حقیقی پروڈکشن مشاہدہ ہے، مگر میں پھر بھی پیمائش کرتا ہوں؛ یہ فرض نہیں کرتا کہ ہر پہلے سے چھوٹا اور بہتر کیا ہوا متحرک WebP لازماً MP4 سے بڑا ہوگا۔

ہر اینیمیشن ایک ہی اسٹریم معاہدے کے تحت الگ سیگمنٹ کے طور پر انکوڈ ہوتی ہے

انکوڈر چلنے تک نظام نظر آنے والے فریم، پورے مجموعے کا CFR، آخری کینوس اور متوقع دورانیہ پہلے ہی جانتا ہے۔

سیگمنٹ انکوڈنگ کے حکم کا مرکزی حصہ تقریباً یہ ہے:

ffmpeg -framerate "$COLLECTION_FPS" -i frame-%06d.png \
  -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 "$GOP_FRAMES" \
  -maxrate:v 4M \
  -bufsize:v 8M \
  -x264-params "stitchable=1:open-gop=0:b-pyramid=normal:nal-hrd=none" \
  -color_range tv \
  -color_primaries bt709 \
  -color_trc bt709 \
  -colorspace bt709 \
  -fps_mode passthrough \
  -map_metadata -1 \
  -map_chapters -1 \
  -an -sn -dn \
  -video_track_timescale 90000 \
  -movie_timescale 90000 \
  -t "$EXPECTED_DURATION" \
  segment.mp4

GOP کی حد منتخب CFR کے حساب سے تقریباً پانچ سیکنڈ ہے: 16 fps پر 80 فریم، 24 fps پر 120، اور 30 fps پر 150۔

-t "$EXPECTED_DURATION" محض اضافی حفاظتی سجاوٹ نہیں۔ میرے فریم-فہرست نظام میں آخری تصویر کو اختتامی نشان کے طور پر دوبارہ رکھا جاتا ہے تاکہ پچھلے حقیقی فریم کا دورانیہ درست لگے۔ واضح دورانیہ حد نہ ہو تو یہی نشان آخر میں ایک اضافی نمونہ بن سکتا ہے۔

49 فریم، 3.063 سیکنڈ والی مثال پر اسے دوبارہ ثابت کیا۔ -t کے بغیر 16 fps پر 50 فریم اور 30 fps پر 94 فریم بنے۔ -t 3.063 کے ساتھ مطلوبہ 16 fps پر 49 فریم اور 30 fps پر 92 فریم ملے۔

اسٹریم-کاپی جوڑ صرف سخت مطابقتی جانچ کے بعد محفوظ ہے

FFmpeg کا کونکیٹ ڈی مکسَر یہ توقع کرتا ہے کہ فائلوں میں کوڈیک اور ٹائم بیس سمیت ایک جیسے اسٹریمز ہوں، اور ہر فائل کا دورانیہ اگلی فائل کی جگہ طے کرنے کے لیے استعمال کرتا ہے۔ غلط دورانیے کا میٹاڈیٹا ٹائم لائن خرابیاں بنا سکتا ہے۔

میں کونکیٹ کو غیر مطابق فائلیں مطابق بنانے کے لیے استعمال نہیں کرتا۔ سیگمنٹ کو قبول ہونے سے پہلے یہ معاہدہ پورا کرنا پڑتا ہے:

پورے مجموعے کا CFR = یکساں
اسٹریم ٹائم بیس = یکساں
MP4 ویڈیو ٹریک ٹائم اسکیل = یکساں
کینوس کے ابعاد / SAR = یکساں
پروفائل / لیول / پکسل فارمیٹ = یکساں
رنگ کی نشان دہی = یکساں
avcC / AVC اضافی ڈیٹا = بائٹ بہ بائٹ یکساں

میں x264 کا stitchable=1 استعمال کرتا ہوں کیونکہ سیگمنٹس آزادانہ انکوڈ ہوتے ہیں، مگر اسے AVC کنفیگریشن کے یکساں ہونے کا ثبوت نہیں سمجھتا۔ جوڑنے سے پہلے حقیقی کنفیگریشن بائٹس کا موازنہ پھر بھی کرتا ہوں۔

معاہدہ پورا ہو تو آخری جوڑ ویڈیو بٹ اسٹریم کی سطح پر دوسری نقصانی نسل کے بغیر رہ سکتا ہے:

ffmpeg -f concat -safe 0 -i segments.ffconcat \
  -c:v copy \
  -an -sn -dn \
  -movflags +faststart \
  final.mp4

-c:v copy پہلے سے انکوڈ H.264 سیگمنٹس کو ڈی کوڈ کرکے دوبارہ کمپریس ہونے سے بچاتا ہے۔

توثیق MP4 فائل اور اس کی حقیقی ترسیل دونوں کو شامل کرتی ہے

صرف اس لیے فائل شائع نہیں کرتا کہ FFmpeg نے اخراج کوڈ 0 دیا۔

ویلیڈیٹر نے حقیقی قطعی زمانی خرابیاں پکڑی ہیں: 16 fps پر 5625 کے بجائے 5580 ٹکس ملے، اور بعد میں 24 fps نتیجہ میں بالکل 3750 کے بجائے 3751۔ ایک ٹک کی گہری تحقیق الگ موضوع ہے؛ یہاں سبق صرف یہ ہے کہ قطعی ٹائم لائن خرابی ایک ہی انکوڈ دوبارہ چلانے سے درست نہیں ہوتی۔

میڈیا فائل کے لیے متوقع اسٹریم تعداد، H.264 پروفائل/لیول، پکسل فارمیٹ، منصوبہ بند درست ابعاد، SAR، رنگ کی نشان دہی، 90 kHz ویڈیو ٹریک ٹائم اسکیل، پیکٹ دورانیے، فریم/پیکٹ تعداد، مجموعی دورانیہ، PTS/DTS تعلقات، سیگمنٹس میں یکساں AVC کنفیگریشن، moov کا mdat سے پہلے ہونا، اور سخت خرابی سنبھالنے کے ساتھ مکمل ڈی کوڈ جانچتا ہوں۔

ffprobe -v error \
  -select_streams v:0 \
  -show_streams \
  -show_packets \
  -of json \
  final.mp4

ffmpeg -v error -xerror -err_detect explode \
  -i final.mp4 -f null -

لیکن مقامی طور پر درست MP4 بھی ویب پر غلط طریقے سے پیش ہو سکتا ہے۔ اس لیے متوقع Content-Type، درست Content-Length، بائٹ رینج سپورٹ، درست 206 Partial Content جواب اور درست Content-Range بھی جانچتا ہوں۔

انکوڈر معاہدہ بدلنے پر ffprobe کو ہارڈویئر مطابقت کا ثبوت نہیں مانتا؛ ایک مختصر حقیقی ڈیوائس/براؤزر کینری بھی چلاتا ہوں۔ موجودہ iPhone/Safari، ایک عام Android ڈیوائس اور اہم ڈیسک ٹاپ براؤزرز پر آغاز، سیک، لوپ، پس منظر/دوبارہ آغاز اور رینج پلے بیک جانچتا ہوں۔

فائل اور ترسیل کا راستہ دونوں معاہدہ پاس کریں تب ہی پروڈکشن فائل کو ایک ناقابلِ تقسیم محفوظ عمل میں بدلتا ہوں۔

یہ نظام جان بوجھ کر کہاں معلومات کھوتا ہے

یہ ترسیلی تبدیلی ہے، آرکائیوی ماسٹر نہیں۔ الفا پس منظر میں ملا دی جاتی ہے۔ غیر ہموار سورس وقت آخری MP4 کے ایک CFR پر کوانٹائز ہوتا ہے۔ بڑے سورس چھوٹے کیے جا سکتے ہیں۔ پہلے سے نقصانی متحرک WebP کو ایک اور نقصانی نسل ملتی ہے۔ آڈیو جان بوجھ کر موجود نہیں۔

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

بہت چھوٹے اور پہلے سے اچھی طرح بہتر کیے گئے متحرک WebP کو بھی ناپتا ہوں؛ یہ فرض نہیں کرتا کہ MP4 لازماً چھوٹا ہوگا۔

اب استعمال ہونے والا پروڈکشن سلسلہ

متحرک فارمیٹ پہچانتا اور حقیقی فریم کنٹرول میٹاڈیٹا پڑھتا ہوں۔
فارمیٹ کے امتزاج اور ہٹانے کے قواعد کے مطابق مکمل دکھائی گئی کینوس حالتیں دوبارہ بناتا ہوں۔
ہر فریم دورانیہ بازیافت اور غلط قدروں کو درست کرتا ہوں۔
ملی سیکنڈ کی درستگی پر قابل اعتماد سورس ٹائم لائن بناتا ہوں۔
ایک ہی آخری MP4 میں آنے والے تمام سورسز کا تجزیہ کرتا ہوں۔
10/12/15/16/18/20/24/25/30 میں سے پورے مجموعے کے لیے ایک CFR چنتا ہوں۔
دکھائی گئی حالتوں کو منتخب CFR ٹائم لائن پر نقش کرتا ہوں۔
صرف چھوٹا کرکے فعال ابعاد نکالتا ہوں؛ کبھی بڑا نہیں کرتا۔
آخری سلسلے کے لیے ضروری سب سے چھوٹا مشترک جفت-ابعاد کینوس بناتا ہوں۔
تصویر کھینچے بغیر خالی جگہ بھرتا اور الفا کو جان بوجھ کر پس منظر میں ملاتا ہوں۔
ہر سورس کو ایک ہی اسٹریم معاہدہ کے تحت H.264 Main@3.1 / yuv420p / avc1 میں انکوڈ کرتا ہوں۔
ہر سیگمنٹ کو متوقع دورانیہ تک محدود کرتا ہوں۔
وہ سیگمنٹ رد کرتا ہوں جس کی حقیقی AVC کنفیگریشن یا وقت معاہدہ توڑتی ہو۔
قبول شدہ سیگمنٹس کو -c:v copy سے جوڑتا ہوں۔
آخری پیکٹ ٹائم لائن کو معمول پر لا کر توثیق کرتا ہوں۔
نتیجے کو مکمل ڈی کوڈ کرتا ہوں۔
HTTP ہیڈرز، بائٹ رینج اور جزوی-مواد برتاؤ جانچتا ہوں۔
انکوڈر پروفائل بدلنے کے بعد ڈیوائس/براؤزر کینری چلاتا ہوں۔
تمام جانچیں کامیاب ہوں تب ہی ایک ناقابلِ تقسیم محفوظ عمل میں شائع کرتا ہوں۔

حقیقی بنیاد فائل ایکسٹینشن نہیں بلکہ ٹائم لائن ہے

متحرک WebP، GIF یا APNG محض تصویری ایکسٹینشن والی تصویروں کا فولڈر نہیں؛ یہ وقت کے ساتھ بدلنے والی مکمل دکھائی گئی کینوس حالتوں کا سلسلہ ہے۔

H.264 زمانی تکرار سے بہت مؤثر فائدہ اٹھا سکتا ہے، مگر غلط کمپوزٹنگ، گھڑا ہوا وقت یا غیر مطابق سیگمنٹ میٹاڈیٹا درست نہیں کر سکتا۔ اس نظام کو قابل اعتماد بنانے والی زیادہ تر انجینئرنگ x264 سے پہلے اور بعد ہوتی ہے۔

میرا آخری اصول یہ ہے: نمائندگی صرف تب بدلو جب ٹھیک ٹھیک بتا سکو کہ کیا چیز لازماً ایک جیسی رہنی چاہیے۔

بنیادی دستاویزات

Google WebP کنٹینر تفصیلات — فریم مستطیل، دورانیہ، امتزاج اور ہٹانے کا طریقہ۔
W3C PNG تفصیلات، تیسرا ایڈیشن — APNG فریم وقت، آف سیٹس، امتزاج اور ہٹانے کی کارروائیاں۔
GIF89a تفصیلات — GIF تاخیر اور ہٹانے کا برتاؤ۔
FFmpeg فارمیٹس کی دستاویزات — کونکیٹ ڈی مکسَر کے تقاضے اور MP4 مکس کا برتاؤ۔
FFmpeg بٹ اسٹریم فلٹرز کی دستاویزات — setts ۔
ffprobe دستاویزات — اسٹریم اور پیکٹ کی جانچ۔
Apple: Safari کے لیے ویڈیو مواد کی ترسیل — جامد ویڈیو کے لیے H.264 MP4 اور متحرک GIF بدلنے کی رہنمائی۔
Android کے معاون میڈیا فارمیٹس — H.264 معاونت اور HTTP اسٹریم کے تقاضے۔