استاندارد HEVC یا همان H.265 برای فشرده‌سازی ویدیوها در سال‌های آتی متداول می‌شود. در حال حاضر اینکدر رایگان x265 از نظر سرعت و کیفیت به خوبی به x264 نزدیک شده و حتی بهینه‌تر از آن است.

در ادامه به موضوعاتی مثل کدک HEVC یا H.265، مقایسه‌ی الگوریتم‌های فشرده‌سازی و تفاوت‌های H.265 با H.264، روش‌های دیکد سخت‌افزاری و ... می‌پردازیم.

مقدمه

قبلاً در دانش‌نامه‌ی اینتوتک فرآیند اینکد یا اصطلاحاً فشرده‌سازی ویدیو و دیکد و سپس رندر کردن یا اصطلاحاً پخش ویدیو را توضیح دادیم.

استاندارد H.264 یا AVC و تعداد زیادی اینکدر و دیکدر مبتنی بر آن:

برای اینکد کردن ویدیو، استانداردهای خاصی تصویب شده و چندین اینکدر و دیکدر نرم‌افزاری و سخت‌افزاری مبتنی از هر یک از استانداردهای فشرده‌سازی و پخش ویدیو، معرفی شده‌اند. به عنوان مثال استاندارد متداول در سال‌های اخیر H.264 است که تقریباً هم‌معنی استاندارد AVC است. اینکدرهای x264 و MainConcept و اینکدرهای سخت‌افزاری مبتنی بر قدرت موتور مالتی‌مدیا در پردازنده‌های اینتل، انویدیا و ای‌ام‌دی و همین‌طور کارت‌های اینکد سخت‌افزاری ویدیو همگی از مشخصات H.264 تبعیت می‌کنند. بنابراین پخش ویدیو و طراحی نرم‌افزار برای پخش ویدیو در کامپیوتر، تلویزیون هوشمند، گوشی، تبلت و پلیرهای مالتی‌مدیا، ساده شده است.

اینکدر امروزی که گوگل از آن استفاده می‌کند، VP9 است و در کنار آن H.265 که تقریباً همان HEVC به عنوان استاندارد عمومی و متداول‌تر، معرفی شده است. بنابراین اینتل، ای‌ام‌دی و انویدیا و همین‌طور طراحان سیستم روی چیپ گوشی‌ها و تبلت‌ها، تلاش می‌کنند تا نرخ دیکد سخت‌افزاری HEVC توسط موتور مالتی‌مدیا، رقم مطلوبی داشته باشد. معمولاً 4K یا اولترااچ‌دی با سرعت 30 فریم بر ثانیه، در تراشه‌های متوسط و رده‌اول پشتیبانی می‌شود.

HEVC توسط ISO/IEC JTC 1/SC 29/WG 11 Motion Picture Experts Group یا به اختصار MPEG تصویب شده و H.265 که نام کامل‌تر آن ITU-T H.265 است توسط ITU-T تصویب شده است. این دو استاندارد عملاً یکی هستند به این معنی که اگر سخت‌افزار و نرم‌افزار با یکی سازگار باشد، دیگری را هم به راحتی پوشش می‌دهد.

چرا استریم ویدیو را فشرده کنیم؟

در یک فایل ویدیویی، استریم صدا و تصویر و زیرنویس و همین‌طور ضمایمی مثل فصل‌بندی (Chapter) و فنت زیرنویس و ... جمع شده است. هر استریم می‌تواند به شیوه‌ی خاصی فشرده شود. استریم ویدیو پیچیده‌ترین و حجیم‌ترین استریمی است که درون فایل ویدیویی قرار گرفته و طبعاً برای فشرده کردن و همین‌طور پخش کردن آن، منابع پردازشی بیشتری استفاده می‌شود.

از فیلم‌برداری و صدابرداری تا ایجاد یک فایل کم‌حجم

