ফ্রেম বা সময় নষ্ট না করে অ্যানিমেটেড 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× এবং শক্তিতে প্রায় 2× বেশি খরচ হতে পারে। 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 কনফিগারেশন, mdat-এর আগে moov থাকা এবং কঠোর ত্রুটি ব্যবস্থাপনাসহ সম্পূর্ণ ডিকোড যাচাই করি।

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 স্ট্রিমিংয়ের প্রয়োজনীয়তা।