चलते 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 fps इस्तेमाल करता है। मैं एक अंतिम स्ट्रीम में खंडों की फ़्रेम दर नहीं मिलाता।

मैं वीडियो ट्रैक के लिए 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 के साथ इच्छित 49 फ़्रेम 16 fps पर और 92 फ़्रेम 30 fps पर बने।

स्ट्रीम-कॉपी कॉनकैट केवल कठोर संगतता जाँचों के बाद सुरक्षित है

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 स्ट्रीमिंग आवश्यकताएँ।