بدون فشرده‌سازی معمولاً ذخیره کردن و پخش ویدیو بسیار دشوار است و وسایل ذخیره‌سازی سرعت کافی ندارند. به خصوص اگر رزولوشن ویدیو 4K و بالاتر باشد. مثلاً ویدیوی 1080p فشرده نشده برای پخش آنی (Real Time) و بدون لگ و تأخیر، به حافظه‌ی ذخیره‌سازی با سرعت 150 مگابایت بر ثانیه! نیازمند است. محاسبه کنیم:

ویدیوی فشرده نشده بسیار حجیم است و به عنوان مثال 1 دقیقه ویدیوی 1080p با سرعت معمولی 24 فریم بر ثانیه و عمق رنگ معمولی 8 بیت، شامل 60 ثانیه ضربدر 24 فریم و ضربدر 2 میلیون پیکسل است، هر پیکسل با سه ساب-پیکسل 8 بیتی تعریف می‌شود و سه بایت داده نیاز است. بنابراین 24 ضربدر 2 میلیون ضربدر 3 بایت داده برای 1 دقیقه ویدیو نیاز داریم که حدود 9 گیگابایت است.

ویدیو چطور فشرده و کم‌حجم می‌شود؟

اصل اساسی: بیت‌ریت متغیر برای فشرده‌سازی حداکثری و صرف‌نظر از آنچه نامحسوس است

اصول کلی فشرده‌سازی ویدیو در اغلب کدک‌ها تقریباً یکی است و تنها تنظیمات و پیچیده‌تر و هوشمندانه‌تر شدن الگوریتم است که تفاوت‌های بزرگ ایجاد می‌کند. اصل اساسی این است که آنچه در گذر سریع فریم‌ها از مقابل چشم انسان کمتر نمایان می‌شود، با تعداد بیت‌های کمتری ذخیره شود و در واقع کیفیت پایین‌تری داشته باشد. در مقابل اگر تصویر ثابت و کم‌تحرک است، فریم‌های اصلی با بیت‌های بیشتری ذخیره شوند. بیت‌ریت متغیر در فشرده‌سازی استریم صوتی هم کاربرد زیادی دارد، هر زمان که لازم است بیت‌ریت بالا می‌رود و در صورتی که نیاز نباشد، بیت‌ریت به صورت هوشمندانه کاهش پیدا می‌کند. در مورد فرمت RAW و ویدیوی فشرده نشده، بیت‌ریت ثابت است.

در بررسی تخصصی آپشن‌های اینکدر x264 که در حال حاضر بهترین اینکدر برای فشرده‌سازی ویدیوست، موارد جالب توجهی را مرور کردیم که بد نیست آن را با حوصله و دقت مطالعه کنید؛

راهکار اول: پردازش تصویر برای کاهش نویز، افزایش وضوح لبه‌ها و ...

اولین روش فشرده‌سازی، از بین بردن جزئیات بسیار ظریف و کوچکی است که حتی ممکن است واقعی نباشند. پردازش تصویر برای تبدیل تصویر RAW یک دوربین به تصویری کم‌حجم با فرمت jpg در مورد فریم‌های یک ویدیو هم مصداق دارد و حجم ویدیو را به شدت کم می‌کند. به عنوان مثال یک سطح صاف و یک‌رنگ، نیازی به پیکسل‌های کاملاً متفاوت ندارد بلکه می‌توان با چند بیت داده، اطلاعات مربوط به تعداد زیادی پیکسل را ذخیره کرد.

هر چه کاهش نویز بیشتر باشد، جزئیات ظریف کمتر نمایان خواهد شد و طبعاً حجم ویدیو و تصویر کمتر می‌شود.

کاهش نویز شدید مشکلاتی به همراه دارد. به عنوان مثال ممکن است ویدیو حالت بلوکی (مربعی یا شطرنجی) به خود بگیرد. پدیده‌ی منفی ماکروبلاکینگ یا بلوک‌های بزرگ در تصویر زیر، حاصل فشرده‌سازی بسیار زیاد و کمبود داده برای توصیف پیکسل‌های مختلف تصویر است:

