پروژه درس چند رسانه ای و سرس کد تبدیل DCT

پروژه درسی سیستم های چند رسانه ای

دانلود پروژه و سرس کد نرم افزار تبدیل DCT

h265.rar (875.30 kb)

استاندارد فشرده‌سازی ویدئویی H.264 سال‌ها است که به عنوان بهترین روش برای فشرده‌سازی فایل‌های ویدئویی استفاده می‌شود. اما استاندارد جدید H.265 یا HEVCآمده تا با یک دوم حجم در همان کیفیت، H.264 را منسوخ کند.
هر موقع که فیلم یا سریالی را دانلود می‌کنید، به تماشای یک فیلم بلو-ری می‌نشینید و یا ویدئوهای اینترنتی را مشاهده می‌کنید، به احتمال زیاد ویدئویی که می‌بینید با استاندارد H.264 کدگذاری شده است.
به طور کلی تمام ویدئوهایی که با آن‌ها سروکار داریم، از قبل به نحوی فشرده شده‌اند تا برای مصارف معمول حجم معقولی داشته باشند.
از ویدئوهای بدون افت کیفیت (Lossless) تنها در مصارف خاصی مانند ساخت فیلم در استودیو‌های فیلم‌سازی استفاده می‌شود.
جالب است بدونید هر دقیقه از یک ویدئوی فشرده‌ نشده‌ی فول اچ‌دی، ۷ گیگابایت فضا اشغال خواهد کرد و بنابراین یک فیلم دو ساعته در صورتی که فشرده نشده باشد ۸۴۰ گیگابایت حجم خواهد داشت.
فرمت‌های کدگذاری بر روی ویدئو قالب‌هایی برای ارائه، ذخیره‌سازی و یا انتقال محتوای دیجیتال هستند.
مثال‌هایی از فرمت‌های کدگذاری عبارتند از 
MPEG-2 Part 2, 
MPEG-4 Part 2
, H.264 (MPEG-4 Part 10),
 HEVCیا همان h265
, Theora, این فرمت کد گذاری برگرفته شده از vp3 هستش سال 2004 که توسط Xiph.org ساخته شده
 Dirac,یک فرمت کد گذاری رایگان است که در سال 2008 توسط BBC Research & Development ایجاد شد
 RealVideo RV40
, VP8
, VP9.
 باید به این نکته توجه داشت که این فرمت‌های کدگذاری تنها برای ویدئو هستند و فایل‌های صوتی را نمی‌توان به وسیله‌ی آن‌ها فشرده کرد.
ویدئویی که توسط یکی از این استاندارد‌ها کدگذاری شود، باید همراه با یک فایل صوتی که با استاندارد مربوط به خودش کدگذاری شده است، در یک «ظرف حمل محتوای دیجیتال» یا کانتِینر بسته‌بندی شود. در ادامه راجع به کانتینرها بیشتر توضیح خواهیم داد.
نباید فرمت‌های کدگذاری ویدئویی را با کدک‌های ویدئویی اشتباه گرفت. نرم‌افزار یا سخت‌افزار خاصی که قادر به فشرده‌سازی و یا غیر فشرده‌سازی با استفاده از یک استاندارد کدگذاری ویدئویی خاص باشد، کُدِک ویدئویی (Video Codec) نامیده می‌شود.
برای مثال می‌توان به کدک Xvid اشاره کرد که با استفاده از استاندارد MPEG-4 Part 2 ویدئوها را فشرده می‌کند.
در تصویر نمونه ای از جایگاه کدک H265 در چرخه فشرده سازی و غیر فشرده سازی را مشاهده میکنید
حتماً تا به حال تعریف و تمجید از «فرمت mkv» و کیفیت برتر آن نسبت به دیگر «فرمت‌ها و یا کدک‌های ویدئویی» را شنیده‌اید.حال آنکه چنین جملاتی از پایه غلط هستند.
یک ظرف حمل محتوای دیجیتال (digital container format)، تنها قالبی برای در بر گرفتن ویدئو، صدا، منو، زیرنویس و موارد اینچنینی است. از جمله ظروف حمل محتوای دیجیتال می‌توان به نمونه‌های زیر اشاره کرد:
(mkv) Matroska، 
 (flv) Flash Video،
 (avi) AVI،
 (mov) QuickTime File Format، 
(mp4) MPEG-4 ،
 (wmv) Windows Media Video،
(3gp) 3GPP 
 (vob) Vob
