শব্দকোষ

ভিডিও আর কোডেক

ভিডিও ফাইল নিয়ে প্রায় প্রতিটা বিভ্রান্তিকর জিনিস একটা পার্থক্য থেকে আসে — বাক্স আর এর ভেতরে থাকা জিনিসের মধ্যে। এখানে দুটোরই শব্দ, আর এগুলোর মাঝে জিনিস সরানো অপারেশনগুলোর।

Container

wrapper, format

ফাইল গঠন যা ভিডিও, অডিও আর সাবটাইটেল ট্র্যাক একসাথে ধরে রাখে আর বর্ণনা করে প্রতিটা কোথায়। MP4, MKV, AVI আর WebM হলো container। একটা container কিছুই কমপ্রেস করে না।

এটাকে একটা কন্টেন্টের লেবেলসহ একটা ফাইলিং বাক্স হিসেবে ভাবো। বাক্সটা বলে: এখানে একটা ভিডিও ট্র্যাক আছে, এভাবে এনকোড করা; সেখানে দুটো অডিও ট্র্যাক, এই ভাষায়; এই অফসেটে সাবটাইটেল। এদের কোনোটা কীভাবে কমপ্রেস করা হয়েছিল তা নিয়ে এটা কোনো মতামত বহন করে না।

এই কারণেই একই ভিডিও একটা MP4 আর একটা MKV-তে অভিন্ন ছবির মান আর অভিন্ন ফাইল আকারসহ থাকতে পারে, আর কেন এই দুটোর একটা একটা আইফোনে খোলে আর অন্যটা খোলে না। পার্থক্যটা বাক্স, কন্টেন্ট না।

আরও দেখো: CodecRemux

Codec

coder-decoder

একটা ভিডিও বা অডিও স্ট্রিম কমপ্রেস করার আর প্লেব্যাকের জন্য আবার ডিকমপ্রেস করার পদ্ধতি। H.264, HEVC, AV1, AAC আর MP3 হলো codec। একটা codec কোনো ফাইল ফরম্যাট না।

নামটা coder-decoder-এর একটা সংক্ষিপ্ত রূপ। এনকোডিং এমনভাবে ডিটেইল ফেলে দেয় যা খেয়াল করা কঠিন হওয়ার হিসেব করে, আর ডিকোডিং যা রাখা হয়েছিল তা থেকে আসলটার একটা আনুমানিক পুনর্নির্মাণ করে। কোডেকটা যত ভালো, একটা নির্দিষ্ট আকারে ক্ষতিটা তত কম লক্ষণীয়।

একটা ডিভাইস একটা ফাইল চালায় যখন এটা container পড়তে *আর* ভেতরের প্রতিটা codec ডিকোড করতে পারে। দুটো অর্ধেকই দরকার, আর যখন একটা ফাইল খোলে কিন্তু কিছু দেখায় না, তখন দ্বিতীয় অর্ধেকটাই ব্যর্থ হয়েছিল।

আরও দেখো: ContainerHardware decoding

H.264

AVC, MPEG-4 Part 10

ভিডিও কোডেক যা সবকিছু ডিকোড করতে পারে। ২০০৩ সালে প্রকাশিত, এখনো সামঞ্জস্যের জন্য সবচেয়ে নিরাপদ পছন্দ, আর গত পনেরো বছরে বানানো প্রতিটা ফোন, কম্পিউটার আর টিভিতে হার্ডওয়্যার-অ্যাক্সিলারেটেড।

H.264 এতটাই সম্পূর্ণভাবে জিতেছে যে "এটা কি সবখানে চলবে" আর "এটা কি H.264" প্রায় একই প্রশ্ন। এটা উপলব্ধ সবচেয়ে দক্ষ কোডেক না — HEVC আর AV1 দুটোই কম বিট দিয়ে বেশি করে — কিন্তু সাপোর্টের বিস্তৃতিতে আর কিছুই কাছাকাছি আসে না।

এর প্রোফাইল আছে, আর এদের একটা Apple ডিভাইসে সমস্যা তৈরি করে: High 10, প্রায়ই Hi10P লেখা, আট বিটের বদলে প্রতি রঙের চ্যানেলে দশ বিট এনকোড করে। হার্ডওয়্যার ডিকোডার শুধু আট-বিট, তাই একটা Hi10P ফাইল এমন একটা ডিভাইসে শব্দ চালায় কিন্তু ছবি ছাড়া যার কোনো সফটওয়্যার ফলব্যাক নেই।

আরও দেখো: HEVCHardware decoding10-bit

HEVC

H.265

H.264-এর উত্তরসূরি, একই মানে প্রায় অর্ধেক আকারে। ২০১৫ থেকে প্রতিটা Apple ডিভাইস এটা হার্ডওয়্যারে ডিকোড করে, আর একটা আইফোন এটাতেই রেকর্ড করে।

HEVC-ই ফোনে 4K ব্যবহারিক করে তুলেছে: প্রায় অর্ধেক বিটরেটে একই ছবি। Apple এটা তাড়াতাড়ি আর সম্পূর্ণভাবে গ্রহণ করেছিল, তাই Apple হার্ডওয়্যারে এটা H.264-এর মতোই নিরাপদ একটা পছন্দ।