ماکروبلاک‌ها در ویدیوی بسیار فشرده شده

خوشبختانه H.264 و نسل‌های بعدی کدک‌های ویدیوی قابلیتی به اسم deblocking برای جلوگیری از شکل‌گیری ماکروبلاک‌ها دارند هر چند فشرده‌سازی شدید، همواره بلوک‌های زشتی در تصویر ایجاد می‌کند.

دیبلاکینگ یا کاهش بلوکی شدن تصویر در کانورت با x264

می‌توان با پردازش تصویر لبه‌ها را در تصویر شناسایی کرد و با دقت بیشتر (بیت‌های بیشتر) لبه‌ها را تعریف کرد. به این فرآیند افزایش وضوح لبه گفته می‌شود که در مورد استریم‌هایی مثل انیمیشن و اجسام یکنواخت با مرز کاملاً واضح (شارپ) بسیار مفید است و حتی می‌تواند کیفیت ویدیو را بیش از ویدیوی اصلی، نشان دهد. به همین منظور در تنظیمات نرم‌افزارها، تلویزیون‌ها و ... گزینه‌ی افزایش وضوح لبه یا Edge Sharpening پیش‌بینی شده است.

روش دوم: ایجاد فریم با ترکیب بخش‌هایی از فریم‌های قبلی و بعدی

این روش بسیار جالب و در عین حال پیچیده است. استریم ویدیویی با الگوریتمی هوشمندانه به بخش‌هایی تقسیم می‌شود. مرز این بخش‌ها یک فریم کلیدی است که به آن Intra Frame می‌گوییم. فریم‌های بین دو فریم کلیدی، با ترکیب کردن بخش‌هایی از فریم‌های کلیدی ساخته می‌شوند. اما چطور؟ به 3 فریم زیر توجه کنید:

فریم B و P یک فریم کامل نیستند، بخشی از داده را دارند.

فریم دوم و سوم شامل بخش‌های تکراری فریم اول هستند و تنها تغییرات کوچکی دیده می‌شود. بنابراین این فریم‌ها حاوی اطلاعات ناقصی هستند و از اطلاعات فریم I برای تکمیل کردن چنین فریم‌هایی استفاده می‌شود. ممکن است ماشین کاملاً ثابت به نظر برسد و در مرکز تصویر باشد و تنها منظره‌ی اطراف آن تغییر کند. بنابراین فقط منظره‌ی متغیر در فریم‌های بعدی ذخیره می‌شود.

روش سوم: ایجاد فریم با ترکیب بخش‌هایی که جابجا شده‌اند

گونه‌ی دیگر ایجاد فریم به این صورت است که جسمی روی پس‌زمینه‌ی ثابت در حرکت است. مثلاً نمونه‌ی زیر:

فشرده‌سازی ویدیو با ترکیب فریم‌ها برای ایجاد فریم‌های میانی

فریم‌های P تنها شامل آبشار و شخص متحرک اطراف آن است و بسیار کم‌حجم‌تر از حد معمول است. گاهی بخش متحرک کاملاً ساده است و در جهتی خاص جابجا شده است. مثل نمونه‌ی زیر:

استفاده از حرکت بخش‌هایی از ویدیو برای ایجاد فریم‌های بعدی

کافی است بخش‌های مشخص شده با یک بردار حرکتی در جهت مناسب جابجا شوند و فریم‌های بعدی ایجاد شود. سایر نقاط ثابت و تکراری است.

روش چهارم: ایجاد فریم با ترکیب بخش‌هایی که تغییر کرده‌اند

در تصویر زیر بیضی از گوشه‌ی فریم به وسط جابجا شده است. با مقایسه می‌توان بردار حرکتی لازم را شناسایی کرد. اما تغییر دیگری هم می‌بینیم که مربوط به روشنایی رنگ آبی است. با مقایسه رنگ می‌توان تغییرات را مشخصت است. این تغییر با تبدیل کسینوسی گسسته یا Discrete Cosinus Transform که به اختصار DCT گفته می‌شود، به زبان بیت‌ها تبدیل شده و برای بهینه‌سازی از کد هافمن نیز استفاده می‌شود.

