ड्रॉबल में वीडियो अनुक्रम

JPEG में एन्कोडिंग वीडियो के लिए Apple के दृष्टिकोण पर एक पोस्ट के बाद, मैंने एंड्रॉइड के लिए अपनी समान "बाइक" के बारे में बात करने का फैसला किया।

हमारे मोबाइल प्रोजेक्ट में, हमने हथियार पूर्वावलोकन को एक स्थिर चित्र नहीं, बल्कि एक वीडियो बनाने का निर्णय लिया। यह समझा गया था कि कलाकार सुंदर एनिमेशन खींचेंगे, शायद 3 डी में भी, लेकिन कुछ काम नहीं हुआ और हमें 256x256 के संकल्प में 1-1.5 सेकंड की सबसे सरल लूप दी गई। आईओएस संस्करण में, उन्होंने ठीक बनाया, लेकिन एंड्रॉइड पर मुझे MediaPlayer और SurfaceView के साथ लड़ना पड़ा, लेकिन फिर भी कुछ "अनाड़ीपन" मिला - SurfaceView की सामग्री मूल दृश्य के बाद नहीं चली, प्लेबैक के दौरान ध्यान देने योग्य ठहराव था, आदि।

एक उचित समाधान एनिमेशन को फ्रेम में विभाजित करना और उन्हें एनिमेशनड्राएबल के लिए xml में रखना होगा, लेकिन 15 प्रकार के हथियारों के लिए इसका मतलब होगा 5000+ फ्रेम का कचरा बिन प्रत्येक 10-15 kb। इसलिए, हमारे स्वयं के एनिमेशनड्राएबल को लागू किया गया था, जो एक स्प्राइट शीट के साथ काम कर रहा था और इस तरह के प्रारूप में वीडियो को परिवर्तित करने की एक अपेक्षाकृत त्वरित विधि थी।

स्प्रिट शीट

किसी भी आगे की हलचल के बिना, उन्होंने विवरण फ़ाइल के बिना, स्प्राइट्स का एक नक्शा बनाने का फैसला किया। यह आदर्श रूप से व्यावहारिक नहीं है, लेकिन 1-2 सेकंड के लिए यह महत्वपूर्ण नहीं है।
मूल वीडियो को ffmpeg के माध्यम से स्प्राइट में विभाजित किया गया है:

ffmpeg -i gun.avi -f image2 gun-%02d.png

यदि 32 से अधिक फ़्रेम प्राप्त होते हैं, तो एफपीएस को कम करने के लिए -r 25 या -r 20 विकल्प जोड़ा जाता है। 32 फ्रेम की सीमा 8192 पिक्सल के अधिकतम उचित क्षैतिज चित्र आकार से ली गई है। स्प्राइट्स की अधिक जटिल व्यवस्था द्वारा इसे दरकिनार किया जा सकता है, लेकिन 1-1.5 सेकंड के अनुक्रम के लिए यह पर्याप्त है।

यह फाइलों के बिखरने का पता लगाता है:



मैं स्प्राइट शीट बनाने के लिए Zwoptex का उपयोग करता हूं , लेकिन कोई समान उपकरण, या यहां तक ​​कि एक स्व-लिखित स्क्रिप्ट भी करेगा।



एक पिस्तौल के साथ उदाहरण में, आकार में 257kb की पीएनजी फ़ाइल और 8192x256 का एक संकल्प प्राप्त किया गया था। 7424x256 को ट्रिम करने और टाइनीपीएनजी वेबसाइट के माध्यम से प्रसंस्करण के बाद , यह गुणवत्ता की हानि के बिना घटकर 101kb हो गया। यदि आप चाहें, तो आप इसे गुणवत्ता के मामूली नुकसान के साथ JPG में भी सहेज सकते हैं और इसे 50-70kb तक कम कर सकते हैं। तुलना के लिए, उच्च गुणवत्ता के साथ .MP4 में मूल वीडियो समान 100kb लेता है। अधिक जटिल पीएनजी एनिमेशन के लिए, आप मूल वीडियो की तुलना में 2-3 गुना अधिक प्राप्त कर सकते हैं, जो वास्तव में महत्वपूर्ण नहीं है।

नेटिव एनिमेशनड्राइव

मूल संस्करण में, इस तथ्य पर शर्त लगाई गई थी कि Bitmap.createBitmap एक नई तस्वीर नहीं बनाता है, लेकिन विवरण के अनुसार मौजूदा एक का सबसेट:

स्रोत बिटमैप के निर्दिष्ट सबसेट से एक अपरिवर्तनीय बिटमैप लौटाता है।

