بهتر است پیش از مطالعه‌ی این مطلب، بخش قبلی را مطالعه بفرمایید:

اهمیت H.265 و 4K

از یک جمله‌ی ساده که در بررسی تراشه‌ی قدرتمندی به نام S810 برایتان نوشتم، شروع می‌کنم، تراشه‌ای 8 هسته‌ای که کوآلکام برای وسایل همراه معرفی کرده و اولین 64 بیتی 8 هسته‌ای این کمپانی محسوب می‌شود. 

S810 به عنوان بهترین تراشه، به اینکودر و دیکودر اختصاصی مجهز شده است تا به راحتی ویدیوهای 4K فشرده شده با این کدک (منظور کدک‌های استاندارد H.265) را باز کند و نیز قدرت فشرده‌سازی ویدیو با این کدک را داشته باشد.

جمله‌ی ساده‌ایست اما جالب است بدانید برای یک استاندارد جدید کدک‌های ویدیویی، چند سال تحقیق و توسعه لازم است. آن هم زمانی که از ویدیوهای 4K صحبت می‌کنیم که از نظر مساحت هر فریم ویدیو، 4 برابر بزرگ‌تر از فریم‌های ویدیوی فول ‌اچ‌دی هستند و بار سنگینی بر دوش تراشه‌های امروزی به حساب می‌آیند. S810 قرار است در سال 2015 به دنیای پرهیاهوی تراشه‌ها و وسایل همراه وارد شود و در آن زمان، ویدیوهای 4K و کدک‌های تحت استاندارد H.265، بیش از دوران فعلی متداول شده‌اند.

H.265 از نظر اینکد و دیکد، بسیار پیچیده‌تر از H.264 امروزی است. در ادامه به بررسی دیکد ویدیوهای فشرده شده با کدک‌های H.264 می‌پردازم. رزولوشن 4K و H.265 بحث اصلی ماست اما فعلاً به H.264 و روش‌های دیکد سخت‌افزاری می‌پردازم.

HEVC و H.265 چه رابطه‌ای با MPEG-4 Part 10 یا AVC و H.264 دارند؟

در بخش بعدی مقاله به استانداردسازی کدک‌های مطرح اشاره می‌کنیم اما فعلاً به صورت خلاصه باید بگوییم که HEVC و H.265 کاملاً مشابه هم هستند. علت این است که دو گروه اصلی استانداردسازی کدک‌های ویدیویی طی همکاری نزدیک خود این دو استاندارد را تصویب کرده‌اند. یک گروه مسئول استانداردهای سری H است که قبلاً H.264 را معرفی کرده بود و گروه دیگر به MPEGها علاقه دارد.

HEVC مخفف High Efficiency Video Coding و به معنی کد کردن ویدیو با بازدهی بالا است. این استاندارد جدید جایگزین استاندارد AVC که نام دیگر آن MPEG-4 Part 10 است، می‌شود. AVC یا کد کردن پیشرفته‌ی ویدیویی از نظر کیفیت و حجم فایل، استاندارد موفقی بوده اما هدف HEVC، نصف کردن حجم ویدیو با همان کیفیت قبلی است.

HEVC معادل H.265 است؛ H.264 معادل AVC یا MPEG-4 Part 10

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

اینکه برای تبدیل ویدیو به H.264 از چه کدکی استفاده کنیم موضوع پیچیده‌ای نیست. به عنوان مثال در دیکد کردن ویدیویی که با یکی از کدک‌های x264، MainConcept، DivX 264، Xvid h.264، Elecard H.264 و انواع سخت‌افزاری مثل Quick Sync H.264 یا CUDA H.264 اینکد شده باشند، تنظیمات متنوع و متفاوت است اما در نهایت وقتی فایل با یکی از کدک‌های تحت استاندارد H.264 تبدیل شده باشد، می‌توان آن را با پلیرهای سازگار با این استاندارد به راحتی اجرا کرد.

در بخش بعدی مقاله در این خصوص کمی بیشتر توضیح می‌دهم گرچه هدف اصلی، معرفی بهترین‌ها برای فشرده‌‎سازی ویدیو است و نیازی به بررسی تمام موارد نداریم.

آمادگی برای اجرای فیلم 4K روی یک پردازنده‌ی خوب اینتل

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