অন্য কোথাও এটা আরও জটিল। HEVC-র চারপাশের পেটেন্ট লাইসেন্সিং যথেষ্ট বিতর্কিত ছিল যে ওয়েব ব্রাউজারগুলো এটা সাপোর্ট করতে ধীর ছিল, যা ঠিক সেই ফাঁক যা AV1 পূরণ করার জন্য তৈরি হয়েছিল।

আরও দেখো: H.264AV1Bitrate

AV1

একটা রয়্যালটি-ফ্রি কোডেক ২০১৮ সালে প্রকাশিত, HEVC-র চেয়ে বেশি দক্ষ আর, এটার বিপরীতে, লাইসেন্সিং বিতর্ক থেকে মুক্ত। হার্ডওয়্যার ডিকোডিং iPhone 15 Pro দিয়ে Apple ডিভাইসে প্রথম এসেছিল।

AV1 আছে কারণ HEVC-র লাইসেন্সিং সবচেয়ে বড় স্ট্রিমিং আর ওয়েব ব্রাউজার কোম্পানিগুলোকে এমন একটা বিকল্প চাওয়ায় যা তারা কাউকে টাকা না দিয়ে পাঠাতে পারত। এখন প্রচুর ওয়েব ভিডিও এতেই দেওয়া হয়।

সমস্যাটা ডিকোডিং খরচ। হার্ডওয়্যার সাপোর্ট ছাড়া, AV1 সফটওয়্যারে ডিকোড হয়, যা সম্ভব কিন্তু লক্ষণীয়ভাবে ব্যাটারি খরচ করে আর উচ্চ রেজোলিউশনে আটকে যেতে পারে। পুরনো ডিভাইসে, একই ভিডিওর একটা H.264 সংস্করণই ভালো ফাইল।

আরও দেখো: HEVCHardware decoding

Bitrate

ভিডিও বা অডিওর এক সেকেন্ড কত ডেটা ব্যবহার করে, সাধারণত প্রতি সেকেন্ডে মেগাবিটে। এটাই মূল জিনিস যা ফাইল আকার আর একটা ডিভাইসকে কতটা কাজ করতে হয় দুটোই ঠিক করে।

রেজোলিউশন মনোযোগ পায়, কিন্তু bitrate ঠিক করে একটা ফাইল আসলে কেমন দেখায়। একটা কম বিটরেটের 4K ফাইল একটা উচ্চ বিটরেটের 1080p ফাইলের চেয়ে খারাপ দেখায়, কারণ এনকোডারটাকে এর লক্ষ্যে পৌঁছাতে বেশি ফেলে দিতে হয়েছিল।

এটাও যা নিয়ে একটা আটকে যাওয়া ফাইল সাধারণত হয়। একটা ভিডিও একটা কম্পিউটারে চলে আর একটা ফোনে আটকে যায় যখন, ফাইলে কিছু ভুল নেই: এটা সহজভাবে সেই চিপ প্রতি সেকেন্ডে যতটা চাইতে পারে তার চেয়ে বেশি ডিকোডিং কাজ চাইছে।

আরও দেখো: CodecAdaptive bitrate

Remux

rewrap

বিদ্যমান ভিডিও আর অডিও স্ট্রিম একটা কন্টেইনার থেকে আরেকটাতে না-আবার-এনকোড করে সরানো। লসলেস, আর প্রসেসরের বদলে ডিস্ক গতি দিয়ে সীমিত হওয়ার মতো দ্রুত।

একটা remux স্ট্রিম কপি করে; এটা একটা ফ্রেমও স্পর্শ করে না। H.264 আর AAC ধরা একটা ঘণ্টা-দৈর্ঘ্যের MKV কয়েক সেকেন্ডে একটা MP4 হয়ে যায়, ছবি আর শব্দে বিট-বাই-বিট অভিন্ন।

এটা শুধু কাজ করে যখন লক্ষ্য কন্টেইনার সোর্স যা ধরে তা গ্রহণ করে — MP4 H.264 আর AAC নেবে, আর VP9 বা Vorbis নেবে না। মানুষ যখন বলে একটা রূপান্তর "তাৎক্ষণিক" ছিল, তারা remux করেছে। যখন এটা একটা ঘণ্টা নিয়েছিল, কিছু আবার এনকোড হয়েছিল।

আরও দেখো: TranscodeContainer

Transcode

re-encode, convert

একটা স্ট্রিম ডিকোড করা আর আবার এনকোড করা, সাধারণত একটা ভিন্ন কোডেকে বা একটা কম বিটরেটে। ধীর, আর প্রতিবার লসি — মান কখনো ফিরে আসে না।