فشرده‌سازی ویدیو با استفاده از بردار حرکتی و اعمال تغییرات

HEVC یا H.265 در برابر H.264 یا AVC

HEVC برای نصف کردن حجم ویدیوها معرفی و استاندارد شده است.

اما چطور می‌توان حجم ویدیو را نصف کرد و تفاوت در چیست؟

بلوک‌های بزرگ‌تر و جست‌وجوی دقیق‌تر تشابهات

اولین تفاوت در پیچیدگی الگوریتم جست‌وجو برای تغییرات فریم‌هاست. همان‌طور که اشاره کردیم، فریم P و فریم B حاوی اطلاعات ناقص هستند. برای ایجاد این فریم‌ها، می‌بایست فریم‌های متوالی مقایسه شوند. ابتدا فریم‌های به بلوک‌های کوچکی تقسیم شده و بلوک‌ها با هم مقایسه می‌شوند. هر چه بلوک‌ها بزرگ‌تر باشند، مقایسه طولانی‌تر و پیچیده‌تر خواهد بود. در HEVC یا H.265، بلوک‌ها به مراتب بزرگ‌تر هستند و البته تلاش شده که انتخاب ابعاد بلوک‌ها، هوشمندانه‌تر باشد تا فشرده‌سازی ویدیو، با سرعت هر چه بیشتری انجام شود. مقایسه کنید:

تقسیم تصویر به بلوک‌های بزرگ‌تر برای شناسایی تشابهات بیشتر، مقایسه‌ی H.265 نسبت به H.264

در واقع ماکروبلاک‌های H.264 حداکثر 16 در 16 پیکسلی هستند و در H.265 ماکروبلاک‌ها حداکثر 64 در 64 پیکسلی هستند. 16 برابر بزرگ‌تر! اگر انتخاب ماکروبلاک‌ها هوشمندانه‌تر نشده باشد، سرعت فشرده‌سازی ویدیو بسیار کمتر خواهد بود. کوچک‌ترین بلوک در HEVC و H.264 ابعاد 4 در 4 دارد.

محدوده‌ی جست‌وجو برای شناسایی بخش‌های حرکت کرده در فریم‌های بعدی نیز در استاندارد HEVC وسیع‌تر شده است. در H.264 از محدوده‌های حداکثر 16 در 16 استفاده می‌شد اما در H.265 محدوده‌ی جست‌وجو 64 در 64 است و خود با ساختار درختی به نواحی کوچک و کوچک‌تر تقسیم می‌شود. هر یک از نواحی می‌تواند باز هم کوچک‌تر شود تا بردار حرکتی با دقت کافی تعیین شود و در عین حال سرعت فشرده‌سازی بالا باشد.

تقسیم فریم‌ها به بلوک‌های بزرگ‌تر برای شناسایی حرکت در استاندارد HEVC

دقت بردارهای حرکتی یا Motion Vectors در استاندارد HEVC بیشتر است و فریم‌ها با کیفیت بالاتری ایجاد می‌شوند. در واقع به جای 9 جهت، 35 جهت حرکتی تعریف شده است. الگوریتم Adaptive Motion Vector Prediction که به معنی پیش‌بینی بردار حرکتی تطبیقی است نیز فرآیند شناسایی حرکت را بهینه می‌کند.

تفاوت مهم دیگر در فیلتر deblocking برای جلوگیری از شطرنجی شدن تصویر است. اثر آن را در تصویر زیر مشاهده کنید:

فیلتر بهتر برای کاهش شطرنجی شدن تصویر در استاندارد HEVC

HEVC بهینه‌سازی‌های ریز و درشت دیگری دارد و در آینده اینکدرهای مبتنی بر آن به راحتی جای اینکدرهای خوبی مثل x264 را می‌گیرند.

ساختار درختی بلوک‌ها در HEVC به جای ماکروبلاک‌های H.264