این سوالی است که چندی پیش برای من مطرح شده بود اما با توجه به اینکه کدک x265 در مراحل ابتدایی و آزمایشی به سر می‌برد و از آن مهم‌تر اینکه استاندارد H.265 هم به طور کامل تعریف و نهایی نشده بود، تا به امروز صبر کرده بودم؛ اما حالا زمان آزمایش هسول در رویارویی 4K H.265 است. در مورد دیکد و تعریف آن در بخش قبلی توضیح دادیم. فعلاً اهمیت 4K را بررسی می‌کنیم.

هسول خوب است اما آیا برای 4K هم کافی است؟

قطعاً در دیکد کردن استریم ویدیویی با رزولوشن 1080p مشکل چندانی وجود ندارد اما وقتی رزولوشن 4 برابر می‌شود، مشکل کاملاً جدیست. برای اینکه امتحان کردن هسول برای شما هم ساده باشد، از نمونه‌ای که Elecard برایمان آماده کرده و به دوربین BlackMagic مربوط می‌شود، استفاده می‌کنم. حجم ویدیوی 4K به مدت  3 دقیقه و 39 ثانیه،  تنها 77 مگابایت است! اگر با بیت‌ریت (bitrate) و کانورت کردن فیلم آشنا باشید، به سرعت متوجه بیت‌ریت کمتر از 3000 کیلوبیت در ثانیه‌ای آن می‌شوید که در حد ویدیوهای فول اچ دی امروزیست اما جالب است که کیفیت آن بسیار بالاست. ویدیوی مربوطه را از اینجا دانلود کنید.

اگر آن را با Pot Player یا Media Player Classic باز کنید، متوجه می‌شوید که نمی‌توان با حرکت اسلایدر، زمان را به عقب و جلو تغییر داد. احتمالاً کانتینر مربوطه با اسپلیترهای موجود روی سیستم من به درستی باز نمی‌شود. بنابراین در همان ابتدای کار با استفاده از MKVtoolinx کانتینر را از h265 به mkv تغییر می‌دهم. به تصویر زیر توجه کنید و اگر مفهوم کانتینر را به خاطر ندارید بخش قبلی را مرور کنید:

یک هسول 4 هسته‌ای با سرعت 3 گیگاهرتز

قدم بعدی پخش ویدیوست. پردازنده‌ی Core i5 4670K را از سرعت عادی آن که نهایتاً 3.8 گیگاهرتز است، به 3 گیگاهرتز آندرکلاک می‌کنم! در واقع قرار نیست با اورکلاک کردن یک هسولی، به این تصور نادرست برسیم که دیکد کردن نرم‌افزاری H.265 ساده است. برای همین سرعت پردازنده را در حد پردازنده‌های معمولی هسول پایین آورده‌ام. ممکن است تراشه‌ی هسول را با خنک‌کاری نیتروژن مایع به سرعت 7 گیگاهرتز برسانیم و حتی رکورد جهانی ثبت کنیم و در ادامه با بررسی دیکد 4K، تصور کنیم دیکد نرم‌افزاری برای یک تراشه‌ی قوی دستاپی کار ساده‌ایست، اما منطق درست  این است که هسول را در حد معمول آن در نظر بگیریم و ببینیم واقعاً چه قدر توانمند است.

سرعت و تعداد هسته‌ها در تصویر زیر قابل بررسی است، واسط ارتباطی کش آندرکلاک نشده و همان سرعت اصلی 3.8 گیگاهرتز را دارد اما هسته‌ها را کندتر از حالت عادی در نظر گرفته‌ام:

دیکدر Libav64 در برابر ویدیوی 4K با کدک H.265

ویدیو را با Potplayer باز می‌کنم. برای نمایش سرعت دیکدرهای مختلف و تفاوت آنها، ابتدا از دیکدر داخلی Libav64 استفاده کرده‌ام. در تصویر زیر می‌بینید که وقتی 4 هسته‌ی هسولی با سرعت 3 گیگاهرتز کار می‌کنند، اگر تمام هسته‌ها را به طور کامل به Pot Player اختصاص دهیم و در واقع با تمام توان همه‌ی هسته‌ها به دیکد ویدیو بپردازیم، نتیجه سرعت پخشی برابر با 24 فریم بر ثانیه خواهد بود.