این ظروف یا کانتینرها، تنها می‌توانند اطلاعات محدودی درباره‌ی اینکه ویدئو و صدای موجود در فایل به چه فرمتی ممکن است باشند به ما ارائه دهند. برای مثال ظرف flv تنها قادر به نگهداری از چند نوع فرمت‌ کدگذاری مانند H.264 است. همچنین فرمت‌های صوتی که این ظرف از آن‌ها پشتیبانی می‌کند نیز انگشت‌شمار هستند.
حجم فایل‌های ویدئویی با واحد بیت بر ثانیه بیان می‌شود.
نرخ بیت می‌تواند در طول ویدئو ثابت (Constant BitRate) یا متغیر (Variable BitRate) باشد.
همانطور که متوجه شده‌اید، نرخ بیت یا به بیان بهتر «حجم فایل ویدئو» تنها عامل تعیین‌کننده‌ی کیفیت آن نیست؛ چرا که به صورت تجربی می‌دانیم ویدئوهای HD یوتیوب کیفیت بهتری نسبت به DVD دارند.
در واقع تمام هنر استانداردهای کدگذاری ویدئویی هم در این است که در یک نرخ بیت خاص، کیفیت بهتری ارائه کنند. به همین دلیل هنگام مقایسه‌ی کیفیت دو فرمت کدگذاری، آن‌ها را در بیت رِیت برابر با هم مقایسه می‌کنند.
از جمله دلایل موفقیت و محبوبیت استاندارد پیشین (H.264) در سال‌های اخیر می‌توان به کیفیت بالای آن در نرخ بیت پایین و پشتیبانی گسترده‌ی دستگاه‌های پخش از آن اشاره کرد؛ بطوری که تقریباً تمامی دستگاه‌هایی که ظرف ۵ تا ده سال گذشته ساخته شده‌اند قادرند فایل‌های ویدئویی که با این استاندارد کدگذاری شده‌ باشند را پخش کنند. این استاندارد همچنین بسیار منعطف است و علاوه بر استفاده در ویدئوهای با نرخ بیت پایین، در ویدئوهای با کیفیت و دارای نرخ بیت بالا مانند بلو-ری هم استفاده می‌شود.
ازآنجایی که آمده است تا جانشین شایسته‌ای برای H.264 باشد، با نام H.265 نیز شناخته می‌شود.
برتری اصلی HEVC نسبت به H.264 در این است که در کیفیت‌های یکسان، نرخ فشرده‌سازی دوبرابری ارائه می‌کند.
HEVC بسیاری از ویژگی‌های خود را از H.264 وام گرفته است؛
برای مثال در هر دو این استانداردها از تکنیکی با نام «پیش‌بینی جبرانی حرکت» (motion compensated prediction) برای پیدا کردن نواحی زائد در یک فریم استفاده می‌شود. منظور از نواحی زائد، قسمت‌هایی از تصویر است که در چندین فریم تغییری نمی‌کنند و می‌توان به جای تکرار آن‌ها در هر فریم و اختصاص حجم اضافه به این قسمت‌ها، تنها یک نسخه از آن‌ها را نگه داشته و در فریم‌های مختلف از همان یک نسخه استفاده کرد. 
تفاوت :در استاندارد H.264 اندازه‌ی این قسمت‌ها به قطعات مربعی شکل حد اکثر تا ۱۶ در ۱۶ پیکسل محدود می‌شد؛ 
اما در استاندارد h265 این اندازه از 4×4 تا حد اکثر ۶۴×۶۴ پیکسل  بنا به محتوا قابل تغییر است.
قابلیت انتعطاف پذیری اندازه میکروبلاک باعث
•	پایین آمدن میزان خطا
•	افزایش میزان فشرده سازی
•	جلوگیری از افت کیفیت میشود
در صورتی که میزان خطا در یک بلاک بزرگ زیاد باشد آنرا به قطعات کوچکتر تقیم میکند و از افت کیفیت جلوگیری میکند
از آنجایی که HEVC استاندارد نسبتاً جدیدی به شمار می‌رود، هنوز به اندازه‌ی H.264 با دستگاه‌های پخش‌کننده سازگار نیست. بسیاری از دستگاه‌ها، «سخت افزار»GPU  و یا CPU مخصوص برای کدگشایی از ویدئوهای H.264 دارند، در حالی که سخت‌افزارهایی که قادر به کدگشایی از HEVC باشند بسیار کمتر متداول هستند. البته این به معنای عدم توانایی پخش HEVC بر روی دستگاه‌های امروزی نیست؛ چرا که علاوه بر روش سخت‌افزاری، به صورت نرم‌افزاری نیز می‌توان ویدئوهای HEVC را کدگشایی و پخش کرد که بار پردازشی CPU بوجود می آورد. اما نکته‌ی اصلی اینجاست که کدگشایی نرم‌افزاری از ویدئو هیچگاه به اندازه‌ی کدگشایی سخت‌افزاری بهینه نخواهد بود
در مبحث فشرده‌سازی فایل‌ها، هر چقدر الگوریتم شما پیشرفته‌تر باشد و حجم فایل‌ها را بیشتر کاهش دهد، هنگام کدگشایی به قدرت پردازشی بیشتری نیاز است. این موضوع فارغ از نوع محتوایی است که آن را فشرده می‌کنید و HEVC هم از این قاعده مستثنی نیست.
در دستگاه‌های موبایل، این کاهش بازده اثر خود را به صورت مصرف بالای باتری نشان می‌دهد.
بدون اینکه از قبل اطلاعاتی راجع به دستگاه‌های فوق داشته باشیم، به راحتی می‌توان حدس زد که کدام یک از آن‌ها به صورت سخت‌افزاری از HEVC پشتیبانی می‌کنند.
چرخه تکنولوژی گارتنر که بهتر است آن را چرخه تب تکنولوژی (Technology Hype Cycle) بنامیم، توسط موسسه گارتنر مطرح و پیشنهاد شده است.
این چرخه در سال ۱۹۹۵ مطرح شد و اکنون بیش از دو دهه از عمر آن می‌گذرد. اما به علت مصداق‌هایی که از آن دیده شده و  اصطلاحاتی که به ترمینولوژی مدیریت تکنولوژی افزوده است،‌هنوز هم مورد توجه قرار می‌گیرد.
نمودار گارتنر نیز مانند بسیاری از نمودارهای چرخه عمر در محور افقی، زمان را نشان می‌دهد.
در نگاه گارتنر، با گذشت زمان به تدریج تکنولوژی بالغ‌تر می‌شود.
روی محور عمودی نیز، میزان دیده شدن تکنولوژی (توسط کسب و کارها، تحلیل‌گران، رسانه‌ها و صاحبان صنایع) نمایش داده شده است.
مرحله1- محرک فناوری(Technology Trigger):
همه چیز از یک پیشرفت غیرمنتظره (کشف یا اختراع) فناوری بالقوه آغاز می شود. اثباتهای اولیه ی داستانهای مفهومی و علاقه مندی رسانه، تبلیغات زیادی را ایجاد می کند. اغلب هیچ محصول قابل استفاده ای وجود ندارد و سود دهی تجاری اثبات نشده است.
مرحله 2- اوج حباب انتظارات (Peak of inflated expectation):
مرحله 3- ترکیدن حباب(Trough of disillusionment ):
همانطور که آزمایشات و پیاده سازی ها در تحویل شکست می خورند، علاقه افول می کند. تولید کنندگان فناوری با تقلا ادامه  می دهند یا شکست می خورند. اگر ارائه دهندگان باقی مانده محصولاتشان را برای ارضای پذیرندگان اولیه بهبود بخشند، سرمایه گذاری ادامه پیدا می کند.
مرحله 4- سراشیبی روشنفکری (Slope of enlightenment):
نمونه های بیشتری از اینکه چگونه فناوری می تواند به سازمان ها سود رساند ، شروع به متبلور شدن می کند و گسترده تر درک می شود. محصولات نسل دوم و سوم از ارائه دهندگان فناوری ظاهر می‌گردند. سازمانهای بیشتری بر روی نمونه های اولیه سرمایه‌گذاری می کنند و شرکتهای محافظه کار همچنان محتاط باقی می مانند
مرحله 5- فلات بهره وری(Plateu of productivity): 
پذیرش عمومی شروع می شود. معیارهای ارزیابی باقی‌ماندن ارائه دهنده با وضوح بیشتری تعریف شده است. ارتباط و کاربرد بازاری گسترده به وضوح شکل می گیرند.
هایپ سایکل ها به سازمان ها کمک می کنند، تا زمان مناسب برای سرمایه گذاری در یک فناوری یا خدمت را بر اساس تحمل ریسک و نیازهای تجاری شان مشخص کنند. سازمان هایی که از هایپ سایکل برای تصمیمات سرمایه گذاری استراتژیک آگاهانه استفاده می کنند، فرصت های بهتری را در عصر کسب و کار دیجیتال مشاهده می کنند و می دانند که چه زمانی باید محصول را به بازار ارائه کنند.

 

