سلام ، آیا این بازدید اول شماست ؟ یا
تبلیغات در این انجمن
×
+
سفارش تبلیغات
صفحه 1 از 3 123 آخرینآخرین
نمایش نتایج: از شماره 1 تا 10 از مجموع 22

موضوع: خلاصه ای از مبانی Encoding ویدئو

  1. #1
    عضو متخصص
    تاریخ عضویت
    May 2012
    ارسال ها
    1,760
    سیستم عامل
    Windows 7 64Bit
    محصول امنیتی
    ESET NOD32
    تشکر تشکر کرده 
    9,558
    تشکر تشکر شده 
    11,809
    اعتبار کاربر
    1

    Post خلاصه ای از مبانی Encoding ویدئو

    بسم الله الرحمن الرحیم


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


    این تاپیک به مرور آماده و کامل خواهد شد، ان شاء الله.
    ویرایش توسط M-AUDIO : 17-01-2017 در ساعت 19:05 دلیل: بروزرسانی
    :)

  2. کاربران : 58 تشکر کرده اند از شما M-AUDIO برای ارسال این پست سودمند:


  3. #2
    عضو متخصص
    تاریخ عضویت
    May 2012
    ارسال ها
    1,760
    سیستم عامل
    Windows 7 64Bit
    محصول امنیتی
    ESET NOD32
    تشکر تشکر کرده 
    9,558
    تشکر تشکر شده 
    11,809
    اعتبار کاربر
    1

    Post Codec ، Format ، Container Format Extension

    Codec , Format , Container Format , File Extension , Standard

    یک Codec (کدک)، یک نرم افزار و در مواردی یک سخت افزار است که فرآیند Encoding (انکدینگ - کد کردن) و Decoding (دیکدینگ - باز گشایی کد) صدا یا تصویر را انجام می دهد. یک کدک در واقع یک فرمت نمی باشد. Format (فرمت) عبارت است از خروجی که کدک تحویل می دهد یا ورودی که تحویل می گیرد. بعنوان نمونه، کدک VORBIS به ما "فرمت" OGG خروجی می دهد و یا کدک X265 به ما "فرمت" H265 (یا همان HEVC) تحویل می دهد. x264 به ما H264 (یا همان MPEG-4 AVC) تحویل می دهد. کدک Xvid به ما "فرمت" MPEG-4 visual تحویل می دهد. کدک DivX هم به ما "فرمت" MPEG-4 visual تحویل می دهد. کدک CoreAVC از ما "فرمت" H264 تحویل می گیرد و برای دیگر کدک ها نیز بهمین منوال. فرمت در واقع همان استاندارد (Standard) هست، یعنی استاندارد فشرده سازی برای مثال MPEG1 یک فرمت و بصورت تخصصی تر یک استاندارد فشرده سازی ویدئو می باشد که در سال 1993 به تصویب رسید. هر کدکی که توانایی تولید این فرمت یا بازگشایی اش را داشته باشد Implementation یا یک پیاده سازی از این استاندراد می باشد. فرمت با پسوند کاملاً متفاوت است. پسوند فایل های ویدئویی (File Extension) که اکثراً و به اشتباه فرمت (ویدئو) نامیده می شود در واقع همان Container Format یا "حامل" نام دارد. Container چیست؟ هنگامی که شما به تماشای یک فیلم می نشینید، فیلم شما معمولا دارای دو Stream یا جریان است که یکی صدای فیلم شما است و دیگری تصویر فیلم شما. از آنجایی که این امکان که بشود یک فایل صدای جداگانه را با یک فایل تصویر جداگانه همزمان و با زمانبندی صحیح پخش کرد و به تماشای فیلم پرداخت وجود ندارد (کار سختی است)، احتیاج است که این دو فایل در یک فایل که Media Container یا حامل نام می گیرد در کنار یکدیگر قرار بگیرند. این Container و نرم افزاری که آنرا تولید کرده است می توانند امکانات زیادی را بسته به نوع حامل فراهم کنند. از مهم ترین این امکانات می توان به تصحیح کردن زمان بندی پخش Stream ها در عملیات پخش (اصطلاحا همگام سازی یا Synchronization) اشاره نمود. از Media Container های شناخته شده می توان به (Audio/Video Interleave (.avi) ، mpeg program stream (.mpg .mpeg) ،mpeg(2) transport stream (.ts .m2ts) ،QuickTime (.mov) ،Realmedia (.rm) ،MPEG4 part14 (.mp4) ،Matroska (.mkv) و ... اشاره نمود. البته این نکته را هم ذکر کنم که "فرمت" را در شرایط خاصی Native Container هم می نامند. برای مثال (ogg.) علاوه بر اینکه "فرمت" خروجی کدک VORBIS است در واقع Native Container خروجی کدک VORBIS نیز می باشد یا (h264.) در واقع Native Container برای فرمت h264 یا همان avc می باشد.
    با مراجعه به این مقاله ویکیپدیا می توانید از امکانات اکثر Media Container های موجود آگاهی کسب نمایید. امکاناتی از قبیل اینکه از چه فرمت های صوتی و تصویری در داخل خود پشتیبانی می کنند و امکانات جانبی دیگر.


    Encoder , Decoder

    یک Encoder با استفاده از یکسری آلگوریتم ها و دستورات خاص (پیاده سازی شده از روی استاندارد مربوطه)، فرمتی را به فرمت دیگر Code می کند. برای اینکه فرمت فایل مبدا توسط Encoder قابل شناسایی و کد گذاری به فرمت مقصد باشد احتیاج است تا فایل اصلی از فرمت اولیه خود به فرمت کد نشده (Uncompressed) تغییر یابد (رمز گشایی یا Decode شود). این کاریست که توسط Decoder (که از روی استاندارد مربوطه پیاده سازی شده) صورت می گیرد. همچنین هنگامی که به تماشای یک فیلم با یک فرمت خاص می نشینیم این Decoder است که جریان صدا و جریان تصویر فیلم ما را که توسط Demuxer از هم جدا شده اند رمزگشایی می کند (به Uncompressed Data تبدیل می کند) و به نرم افزار پخش کننده برای فیلتر گذاری، Render کردن و نمایش تحویل می دهد.

    از واژه ی Codec می توان هم بعنوان Encoder و هم بعنوان Decoder استفاده نمود. در واقع خود واژه ی Codec هم از مخفف این دو کلمه بر گرفته شده می باشد. Codec = Coder/Decoder و همچنین برای استفاده از این واژه نیازی نیست که نرم افزار یا سخت افزار مذکور هر دو کار را انجام بدهد. کافیست تنها یکی از عملیات Coding و یا Decoding را انجام بدهد تا بتوان واژه ی Codec را به آن اختصاص داد. همانطور که اگر هردو کار را باهم بتواند انجام بدهد می توان این واژه را به آن اختصاص داد.

    ممکن است برای یک فرمت خاص، Encoder ها و Decoder های گوناگونی وجود داشته باشد که توسط متخصصان امر نوشته شده باشند. بعضی هایشان متن باز و بعضی هایشان هم تنها تحت مجوز تجاری کمپانی سازنده می باشند و در مقایسه باهم تفاوت هایی نیز دارند. برای مثال برای فرمت H264، بیش از ده Encoder وجود دارد که از جمله ی آنها می توان به X264 ، Nero ،MainConcept ،ProCoder و .. اشاره داشت.
    و یا برای فرمت (MPEG-4 Part2(mpeg-4 visual یا همان MPEG-4 (A)SP چندین Encoder وجود دارد که معروف ترین های آنها Xvid , DivX و Div3 و MSMPEG4v3.. هستند که اکثرا و به اشتباه خودشان بعنوان فرمت خوانده می شوند. برای مثال گفته می شود ویدئو با فرمت Xvid که اشتباه است. اما اگر گفته بشود تبدیل ویدئو با کدک Xvid صحیح است.
    برای Decoder ها هم مانند Encoderها تفاوت هایی در امکانات و بخصوص کارایی و سرعت وجود دارد و همچنین Decoder ها هم انواع متن باز و تحت مجوز کمپانی سازنده دارند. از جمله آنها هم می توان به libavcodec ،Nero ،elecard ،moonlight و... اشاره داشت.


    MUX , DEMUX , REMUX , Multiplex , Demultiplex
    Elementary Stream , Bitstream , Stream

    به عملیات قرار دادن فایل (صدا، تصویر، زیرنویس و... ) داخل Media Container (مدیا کانتِینِر)، عملیات Muxing (ماکسینگ) و به در آوردن فایل از داخل Media Container عملیات Demuxing (دیماکسینگ) گفته می شود. به هر فایل داخل یک Media container یک Stream (استریم) یا جریان گفته می شود. برای مثال فایل ویدئو یک Stream و فایل صدا یک Stream و زیرنویس یک Stream. اگر دو صدا وجود داشته باشد هرکدام به تنهایی برای خود یک جریان می باشند. پس عملیات Demux را در واقع می توان استخراج Stream ها نامید. طی عملیات Mux (یا همان Multiplex) است که در Media container هایی مانند (mp4.) و (mkv.) و ... چند صدا و زیرنویس به یک فیلم اضافه می کنند. به عملیات تغییر (کلی) Container عملیات Remux (ریماکس) گفته می شود. برای مثال شما یک فایل (mkv.) در اختیار دارید و می خواهید بدون انجام عملیات Convert (دیکد و انکد) بر روی خود جریان ها، آنرا به یک فایل (mp4.) تبدیل کنید. از برخی نرم افزار ها برای انجام عملیات های یاد شده می توان به Libavformat (برای اکثر Container Formatها)، برای Container های (mkv .mk3d .mka .mks.) به پکیج MKVToolNix، برای Container های (mp4 .m4a.) به نرم افزار MP4Box و غیره اشاره داشت.
    هنگامی که یک جریان ویدئویی و یا صوتی را به داخل هیچ Containerـی قرار نداده باشند از آن بعنوان Elementary Stream یاد می کنند. برای مثال برای اشاره به فایل فرضی test video stream.h264 از واژه ی h264 Elementary Stream استفاده می کنند. برخی از نرم افزارها حتما احتیاج دارند که برخی فرمت ها درون یک Container باشند تا بتوانند آنها را باز کنند و اگر بصورت ES باشند آنها را باز نخواهند کرد.
    از واژه bitstream معمولا هنگامی که لازم هست از دیدگاه برنامه نویسی به Stream اشاره بشود بجای واژه ی تنهای Stream استفاده می شود. مثلا هنگامی که می خواهند راجب ساختار یک Steram ویدئویی mpeg-1 بحث کنند از عبارت mpeg-1 bitstream structure استفاده می کنند.
    ویرایش توسط M-AUDIO : 17-01-2017 در ساعت 14:24 دلیل: بروزرسانی
    :)

  4. کاربران : 54 تشکر کرده اند از شما M-AUDIO برای ارسال این پست سودمند:


  5. #3
    عضو متخصص
    تاریخ عضویت
    May 2012
    ارسال ها
    1,760
    سیستم عامل
    Windows 7 64Bit
    محصول امنیتی
    ESET NOD32
    تشکر تشکر کرده 
    9,558
    تشکر تشکر شده 
    11,809
    اعتبار کاربر
    1

    Post Encoding Compression Mod

    Encoding Compression Mod


    Uncompressed (فشرده سازی نشده):
    به معنی فشرده نشده و کدگذاری نشده می باشد. از فرمت های فشرده سازی نشده می توان به Digital Camera RAW Format ،PCM (Linear Pulse Code Modulation) ،PAM و برای ویدئو انواع فرمت های فشرده نشده در Colorspaceهای مختلف مانند YUV ،YUY2 و... اشاره نمود که خودشان نیز به ساختارهای گوناگونی طبقه بندی می شوند. بعنوان مثال برای صدا یک استریم صدای PCM با داده های 32بیت یا با داده های 24بیت و...
    عملیات Compression (فشرده سازی) در هنگام Encoding صورت می گیرد و فرمت های گوناگون معمولاً از روش های گوناگونی برای فشرده سازی استفاده می کنند. بطور کلی عملیات فشرده سازی به دوصورت انجام می شود:

    Lossy Data Compression (فشرده سازی با از دست رفتن بخشی از اطلاعات):
    به گونه ای از فشرده سازی اطلاق می شود که در آن داده ها با از دست دادن بخشی از خود، فشرده سازی می شوند. در این فرآیند تمرکز بر روی این نکته می باشد که میزان فضای لازم برای نگهداری اطلاعات و یا جابجایی و انتقال آنها به حداقل رسانده شود. در زیر سه عدد عکس قرار داده شده که اولی اصلی (با حجم 106 کیلوبایت) و دومی (با حجم 23 کیلوبایت) و سومی (با حجم 11 کیلوبایت) به ترتیب به میزان 22 درصد و 11 درصد از حجم فایل اصلی کاهش حجم داده شده اند. (یعنی نسبت حجم فایل به حجم فایل اصلی ضربدر 100).

    مشاهده تصوایر




    در واقع تا زمانی که تصویر بیش از اندازه کیفیت خود را از دست ندهد و توسط بیننده، یک فایل بی کیفیت شناخته نشود، می توان به حذف قسمت هایی از جزئیات و فشرده سازی ادامه داد. ضایعه ی فشرده سازی بیش از حد به این روش، Compression Artifact نامیده می شود. Lossy Compression در بسیاری از فرمت های مالتی مدیا مانند AAC (Advanced Audio Coding) ،DTS (Digital Theatrer Systems) ،AC3 (Dolby Digital) ،MPC (Musepack) ،MP1 ،MP2 ،MP3 (MPEG-1 Layer III) ،OGG (Vorbis) ،Dirac ،MPEG-1 ،MPEG-2 ،H261 ،H262 ،H263 ، H264 (MPEG-4 AVC , MPEG-4 Advanced Video Coding or MPEG-4 Part 10) ،MPEG-4 Part 2 (MPEG-4 ASP or MPEG-4 Advanced Simple Profile) ،Snow (Walvet Codec) ،Theora ،Windows Media Video ،JPEG ،HEVC (High Efficiency Video Coding و ... مورد استفاده قرار می گیرد.

    Lossless Data Compression (فشرده سازی بدون از دست رفتن اطلاعات):
    این متد استفاده از یک رده از آلگوریتم های فشرده سازی اطلاعات می باشد که اجازه می دهد تا تمام فایل منبع بصورت کامل در نسخه فشرده سازی شده قابل دستیابی باشد.
    فشرده سازی بصورت Lossless در بسیاری از نرم افزار ها اتفاق می افتد. برای نمونه در فرمت ZIP و دیگر فرمت های آرشیوی و یا در فایل های EXE یا MSI نصب Setup نرم افزار ها. در واقع هنگامی از این متد استفاده می شود که احتیاج است تا فایل فشرده شده بعد از درآمدن از حالت فشرده با فایل منبع از هر لحاظ برابری کند. این متد در بعضی از فرمت های مالتی مدیا نیز برای مثال فرمت های FLAC (Free Lossless Audio Codec) ،ALAC (Apple Lossless Audio Codec) ،APE (Monkey's Audio) ،PNG (portable network graphics) ،TIFF (Lossless Mode) ،ZMBV (Zip Motion Block Video) ،Snow (Snow Lossless Mode) ،H264 (Lossless Mode) ،FFV1 ،Lagarith HuffYuv و .... مورد استفاده قرار می گیرد.
    ویرایش توسط M-AUDIO : 21-01-2017 در ساعت 12:36 دلیل: بروزرسانی
    :)

  6. کاربران : 42 تشکر کرده اند از شما M-AUDIO برای ارسال این پست سودمند:


  7. #4
    عضو متخصص
    تاریخ عضویت
    May 2012
    ارسال ها
    1,760
    سیستم عامل
    Windows 7 64Bit
    محصول امنیتی
    ESET NOD32
    تشکر تشکر کرده 
    9,558
    تشکر تشکر شده 
    11,809
    اعتبار کاربر
    1

    Post Data Rate

    Data Rate

    در فایل های چند رسانه ای Bitrate یا Data rate به تعداد بیت هایی گفته می شود که در یک واحد از زمان استفاده، نقل، پردازش و یا ذخیره می شوند تا فایل هایی مانند فایل های صوتی و تصویری به نمایش در آیند، Encode بشوند و یا Record و ذخیره بشوند. Bitrate یک کمیت است که از واحد bps یا "بیت در ثانیه" پیروی میکند. گاهی هم با پیشوند های سیستم بین المللی متری مانند k (کیلو) M (مگا) و G (گیگا) همراه می شود بعنوان نمونه kbps ،Mbps و Gbit/s. این واحد برخلاف دیگر واحد های حجمی کامپیوتری می باشد و در آن برای مثال 1Kbps (یک کیلوبیت در ثانیه) دقیقاً برابر با 1,000 بیت در ثانیه می باشد و برابر 1,024 بیت در ثانیه نمی باشد. مخفف Bit با حرف b کوچک نوشته می شود تا با Byte که مخفف آن با حرف B بزرگ نوشته می شود اشتباه گرفته نشود.
    Ratecontrol: در واقع اصلی ترین بخش Encode فایل های مالتی مدیا مانند موسیقی و فیلم می باشد که در انکدر پیاده سازی می گردد و به معنی "طریقه ی" کنترل کردن پارامترهای مربوط به اختصاص بیت ریت، در طول مدت زمان ویدئو/موسیقی مورد نظر و سنجش خروجی در حال تولید نسبت به موارد گوناگون می باشد.


    Bitrate control

    به معنی تعیین مستقیم خود یا محدوده بیت ریت می باشد و به زیرمجموعه های زیر تقسیم می شود:
    CBR یا Constant Bitrate (بیت ریت ثابت):
    به این معنا می باشد که Bitrate مصرف شده توسط کدک برای خروجی، Constant یا ثابت باشد. البته این کلمه ی "ثابت" به این معنا نیست که میزان Bitrate حتی 1 بیت هم نسبت به میزان تعیین شده بازی نکند، بلکه به این معناست که مقدار بسیار کمی بازی خواهد کرد. CBR برای Streaming محتوای چند رسانه ای (انتشار از طریق کانال های ماهواره ای، تلویزیونی و Broadcasting کابلی و اینترنتی)، مناسب می باشد که در واقع ظرفیت محدودی را در کانال ارتباطی دارا می باشند و موضوع Bitrate ماکسیموم یا حد اکثر مطرح است و برای اینکه بتوان از حداکثر ظرفیت کانال استفاده شود از CBR استفاده می شود. CBR گزینه ی مناسبی برای ذخیره سازی فیلم ها و صدا ها (موارد Storage) در بیت ریت های پایین و کم نمی باشد.
    ABR یا Average Bitrate (بیت ریت میانگین):
    این متد بر می گردد به مقدار میانگین بیت ریت که در یک واحد از زمان مصرف می شود. بعنوان مثال یک فایل صوتی MP3 را درنظر بگیرید که Bitrate میانگین آن 128kbps (یعنی 128 کیلوبیت در ثانیه) می باشد. این فایل بطور میانگین 128,000 بیت در ثانیه مصرف/منتقل می کند و می تواند شامل قسمت هایی باشد که در آن مقدار Bitrate بالا تر از عدد مذکور و قسمت هایی که مقدار Bitrate کمتر از عدد مذکور باشد. برای مثال در یک ویدئو، در صحنه های به اصطلاح پیچیده و شلوغ و پر از جزئیات و حرکات سریع، Bitrate بیشتر از مقدار میانگین افزایش خواهد یافت و در قسمت های ساده (مثلا قسمت هایی که بالای 80 درصد کادر با یک رنگ ساده بدون سایه روشن پر شده) و کم تحرک، Bitrate کمتر از مقدار میانگین اختصاص خواهد یافت. به قسمت های با بیت ریت بسیار بالاتر از میانگین تعیین شده، Peak می گویند. اما بیت ریت میانگین در طول کل فایل در اطراف میزان میانگین که شما تعیین کردید بازی خواهد کرد.
    VBR یا Variable Bitrate (بیت ریت متغیر):
    بر خلاف CBR در این متد مقدار Bitrate اختصاص یافته در هر بخش از فایل خروجی، متغیر می باشد. در VBR، به قسمت های یک فایل که دارای صحنه های شلوع و پر تحرک می باشد Bitrate بیشتری اختصاص خواهد یافت و در نتیجه حجم بیشتری نیز حاصل خواهد شد و در صحنه های ساده و کم تحرک مقدار Bitrate کمتری اختصاص خواهد یافت که این امر باعث می شود این صحنه ها از حجم خروجی کمتری برخوردار باشند. در برخی کدکها، در زمان انکد بصورت VBR همچنین می توان مقدار Bitrate حداقل (کف بیت ریت) و مقدار Bitrate حداکثر (سقف بیت ریت) را تعیین نمود.

    پس تا اینجا متوجه شدیم که از لحاظ کیفی در موارد Storage (ذخیره سازی) به ترتیب VBR بهتر از ABR و ABR بهتر از CBR می باشد و برای Streaming (بخصوص در پهنای باند بسیار کم) گزینه توصیه شده، CBR می باشد. همچنین به این موضوع هم می توان دست یافت که CBR در واقع شکل محدود شده ای از ABR است و ABR نیز در واقع شکل محدود شده ای از VBR می باشد.
    Multiple Pass Bitrate Mode, Two-Pass Bitrate Mode:
    یک هدف اصلی استفاده از Bitrate control در موارد ذخیره سازی (موارد Storage) ، "تعیین بیت ریت و در نتیجه دریافت حجم فایل خروجی مشخص و تعیین شده" می باشد. این موضوع برای ما مشکلی ایجاد خواهد نمود و آن این است که در انکدهای ABR و VBR درست است که نرخ بیت به صحنه های به اصطلاح Complex می تواند بیشتر اختصاص پیدا کند اما Codec نمی تواند بصورت کاملاً صحیح تشخیص دهد که کدام صحنه ها Complex هستند و کدام صحنه ها ساده. همچنین همانطور که بعدا خواهید خواند موضوع دیگری در فشرده سازی انواع رایج استاندارد ویدئویی بصورت Lossy مطرح است به اسم Picture Type که در واقع مشخص کننده ی نوع فریم های استفاده شده برای هر صحنه از ویدئو می باشد. اینکار نیز یکی از کارهای محاسباتی سنگینی هست که می بایست توسط انکدر انجام بشود و دقت آن تاثیر بسزایی در کیفیت فایل خروجی با یک بیت ریت معین خواهد گذاشت. در Encode های ABR و VBR یک مرحله ای، Encoder مجبور است که دو عملیات بالا یعنی Bitrate Distribution (اختصاص بیت ها به هرفریم و هر صحنه) و Frame Type Decision (تشخیص نوع فریم ها) را بدون دانستن اطلاعات زیادی از فایل مبدا انجام بدهد و در نتیجه این کار را به اصطلاح "On The Fly" انجام می دهد که خب کیفیت حداکثر بدست نخواهد آمد. راه حل این مشکل استفاده از Encode چند مرحله ای می باشد.
    بطور کلی توسط برخی از کدک ها می توان یک Encode را در چند مرحله انجام داد مثلا 2 مرحله، 3 مرحله یا n مرحله. بستگی دارد که این توانایی در کدک مذکور Implement شده باشد (طراحی و پیاده سازی شده باشد) یا خیر. اما بهترین بالانس در "میزان زیاد شدن زمان کل Encode" (نسبت به تک مرحله ای) و "میزان تاثیر در کاهش افت کیفیت (نسبت به تک مرحله ای)" را انکد دو مرحله ای (Two-Pass) دارا می باشد.
    در این شیوه، Encoder در ابتدا یکبار عملیات انکد را انجام می دهد اما نه بصورت فیزیکی بلکه وقایع اتفاق افتاده و تعداد تمام بیت های اختصاص داده شده به هر لحظه از فیلم و نوع فریم های تعیین شده را در یک فایل Log ذخیره می کند. سپس در مرحله ی دوم از این فایل Log استفاده می کند و صحنه های Complex و Less Complex و نوع فریم تعیین شده برای هر صحنه را بصورت دقیق شناسایی می کند و مقدار بیت اختصاص داده شده برای صحنه های مختلف با توجه به نوع فریم تعیین شده را با حداکثر دقت و انعطاف پذیری تعیین می کند. این باعث افزایش کیفیت نسبت به تک مرحله ای می شود. توجه داشته باشید که این افزایش کیفیت یعنی کاهش میزان افت کیفیت نسبت به انکد تک مرحله ای همان فایل (در Data rate مشابه). و به ازای یک و نیم الی دوبرابر شدن زمان تبدیل حاصل می شود. همچنین در کدک های مختلف ممکن است اطلاعات دیگری نیز از مرحله اول بدست بیاید و در مرحله دوم استفاده بشود.


    CQP یا Constant Quantization Parameter
    کدک را به گونه ای تنظیم می کند که با Quantizer ثابت به Encode کردن هر فریم بپردازد. زمانی که با Quantizer ثابت انکد کنیم، بیت ریت متغیر خواهد شد. بنابراین مقدار بیت های اختصاص داده شده و در نتیجه حجم فایل خروجی در این متد مشخص نخواهد بود.
    بعدا و در پست های مربوط به quantization and sampling اشاره ی بیشتری به این فراِیند خواهد شد و متوجه خواهید شد که رابطه ی آن با بیت ریت چیست و چگونه می شود که هرچقدر بیشتر ویدئو را Quantize کنیم، میزان بیت ریت کمتری (در نتیجه خروجی با سایز کمتری) حاصل می شود.


    CQ یا Constant Quality
    در حالی که متد QP ثابت، Quantizer ثابت را هدف قرار داده است و متد Bitrate معین، بیت ریت و درنتیجه حجم فایل خروجی مشخص را، CQ کیفیت (Quality) ثابت را هدف اصلی خود قرار داده است. هدف CQ این است که همان کیفیت قابل درک خروجی QP ثابت را در حجم خروجی کمتر ارائه کند. نرخ بیت و همچنین qp فایل نهایی هردو متغیر خواهند بود. این متد بطور تئوریک، تا حد زیادی مانند VBR عمل می کند برای همین در برخی متون از آن بعنوان Quality Based VBR نیز یاد شده است. نوع مشابهی از این متد با نام CRF یا Constant Rate Factor در کدک x264 پیاده سازی شد و بعدا در x265 نیز با تغییرات جزئی پیاده سازی شد. واحدی که در x264 برای این متد تعیین می کنید Ratefactor نام دارد. این متد با بالا بردن Quantizer "فریم های غیر مهم" که بیننده نمی تواند بخوبی متوجه کیفیت آنها بشود این کار را انجام می دهد.


    VBV
    در بالا به موضوع Peak ها اشاره شد. این موضوع Peak ها به خودی خود مشکلی ایجاد نخواهد کرد تا زمانی که بحث سازگاری با سخت افزار مطرح گردد و یک سخت افزار که پهنای باند محدودی دارد (در نتیجه میزان محدودی از بیت ها را می تواند در واحد زمان از خودش عبور بدهد، پردازش و یا پخش کند) برای پخش صحیح نیاز داشته باشد تا ویدئوی ورودی Peak هایی بالاتر از حد مجاز دستگاه مورد نظر نداشته باشد. برخی استاندارد های فشرده سازی ویدئویی خانواده MPEG برای کنترل Peak ها از سیستم VBV استفاده می کنند.
    VBV=Video Buffer Verifier: هدف اصلی استفاده از سیستم VBV این است که ویدئوی Encode شده بصورت صحیح در داخل دستگاه Decode کننده ی مورد نظر Buffer بشود و به نمایش درآید و از مقدار حافظه Buffer دستگاه Decoder تجاوز نکند و یا کمتر نباشد. از VBV معمولا در موارد Encode مختص سخت افزار (برای مثال Encode برای سخت افزار های Blu-Ray Stanalone Players ،DVD Video Players و ...) و جایی که پهنای باند تعیین شده و محدودی در اختیار هست مثلا Stream (انتشار) از طریق کابل، کانکشن آنلاین و یا سیستم ارسال از طریق ماهواره استفاده می شود.
    از مهم ترین پارامتر های VBV می توان به VBV Maxrate و VBV Buffer Size اشاره نمود. برای مثال، طبق specification ارائه شده، در Encode های مخصوص DVB-S و کانال های MPEG-2 PAL SD میزان VBV Maxrate را روی 10368000bit/s تنظیم می کنند و VBV buffer Size را بر روی 1835008bit. در سایر استانداردهای فشرده سازی ویدئویی مدل های مشابه دیگری معرفی شده است مانند HRD در VC-1.
    ویرایش توسط M-AUDIO : 17-01-2017 در ساعت 19:07 دلیل: بروزرسانی
    :)

  8. کاربران : 37 تشکر کرده اند از شما M-AUDIO برای ارسال این پست سودمند:


  9. #5
    عضو متخصص
    تاریخ عضویت
    May 2012
    ارسال ها
    1,760
    سیستم عامل
    Windows 7 64Bit
    محصول امنیتی
    ESET NOD32
    تشکر تشکر کرده 
    9,558
    تشکر تشکر شده 
    11,809
    اعتبار کاربر
    1

    Post Film frame , Frame rate , Picture rate , نرخ فریم

    Film frame , Frame rate , Picture rate , نرخ فریم

    در صنعت فیلم سازی، تولید ویدئو، انیمیشن و ...، Film Frame یا Video Frame به هر یک از تصاویر ثابتی اطلاق می شود که با قرار گرفتن پشت سر هم، تصویر در حال حرکت را ایجاد می کنند. هنگامی که فیلم به نمایش در می آید هر کدام از این فریم ها در یک زمان کوتاه بر روی صفحه (پرده ی سینما، صفحه مانیتور و ...) ظاهر می شوند و سپس بی درنگ توسط فریم بعدی جایگزین می شوند. ادامه ی این روند باعث می شود که فریم ها در دید ما، با هم ترکیب بشوند و توهّم یک تصویر واقعاً متحرک را به ما القاء کنند. ار آنجایی که واژه ی "Frame" در علوم گوناگون معانی مختلفی دارد مثلا بیشتر آنرا به معنی "کادر" در عکاسی می شناسند و ...، برای اشاره به فریم های یک ویدئو از اصطلاح دقیق تر "Video Picture" و بطور خلاصه "Picture" استفاده می کنند. به میزان پخش Video Picture ها در یک ثانیه، Frame rate ،Picture rate و یا نرخ فریم می گویند و آن را معمولاً با واحد fps=frames per second بیان می کنند.

    عکس زیر، تصویر فریم به فریم "یک ثانیه" از یک ویدئو می باشد که حاوی "30 فریم کامل (Progressive) در ثانیه" است. هنگامی که این فریم ها دریک ثانیه نشان داده بشوند یک تصویر متحرک بوجود خواهد آمد.

    مشاهده تصویر


    استاندارد های Frame rate گوناگونی برای سیستم های ویدئویی و فیلم ها در سرارسر جهان شکل گرفته اند. در آمریکای شمالی و ژاپن، 30 frame per second=fps استاندارد مخصوص سیستم Broadcasting می باشد. 24 فریم در ثانیه در حال حاضر در سیستم های ویدئویی high-definition=HD رایج است. در اکثر نقاط جهان نیز 25 frames/s رایج می باشد.
    گاهاً این نرخ فریم های بیان شده بصورت Nominal و غیر واقعی مطرح می شوند. برای مثال در سیستم NTSC، نرخ فریم در عمل و بصورت واقعی برابر با Nominal frame rate x 1000/1001 می باشد. مانند 30x1000/1001 که برابر می شود با 29.970fps. در سیستم های دیگرهم این اتفاق می افتد مانند 24x1000/1001 = 23.976 fps . در سیستم PAL این اتفاق نمی افتد و نرخ فریم برابر 25fps می باشد.

    گاهی اوقات و در برخی متون و نرم افزارها برای اشاره به نرخ فریم از عبارت هایی مانند زیر استفاده می شود که می توانید نرخ فریم واقعی مدنظر آن ها را مشاهده بفرمائید.
    NTSC FILM=23.976
    NTSC VIDEO=29.970
    PAL=25.000

    50p=50 (progressive) frames per second
    60p=60 (progressive) frames per second

    25i=50 (interlaced) fields per second
    30i=59.940 (interlaced) fields per second
    50i=50 (interlaced) fields per second
    60i=59.940 (interlaced) fields per second
    (در برخی متون گفته شده استفاده از 50i و 60i بجای 25i و 30i، صحیح است و به 25i و 30i اشاره ای نشده است.)


    نحوه های گوناگون نرخ فریم:

    Constant Frame rate یا CFR (نرخ فریم ثابت):
    در فشرده سازی ویدئو به نرخ فریمی که پایدار و ثابت باشد Constant Frame rate گفته می شود. این نحوه ی Frame rate با همه ی Container ها و Hardware Stand-alone Player ها سازگار می باشد. در استانداردهای DVD و Blu-Ray ویدئویی، تنها این نوع نرخ فریم مجاز می باشد.

    Variable Frame rate یا VFR (نرخ فریم متغیر):
    در فشرده سازی ویدئو، نام یک نحوه نرخ فریم است که توسط Container های محدودی پشتیبانی می شود و به ویدئو اجازه می دهد تا بصورت فعال نرخ فریم خود را در هنگام پخش تغییر دهد. VFR بخصوص برای Slideshow ها و ویدئو هایی که تعداد زیادی از صحنه های آنها ساکن (بی حرکت) است مانند Desktop Capture ها مفید است و به فشرده سازی کمک شایانی می کند. VFR توسط همه ی Hardware Stand-alone Player ها پشتیبانی نمی شود. همچنین در زمان انکد مجدد، توسط برخی از دیکدرها مشکل Desync و یا همان عدم هماهنگی صوت و تصویر را ایجاد می کند.
    ویرایش توسط M-AUDIO : 21-01-2017 در ساعت 12:34 دلیل: بروزرسانی
    :)

  10. کاربران : 35 تشکر کرده اند از شما M-AUDIO برای ارسال این پست سودمند:


  11. #6
    عضو متخصص
    تاریخ عضویت
    May 2012
    ارسال ها
    1,760
    سیستم عامل
    Windows 7 64Bit
    محصول امنیتی
    ESET NOD32
    تشکر تشکر کرده 
    9,558
    تشکر تشکر شده 
    11,809
    اعتبار کاربر
    1

    Post Aspect Ratios , AR

    Aspect Ratios , AR

    در یک تصویر، ارتفاع (Height) به اندازه ی عمودی (Vertical) کادر و پهنا (Width) به اندازه ی افقی (Horizontal) کادر "همان تصویر" گفته می شود. Aspect Ratio یک اصطلاح کلی است که بیان کننده ی نسبت اندازه ای به اندازه ی دیگر برای مثال طول به عرض یا پهنا به ارتفاع می باشد. بصورت رایج بوسیله دو عدد که با یک 2نقطه از یکدیگر جدا شده اند بیان می شود و درواقع فرم String یا Fraction نام دارد. بعنوان نمونه h:v که عدد سمت چپ که h باشد بیانگر نسبت پهنا (Width , Wide) و عدد سمت راست که v باشد بیانگر نسبت ارتفاع (High , Tall) در "کل" عکس می باشد. برای مثال 16:9 را درنظر بگیرید. این عدد به ما می گوید که تصویر ما به نسبت هر 16 پیکسل پهنا، دارای 9 پیکسل در ارتفاع می باشد، حال اندازه ی عکس هر مقدار که می خواهد بزرگ باشد مهم نیست زیرا این مقدار ثابت خواهد ماند. برای نمونه 1920x1080. حتی می توان از واحد های دیگر مانند اینچ و سانتی متر و ... نیز استفاده نمود و البته برای ویدئو معمولاً از واحد پیکسل استفاده می شود. این اعداد را به گونه ای دیگر نیز می نگارند که به آن فرم Decimal می گویند. برای مثال 1.33:1 یا بطور خلاصه 1.33 هم یک گونه نگارش AR می باشد و دقیقاً برابر با 4:3 می باشد. اینگونه نگارش از تقسیم پهنا به ارتفاع تصویر بدست می آید. اگر همین حالا با استفاده از ماشین حساب 4 را بر 3 تقسیم کنید عدد 1.333333333333333 را بدست خواهید آورد که استفاده تا دورقم بعد از اعشار آن کفایت می کند و اینگونه خوانده می شود که در تصویر ما پهنا، 1.33 برابر ارتفاع می باشد. حال مهم نیست که اندازه تصویر چقدر بزرگ باشد. برای مثال اگر 720 را تقسیم بر 540 کنید نیز عدد بالا را بدست خواهید آورد.
    اصطلاح Aspect Ratio در زبان ویدئو، یک تعریف کلی دارد و نمی توان منظور دقیق را از بیان آن منتقل کرد. اکثر افراد وقتی از آن استفاده می کنند منظورشان DAR است (که خب در صورتی که تصویر موردنظر، در استاندارد پیکسل های مربعی تولید شده باشد کاملا صحیح است). بنابراین اصطلاحات دقیق تری شکل گرفته اند که مهم ترین هایشان 3 مورد زیر می باشند:

    Storage Aspect Ratio=SAR

    Storage Aspect Ratio "شکل واقعی کادر ویدئو" می باشد که از تقسیم اندازه پهنای واقعی بر اندازه ارتفاع واقعی بدست می آید. یعنی نسبت پهنا به ارتفاع Video Picture. یعنی Storage Aspect Ratio تغییر نخواهد کرد مگر اینکه Picture Size توسط شما تغییر داده بشود.

    Display Aspect Ratio=DAR
    واژه ی Display Aspect Ratio=DAR به معنی شکلی است که کادر تصویر ویدئو "در هنگام نمایش" به خود می گیرد. در تعریفی دیگر می توان DAR را به این شکل مطرح نمود که مهم نیست AR اصلی Video Pictureها (یا بطور دقیق تر Storage Aspect Ratio) به چه میزان باشد. اگر DAR را فرضاً بر روی 16:9 قرار بدهید ویدئوی شما در "هنگام پخش" به ازای هر 16 پیکسل در عرض، 9 پیکسل در ارتفاع خواهد داشت (به شرط پشتیبانی حامل و پخش کننده استفاده شده). تنظیم اشتباه DAR نسبت به SAR می تواند باعث ایجاد حالت "کش آمدگی" افقی یا عمودی در ویدئو در زمان پخش گردد. DAR در Encodeهای به شیوه ی Anamorphic که در بعد به آنها اشاره خواهد شد نقش اساسی ایفا می کند.

    Pixel Aspect Ratio=PAR
    مقدار بعدی با عنوان Pixel Aspect Ratio=PAR یا Sample Aspect Ratio=SAR نام گذاری می شود. دقت کنید که اصطلاح Sample Aspect Ratio که دقیقا همان PAR می باشد و بیشتر ازش در استاندارد فرمت H264 (و H265) برای اشاره به شکل پیکسل ها استفاده می شود را با Storage Aspect Ratio اشتباه نگیرید. PAR یک نسبت ریاضی است که رابطه ی بین پهنای یک پیکسل از یک تصویر دیجیتالی را با ارتفاع همان پیکسل توصیف می کند. می دانیم که پیکسل ها (سمپل ها)، اجزای تشکیل دهنده ی یک تصویر می باشند و به طور معمول در اکثر سیستم های تصویری دیجیتال، شکل آنها مربع است. پیکسل های مربع شکل را Square Pixels می نامند و Aspect Ratio آنها برابر با 1:1 یا به اختصار، 1 می باشد. اما در بعضی از سیستم های تصویری دیجیتال برای مثال standard-definition television، پیکسل های تصویر بصورت مستطیل شکل (Rectangular Pixels) هم خواهند شد. یعنی پهنا و ارتفاع آنها یکسان نخواهد بود و PAR، شرح دهنده ی این نسبت می باشد. در سیستم دیجیتال مدرن و high-definition television و سیستم هایی که در توافق با استاندارد SMPTE قرار دارند، تنها پیکسل های مربع (SAR=1:1) برای نمایش و Broadcast استفاده می شود. البته در این سیستم ها نیز استثنا هایی وجود دارد که از جمله ی آن می توان به HDV اشاره داشت.

    عناوین دیگر
    نام های دیگری برای اشاره به Aspect Ratio های مختلف موجود است که توصیه می کنم تنها برای افزایش اطلاعات عمومی نگاهی به آنها بیندازید. درحالت عادی نیازی به آنها پیدا نمی کنید. چنانچه عبارت Aspect Ratio Calculator را گوگل کنید نرم افزارهایی برای محاسبه انواع مختلف آن خواهید بافت.
    ویرایش توسط M-AUDIO : 21-01-2017 در ساعت 13:56 دلیل: بروزرسانی
    :)

  12. کاربران : 40 تشکر کرده اند از شما M-AUDIO برای ارسال این پست سودمند:


  13. #7
    عضو متخصص
    تاریخ عضویت
    May 2012
    ارسال ها
    1,760
    سیستم عامل
    Windows 7 64Bit
    محصول امنیتی
    ESET NOD32
    تشکر تشکر کرده 
    9,558
    تشکر تشکر شده 
    11,809
    اعتبار کاربر
    1

    Post Video Picture Size , Frame Size , Video Resolution , mod16

    Video Picture Size , Frame Size , Video Resolution , Frame Dimensions
    این واژه ها در واقع یک مفهوم را می رسانند و آن مفهوم، اندازه ی هر فریم است که در ویدئو معمولاً با واحد پیکسل اندازه می شود. فریم ها در واقع عکس های ثابتی هستند که هنگامی که پشت سر هم قرار می گیرند ویدئوی متحرک ما را تشکیل می دهند و از آنجایی که هر عکس باید دارای یک اندازه مشخص باشد بنابراین این اندازه را Frame Size یا Picture Size نیز می نامند. بعنوان نمونه هنگامی که می گوییم سایز تصویر یک ویدئو برابر با 720x480 پیکسل است و یا مثلا می گوییم ویدئوی ما HD یا FullHD است در واقع Frame Size یا Picture Size آن ویدئو مدّ نظر می باشد (نه کیفیت آن). یعنی تصویر ویدئو ی ما یک مستطیل یا مربع است که N پیکسل پهنا و N پیکسل ارتفاع دارد. از ضرب تعداد پیکسل های پهنا در ارتفاع، میزان کل پیکسل های موجود در تصویر مشخص خواهد شد (که اگر عدد حاصله را بر 1میلیون تقسیم کنیم مقداری بدست خواهد آمد که از آن (در زمینه ی دوربین های عکاسی دیجیتال) خیلی زیاد شنیده اید یعنی مگاپیکسل).
    توجه: واژه ی رزولوشن (Resolution) اگر خیلی با دقت عنوان بشود، مفهومی دیگر نسبت به ابعاد تصویر پیدا می کند. بخصوص در صنعت لنز دوربین و صفحات نمایش. اگر چه استفاده از آن برای بیان ابعاد یک تصویر ویدئویی در بسیاری از نرم افزارهای مرتبط و صفحات اینترنتی انقدر انجام گرفته است که کاملا بی اشکال به نظر می رسد. اما استنباط می شود واژه بهتر همان سایز یا ابعاد می باشد.

    تغییر سایز , Resize
    بسیار خب. صفحات زیادی بر روی اینترت نوشته شده اند که به جرات می توان ذکر کرد که نیمی از آنها طرفدار تغییر ابعاد ویدئو و نیمی دیگر از آنها بر خلاف آن می باشند. دلیل گروه دوم این موضوع است که عملیات Resize (تغییر سایز) همیشه یک عملیات lossy بوده و باعث از دست رفتن جزئیات خواهد شد صرف نظر از الگوریتم استفاده شده برای تغییر سایز و میزان تغییر سایز. این دسته معتقدند تا زمانی که محدودیت سخت افزاری برای پخش وجود نداشته باشد (برای مثال شما نمی توانید هر ابعادی را در فرمت استاندارد دی وی دی ویدئویی جای بدهید، یا باید PAL-SD باشد یا NTSC-SD، و سایر موارد مشابه...) نباید عملیات Resize را انجام داد. در طرف دیگر، گروهی که به Resize علاقه دارند معتقدند با استفاده از سایز حاصل شده، همیشه می توان SAR و DAR صحیح در هر کجا بدست آورد و در همه ی Containerها. یک نکته هم ذکر کنم که بهترین متر برای سنجش کیفیت چشمان شما هستند که باید با یک مانیتور با نوردهی خوب همراه شوند.

    مُد16
    از عبارت mod16 یا modulus 16 هنگامی استفاده می شود که ابعاد ویدئوی ما (هم ارتفاع و هم پهنا بطور جداگانه) بر 16 بخش پذیر باشد و حاصل، باقیمانده نداشته باشد. به همین اندازه ساده. برای مثال ما یک ویدئو با ابعاد 640x272 در اختیار داریم. می خواهیم ببینیم mod16 هست یا خیر.
    کد HTML:
    640 / 16 = 40
    که نشان می دهد پهنای ویدئوی ما بر 16 بخش پذیر است و
    کد HTML:
    272 / 16 = 17
    که بخش پذیری ارتفاع ویدئوی ما بر 16 را نشان می دهد. خب پس ابعاد ویدئوی ما mod16 می باشد. اگر پهنای ویدئوی ما 650 بود، ویدئوی ما mod16 نمی شد زیرا
    کد HTML:
    650 / 16 = 40.625
    حال هنگامی که قصد تغییر سایز ویدئو را دارید می توانید با دقت بر این موضوع پهنا و ارتفاع ویدئو ی خود را به "نزدیک ترین" عدد در mod16 یا mod8 یا مد دلخواه خود، تغییر بدهید (رُند کنید).

    از دلایلی که باید یک ویدئو با ابعاد mod16 داشته باشیم:
    بعضی از Decoder های سخت افزاری (عمدتا قدیمی)، ویدئو هایی که mod16 نمی باشند را کلا، و یا بصورت صحیح، Decode نمی کنند و خطوط سبز و یا سفید را در گوشه های ویدئو در هنگام پخش نمایش می دهند. همچنین برخی انکدرها و دیکدرهای قدیمی که سال هاست بروزرسانی نشده اند.
    از دلایلی که تاکید بر mod16 عقیده ی جالبی نمی باشد:
    هنگامی که بر روی ابعاد بسیار پایین کار می کنید.
    هنگامی که نیاز است تا Aspect Ratio سورس بدون تغییر و یا با کمترین تغییر (error) حفظ شود.
    به این نکته ی جالب نیز توجه داشته باشید که ابعاد HD1080 که همه ی شما تقریبا با آن آشنایی دارید و در بلوری ها استفاده می شود، mod8 می باشد.
    ویرایش توسط M-AUDIO : 21-01-2017 در ساعت 15:10 دلیل: بروزرسانی
    :)

  14. کاربران : 37 تشکر کرده اند از شما M-AUDIO برای ارسال این پست سودمند:


  15. #8
    عضو متخصص
    تاریخ عضویت
    May 2012
    ارسال ها
    1,760
    سیستم عامل
    Windows 7 64Bit
    محصول امنیتی
    ESET NOD32
    تشکر تشکر کرده 
    9,558
    تشکر تشکر شده 
    11,809
    اعتبار کاربر
    1

    Post mod16 part2 , overcrop , undercrop , aspect ratio error

    از راه های رسیدن به mod16 یا mod دلخواه می توان به موارد زیر اشاره داشت:
    Resize: اولین راه برای شما تغییر سایز کادر به mod دلخواه می باشد و درباره ی آن بحث شد.
    Overcrop: این حالت به این معنا است که اگر کادر تصویر ویدئوی شما از یک جهت ارتفاع یا پهنا، مد دلخواه نبود شما آن جهت را مقداری Crop کنید (برش بزنید و حذف کنید) تا به مد دلخواه تبدیل بشود.
    Undercrop یا Pad: در این روش ما با اضافه کردن کادرهای سیاهرنگ (که Pad نامیده می شوند) به قسمت مورد نظر کادر، ابعاد مد دلخواه را بدست می آوریم.


    Aspect Ratio Error , Resize Error
    به آن میزان از تغییر سایز که برای رسیدن به یک هدف خاص (که می تواند یک ابعاد خاص باشد یا یک mod خاص) انجام می شود و به میزانی از Storage Aspect Ratio که با این میزان تغییر سایز، تغییر پیدا می کند Aspect Ratio Error گفته می شود. بعنوان نمونه بیاید یکبار فرمول تغییر سایز را باهم مرور کنیم:
    از چپ به راست بخوانید
    کد HTML:
    ارتفاع مقصد = پهنای مقصد × پهنای مبدا / ارتفاع مبدا
    کد HTML:
    پهنای مقصد = ارتفاع مقصد × ارتفاع مبدا / پهنای مبدا
    دو فرمول بالا یکی هستند فقط با عوض کردن جای داده ها، که بُعد موردنظر بدست می آید.
    برای مثال ما یک ویدئو NTSC DVD با ابعاد 720x480 در اختیار داریم یعنی 720پیکسل پهنا و 480 پیکسل ارتفاع. حال می خواهیم آنرا بر روی یک NTSC VCD که ابعاد استاندارد آن 352x240 است تبدیل کنیم. برای اینکار می بایست ابتدا عملیات تغییر سایز را انجام بدهیم. پس سایز مقصد را با توجه به فرمول محابسه می کنیم:
    کد HTML:
    480 / 720 x 352 = 236.6
    پس سایز تصویر مقصد ما بصورت دقیق می شود 352x236.6. پهنای ابعاد مقصد ما در حال حاضر برابر با ابعاد هدف می باشد اما ارتفاع مقصد با ابعاد هدف متفاوت می باشد و باید به 240 تغییر داده بشود. این تغییر سایز (یعنی مرحله دوم که از 236.6 به 240 انجام می شود) باعث تغییر در Storage Aspect Ratio می شود که به این میزان تغییر و اختلاف آن با Storage Aspect Ratio ورودی، Aspect Ratio Error گفته می شود. تکرار می کنم که منظور از واژه ی تغییر سایز در جمله ی قبل، مرحله ی اول تغییر سایز که با فرمول بود "نمی باشد" بلکه بخشی از تغییر سایز است که از 236.36 به 240 و برای رسیدن به ابعاد هدف انجام دادیم. و منظور هم حتما تغییر سایز است نه اضافه کردن Pad و نه برش زدن.
    ویرایش توسط M-AUDIO : 21-01-2017 در ساعت 19:45 دلیل: بروزرسانی
    :)

  16. کاربران : 37 تشکر کرده اند از شما M-AUDIO برای ارسال این پست سودمند:


  17. #9
    عضو متخصص
    تاریخ عضویت
    May 2012
    ارسال ها
    1,760
    سیستم عامل
    Windows 7 64Bit
    محصول امنیتی
    ESET NOD32
    تشکر تشکر کرده 
    9,558
    تشکر تشکر شده 
    11,809
    اعتبار کاربر
    1

    Post Anamorphic Encoding

    Anamorphic Encoding
    Anamorphic Encoding (آنامورفیک انکدینگ)، بطور خلاصه، یک حالت از Encoding ویدئو می باشد که در آن تصویر ویدئو با ابعاد مشخصی انکد می شود اما با ابعاد دیگری پخش می شود. این شیوه عمدتا در Encode هایی که میزان PAR نمی تواند در آنها 1:1 باشد (پیکسل ها نمی توانند در آنها مربع باشند) مورد استفاده قرار می گیرد. برای مثال می توان به سیستم استاندارد دی وی دی های ویدئویی حال حاضر و برخی از استانداردهای ماهواره ای که با سیستم تلویزیونی دیجیتالی SDTV مطابقت می کنند اشاره داشت.
    توضیح Anamorphic با ذکر مثال به یک دی وی دی ویدئویی با استاندارد NTSC :
    تصویر زیر، یک فریم با اندازه ی واقعی (همان اندازه ای که داخل Bitstream قرار گرفته) از فیلمی است که در یک NTSC DVD با دار 16:9 قرار گرفته است. مشاهده می کنید که تصویر بیش از حد طبیعی خود از جهت عمودی (ارتفاع) دچار کشیدگی شده است (به دایره ی مارک Volkswagen دقت کنید). یا می تواند گفته بشود بیش از حد از جهت پهنا به داخل فشرده شده است. این دقیقاً اتفاقی است که در دی وی دی های استاندارد ویدئویی رخ می دهد.
    تصاویر

    ابعاد: 720x480

    حال در تصویر زیر مشاهده می فرمایید که "هنگام پخش ویدئو"، تصویر از جهت افقی (همان پهنا) تغییر سایز داده می شود و درست می شود:
    ابعاد در هنگام نمایش: 854x480


    فرمول ها با مثال از DVD استاندارد ویدئویی

    فرمول بدست آوردن پهنای نمایش بوسیله DAR:
    برای بازسازی پهنای نمایش، "ارتفاع اصلی تصویر" ضربدر DAR می شود.
    مثلا DVD های 16:9 و 4:3 با سیستم NTSC "در ابعاد Full-D1" به ترتیب:
    کد HTML:
    480 x 16 / 9 = 854
    کد HTML:
    480 x 4 / 3 = 640
    DVD های 16:9 و 4:3 با سیستم PAL به ترتیب:
    کد HTML:
    576 x 16 / 9 = 1024
    کد HTML:
    576 x 4 / 3 = 768
    که "پهنای ویدئو در هنگام پخش" بدست می آید و "پهنای اصلی ویدئو" که داخل DVD (بطور صحیح تر داخل Bitstream) قرار گرفته است در هر دو سیستم استاندارد دی وی دی ویدئویی "در ابعاد Full-D1" برای NTSC و PAL برابر 720 می باشد.

    فرمول بدست آوردن پهنای نمایش بوسیله PAR:
    برای بازسازی پهنای نمایش، "پهنای اصلی تصویر" ضربدر PAR می شود.
    DVD های 16:9 و 4:3 با سیستم NTSC "مجددا در ابعاد Full-D1" به ترتیب:
    کد HTML:
    720 x 32 / 27 = 854
    کد HTML:
    720 x 8 / 9 = 640
    DVD های 16:9 و 4:3 با سیستم PAL به ترتیب:
    کد HTML:
    720 x 64 / 45 = 1024
    کد HTML:
    720 x 16 / 15 = 768


    ITU-BT R.601 و نسبت ابعاد پیکسل ها:
    فرض این استاندارد بر پهنای 704 پیکسل بجای 720 پیکسل است و به همین دلیل نسبت ابعاد پیکسل ها در آن با نسبت های عنوان شده در مثال های بالا (که در برخی متون و نرم افزارها Generic PARs نامیده شده اند) متفاوت می باشد.
    ابعاد 704x480 و 704x576 را که از جمله ابعاد مجاز دی وی دی استاندارد ویدئویی می باشند را برخی نرم افزارها Broadcast D1 نامیده اند.

    از دلایل دیگر استفاده از Encode به شیوه ی Anamorphic ( به غیر از سازگاری با استاندارد):
    یکی دیگر از قابلیت های Anamorphic می تواند این مثال باشد که ذخیره و انتقال یک تصویر Anamorphic با ابعاد 720x576 با دار 16:9 به پردازش، پهنای باند و Data rate کمتری نسبت به همان تصویر بصورت Square Pixel و ابعاد 1024x576 احتیاج خواهد داشت (زیرا تعداد پیکسل های کمتری در هر فریم و در هر ثانیه باید پردازش بشوند) در صورتی که تصویر 720x576 نیز در زمان پخش با استفاده از DAR با نسبت 16:9 خود، به 1024x576 تغییر سایز داده خواهد شد.
    همچنین خیلی ها نیز از این قابلیت برای جلوگیری از انجام عملیات Resize بهره می برند. برای مثال سورس یک DVD استاندارد ویدئویی Anamorphic هست و شخص فقط LetterBox (یا همان کادر های سیاه آنرا) برش می زند و تغییری در PAR ایجاد نمی کند.
    ویرایش توسط M-AUDIO : 31-01-2017 در ساعت 18:18 دلیل: بروزرسانی
    :)

  18. کاربران : 39 تشکر کرده اند از شما M-AUDIO برای ارسال این پست سودمند:


  19. #10
    عضو متخصص
    تاریخ عضویت
    May 2012
    ارسال ها
    1,760
    سیستم عامل
    Windows 7 64Bit
    محصول امنیتی
    ESET NOD32
    تشکر تشکر کرده 
    9,558
    تشکر تشکر شده 
    11,809
    اعتبار کاربر
    1

    Post Macroblocks ، Vertical resolution , Display resolution

    Macroblocks
    در اکثر استاندارد های ویدئویی خانواده MPEG یا آنهایی که با الگو گرفتن از آن نوشته شده اند، تصویر ویدئو ابتدا به بلوک های 16 در 16 پیکسل تقسیم شده و سپس هر بلوک Encode می شود. به هر یک از این بلوک ها، یک Macroblock گفته می شود.

    Macroblocks Per Frame:
    برای اندازه گیری تعداد Macroblock ها در یک فریم می توان از این فرمول استفاده نمود (از چپ به راست خوانده شود):
    تعداد Macroblock ها در هر فریم = 256 / ارتفاع ویدئو X پهنای ویدئو
    مثال: ابعاد ویدئوی ورودی ما برابر است با 1920x1080. حال برای محاسبه تعداد Macroblock ها در هر فریم به اینصورت عمل می کنیم:
    کد HTML:
    1920 x 1088 / 256 = 8160
    پس ویدئو ی ما در هر فریم خود دارای 8160 ماکروبلاک می باشد.
    توجه:
    برای بدست آوردن تعداد Macroblock ها در یک فریم حتما باید ابعاد ویدئو را قبل از قرار دادن در فرمول ابتدا به نزدیک ترین عدد Mod16 "از بالا" تبدیل کنیم. برای همین در بالا بجای 1080 نوشتیم 1088.

    Macroblocks Per Second , Macroblocks/s:
    برای محاسبه ی تعداد Macroblock ها در هر ثانیه ابتدا باید با استفاده از فرمول بالا تعداد Macroblock ها در هر فریم را محاسبه کنیم و سپس عدد بدست آمده را ضربدر Frame rate یا همان Picture rate ویدئو کنیم.
    مثال: ابعاد ویدوی ما برابر با 720x576 و نرخ فریم ویدئوی ما برابر با 25 فریم در ثانیه می باشد. پس تعداد Macroblock های ویدئوی ما در هر ثانیه برابر می شود با
    کد HTML:
    720 x 576 / 256 x 25 = 40,500
    پس ویدئوی ما در هرثانیه دارای 40,500 عدد ماکروبلاک می باشد.


    برای اطلاع بیشتر:
    دانستن این مقادیر به ما کمک می کند تا بتوانیم فایل خروجی خود را با استاندارد های فرمت های مختلف هماهنگ کنیم.
    برای مثال استاندارد H264 دارای Level بندی هایی برای خودش است و برای هر Level، تعداد Maximum یا حداکثر برای Macroblock Per Second و Macroblock Per Frame در نظر گرفته است. مثلا در این فرمت، Level 3.1 دارای Maximum تعداد 3600 عدد Macroblock در هر فریم و تعداد 108,000 عدد Macroblock در هر ثانیه می باشد.
    پس یعنی اگر تعداد Macroblock های ما بیش از این مقدار بشود خروجی ما دیگر در این Level نمی باشد و به Level بالاتر تبدیل خواهد شد. البته توجه داشته باشید که توجه به Level ها برای پخش صحیح فایل در پخش کننده های سخت افزاری مهم است. یعنی خیلی از دستگاه های پخش خانگی تنها می توانند فرمت AVC را با Level 4.1 (که استاندارد بلوری پلیرها نیز هست) رمزگشایی (Decode) کنند و اگر از محدودیت این Level فراتر برویم دستگاه مرد نظر از پخش فایل باز می ماند.
    در استاندارد HEVC یا همان H265 بالاخره ایده ی Macroblockها با Coding tree unit جایگزین شد که می توانند در سایز های متفاوتی بسته به انتخاب انکدر تولید بشوند.

    Vertical resolution , Display resolution
    حتماً تابحال باید عناوینی مانند 720p, 1080p, 420p, 1080i, 2160p به چشمتان خورده باشند. این اعداد بطور دقیق بیانگر اندازه ارتفاع تصویر و بطور خلاصه بیانگر ابعاد می باشند و هیچ ارتباط درستی به کیفیت تصویر ندارند (مگر اینکه در فارسی کلمه "کیفیت" را جایگزین یا تعبیر کلمه "ابعاد" بدانیم که درست به نظر نمی رسد. زیرا این ایده که یک تصویر 1280در720 همیشه از یک تصویر 720در480 با کیفیت تر است درست نیست و بسته به نوع فشرده سازی یا سایر شرایط تصویر برداری، ممکن است برعکس این صدق کند). این شیوه در بیان "رزولوشن های استاندارد" و شناخته شده که ابعاد مشخصی دارند (و لیستی از آن ها در لینک های داده شده مشخص است) مورد استفاده قرار می گیرد و در بیان رزولوشن های دیگر مورد استفاده قرار نمی گیرد (یا بهتر گفته بشود، در سایت های دانلود فیلم و تورنت مورد سوء استفاده قرار می گیرد ;)

    مقادیر (i) و (p) در واقع مشخص کننده ی شیوه ی اسکن شدن و به نمایش درآمدن فریم های ویدئو (Scan Type) می باشند و بصورت بهتر بیان کننده ی ساختار فریم های ویدئو می باشند که در پست های بعدی، توضیحاتی در این خصوص ارائه خوهد شد.
    p=Progressive و i=Interlaced .
    ویرایش توسط M-AUDIO : 31-01-2017 در ساعت 19:08 دلیل: بروزرسانی
    :)

  20. کاربران : 36 تشکر کرده اند از شما M-AUDIO برای ارسال این پست سودمند:


صفحه 1 از 3 123 آخرینآخرین

اطلاعات تاپیک

Users Browsing this Thread

در حال حاضر 1 در حال مشاهده این موضوع می باشد.. (0 کاربر و 1 مهمان در این انجمن حضور دارند)

برچسب برای این موضوع

بوک مارک ها

بوک مارک ها

مجوزهای ارسال و ویرایش

  • شما نمی توانید موضوع جدید ارسال کنید
  • شما نمی توانید به پست ها پاسخ دهید
  • شما نمی توانید فایل پیوست ضمیمه کنید
  • شما نمی توانید پست های خود را ویرایش کنید
  •