سرعت ویدیوی اصلی که Elecard ارایه کرده، 25 فریم بر ثانیه است پس با اجرای روان و سرعتی کافی سرو کار نداریم البته 1 فریم بر ثانیه، اختلاف زیادی نیست ولیکن موضوع این است که حتی اگر 4 هسته‌ی 3 گیگاهرتزی هسول داشته باشیم هم نمی‌توانیم به حداقل سرعت لازم برای پخش روان ویدیو برسیم. حتی در صحنه‌های شلوغ‌تر ممکن است سرعت پایین‌تر از این مقدار حداقلی باشد و به وضوح ببینیم که تصویر اصطلاحاً پرک یا تیک می‌زند! برای بزرگنمایی تصاویر و نگاهی دقیق به اعداد و ارقام، روی تصاویری که در ادامه مشاهده می‌کنید، کلیک کنید:

Libav64 دیکدر پیش‌فرض نیست و من با توجه به ضعفی که در آن دیده بودم، عمداً آن را انتخاب کردم. دیکدر پیش‌فرض، مبتنی بر FFmpeg است که FFshow نام دارد. بنابراین استفاده از اینکدر اینترنال FFshow عملاً مثل استفاده از FFshow است که به صورت اکسترنال نصب شده است.

دیکدر LAV64 در برابر 4K و H.265

قبل از دیکدر اصلی که  احتمالاً بهینه‌ترین دیکدر هست، به سراغ LAV می‌روم که از دیکدرهای قدرتمند و نسبتاً تازه است و هنوز در نسخه‌ی آزمایشی 0.61 به سر می‌برد. ببینیم این دیکدر با استفاده از 4 هسته‌ی 3 گیگاهرتزی، قادر به تأمین سرعت کافی برای پخش روان ویدیو هست یا نه.

به نظر می‌رسد که راهکار LAV filters هم موثر واقع نمی‌شود.

دیکدر پیش‌فرض؛ FFshow با رزولوشن  4K و کدک H.265 چه می‌کند؟

دیکدر پیش‌فرض که بخشی از مجموعه‌ی با سابقه و سریع FFshow است را انتخاب می‌کنم. این بار اوضاع بسیار بهتر شده است:

59 درصد از 4 هسته. رقم خوبی است اما دقت کنید که 59 درصد از 4 هسته، کمی بیشتر از 2 هسته خواهد بود. بنابراین اگر هسته‌های پردازنده را به 2 عدد کاهش دهیم، سرعت از حداقل لازم، کمی پایین‌تر خواهد بود.

 اگر لپ‌تاپ هسولی شما پردازنده‌ی i5 یا i3 با دو هسته که کمتر از 3 گیگاهرتز سرعت دارند بخواهد این استریم ویدیویی را اجرا کند، چه اتفاقی می‌افتد؟ برای پاسخ به این سوال، تعداد هسته‌هایی که Pot Player مجاز به استفاده از آن است را به 2 عدد کاهش می‌دهم تا یک شبیه‌سازی از هسول‌های 2 هسته‌ای داشته باشیم. نتیجه را ببینید:

مقیاس‌پذیری دیکد نرم افزاری یعنی افزایش سرعت پخش ویدیو با افزایش فرکانس کاری پردازنده

یک محاسبه‌ی سرانگشتی انجام بدهیم تا مقیاس‌پذیری سرعت پخش ویدیو را درک کنید. وقتی 59 درصد از توان کامل پردازنده را استفاده کرده بودیم، سرعت پخش حدود 25 فریم بر ثانیه بود. با کاهش استفاده از پردازنده به 50 درصد که در واقع دو هسته‌ی کامل است، توان استفاده شده 15 درصد کاهش یافته و لذا سرعت پخش هم با 15 درصد کاهش می‌بایست به حدود 21 فریم بر ثانیه برسد. آیا اینگونه است؟ با نگاه به تصویر فوق در اندازه‌ی اصلی همین سرعت را مشاهده می‌کنید.

در مجموع برای دیکد توسط دیکدرهای مختلف، منابع مورد نیازی مثل رم و حافظه بسیار متفاوت خواهد بود.

پیچیدگی اجرا و تنظیمات اینکدر

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

ترکیب تعداد بیشتری فریم، بار پردازشی هنگام پخش ویدیو را افزایش می‌دهد