معرفی API توییتر

API توییتر ابزاری قوی و ساده برای گزارش گیری جستجو و درج محتوا بدون مراجعه به سایت توییتر است

قبل از شروع باید بدانید که اکانت Developer توییتر شامل چند حالت مختلف است

Standard : رایگان

Premium : رایگان و پولی

Enterprise : پولی

اکانت های فوق در قسمت های مختلف API دسترسی های متفاوت ارائه میدهند و قالبا در میزان ارائه محتوا و بازه زمانی اثر گذار هستند.

انواع سرویس های قابل دسترس عبارت اند از

Search Tweets :

پارامتر های ارسالی :  query , tag , fromDate , toDate , maxResults, next

query : محدودیت 2048 کاراکتری دارد و اجباری است

fromDate : تاریخ شروع عددی مانند 201207220000

 Filter realtime Tweets :

اعمال یک فیلتر برای دریافت جریانی از Tweet ها به صورت زنده

پارامتر های ارسالی : موقعیت مکانی , نام کاربر

ارتباط در این API به سورت جریان است و محدودیت ندارد لذا فقط در حالتی که ماشین شما ارتباط را قطع کند جریان پایان میابد

Account Activity API :

این API از رویداد اطلاع رسانی Webhook استفاده میکند که نیاز به ارتباط پایدار (جریان ارتباطی) را از بین می برد همچنین با RestAPI نیز متفاوت است و برای دریافت داده مورد نظر نیازی به ارسال درخواست به صورت مکرر وجود ندارد.

