بیژن بینایی GitHub
بیژن بینایی Rss

x.264

نوشته شده توسط بیژن | در دسته لینوکس | نوشته شده در ۰۱-۰۱-۱۳۹۷

۴

آره این هم باز از اون مواردیه که همیشه برام سوال بود.  دو تا سناریو زیر رو که احتمالا برای شما هم پیش اومده در نظر بگیرید. سناریو اول: شما دوربین موبایلتون رو روشن می کنید و شروع می کنید به فیلم گرفتن از فنقلک دایی تون که تازه راه رفتن یاد گرفته. بعد ده دقیقه فیلم گرفتن بالاخره یا خودتون یا نی نیه خسته می شید و دکمه stop رو می زنین. بعد می بینین ۱۰ دقیقه فیلم ۱ گیگ از حافظه گوشیتون رو بلعیده.

سناریو دوم: آخر هفته می شه و فلان رفیقتون می خواد بیاد خونتون. شما تصمیم می گیرید برید یه فیلم توب با rating بالا تو imdb براش دانلود کنید تا وقتی اومد با هم ببینید. و اینبار می بینید ۱۵۰ دقیقه فیلم با کیفیت خیلی بالاتر باز شده ۱ گیگ. و سوال اینه که چطور…

 اگه با ffmpeg کار کرده باشید می دونین می شه اون ۱ گیگی که ضبط کردید رو تا حدود ۱۵۰ ۲۰۰ مگ رسوند اما مشکل من این بود که هر چی بیشتر تلاش می کردم اتفاق خاصی نمی افته. یه سری option ها هم هست مثل bit rate و … که مجبور می کنه حجم کم بشه ولی روی کیفیت و PSNR تاثیر زیادی داتشتن. و همیشه برام ابهام بود که چطور بر و بچ های YiFy این ۲۰۰ مگ آخر رو راحت ۱۰۰ مگ تحویل می دن و به نظرم compress پنجاه درصدی چیزی بود که ارزش داشت ذهنم ۷ ۸ سالی درگیرش باشه.

از اون ور توی این دموی Xilinx بر و بچ شرکت رو دیدم که یه ZYNQ Ultra Scale رو برداشتن و دارن باهاش real time فیلم 4K با H264 انکود و دیکود می کنن. خب دستشون درد نکنه اما اینجا بود که سوال دوم برام پیش اومد که واقعا H264 چقدر الگوریتم سنگینی هست و اینطوری بود که تصمیم گرفتم یک روزم رو صرف کنم برای فهمیدن نحوه کار این خوشگله. اگه بخوام نتیجه امروزم رو بگم H264 مثل یک سیستم search دو بعدی می مونه. یه الگوریتم ساده که دنبال تکرار توی frame اصلی و بین frame بعدی و قبلی با frame حال می گرده. و اینجا دقیقا جاییه که می تونید بفهمید کلک بر و بچ Xilinx چی بوده. H264 یه الگوریتم سرچه. شما می تونید تا ۱۰ تا پیکسل اون ور تر دنبال تکرار بگردید می تونید پنجرتون رو بزرگتر بگیرید. و این دقیقا جاییه که می شه ملت رو گول زد. در نهایت بعد چند تا تست روی سیستم ۴ هسته ای Core i5 ام که رو سری تیک 14nm اینتل ساخته شده می تونم بگم با ۴ تا thread سرعت پردازشش حدود 6x بود (یعنی 6 برابر سرعت real time پردازش ها انجام می شد). با یک thread هم سرعت حدود 2x بود. (چرا؟)

و بالاخره تمام تیکه های پازل کنار هم جمع شدند. یه option ای ffmpeg داره به نام preset. خیلی ساده این option اجازه می ده عمق سرچ رو مشخص کنید و می تونید از veryslow تا ultrafast بهش مقدار بدین. مثلا من با veryslow سرعت پردازشم با تک هسته 0.3x بود با bite rate حدود 700kbps و با ultrafast سرعت تک هسته 10x و با bit rate حدود 2Mbps. لازم به ذکر نیس که کیفیت توی این تست ثابت فرض شده. پس دو تا نکته اینجا یادگرفتم. یکی اینکه اگه حجم براتون خیلی مهمه (مثل فیلم هایی که قراره share بشه و کلی آدم قراره دانلودشون کنن) می تونین با preset پایین می تونید تا ۵۰ ۶۰ درصد حجم رو کاهش بدین. نکته دوم اینکه الگوریتم H264 فی ذات الگوریتم سریعی هست (البته تو آزمایش بالا H264 بصورت سخت افزاری داخل CPU (بله جزء معدود الگوریتم های گرافیکی هست که بصورت سخت افزاری روی CPU به جای GPU پیاده سازی می شه) پیاده سازی شده) اما تو آزمایش Xilinx خیلی مهمه که ببینیم با چه preset ای به این قابلیت دست پیدا کردن.