در HEVC صرفاً ابعاد بلوک‌ها تغییر نکرده بلکه ماکروبلاک‌ها تعریف متفاوتی دارند و در حقیقت ماکروبلاک به CTU تبدیل شده است. به یک بلوک بزرگ به اختصار CTU (یا coding tree unit) گفته می‌شود. CTU به معنی واحد درخت کدینگ است و خود به یک CTB یا بلوک درخت کدینگ تبدیل می‌شود. در حقیقت قدم اول تقسیم CTU به بخش‌های جزئی‌تر است که از نظر رنگ (رنگ در فضای رنگ YUV شامل روشنایی یا Luma و فام یا Cr و Cb است) متفاوت هستند و ساختار درختی به اسم CTB دارند. CTB در قدم بعدی به CU یا واحدهای کدینگ تقسیم می‌شود. هر CU به PU و TU تقسیم می‌شود.

تبدیل CTU به CTB در فشرده‌سازی ویدیو به کمک HEVC

CTU با مساحت 16 برابر، ویدیو را 1.1 برابر فشرده‌تر می‌کند

CTU با ابعاد 16 در 16 از نظر سرعت اینکد حدود 1.5 برابر سریع‌تر از CTU با ابعاد 64 در 64 است و حجم ویدیو حدود 1.12 برابر می‌شود. در واقع سرعت تبدیل 1.5 برابر کمتر شده و حجم فایل نهایی حدود 1.1 برابر فشرده‌تر است. به همین اینکد با H.265 هوشمندانه‌تر و بهینه‌تر از H.264 است. البته آثار بهینه بودن اینکدر، مقوله‌ی دیگری است و طبعاً بهترین اینکدرهای H.264 می‌توانند از اینکدرهای معمولی H.265 بهتر باشند.

و انواع بلوک‌ها در ساختار درختی اشاره شده:

CU شامل سه CB است. این سه بخش برای تخمین سه کمیت Y و Cb و Cr در فضای رنگ YUV به کار می‌روند. بنابراین CB برای تخمین رنگ است و بسته به نیاز، به تقسیمات کوچک و کوچک‌تر تقسیم می‌شود.

فشرده‌سازی ویدیو به کمک HEVC، ساختار CTB برای تخمین رنگ

برای بردار حرکتی بهتر است ابعاد بلوک‌ها کوچک‌تر باشد. بنابراین بلوک‌های PB یا Prediction Block اضافه می‌شود. بلوک پیش‌بینی یا PB برای ذخیره کردن بردارهای حرکتی به کار می‌رود و می‌تواند یک بلوک CB را به تقسیمات کوچک و متنوعی تقسیم کند:

بلوک PB برای شناسایی و ذخیره کردن بردار حرکتی در فشرده‌سازی به کمک HEVC

از طرفی برای ذخیره کردن تغییر رنگ که با روش DCT صورت می‌گرفت، بلوک‌هایی به اسم Transform Block یا بلوک تبدیل تعریف می‌شود چرا که CB برای این فرآیند، نسبتاً بزرگ است. TB هم مثل PB ابعاد متفاوتی دارد:

بلوک TB برای شناسایی و ذخیره کردن تغییر رنگ در فشرده‌سازی به کمک HEVC

سه نوع بلوک با سه کاربری متفاوت در ابعادی بهینه

بنابراین سه نوع بلوک CB و PB و TB به ترتیب برای رنگ، بردار حرکتی و تغییر رنگ به کار می‌روند. PB و TB بسته به نیاز و در واقع هوشمندانه تعیین می‌شوند تا سرعت تبدیل ویدیو، سرعت دیکد ویدیو و همین‌طور فشرده‌سازی بهینه شود. در واقع اگر به جای سه نوع بلوک، صرفاً یک نوع بلوک تعریف می‌شد، CB ابعاد کوچکی در حد PB و TB داشت و در نتیجه بیت‌های بیشتری برای تعیین رنگ به کار می‌رفت.