این روش بسیار ساده است و سرعت بالایی دارد

شما میتوانید با این API به موارد یاد شده زیر دسترسی یابید

Tweet ,  mention , Replies , Quote Tweets

Likes , Direct Messages Send/Received , Follows , Blocks , Mutes

Direct Message API :

Sending and receiving events/Direct Messages
Send and receive
Welcome Messages < برای سناریو های مختلف
Message Attachments
Quick Replies
Custom profiles < نمایش نام و تصویر پروفایل در پیام های مستقیم

 Twitter For Websites :

Embedded Tweets < محتوا را از تویتر به وبسایت منتقل میکند
Embedded timelines < نمایش چند توییت در یک سایت به صورت خطی با امکان جستجو و پاسخ
Tweet Button < کلید اشتراک گذاری
Follow Button < کلید فالو

منبع : https://developer.twitter.com/en/docs.html

کاربران گوگل چگونه سرچ میکنند

Answer The Public

کاربران اینترنتی برای جستجوی یک جمله از این الگو استفاده میکنند

با کمی دقت میتوانید محتوای سایت خود را بر اساس این الگو انتخاب کنید و نتیجه بهتری دریافت کنید

کاراکتر های غیر مجاز XML

زمانی که فایل XML شما مبتنی بر دیتای موجود در پایگاه داده باشد و به صورت خودکار تولید شود

ممکن است که شما در زمان مشاهده فایل XML پیام خطایی مبنی بر غیر مجاز بودن کاراکتر های استفاده شده برخورد کنید

برای پیدا کردن کاراکتر های غیر مجاز توسط Query SQL میتوانید کاراکتر های زیر را جستجو کنید

  CHAR(0x0)
+ CHAR(0x1)
+ CHAR(0x2)
+ CHAR(0x3)
+ CHAR(0x4)
+ CHAR(0x5)
+ CHAR(0x6)
+ CHAR(0x7)
+ CHAR(0x8)
+ CHAR(0x9)
+ CHAR(0xa)
+ CHAR(0xb)
+ CHAR(0xc)
+ CHAR(0xd)
+ CHAR(0xe)
+ CHAR(0xf)
+ CHAR(0x10)
+ CHAR(0x11)
+ CHAR(0x12)
+ CHAR(0x13)
+ CHAR(0x14)
+ CHAR(0x15)
+ CHAR(0x16)
+ CHAR(0x17)
+ CHAR(0x18)
+ CHAR(0x19)
+ CHAR(0x1a)
+ CHAR(0x1b)
+ CHAR(0x1c)
+ CHAR(0x1d)
+ CHAR(0x1e)
+ CHAR(0x1f)
+ CHAR(0x7f);

 

هر یک از این کاراکتر ها در صورتی که در فایل XML شما وجود داشته باشد پیام خطا را مشاهده میکند

نحوه استفاده در Query

DELETE FROM [TABLENAME] where [FIELDNAME] like '%' + CHAR(0xa) + '%'

البته این ساده ترین مثال است و در این روش شما به ازای هر یک از کاراکتر های غیر مجاز یک جستجو انجام میدهید ولی شما میتوانید با کمی جستجو در اینترنت نحوه Select یک با شرط یک آرایه را نیز پیدا کنید که توسط یک query تمامی کاراکتر های غیر مجاز را پیدا کنید.

تلگرام فیلتر نیست !

صبح امروز 97/2/9 بعد از اینکه متوجه شدم که پیامرسان telegram قطع شده است با کمی بررسی و استفاده از وبسایتی جهت ping کردن (عملیاتی که جهت بررسی در دسترس بودن یک سرور انجام میگیرد ) سرور تلگرام متوجه شدم که مشکل از ایران نیست و سرور های تلگرام به دلایلی نامعلوم از دسترس خارج شده اند

در تصویر فوق می توانید مشاده کنید که سرور تلگرام از چند کشور مختلف بررسی شده است و در دسترس نیست

زمان بررسی ساعت 8 صبح روز 9 اردیبهشت 97