اما در هنگام دیکد چطور؟ باید فریم‌های I، B  و P با هم ترکیب شوند. هزینه‌ی دیکد کردن فریم‌های I با توجه به توضیحاتی که در بخش‌های قبلی دادم، کمترین میزان ممکن است و کیفیت هم به مراتب بالاتر از فریم‌های B و P است. اما موضوع این است که برای فشردگی بیشتر و کاهش داده‌های استفاده شده، باید فریم‌های B و P هم به وفور استفاده شوند. این دو نوع فریم در هنگام دیکد، به تحلیل و ترکیب فریم‌های مختلف نیاز دارند و لذا دیکد این دو نوع فریم، بار پردازشی بالاتری بر دوش پردازنده‌ی اصلی یا اختصاصی است.

صرفاً برای مقایسه و توضیح پیچیدگی‌ها، بخشی از فیلم The Hobbit An Unexpected Journey  را با کدک متن‌باز x265 تبدیل می‌کنم. تنظیمات را ببینید:

اگر با H.264 آشنایی داشته باشید سریعاً متوجه تعداد عجیب Refrence Frame و B-Frame می‌شوید. 6 عدد! رقم بالایی است که علاوه بر افزایش فشردگی فایل ویدیویی، دیکد کردن آن را هم مشکل می‌کند. البته عمداً تعداد را بالاتر از تمام پریست‌ها و حتی کندترین حالت یعنی Placebo انتخاب کرده‌ام تا پیچیدگی فرآیند دیکد و اثر آن روی هسول را بررسی کنم. در واقع انتخاب بهینه چه در مورد x264 بحث کنیم و چه به استفاده از x265 بپردازیم، ارقامی در حد 2 و یا 3 فریم است.

پس از تبدیل و پخش ویدیو، نتیجه به صورت زیر است:

 اما اگر تبدیل با پریست Ulata Fast صورت گرفته باشد و از b-frame به کلی صرف‌نظر کنیم، دیکد به شدت ساده می‌شود. B فریم‌ها به فریم‌های قبلی و بعدی برای بازساخت نیاز دارند و  پیچیده‌تر از P فریم هستند. که در تصویر اثر آن قابل بررسی است:

جالب است که میزان استفاده از 4 هسته‌ی هسول به جای 64 درصد به 33 درصد کاهش یافته و مقدار رم استفاده شده هم از 396 مگابایت به 295 مگابایت تقلیل پیدا کرده است. بنابراین مشخص است که چه قدر تنظیمات کدک در سنگینی فرآیند دیکد ویدیو موثر است.  اما نکته‌ی جالب توجه دیگر در این خصوص، کدک یا در واقع اینکدر انتخابی است. ویدیوی مورد بحث را با کدک DivX265 هم تبدیل می‌کنم و تست سوم را با هم می‌بینیم:

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

سنگینی اجرای ویدیو به تنظیمات اینکدر هم وابسته است.

بنابراین یک جمع‎‌بندی کلی از سرعت اجرا در حالات مختلف داشته باشیم تا موضوع روشن‌تر شود:

در بخش بعدی مقاله نگاهی به پلیرهای خوب امروزی خواهیم داشت و سرعت پخش ویدیو، کیفیت و استفاده از منابع سخت‌افزاری را بررسی می‌کنم. باید دید VLC پلیر محبوب دنیای لینوکس، KMPlayer که پلیر کهنه‌کار ویندوز است، GOM Player با کدک‌های اختصاصی سازنده‌ی آن، PowerDVD نمونه‌ای از بهترین پلیرهای تجاری و همچنین Qucik Time که با مک‌های اپل به معروفیت بالایی دست یافته چطور عمل می‌کنند.

پلیرهای Pot Player و Media Player Classic دو موردی هستند که شاید کمتر نامشان را شنیده باشید اما در بخش بعدی متوجه کم و کیف عملکردشان می‌شویم.

نظر شما در خصوص H.265 و 4K چیست؟ آیا شما هم با اجرای روان ویدیو روی سخت‌افزار خود مشکل دارید؟ اگر اینطور است، لطفاً  ذکر کنید که چه سخت‌افزاری در اختیار شماست و سرعت اجرا در چه حدی است تا در این خصوص بیشتر بحث کنیم.