VP9 گوگل

گوگل ویدیوهای یوتیوب را با اینکدر خاص خود به نام VP9 اینکد می‌کند. VP9 جایگزین VP8 سابق شده و رقیبی برای H.265 است. در VP9 هم سوپربلاک‌های 64 در 64 پیکسلی تعریف شده و هر یک می‌تواند به 4 قسمت کوچک‌تر تقسیم شود اما تفاوت‌های کوچکی مطرح است. بررسی‌های تخصصی نشان می‌دهد که HEVC می‌تواند حجم ویدیو را با کیفیت یکسان تا 43 درصد کمتر از VP9 کند. با توجه به عمومی‌تر بودن HEVC، طبعاً طراحان تراشه نیز از آن پشتیبانی بهتری به عمل می‌آورند و احتمالاً HEVC کدک رایج در سال‌های آتی است.

سوپربلاک‌ها در VP9

برای مقایسه کیفیت فشرده‌‎سازی نسخه‌های چند ماه پیش x264 و x265 و VP9 و همین‌طور اینکدرهای سخت‌افزاری انویدیا و اینتل به مقاله‌ی اختصاصی اینتوتک مراجعه کنید.

دیکد و پخش HEVC و H.265 به صورت سخت‌افزاری

دیکد نرم‌افزاری و دیکد سخت‌افزاری را در دانش‌نامه‌ی اینتوتک توضیح دادیم. خلاصه بگوییم: دیکد سخت‌افزاری سریع‌تر، کم‌مصرف‌تر و بهینه‌تر است. گاهی پردازنده‌ی اصلی آن قدر ضعیف است که محتوای 4K با کدک H.265 را بسیار کند دیکد می‌کند و لرزش یا لگ تصویر نمایان می‌شود اما دیکدر سخت‌افزاری با سرعت بالاتر و بسیار ساده، ویدیو را دیکد می‌کند.

انویدیا در تگرا ایکس‌وان از دیکد سخت‌افزاری HEVC پشتیبانی به عمل آورد و سپس در کارت گرافیک GTX 906 یا در حقیقت تراشه‌ی GM206، این پشتیبانی اضافه شد. ای‌ام‌دی برای اولین بار در APUهای کریزو از دیکد سخت‌افزاری HEVC پشتیبانی کرد. اینتل نیز در پردازنده‌های اسکای‌لیک از دیکد سخت‌افزاری HEVC پشتیبانی به عمل آورده ولیکن پروفایل Main 10 که در حقیقت عمق رنگ 10 بیتی دارد، به صورت هیبریدی دیکد می‌شود.

منظور از دیکد هیبریدی یا دیکد ترکیبی این است که بخشی از فرآیند دیکد توسط پردازنده‌ی اصلی و بخش دیگر توسط موتور مالتی‌مدیا که ممکن است بخشی از پردازنده‌ی گرافیکی باشد، صورت می‌گیرد.

در باب اهمیت دیکد سخت‌افزاری به دانش‌نامه‌ی اینتوتک مراجعه کنید. خلاصه‌ی مطلب این است که با دیکد سخت‌افزاری، پخش ویدیو با مصرف انرژی کمتر و روان‌تر صورت می‌گیرد. بنابراین تراشه‌ی مرکزی داغ نمی‌شود و عمر باتری بیشتر است. ممکن است کیفیت دیکد نیز اندکی بیشتر شود.

برای اطلاعات بیشتر در مورد تنظیمات دیکد ویدیو در پلیرهای مختلف و همین‌طور انتخاب بهترین پلیر از نظر مصرف باتری، به مقاله‌ی اختصاصی اینتوتک مراجعه فرمایید.

با توجه به توضیحات فوق، روشن است که پشتیبانی از دیکد سخت‌افزاری HEVC یا دیکد سخت‌افزاری H.265 و حتی VP9، یک امتیاز مهم برای تراشه‌هاست به خصوص اگر با محتوای 4K و 2K سر و کار داشته باشیم.