जीआईएफ करने के लिए या नहीं करने के लिए?

सभी को नमस्कार! मेरा नाम एंटोन है, मैं iFunny के सर्वर पक्ष को विकसित कर रहा हूं - एक मोबाइल हास्य सेवा। इस लेख में मैं इस बारे में बात करूंगा कि परियोजना में एनीमेशन के साथ काम करने के लिए हमारा दृष्टिकोण कैसे विकसित हुआ है और अंत में क्या लाभ हुआ है।




यह ज्ञात है कि हास्य उम्र बढ़ने की प्रक्रिया को धीमा कर देता है, और हंसी जीवन को लम्बा खींचती है, यही कारण है कि हम iFunny बनाने के लिए बहुत खुश हैं, जो हर दिन 4 मिलियन से अधिक उपयोगकर्ताओं को मुस्कान और अच्छा मूड देता है (फिलहाल, दुर्भाग्य से या सौभाग्य से, ज्यादातर यूएसए से) । हम दुनिया में सबसे सुविधाजनक मज़ा ब्राउज़र बनने का प्रयास करते हैं, साथ ही साथ उस जगह पर जहां सबसे अच्छा हास्य पैदा होता है। हमारे उपयोगकर्ता प्रतिदिन 250,000 से अधिक कार्य अपलोड करते हैं।

कुछ समय पहले तक, हम प्रति दिन लगभग 150TB का वितरण कर रहे थे, लेकिन परियोजना में एनीमेशन के अतिरिक्त, हमें डाउनलोड की गई सामग्री की संख्या में 17% की वृद्धि हुई और दैनिक यातायात में 750TB की वृद्धि हुई।

जीआईएफ अनुकूलन

ऐसा हुआ कि वर्तमान में हास्य से सबसे दिलचस्प कटौती (और ऐसा नहीं है) वीडियो जीआईएफ में एन्कोड किए गए हैं, जो परिणामस्वरूप फ़ाइलों की मात्रा को दुखद रूप से प्रभावित करता है। हमारी भावनाओं के अनुसार, आधुनिक इंटरनेट पर जीआईएफ-एनिमेशन का औसत आकार लगभग 5 एमबी है। विकास के दौरान हमने जो तार्किक प्रश्न पूछा था, क्या हम इसकी मात्रा कम करने के लिए सर्वर साइड पर किसी तरह एनीमेशन का अनुकूलन कर सकते हैं?

विभिन्न एनिमेटेड फ़ाइलों और अनुकूलन एल्गोरिदम (बेसिक फ्रेम ऑप्टिमाइज़ेशन, ट्रांसपेरेंसी ऑप्टिमाइज़ेशन) के साथ प्रयोगों की एक श्रृंखला के बाद, हम इस निष्कर्ष पर पहुंचे कि अधिकांश छवियों के लिए अनुकूलन से प्राप्त लाभ बहुत छोटा निकला, लगभग 10-20%। इसके अलावा, अगर GIF-एनीमेशन पहले से ही इसके लेखक द्वारा अच्छी तरह से अनुकूलित किया गया था, तो एक स्वचालित दृष्टिकोण के साथ हम विपरीत प्रभाव प्राप्त कर सकते हैं।

आशा की रोशनी कि हम किसी तरह एनीमेशन फ़ाइलों की मात्रा को कम कर सकते हैं, और हम उस रूप में जीआईएफ का उपयोग करना शुरू कर दिया, जिसमें उपयोगकर्ता इसे हमारे पास अपलोड करते हैं।

जीआईएफ संस्करण रिलीज

अगर सर्वर पर और iOS क्लाइंट में जीआईएफ सपोर्ट लागू करना काफी सरल था, तो एंड्रॉइड क्लाइंट पर हमें दाढ़ी वाले जेडी टूल्स - लिबजीफ + जेएनआई का सहारा लेना पड़ा, जिसने हमें परेशान किया।

जैसे ही सब कुछ समाप्त हो गया, हमने ऐप स्टोर में सेंसर की जाँच को पारित कर दिया, आवेदन को Google Play पर अपलोड कर दिया और शुरू कर दिया ... और पहले दिन के ठीक बाद हमने सामग्री दृश्यों में एक तेज उछाल देखा और, तदनुसार, यातायात। पहले 24 घंटों में, यातायात 6 गुना बढ़ गया!