डिजाइनर तस्वीर को लोड करता है, इसे फ्रेम में विभाजित करता है और उन्हें एनिमेशनड्रैबल में जोड़ता है। हमारे मामले में एनिमेशन नाम से पहुंच के लिए परिसंपत्तियों में संग्रहीत किए जाते हैं, लेकिन कोड को R.drawable के साथ काम करने के लिए अनुकूलित करना बहुत आसान है। *

 public class AssetAnimationDrawable extends AnimationDrawable { public AssetAnimationDrawable(Context context, String asset, int frames, int fps) throws IOException { BitmapFactory.Options options = new BitmapFactory.Options(); options.inPreferredConfig = Config.RGB_565; // AG: use 16-bit mode without alpha for animations this.bitmap = BitmapFactory.decodeStream(context.getResources() .getAssets().open(asset), null, options); int width = bitmap.getWidth() / frames; int height = bitmap.getHeight(); int duration = 1000 / fps; // AG: note the little gap cause of integer division. // ie duration would be 33 for 30fps, meaning 990ms for 30 frames. for (int i = 0; i < frames; i++) { Bitmap frame = Bitmap.createBitmap(bitmap, i * width, 0, width, height); addFrame(new BitmapDrawable(frame), duration); } } } 

एक कक्षा का उपयोग किया जाता है, एक नियमित एनिमेशनड्राइव की तरह:

  AnimationDrawable animation = new AssetAnimationDrawable(getContext(), "movies/gun.jpg", 28, 25); animation.setOneShot(false); previewImage.setImageDrawable(animation); animation.start(); 

दुर्भाग्य से, प्रयोगों से पता चला कि मूल के लिए एक अपरिवर्तनीय लिंक नहीं बनाया गया है, लेकिन प्रत्येक फ्रेम के लिए एक नई छवि, क्योंकि यह समाधान काफी संसाधन-गहन निकला, हालांकि यह कई स्थितियों के लिए ठीक काम करता है।

अगला विकल्प पहले से ही अधिक जटिल है और ड्रॉबल से सीधे विरासत में मिला है। कंस्ट्रक्टर में, स्प्राइट शीट को कक्षा के सदस्य में लोड किया जाता है, और वर्तमान फ्रेम को ड्रा विधि में खींचा जाता है। कक्षा एनीमेशन के लिए मूल एनिमेशनड्रैबल के समान रननेबल इंटरफ़ेस को भी लागू करती है।

  @Override public void draw(Canvas canvas) { canvas.drawBitmap(m_bitmap, m_frameRect, copyBounds(), m_bitmapPaint); } @Override public void run() { long tick = SystemClock.uptimeMillis(); if (tick - m_lastUpdate >= m_duration) { m_frame = (int) (m_frame + (tick - m_lastUpdate) / m_duration) % m_frames; m_lastUpdate = tick; // TODO: time shift for incomplete frames m_frameRect = new Rect(m_frame * m_width, 0, (m_frame + 1) * m_width, m_height); invalidateSelf(); } scheduleSelf(this, tick + m_duration); } public void start() { run(); } public void stop() { unscheduleSelf(this); } public void recycle() { stop(); if (m_bitmap != null && !m_bitmap.isRecycled()) m_bitmap.recycle(); } 

रन () विधि वर्तमान फ्रेम की गणना करती है और कार्य को कतार में लगाती है। दिए गए कोड की सटीकता आदर्श नहीं होगी, क्योंकि फ्रेम के आंशिक समय को ध्यान में नहीं रखा जाता है (उदाहरण के लिए, जब टिक - m_lastUpdate अवधि की तुलना में 1ms कम है), लेकिन यह हमारे कार्य में प्रासंगिक नहीं था, और जो लोग अपने दम पर कक्षा को संशोधित कर सकते हैं।
पेस्ट 2 के लिए पूरा कोड: paste2.org/p/2240487

मैं रीसायकल () पद्धति पर ध्यान देना चाहता हूं, जो m_bitmap को साफ करती है। ज्यादातर मामलों में, इसकी आवश्यकता नहीं होती है, लेकिन हम स्टोर में खरीद पर जल्दी से क्लिक कर सकते हैं, क्योंकि कई एसेटटाइमिमेशन बनाए जाते हैं और मेमोरी समाप्त हो सकती है, इसलिए एक नया एनीमेशन बनाते समय, हम पुराने के संसाधनों को साफ करते हैं।

पेशेवरों और विपक्ष

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

विपक्ष:

• ड्रायबल से विरासत में हमें कुछ एनिमेशनड्राएबल फ़ीचर मिलते हैं जैसे कि सेटऑनशॉट
• 8192x256x32bpp छवि 8MB मेमोरी में रहती है
• आपको कहीं न कहीं प्रत्येक एनीमेशन के लिए फ़्रेम और एफपीएस की संख्या को संग्रहीत करने की आवश्यकता है
• मानक समाधान के लिए मूल कोड कार्यक्रम की पठनीयता को बाधित करता है और इसके समर्थन को जटिल बनाता है
• जेपीजी के साथ संपीड़ित करने से हमें सबसे खराब गुणवत्ता मिलती है, मूल वीडियो के समान आकार के साथ। पीएनजी में संपीड़ित करने से हमें एक ही गुणवत्ता मिलती है, 1-3 गुना आकार के साथ

पेशेवरों:

• SurfaceView, MediaPlayer, लोड ब्रेकिंग के साथ कोई बग नहीं
• RGB_565 मोड में, चित्र 8192x256 में 4 एमबी मेमोरी होती है, और यदि आवश्यक हो, तो आप विकल्प में डाल सकते हैं। निर्माण और 2 या अधिक में आकार कम करने के लिए और कब्जा की गई मेमोरी (2 के मान के साथ, आपको 0.5 एमबी मेमोरी और 4096x128 का रिज़ॉल्यूशन मिलता है)
• आप अपने पसंदीदा संपादक में स्प्राइट शीट को किसी भी आकार में स्केल कर सकते हैं। मुख्य नियम यह है कि चौड़ाई तख्ते की संख्या से कई गुना अधिक रहती है
• आप एफपीएस के माध्यम से प्लेबैक गति को आसानी से समायोजित कर सकते हैं, बिना किसी समस्या के समाप्त की गई फ़ाइलों को बदले बिना
• ARGB_8888 या ARGB_4444 मोड में पारदर्शिता के साथ एनीमेशन खेलना काफी संभव है
• किसी भी समय आप एनीमेशन को रोक सकते हैं और संसाधनों को मुक्त कर सकते हैं

पुनश्च

यदि यह किसी के लिए दिलचस्प होगा, तो मैं आपको अलग से एक iOS परियोजना के लिए मोनो वीडियो में GUI में छोटे वीडियो को एकीकृत करने के अनुभव के बारे में बता सकता हूं। मोनो प्रलेखन अपेक्षाकृत छोटा है, और वहाँ बहुत सारे नुकसान हैं।