چطور با کمترین استفاده از رم، پردازنده و کارت گرافیک، ویدیو اجرا کنیم؟

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

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

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

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

همان‌طور که در تصویر فوق مشخص شده، هر یک از 4 هسته‌ی پردازنده‌ی اصلی این تراشه، یعنی هسته‌های Puma+ از نظر مساحت کمی کوچکتر از واحد دیکد ویدیو یا UVD هستند! در واقع برای دیکد ویدیو، یک هسته‌ی اختصاصی که کمی بزرگ‌تر از یک هسته‌ی CPU است، در نظر گرفته شده است. برای اینکد هم به مساحت VCE توجه داشته باشید، کمی کوچکتر از یک هسته‌ی پردازنده‌ی اصلی است.

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

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

H.265 پیچیدگی و فشردگی بالاتری نسبت به استاندارد مطرح فعلی یعنی H.264 دارد. بنابراین بد نیست ابتدا کمی با H.264 بیشتر آشنا شویم.

قبل از هر چیز به این موضوع اشاره می‌کنم که در بخش بعدی مقاله، ویدیویی با رزولوشن 4K و کدک H.265 را به صورت نرم‌افزاری دیکد می‌کنم و میزان استفاده از پردازنده‌ی اصلی را اندازه می‌گیرم. اما فعلاً در این حد اشاره کنم که میزان استفاده از 4 هسته‌ی یک پردازنده‌ی جدید اینتل با معماری هسول که سرعت آن نهایتاً 3 گیگاهرتز است، به راحتی به بیش از 60 درصد می‌رسد. اگر ویدیو Full HD باشد هم به 20 درصد توان هسول چهار هسته‌ای نیاز است تا مراحل دیکد و رندر کامل شوند.

بنابراین موافق هستید که حتی S800 کوآلکام که قلب تپنده‌ی چند گوشی و تبلت رده اول امروزی است توان پخش چنین ویدیوهایی را ندارد! اما جالب است که پاسخ شما منفی است چرا که عملاً ویدیوهای H.265 با رزولوشن فول اچ‌دی را با گوشی‌های رده‌اول اجرا کرده‌اید. H.264 هم حتی به روش‌های دیکد نرم‌افزاری به راحتی روی تراشه‌هایی مثل S600 یا S800 اجرا می‌‎شود.

موضوع همان پردازنده‌ی اختصاصی و بهینه‌ای است که به راحتی و با مصرف انرژی کمتر ویدیو را اجرا می کند.

خوشبختانه در مورد H.264، دیکد به کمک شتاب‌دهی سخت‌افزاری به راحتی صورت می‌گیرد و می‌توان با دستکاری تنظیمات پخش ویدیو در پلیرهای مختلف، استفاده از پردازنده‌ی اصلی را به صفر نزدیک کرد. البته در این صورت پردازنده‌ی گرافیکی مجزا یا مجتمع، مسئول دیکد خواهند بود. درست شبیه چیزی که در گوشی‌ها و تبلت‌ها اتفاق می‌افتد. تراشه‌ی گوشی‌ها و تبلت‌ها معمولاً بخشی جداگانه برای دیکد ویدیو دارد که با کمترین مصرف انرژی و بدون نیاز به فعالیت شدید هسته‌های پردازنده‌ی اصلی که نسبت به هسول‌های دسکتاپ بسیار ضعیف هستند، عمل دیکد را انجام می‌دهد.

DXVA به ویندوز ویستا و ویندوزهای جدیدتر نیاز دارد. اگر کارت گرافیک شما از سری 7000 انویدیا و مدل‌های بعدی باشد و یا از کارت گرافیک‌های سری 2000 رادئون ATI و محصولات جدیدتر استفاده کنید، می‌توانید DXVA را برای دیکد ویدیو به کار ببرید. در این صورت اجرای یک ویدیوی 1080p با وجود ضعف پردازنده‌ی اصلی سیستم هم بعید نیست و می‌توان آن را بدون تیک زدن، تماشا کرد.

• در Pot Player با زدن کلید Tab، اطلاعات پیشرفته‌ی پخش ویدیو را روی صفحه ببینید و اگر DXVA در بخش Decoder دیده نمی‌شود، به فکر فعال کردن آن باشید تا از اجرای کند ویدیوها خلاص شوید.

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

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

همان‌طور که گفتیم، استفاده از DXVA که یک راهکار عمومی برای دیکد ویدیو است و به صورت پیش‌فرض در بیشتر پلیرهای خوب انتخاب شده، استفاده از پردازنده‌ی اصلی را به شدت کاهش می‌دهد. بنابراین عجیب نیست که برای پخش یک ویدیوی 4K که با x264 فشرده شده، بار پردازشی پردازنده‌ی اصلی در حد صفر! است. اما تصویر زیر نشان می‌دهد که بار دیکد روی کدام بخش سخت‌افزار است:

موتور ویدیویی کارت گرافیک GTX 770 است که با حدود یک سوم از حداکثر توان پردازشی خود، به راحتی یک ویدیوی 4K را دیکد کرده است و اهمیت شتاب‌دهی سخت‌افزاری را روشن می‌کند.

به میزان استفاده از رم هم توجه داشته باشید که به خاطر شتاب‌دهی ویدیویی DirectX و ارتباط پردازنده و کارت گرافیک، حدود 150 مگابایت است.

با استفاده‌ی مستقیم از CUDA انویدیا، مقدار رم استفاده شده تقریباً نصف می‌شود و ارتباط پردازنده و کارت گرافیک کمتر شده است:

بد نیست نگاهی به Quick Sync اینتل هم داشته باشیم که موتور اینکد و دیکد قدرتمندی است. به خصوص در هسول که کیفیت آن کمی بهتر شده است.

ابتدا ویدیو را با DXVA اجرا می‌کنم، البته برای اینکه دایرکت ایکس از کارت گرافیک مجزای انویدیا استفاده نکند و به Quick Sync اینتل مراجعه کند، کابل HDMI را به خروجی HDMI مادربورد متصل کرده‌ام:

440 مگابایت رم! این مقدار زیاد استفاده از رم، با به کارگیری مستقیم Quick Sync اینتل، شاید نصف می‌شود، همان‌طور که در مورد CUDA انویدیا شاهد بودیم.

کوییک سینک اینتل هم عملکرد فوق‌العاده‌ی خود را پس از چند نسل ظهور موفق، در هسول تکرار کرده است:

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

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

بنابراین یک مقایسه بین فریم شماره‌ی 60 از دو مرحله‌ی دیکد به کمک CUDA و FFmpeg64 انجام می‌دهم. تفاوت سایر حالات به قدری کم است که نیازی به نمایش نتیجه و مقایسه نیست. در واقع CUDA و FFmpeg64 را به عنوان دو نمونه از بین دیکدرهای نرم‌افزاری و سخت‌افزاری خوب انتخاب کرده‌ام. نتیجه را ببینید:

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

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