कुल मिलाकर, आधे महीने में वितरित यातायात की मात्रा में 200% की वृद्धि हुई और जून में, iFunny में एनीमेशन के लॉन्च के लिए धन्यवाद, हमने 4.75 पेटाबाइट्स दिए! दर्शकों की गतिविधि में वृद्धि, निश्चित रूप से आनन्दित नहीं कर सकती है, लेकिन क्या अंत में सब कुछ ठीक हो गया?

हम iFunny में GIF एनीमेशन की एक निश्चित मात्रा के लिए तैयार थे, लेकिन पहले कुछ दिनों में हमें जो आंकड़े मिले, उससे यह स्पष्ट हो गया कि हम आशावादी नहीं थे: प्रति दिन लोड किए गए GIF एनिमेशनों की वास्तविक संख्या 5 बार से अधिक थी। बड़े पैमाने पर 3-4 मेगाबाइट जीआईएफ के साथ जो हर 3-5 स्थिर छवियों के माध्यम से चलते हैं, हमें एक सेवा मिली जो केवल वाईफाई के माध्यम से उपयोग की जा सकती है। यहां तक ​​कि असीमित 3 जी वाले उपयोगकर्ताओं के पास एक कठिन समय था: एनीमेशन लंबे समय तक लोड हो रहा था, और 3 जी मॉड्यूल के सक्रिय काम के कारण, डिवाइस बहुत गर्म था और बैटरी की मौत हो गई थी।

कुछ करने की जरूरत है ...

साहसी आंकड़ों की पृष्ठभूमि के खिलाफ, हमने सोचा: इस तरह के उपयोग के लिए जीआईएफ (छवियों का एक सेट, वास्तव में) कितना उपयुक्त है? हम देखते हैं कि यदि हम कम संख्या में फ़्रेम वाले सरल एनिमेशन से निपट रहे हैं, तो GIF का उपयोग करना उचित से अधिक है। हालांकि, जैसा कि मैंने ऊपर कहा था, एक आधुनिक हास्य GIF वीडियो से दिलचस्प क्षणों का एक कटिंग है ...

पूर्वगामी के आधार पर, हमने लघु एनिमेटेड वीडियो चलाने के लिए कुछ उपयुक्त वीडियो प्रारूप के पक्ष में GIF को छोड़ने का प्रयास करने का निर्णय लिया। इस मामले में, एक उपयुक्त एन्कोडिंग प्रारूप खोजना आवश्यक था। कोडिंग मानकों h.263, h.264, साथ ही साथ WebM कंटेनर में vp8 वीडियो कोडेक पर विचार किया गया।

हमने वीडियो में GIF रूपांतरण परीक्षण चलाए, और सुरंग के अंत में प्रकाश कम हो गया: परिणामस्वरूप वीडियो का आकार GIF स्रोत से 2-10 गुना छोटा था!

यह कोडेक को निर्धारित करने के लिए बनी हुई है। एक सेवानिवृत्त कोडेक का उपयोग करना - h.263 ने एक भयानक परिणामी तस्वीर निकाली और हमारे नैतिक मानकों का खंडन किया, इसलिए हमने इसे पहले खारिज कर दिया।
h.264 एक अच्छा कोडेक है, लेकिन हम पेटेंट द्वारा संरक्षित तकनीक के साथ संवाद नहीं करना चाहते हैं, और परिणामस्वरूप फ़ाइल का आकार काफी बड़ा हो गया है: vp8 में समान टुकड़े को एन्कोडिंग करते समय 20-40% अधिक। इसलिए, हमने vp8 पर रुकने का फैसला किया।

Vp8 चुनते समय एक अतिरिक्त तर्क यह भी था कि Google सक्रिय रूप से YouTube पर इसे शुरू कर रहा है और इसका उपयोग कर रहा है, और वर्तमान में एक बेहतर VP9 प्रारूप विकसित किया जा रहा है, जो हमें संपूर्ण परियोजना की सफलता और संभावनाओं को समग्र रूप से आंकने की अनुमति देता है।

GIF से WebM में बदलने के लिए, हम GIF डिकोडर और vp8 एनकोडर के समर्थन के साथ ffmpeg असेंबली का उपयोग करते हैं। रूपांतरण प्रक्रिया स्वयं विशेष टिप्पणी के बिना और जल्दी से जगह लेती है, लेकिन हम तुरंत परिणामी वीडियो में एक समस्या का सामना करते हैं। उदाहरण के लिए, इस GIF एनीमेशन को लें:



कृपया ध्यान दें कि अंतिम फ्रेम में 2 सेकंड की देरी है, जिसके बाद एनीमेशन फिर से खेला जाता है। प्राप्त वेबएम फ़ाइल में, यह देरी जादुई रूप से कहीं गायब हो जाती है, और अंतिम फ्रेम "स्किप"। अन्य सामग्री के विश्लेषण से पता चला कि एनीमेशन के अंतिम फ्रेम के बाद देरी हमेशा के लिए दूर हो जाती है, जो हमारे लिए एक बड़ी समस्या है, क्योंकि हम चाहते हैं कि एप्लिकेशन के उपयोगकर्ता जीआईएफ और वीडियो के बीच का अंतर बिल्कुल न देखें। समस्या हल हो गई थी, लेकिन इस तरह के बैसाखी के साथ कि हम अभी भी शर्म के साथ शरमा रहे हैं: हम कन्वर्टिबल जीआईएफ में अंतिम फ्रेम के डुप्लिकेट को जोड़ते हैं।

उस समय मोबाइल डेवलपर्स के रैंक में कट्टर शासनकाल: उन्होंने आवश्यक प्लेटफार्मों के लिए libvpx का निर्माण किया, सी और वॉइला में एक आवरण खिलाड़ी लिखा।

WebM संस्करण रिलीज़

संस्करण की रिहाई के बाद, जहां GIF एनिमेशन के बजाय हमने उपयोगकर्ताओं को लघु वीडियो खेलना शुरू किया, यह स्पष्ट हो गया कि किए गए काम का भुगतान किया गया था: एक सत्र में यातायात की खपत अपर्याप्त 50-100Mb से काफी आरामदायक 7-20Mb तक कम हो गई, डिवाइस कम गर्म होने लगे और मारना शुरू हो गए। बैटरी, और सबसे महत्वपूर्ण बात, उपयोगकर्ताओं को इसके प्रीलोडर की तुलना में अधिक बार सामग्री दिखाई देने लगी।

अगर हम अपने हाथ से जाने वाले ट्रैफिक के बारे में बात करते हैं, तो तस्वीर इस प्रकार है:



जीआईएफ से वेबएम पर स्विच करने से हमें वितरित ट्रैफ़िक की मात्रा 30% कम करने और प्रति माह लगभग 50,000 डॉलर सीडीएन लागत कम करने की अनुमति मिली।

निष्कर्ष

20 से अधिक वर्षों पहले बनाया गया GIF87 प्रारूप, नेटवर्क पर रेखापुंज छवियों को स्थानांतरित करने के लिए उपयोग किया जाना था, और GIF89 संशोधन ने पारदर्शिता के साथ छवियों का उपयोग करने और एक निश्चित देरी के साथ सरल स्लाइड के सेट को संग्रहीत करने की अनुमति दी - एनीमेशन।

अपने जीवन के पथ पर, प्रारूप कई महत्वपूर्ण क्रांतियों को बनाने में कामयाब रहा, अब मर रहा है, फिर पुनर्जन्म हुआ।

उदाहरण के लिए, हम सभी को एनिमेटेड विज्ञापन बैनर याद हैं, जो दुर्भाग्य से, अभी भी कुछ विज्ञापन नेटवर्क में उपयोग किए जाते हैं। हां, अब चमकती और चिकने बैनर की यादें एलएसडी से मतिभ्रम से अधिक जुड़ी हैं, लेकिन 10-20 साल पहले यह एक क्रांति थी - इंटरनेट स्थिर होना बंद हो गया।

अब जीआईएफ एक क्रांति भी बना रहा है, जो हिमालयी सामग्री के नए प्रारूप - लघु वीडियो क्लिप के हिमस्खलन-जैसे वितरण में योगदान देता है। हालांकि, हमारे अनुभव की ऊंचाई से, हम कह सकते हैं कि ऊपर सूचीबद्ध कई कारणों के लिए ऐसी सामग्री के लिए जीआईएफ का उपयोग सही नहीं है, और केवल एक शक्तिशाली तर्क उपयोगकर्ताओं को वीडियो से जीआईएफ में स्लाइस वितरित करने के लिए मजबूर करता है - यह सभी ब्राउज़रों में इसका व्यापक समर्थन है। हमारे हाथ वेब नेविगेटर की संभावना से बंधे नहीं हैं, इसलिए हम GIF में निहित minuses के बिना iFunny को "पुनर्जीवित" करने में सक्षम थे।