"একটা ভিডিও রূপান্তর করা" বলতে মানুষ Transcoding বোঝায়, আর এটা সত্যিকারের একটা ব্যয়বহুল অপারেশন: প্রতিটা ফ্রেম আবার ডিকোড, প্রসেস আর কমপ্রেস হয়। কোডেকটা সত্যিই সাপোর্ট করা না হলে, বা একটা ফাইল ছোট করতে হলে এটাই সঠিক উত্তর।

"আমার ফোন এটা খুলবে না" এর ভুল উত্তর এটা, যখন একটা remux কাজটা করত, আর এটা এমন একটা ফাইলের জন্য একটা খারাপ উত্তর যার একমাত্র সমস্যা একটা DTS অডিও ট্র্যাক — শুধু একটা ট্র্যাক বদলানো ছবিটা অস্পৃষ্ট রাখে।

আরও দেখো: RemuxBitrate

Hardware decoding

মূল প্রসেসরের বদলে একটা নির্দিষ্ট চিপে ভিডিও ডিকোড করা। অনেক দ্রুত, অনেক ঠান্ডা আর ব্যাটারির প্রতি অনেক দয়ালু — কিন্তু এটা শুধু যেসব কোডেকের জন্য বানানো হয়েছিল সেগুলোই সামলায়।

প্রতিটা ফোনে একটা স্থির-ফাংশন ভিডিও ডিকোডার আছে যা H.264 আর HEVC অত্যন্ত দক্ষতার সাথে করে। এটা যা সাপোর্ট করে না তা সফটওয়্যারে পড়ে, যা কাজ করে কিন্তু ব্যাটারি আর তাপ খরচ করে, আর উচ্চ রেজোলিউশনে ধরে রাখতে না-ও পারে।

এই কারণেই একটা ফোনে ফরম্যাট সাপোর্ট একটা একক হ্যাঁ বা না না। একটা ডিভাইস 1080p-তে সফটওয়্যারে একটা কোডেক নিখুঁতভাবে চালাতে পারে আর 4K-তে একই কোডেক ব্যর্থ হতে পারে, আর কোনো ফলাফলই ফাইলটা ভুল বলে না।

আরও দেখো: CodecAV110-bit

10-bit

Hi10P, High 10

আট বিটের বদলে প্রতি রঙের চ্যানেলে দশ বিট রাখা ভিডিও, আরও মসৃণ গ্র্যাডিয়েন্টের জন্য। HEVC-তে এটা স্বাভাবিক আর ভালোভাবে সাপোর্টেড; H.264-এ এটা একটা আইফোনে শব্দ আছে কিন্তু ছবি নেই এমন একটা ফাইলের সবচেয়ে সাধারণ একক কারণ।

প্রতি চ্যানেলে বেশি বিট মানে রঙের মধ্যে সূক্ষ্ম ধাপ, যা অন্ধকার আকাশ আর ধীর ফেডে তুমি যে ব্যান্ডিং দেখো তা সরিয়ে দেয়। HDR-এর জন্য এটা একটা প্রয়োজনীয়তা, একটা পরিমার্জন না।

সমস্যাটা নির্দিষ্টভাবে H.264। দশ-বিট H.264 হার্ডওয়্যার ডিকোডার যা বাস্তবায়ন করে তার বাইরে, আর Apple-এর সিস্টেম প্লেয়ারের এর জন্য কোনো সফটওয়্যার পথ নেই, তাই অডিও চলে আর ছবি কখনো আসে না। অ্যানিমে রিলিজ এটা প্রচুর ব্যবহার করে, যে কারণে এটা ফরম্যাটটার সামগ্রিক অংশ যা প্রস্তাব করবে তার চেয়ে অনেক বেশি সামনে আসে।

আরও দেখো: H.264Hardware decoding

Keyframe

I-frame

পুরোপুরি সংরক্ষিত একটা ফ্রেম বরং এর আগের ফ্রেম থেকে একটা পার্থক্য হিসেবে না। সিক করা শুধু একটার ওপর নামতে পারে, যে কারণে একটা ভিডিও কখনো কখনো তুমি যা চেয়েছিলে তার থেকে একটু ভিন্ন মুহূর্তে লাফায়।

ভিডিও কমপ্রেশন বেশিরভাগ ফ্রেমকে তাদের প্রতিবেশী থেকে পরিবর্তন হিসেবে বর্ণনা করে কাজ করে। শুধু keyframe একা দাঁড়ায়, আর এগুলো সাধারণত প্রতি দুই থেকে দশ সেকেন্ডে আসে।

তুমি একটা স্ক্রাব বার টানলে, একটা প্লেয়ার নিকটতম keyframe খুঁজে পায় আর সেখান থেকে শুরু করে। বিস্তৃতভাবে ব্যবধান রাখা keyframe একটা ফাইল ছোট করে আর সিকিং অমসৃণ করে; সেই ট্রেড-অফটা এনকোডিং সময়ে ঠিক হয় আর পরে আবার এনকোড না করে বদলানো যায় না।

আরও দেখো: TranscodeSegment

অন্য বিষয়গুলো

স্ট্রিমিং আর IPTV ফাইল, ডাউনলোড আর ট্রান্সফার প্রাইভেসি আর এনক্রিপশন সব শব্দ