■ مخصوص

این زیریا note برا بعدا خودم هست. نقطه پایان

allegro رو openGL اجرا می شه. VMWare رو direct x 10 پیاده سازی شده و خیلی از API های حتی openGL 2 هم پیاده سازی نشده. درایور VMWare برای شتابدهنده های گرافیکی sVGA نام داره که مخفف software vga هست. به عبارت دیگه خبری از accelerator های سخت افزاری نیس. vDGA و vGPU دو روش جایگزین هستن که رو esxi استفاده می شه. متاسفانه هر دو نیاز به کارت گرافیک های بالای چندین ملیون tesla و… دارن. بخاطر این ایده چرند و محدودیت های سخت افزاری عملا develop بخش گرافیک و api ها از سمت vmware متوقف شده. wine هم با اینکه نسخه ۳.۴ اش هم در اومده همچنان آشغالی بیش نیست. به خودم قول می دم دیگه تا سال دیگه حتی google اشم نکنم. دو تا option باقی می مونه یه سیستم بگیرم و KVM کنم که خیلی رو مخه همزمان نمی تونی رو دو تا سیستم کنترل داشته باشی. راه دیگه remote بود. پردازش ها و کارهای گرافیکی روی یه ماشین انجام بشه و فقط خروجی بیاد رو PC. تست های اولیه با rdp و vnc فاجعه بود حتی با lan 1Gbps. تست ۲: هر دوی پروتکل ها بیشتر از 15Mbps از شبکه رو استفاده نمی کنن. راه حل مثل همیشه وجود داشت. رزولوشن من 1920×1080 هست یعنی 2Megapixel که اگه raw بخوایم بفرستیم می شه 2 در 8 در 3 در 60 که در حدود 3Gbps هست. اما همه ما می دونیم هیچ خری raw نمی فرسته. اینجا وقتشه که معجزه کنیم. با kazam هشت ثانیه از صفحم وقتی که داشتم به Youtube نگاه می کردم با سرعت 60fps بو صورت raw فیلم گرفتم. حجمش شد حدود 4GB با bit rate حدود 4Gbps (چرا؟ منم نمی دونم). با veryslow با سرعت 0.1x  انکود می کنیم و چهار گیگابایت داده می شه ۱ مگ :|. خیلی بیش از انتظارم کوچیک شد. با ultrafast و سرعت 1x شد ۳ مگ. ۱۱۰۰ برابر. نتیجه گیری اگه یه thread همیشه دیکود کنه و یه thread ذخیره کنه و رو یه ترد هم برنامه باز باشه و رو یه ترد هم سیستم عامل. همه چیز می تونه به خوبی و خوشی real time و بدون lag به مقصد remote شه. delay شبکه هم 1ms هست که خیلی کمتر از delay ده میلی ثانیه ایه مانیتوره

نظرات (۴)

یه سری ویدیو و دمو از vnc دیدم که قشنگ ۳۰ الی ۶۰ فریم روی وایفای میفرستادن ولی منم مث تو هر چی تست کردم نشد که نشد جز یه خروچی افتضاح

ایول چه باحال! مهران من یکم دیگه تست کردم و شد (البته سناریو خودم)
رو وایفای که می گی می شه. اما ۱ باید وای فایت ۳۰۰Mbps باشه (نوع n)
۲. پردازنده Core I7 یا I5 که کلاکش حداقل ۳GHz باشه می خوای. تو case بالا من داشتم رو لپتاپ Core M ام encode می کردم که lag داشت. وقتی بردم رو PC و لپتاپ فقط decode کرد ۶۰fps تصویر داشتم.
۳. وایفای برا VNC تاخیرش فاجعست. desktop ات ۶۰FPS پخش می شه (مثلا می تونی با پخش فیلم رو server تست کنی) ولی delay مسیر انقدر زیاده (حدود ۱۰۰ms) که برا کار کردن اعصابت خورد می شه.
۴. اگه هدفت VNC هست نرم افزار turbo vnc رو دانلود کن و تنظیمش کن رو انکودر tight. یه مودم با LAN 1Gbps هم بیاب که delay اشم کم باشه (من ping گرفتم delay ام کمتر از ۰.۵ms بود). رو این حالت من حواب گرفتم

سلام یه سوال داشتم میخاستم بدونم فریم ورک جانگو پایتون رو اب کجا بعتره یاد بگیریم سایت یا کتاب پیشنهادی شما چیست؟؟

سلام آرمین
من django کار نکردم ولی با یه سرچ گوگل می تونی نظر آدم های متخصص تر رو بدست بیاری. اینجا یک نمونش هست.
راستی کاری داشتی تلگراممو که داری. فکر کنم اونطوری بپرسی هم بهتر هست هم سریعتر جواب می گیری