اگر ویدئو تولید می‌کنید، فایل‌های موجود را تبدیل می‌کنید یا محتوای ویدئویی برای وب‌سایت آماده می‌کنید، انتخاب قالب مناسب و تنظیمات فشرده‌سازی یکی از مهم‌ترین تصمیم‌هاست. کوچک‌ترین فایل ممکن لزوماً بهترین فایل نیست. ویدئو باید در مرورگرها بدون مشکل پخش شود، روی گوشی‌های هوشمند کار کند، رمزگشایی آن بهینه باشد و برای کاربرد موردنظر کیفیت تصویری کافی داشته باشد.
من MP4، WebM، H.264، H.265/HEVC، VP9، AV1، FFmpeg، پیش‌تنظیم‌های رمزگذار x264، سازگاری مرورگرها، رمزگشایی سخت‌افزاری در موبایل و سنجش کیفیت ویدئو را بررسی کردم. آزمایش‌های عملی فشرده‌سازی هم انجام دادم: یک ویدئوی منبع را با مقادیر مختلف CRF رمزگذاری کردم و خروجی‌ها را هم با چشم و هم با معیارهای عینی مقایسه کردم.
در نهایت تصمیم گرفتم وقتی قرار است فقط یک فایل ویدئویی روی گسترده‌ترین طیف عملی از مرورگرها، گوشی‌ها و برنامه‌های دیگر پخش شود، MP4 با کدک H.264 را در اولویت بگذارم.
برای ویدئوهای کوتاهی که عمدتاً روی موبایل دیده می‌شوند و بارگذاری سریع و حجم کم مهم‌تر از حفظ تک‌تک جزئیات است، x264 CRF 30 را انتخاب کردم؛ چون هنگام پخش معمولی، حتی روی نمایشگر بزرگ رایانه، تفاوت بصری معناداری میان CRF 22 و 30 نمی‌دیدم.
البته این تصمیم یک قید بسیار مهم دارد: CRF 30 را برای فیلم‌های سینمایی، تولیدات ویدئویی ممتاز یا تصاویری که بیشترین وفاداری بصری در آن‌ها اهمیت دارد توصیه نمی‌کنم. برای چنین کاربردهایی، مقدار بسیار محافظه‌کارانه‌تری، اغلب نزدیک CRF 20، ممکن است نقطه شروع بهتری باشد. من آزمایش مشابهی روی فیلم‌های بلند یا تصاویر سینمایی باکیفیت انجام نداده‌ام؛ بنابراین این تنظیمات فقط نقطه شروعی برای آزمون‌های جداگانه‌اند.
در این مقاله منطق فنی انتخابم، نتایج واقعی فشرده‌سازی، محدودیت‌های آن نتایج و روش انتخاب قالب و تنظیم کیفیت مناسب برای پروژه خودتان را توضیح می‌دهم.
1. ظرف ویدئو و کدک دو چیز متفاوت‌اند
پیش از مقایسه MP4 و WebM باید تفاوت میان ظرف و کدک را بدانیم.
ظرف یا Container تصویر، صدا، زمان‌بندی و فراداده را در یک فایل نگه می‌دارد. کدک ویدئو تعیین می‌کند فریم‌ها چگونه فشرده و رمزگشایی شوند.
برای مثال، یک فایل MP4 می‌تواند ویدئویی با کدک H.264، HEVC یا AV1 داشته باشد. با وجود یکسان بودن پسوند فایل، این ترکیب‌ها از نظر ویژگی‌های فشرده‌سازی و نیازمندی‌های دستگاه متفاوت‌اند.
| جزء | نمونه‌ها | کاربرد |
|---|---|---|
| ظرف ویدئو | MP4، WebM، MOV، MKV | بسته‌بندی تصویر، صدا و داده‌های زمان‌بندی |
| کدک ویدئو | H.264، HEVC، VP9، AV1 | فشرده‌سازی و بازکردن فشرده‌سازی فریم‌های ویدئو |
| کدک صوتی | AAC، Opus، MP3 | فشرده‌سازی و بازکردن فشرده‌سازی صدا |
| رمزگذار ویدئو | x264، x265، SVT-AV1، libvpx-vp9 | اجرای فرایند فشرده‌سازی ویدئو |
تغییر نام فایل از .webm به .mp4 کدک ویدئو را تبدیل نمی‌کند. به همین ترتیب، قراردادن AV1 در ظرف MP4 باعث نمی‌شود ویدئو روی دستگاهی که از رمزگشایی AV1 پشتیبانی نمی‌کند قابل پخش شود.
هنگام بررسی سازگاری ویدئو همیشه ترکیب کامل را در نظر بگیرید: ظرف، کدک ویدئو، کدک صدا، پروفایل کدک، عمق بیت و محیط پخش.
2. MP4 یا WebM: کدام برای ویدئوی وب بهتر است؟
MP4 و WebM هر دو ظرف‌های مدرن و معتبری برای ویدئو هستند. هیچ‌کدام در همه شرایط برتر نیستند؛ زیرا ویژگی‌های عملی آن‌ها به کدک‌های درونشان بستگی دارد.
MP4 با H.264: بیشترین سازگاری عملی
فایل MP4 حاوی ویدئوی H.264 و صدای AAC سابقه بسیار گسترده‌ای در سازگاری دارد. مرورگرهای رایج دسکتاپ و موبایل، پخش‌کننده‌های ویدئوی سیستم‌عامل‌ها و بسیاری از برنامه‌های شخص ثالث از آن پشتیبانی می‌کنند.
رمزگشاهای سخت‌افزاری ویدئو در گوشی‌ها و رایانه‌ها نیز معمولاً از آن پشتیبانی می‌کنند. رمزگشایی سخت‌افزاری می‌تواند در مقایسه با رمزگشایی نرم‌افزاری، مصرف CPU را کاهش دهد، بازده پخش را بهبود بخشد و انرژی کمتری مصرف کند.
نقطه‌ضعف اصلی آن بازده فشرده‌سازی است. کدک‌های جدیدتر اغلب می‌توانند با نرخ بیت کمتر، کیفیت ادراکی مشابهی ارائه دهند.
بااین‌حال، وقتی پخش مطمئن مهم‌تر از دستیابی به کوچک‌ترین فایل ممکن است، H.264 همچنان انتخاب بسیار خوبی است.
WebM با VP9: فشرده‌سازی کارآمد و مناسب مرورگر
WebM معمولاً ویدئوی VP8، VP9 یا AV1 را در خود دارد و صدا در آن اغلب با Opus یا Vorbis رمزگذاری می‌شود.
VP9 در کیفیت تصویری مشابه، اغلب فشرده‌سازی کارآمدتری نسبت به H.264 دارد. مرورگرهای امروزی، ازجمله نسخه‌های جدید Safari، به‌طور گسترده از آن پشتیبانی می‌کنند.
این ادعا که Safari اساساً از WebM یا VP9 پشتیبانی نمی‌کند نادرست است. سازگاری مرورگرها در طول زمان به‌طور چشمگیری بهتر شده است.
محدودیت مهم‌تر، سازگاری خارج از مرورگر است. برنامه‌های بومی سیستم‌عامل، دستگاه‌های قدیمی و نرم‌افزارهای دیگر ممکن است به‌اندازه MP4 متداول با کدک H.264، با WebM سازگار نباشند.
برای برنامه‌ای که فقط در مرورگر اجرا می‌شود و می‌توان قابلیت‌های پخش را کنترل کرد، WebM انتخاب قدرتمندی است. اما برای ویدئویی که بازدیدکنندگان ممکن است دانلود کنند و با نرم‌افزارهای دلخواه باز کنند، عملکرد MP4/H.264 قابل‌پیش‌بینی‌تر است.
تفاوت در عمل
| نیاز | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| پخش در مرورگرهای جدید | عالی | بسیار خوب |
| پشتیبانی از مرورگرها و دستگاه‌های قدیمی | عموماً بهتر | وابسته‌تر به محیط |
| سازگاری فایل دانلودشده | عموماً بهتر | در برنامه‌های بومی کمتر قابل‌پیش‌بینی |
| بازده فشرده‌سازی | خوب | اغلب بهتر |
| رمزگشایی سخت‌افزاری | بسیار فراگیر | رایج، اما وابسته به دستگاه |
| کاربرد مناسب | یک فایل با سازگاری گسترده | ارائه کارآمد ویدئو در وب برای دستگاه‌های شناخته‌شده |
پرسش اصلی این نیست که WebM قالب خوبی هست یا نه؛ مهم این است که آیا مزیت فشرده‌سازی آن در محیط مشخص شما ارزش محدودیت‌های سازگاری را دارد یا نه.
3. H.264 یا H.265 یا VP9 یا AV1: کدام کدک را انتخاب کنیم؟
هر کدک اصلی ویدئو توازن متفاوتی میان بازده فشرده‌سازی، هزینه رمزگذاری، پشتیبانی سخت‌افزاری، سازگاری نرم‌افزاری و مجوزها برقرار می‌کند.
| کدک | بازده فشرده‌سازی | سازگاری عملی | کاربرد معمول |
|---|---|---|---|
| H.264 / AVC | خوب | عالی | ویدئوی عمومی وب، پخش موبایل، دانلود |
| H.265 / HEVC | عموماً بهتر از H.264 | وابسته به محیط | دستگاه‌های سازگار Apple، محیط‌های کنترل‌شده، ویدئوی با وضوح بالا |
| VP9 | عموماً بهتر از H.264 | بسیار خوب در مرورگرهای جدید | ارائه ویدئو در مرورگر |
| AV1 | ظرفیت بالقوه عالی برای فشرده‌سازی | رو به گسترش، با محدودیت در دستگاه‌های قدیمی | پخش جریانی جدید و دستگاه‌های سازگار |
این‌ها مقایسه‌هایی کیفی‌اند، نه رتبه‌بندی‌های همگانی نرخ بیت. بازده واقعی به محتوای ویدئو، پیاده‌سازی رمزگذار، کیفیت هدف، پیش‌تنظیم رمزگذاری و روش اندازه‌گیری بستگی دارد.
H.264: بالغ، سریع در رمزگشایی و دارای پشتیبانی گسترده
H.264 بسیار بهینه شده و طیف بزرگی از سخت‌افزارها و نرم‌افزارها از آن پشتیبانی می‌کنند. بلوغ این کدک زمانی مزیت است که ویدئو باید بدون نیاز به پخش‌کننده‌ای خاص، مطمئن اجرا شود.
ضعف آن این است که کدک‌های جدیدتر اغلب فشرده‌سازی کارآمدتری دارند. همچنین H.264 مشمول ملاحظات حق اختراع و مجوز است که باید برای سناریوهای مربوط به توزیع تجاری بررسی شوند.
H.265 / HEVC: فشرده‌سازی بهتر با مصالحه در سازگاری
HEVC می‌تواند در کیفیت مشابه، نرخ بیت را نسبت به H.264 به‌طور قابل‌توجهی کاهش دهد. این ویژگی به‌ویژه برای محتوای با وضوح بالا و محیط‌هایی جذاب است که سازگاری دستگاه‌ها در آن‌ها قابل‌کنترل است.
بسیاری از دستگاه‌های Apple به‌خوبی از HEVC پشتیبانی می‌کنند. اما پشتیبانی مرورگرها و برنامه‌های خارجی بسته به سیستم‌عامل و اجزای رمزگشایی نصب‌شده متفاوت است. مجوزها هم موضوع دیگری برای بررسی‌اند.
HEVC می‌تواند انتخابی عالی باشد، اما من به‌صورت پیش‌فرض آن را تنها قالب ویدئوی قابل‌دانلود در یک وب‌سایت عمومی قرار نمی‌دهم.
VP9: جایگزینی باز و کاربردی
VP9 فشرده‌سازی خوبی ارائه می‌دهد و با مرورگرهای امروزی سازگاری گسترده‌ای دارد. وقتی ویدئوها در مرورگر باقی می‌مانند و محیط پخش قابل‌پیش‌بینی است، انتخاب جذابی محسوب می‌شود.
عیب اصلی آن برای کاربرد من، عدم قطعیتی بود که هنگام دانلود ویدئو یا بازکردن آن در برنامه‌های بومیِ فاقد پشتیبانی یکسان از WebM یا VP9 ایجاد می‌شود.
AV1: بازده عالی، اما نه پشتیبانی سخت‌افزاری همگانی
AV1 یکی از امیدبخش‌ترین کدک‌های جدید ویدئوست. این کدک در مقایسه با کدک‌های قدیمی‌تر می‌تواند صرفه‌جویی قابل‌توجهی در نرخ بیت ایجاد کند و پشتیبانی از رمزگشایی سخت‌افزاری آن همچنان گسترش می‌یابد.
بااین‌حال، دستگاه‌های قدیمی ممکن است رمزگشای AV1 نداشته باشند یا ناچار به رمزگشایی نرم‌افزاری شوند. رمزگشایی نرم‌افزاری ویدئوی با وضوح بالا می‌تواند CPU و باتری بیشتری مصرف کند و در دستگاه‌های ضعیف‌تر مشکل پخش ایجاد کند.
اگر محیط پخش تحت کنترل شماست، AV1 ارزش بررسی جدی دارد. اما اگر قرار است تنها یک فایل روی دستگاه‌های قدیمی و جدید و پخش‌کننده‌های معمول خارج از مرورگر کار کند، H.264 همچنان گزینه پیش‌فرض مطمئن‌تری است.
راهنمای کدک‌های ویدئویی MDN جزئیات مفیدی درباره این کدک‌ها و شرایط پشتیبانی مرورگرها ارائه می‌دهد.
4. یک قالب ویدئو یا چند نسخه؟
این یکی از مهم‌ترین تصمیم‌های معماری در ارائه ویدئوست.
اگر امکان تهیه چند نسخه وجود داشته باشد، وب‌سایت می‌تواند برای دستگاه‌های سازگار AV1 یا VP9 ارائه دهد و در محیط‌های دیگر به H.264 برگردد. این کار ممکن است بازده فشرده‌سازی را افزایش دهد و درعین‌حال پوشش گسترده پخش را حفظ کند.
بااین‌حال، نگهداری چند نسخه پیچیدگی بیشتری در رمزگذاری، ذخیره‌سازی، کش‌کردن، اعتبارسنجی و انتخاب نسخه مناسب پخش ایجاد می‌کند.
اگر برای هر منبع دقیقاً به یک فایل ویدئویی نهایی نیاز دارید، اغلب بهتر است سازگاری را در اولویت قرار دهید.
من MP4/H.264 را انتخاب کردم؛ چون می‌خواستم بدون تکیه بر قالب جایگزین، یک فایل در مرورگرهای اصلی، گوشی‌های هوشمند و روش‌های رایج دانلود و پخش ویدئو کار کند.
این به‌معنای آن نیست که MP4/H.264 بهترین فشرده‌سازی را ارائه می‌دهد؛ بلکه تصمیمی است که پخش قابل‌پیش‌بینی را به مزیت احتمالی حجم کمتر با کدکی جدیدتر ترجیح می‌دهد.
5. چرا اولویت‌های ویدئوی موبایل متفاوت‌اند؟
فشرده‌سازی ویدئو باید متناسب با شیوه واقعی تماشای محتوا باشد.
نیازهای یک کلیپ کوتاه که عمدتاً روی گوشی دیده می‌شود با فیلم بلندی که روی تلویزیونی بزرگ نمایش داده می‌شود متفاوت است. در حالت اول، بارگذاری سریع و مصرف کمتر اینترنت موبایل ممکن است از حفظ ظریف‌ترین جزئیات تصویری ارزشمندتر باشد. در حالت دوم، کیفیت تصویر شاید هدف اصلی باشد.
برای کلیپ‌های کوتاه مخصوص موبایل، فایل‌های کوچک‌تر چند مزیت دارند:
- پیش از شروع پخش، داده کمتری باید منتقل شود.
- در اتصال‌های محدود ممکن است دانلود زودتر تمام شود.
- فضای ذخیره‌سازی کمتری روی دستگاه لازم است.
- مصرف اینترنت همراه کاربر کمتر می‌شود.
- وقتی نرخ بیت ویدئوی رمزگذاری‌شده پایین‌تر است، پخش ممکن است در برابر محدودیت پهنای باند مقاوم‌تر شود.
بااین‌حال، فایل کوچک‌تر تضمین نمی‌کند که ویدئو هیچ‌وقت با مکث، بافرشدن یا توقف تصویر روبه‌رو نشود. نوسان شبکه، بیشینه نرخ بیت، رفتار سرور، بافر پخش و توان رمزگشایی دستگاه هم اهمیت دارند.
سازگاری موبایل فراتر از پسوند فایل است: رمزگشایی سخت‌افزاری، پروفایل و سطح کدک، عمق بیت، نمونه‌برداری رنگی، وضوح تصویر، نرخ فریم و بیشینه نرخ بیت هم مؤثرند. ویدئویی که با عرض 390 پیکسل CSS نمایش داده می‌شود ممکن است روی نمایشگر پرتراکم گوشی، تعداد بسیار بیشتری پیکسل فیزیکی را اشغال کند. بنابراین بررسی فریمی که عرض آن به 390 پیکسل کاهش یافته لزوماً معادل تماشای ویدئوی اصلی روی همان گوشی نیست. دستگاه‌های واقعی و شرایط واقعی پخش را آزمایش کنید.
CRF کیفیت را کنترل می‌کند، نه سقف دقیقی برای نرخ بیت. حتی ویدئویی با حجم کلی نسبتاً کم هم در صحنه‌های پیچیده ممکن است جهش‌های سنگین نرخ بیت داشته باشد. اگر پخش مطمئن روی اتصال‌های بسیار کند ضروری است، محدودیت صریح نرخ بیت یا VBV، حدود مناسب وضوح تصویر و آزمون در شرایط شبکه واقعی را در نظر بگیرید.
اصل ماجرا ساده است: برای تجربه تماشای موردنظر بهینه‌سازی کنید، نه برای یک هدف انتزاعیِ حداکثر کیفیت.
6. درک CRF در x264: عدد کمتر یعنی کیفیت بیشتر، عدد بالاتر یعنی فایل کوچک‌تر
پس از انتخاب H.264، مسئله بعدی تعیین شدت فشرده‌سازی ویدئوست.
در x264، عامل نرخ ثابت (Constant Rate Factor) یا CRF، توازن میان حفظ جزئیات بصری و حجم فایل را کنترل می‌کند.
CRF پایین‌تر عموماً کیفیت بالاتر و فایل بزرگ‌تری ایجاد می‌کند. CRF بالاتر معمولاً فایل کوچک‌تر همراه با افت کیفیت بیشتر بر اثر فشرده‌سازی به همراه دارد.
CRF نرخ بیت یا حجم خروجی دقیقی تعیین نمی‌کند. رمزگذار بسته به محتوای منبع بیت‌ها را تخصیص می‌دهد؛ بنابراین یک صحنه ساده و یک صحنه پرجزئیات می‌توانند با CRF یکسان حجم فایل بسیار متفاوتی داشته باشند.
CRF همچنین سازگاری بنیادی رمزگشا را تعیین نمی‌کند. دو ویدئوی H.264 که به‌درستی با CRF 22 و CRF 30 رمزگذاری شده‌اند، می‌توانند کدک، پروفایل، سطح، قالب پیکسل، ابعاد و نرخ فریم یکسانی داشته باشند.
تفاوت اصلی در کیفیت فشرده‌سازی و ویژگی‌های نرخ بیت آن‌هاست.
نکته مهم این است که اعداد CRF در پیاده‌سازی‌های مختلف کدک مستقیماً قابل‌مقایسه نیستند. CRF 30 در x264 الزاماً همان کیفیت بصری CRF 30 در رمزگذار AV1 را ندارد.
7. آزمایش واقعی فشرده‌سازی من: از CRF 22 تا 32
می‌خواستم مشخص کنم پیش از آنکه تفاوت هنگام پخش عادی اهمیت پیدا کند، تا چه اندازه می‌توانم ویدئو را فشرده کنم.
از یک ویدئوی کوتاه که قبلاً فشرده شده بود استفاده کردم و نسخه‌های مقایسه‌ای H.264 را با CRFهای 22، 24، 26، 28، 29، 30، 31 و 32 ساختم.
ویژگی‌های اصلی ویدئو ازجمله وضوح تصویر، نرخ فریم، مدت و تعداد فریم‌ها حفظ شدند. تنظیمات رمزگذار نیز یکسان نگه داشته شدند تا اثر تغییر CRF قابل‌ارزیابی باشد.
نتایج تفاوت‌های قابل‌توجهی در حجم فایل‌ها نشان دادند.
| CRF | حجم تقریبی نسبت به فایل اصلی | مفهوم نتیجه |
|---|---|---|
| 22 | 63% | فشرده‌سازی محافظه‌کارانه‌تر و حفظ بهتر جزئیات |
| 24 | 49% | فایل کوچک‌تر با افت کیفیت اضافی محدود |
| 26 | 38% | صرفه‌جویی بیشتر با حفظ جزئیات قابل‌توجه |
| 28 | 30% | خروجی کم‌حجم با شباهت نسبتاً زیاد به منبع |
| 29 | 26% | فشرده‌سازی تهاجمی‌تر |
| 30 | 23% | توازنی که برای این محتوای آزمایش‌شده ترجیح دادم |
| 31 | 21% | کاهش بیشتر حجم با وفاداری کمتر به منبع |
| 32 | 19% | کوچک‌ترین خروجی آزمایش‌شده و بیشترین افت کیفیت اندازه‌گیری‌شده |
این درصدها به همان فایل منبع آزمایش‌شده مربوط‌اند و نباید آن‌ها را میزان صرفه‌جویی معمول برای هر ویدئویی دانست. درصدهای جدول جداگانه گرد شده‌اند؛ برای محاسبه دقیق صرفه‌جویی نسبی، از حجم‌های واقعی فایل‌ها استفاده کنید، نه از تقسیم اعداد گرد‌شده جدول.
شگفت‌انگیزترین نتیجه این بود که در پخش عادی، حتی روی نمایشگر بزرگ دسکتاپ، تفاوت بصری معناداری میان CRF 22 و CRF 30 نمی‌دیدم.
نسخه‌های با فشرده‌سازی شدیدتر، ازجمله CRF 32، را هم بررسی کردم و در پخش عادی همان کلیپ خاص تفاوت چشمگیری ندیدم.
این مشاهده اهمیت داشت؛ چون ویدئوها در اصل برای نمایشگرهای کوچک‌تر موبایل تهیه شده بودند. اگر افت کیفیت روی نمایشگر رایانه من آزاردهنده نبود، دلیل چندانی نداشتم هزینه افزایش قابل‌توجه حجم فایل را برای جزئیات بیشتری بپردازم که تجربه تماشای موردنظرم را بهتر نمی‌کردند.
البته این فقط مشاهده‌ای ذهنی درباره یک نوع محتوای منبع بود. ثابت نمی‌کند همه کاربران، همه گوشی‌ها یا همه ویدئوها رفتار یکسانی دارند. نمایشگرهای موبایل با تراکم بالا و فاصله نزدیک چشم تا صفحه همچنان می‌توانند عیب‌های فشرده‌سازی را، به‌خصوص در جزئیات ریز یا گرادیان‌ها، آشکار کنند.
8. اندازه‌گیری‌های عینی افت واقعی کیفیت را تأیید کردند
اینکه هنگام پخش تفاوتی نمی‌بینیم به‌معنای یکسان بودن ریاضی دو ویدئو نیست.
خروجی‌های رمزگذاری‌شده را با معیارهای عینی کیفیت تصویر نیز مقایسه کردم. با افزایش CRF، شباهت به منبع کاهش یافت.
در مقایسه‌ای که همه نسخه‌ها به‌شکل یکسان کوچک شده بودند تا نمایشگر پرتراکم موبایل را تقریب بزنند، نمونه مقادیر SSIM چنین بود:
| CRF | SSIM تقریبی | حجم خروجی نسبت به CRF 28 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
روند روشن است: فشرده‌سازی شدیدتر، وفاداری اندازه‌گیری‌شده ویدئوی رمزگذاری‌شده به منبع را کاهش داد. بررسی دقیق نیز تفاوت‌های ظریفی در خطوط نازک و بافت‌ها نشان داد.
بااین‌حال، تجربه تماشای معمولی برای منبع آزمایش‌شده بسیار شبیه باقی ماند. دقیقاً به همین دلیل باید اندازه‌گیری عینی و ارزیابی شخصی را کنار هم به کار برد.
SSIM شباهت تصویر را می‌سنجد، نه تمام تجربه تماشای انسان را. این معیار نمی‌تواند همه عیب‌های زمانی، شارپنس ادراک‌شده، رفتار حرکت یا اهمیت ذهنی تک‌تک جزئیات بصری را کامل در نظر بگیرد.
VMAF معیار مفید دیگری برای کیفیت ادراکی است. Netflix مدل‌های VMAF v1 را در ژوئن 2026 منتشر کرد که یکی از آن‌ها برای شرایط تماشای ویدئو روی گوشی طراحی شده است. این مدل‌ها آشکارا می‌پذیرند که کیفیت ادراک‌شده تا حدی به اندازه نمایشگر و فاصله نسبی تماشا بستگی دارد.
در این بررسی، میانگین VMAF گزارش‌شده برای یک نمونه رمزگذاری‌شده با تنظیم محافظه‌کارانه حدود 95 بود، اما برای همه تنظیمات تهاجمی CRF مجموعه‌ای یکدست از مقادیر VMAF وجود نداشت. بنابراین از VMAF استفاده نکردم تا ادعا کنم CRF 30 یا 32 به آستانه‌ای همگانی از کیفیت رسیده‌اند.
نتیجه عملی محدودتر بود: ویدئوی کوتاه آزمایش‌شده هنگام پخش معمولی، فشرده‌سازی شدید H.264 را بسیار خوب تحمل کرد.
9. چرا CRF 30 را برای ویدئوهای کوتاه موبایل انتخاب کردم؟
پس از مقایسه فایل‌ها تصمیم گرفتم برای ویدئوهای کوتاه مشابه که عمدتاً روی موبایل تماشا می‌شوند از CRF 30 استفاده کنم.
دلایل این تصمیم روشن بودند:
- ویدئوها کوتاه بودند و قرار نبود کیفیت تصویر سینمایی ارائه دهند.
- بارگذاری سریع و دانلودهای کم‌حجم اهمیت داشتند.
- روی نمایشگر بزرگ دسکتاپ تفاوت بصری معناداری میان CRF 22 و 30 نمی‌دیدم.
- CRF 30 در مقایسه با تنظیمات محافظه‌کارانه فایل‌های بسیار کوچک‌تری ساخت.
- CRF 32 هم برای نمونه آزمایش‌شده از نظر بصری قابل‌قبول بود، اما برای محتوای پیچیده‌تر اطمینان کمتری ایجاد می‌کرد.
در مقایسه با CRF 28، مقدار CRF 30 حجم خروجی آزمایش‌شده را حدود 21% کاهش داد. در مقایسه با CRF 22، کاهش حجم بیش از 60% بود.
برای کلیپ‌های کوتاه مخصوص موبایل که هدفشان تصویر خوشایند، بارگذاری سریع و مصرف معقول پهنای باند است، این مصالحه ارزشش را داشت.
اما شرط انتخاب بسیار مهم است: عدد 30 را به‌خاطر هدف واقعی تماشا و نتایج محتوای آزمایش‌شده انتخاب کردم، نه چون 30 ذاتاً بهترین CRF برای گوشی‌های هوشمند است.
گوشی موبایل به CRF 30 نیاز ندارد و می‌تواند ویدئوی رمزگذاری‌شده با وفاداری بسیار بالاتر را هم به‌خوبی نمایش دهد. CRF 30 تصمیمی آگاهانه برای معاوضه بخشی از وفاداری به منبع با فایل کوچک‌تر است، آن هم زمانی که چنین معاوضه‌ای پذیرفتنی باشد.
پیش از اعمال این تنظیم روی مجموعه‌ای با محتوای بسیار متفاوت، چند کلیپ نماینده را می‌آزمایم؛ ازجمله صحنه‌های دارای حرکت دشوار، صحنه‌های تاریک، گرادیان‌ها، متن و بافت‌های ظریف.
10. چرا CRF 30 را برای فیلم‌ها و ویدئوهای باکیفیت توصیه نمی‌کنم؟
این مهم‌ترین محدودیت آزمایش من است.
نتیجه CRF 30 من را کورکورانه برای فیلم‌های بلند، محتوای ویدئویی ممتاز، تصاویر حرفه‌ای یا ویدئوهایی که برای نمایشگرهای بزرگ تهیه شده‌اند به کار نبرید.
چنین محتواهایی ممکن است گرادیان‌های ظریف، دانه‌بندی فیلم، صحنه‌های کم‌نور، حرکت پیچیده، سطوح با بافت ریز و رنگ‌بندی دقیق داشته باشند. حفظ این جزئیات شاید از صرفه‌جویی نسبتاً اندکی در پهنای باند مهم‌تر باشد.
برای ویدئوی معمول 1080p با کیفیت بالا، از تنظیم بسیار محافظه‌کارانه‌تری در x264، نزدیک CRF 20، شروع می‌کنم و با توجه به محتوا مقادیر کمتر و بیشتر را می‌سنجم.
وقتی وفاداری تصویری مهم است، بازه CRF 18–22 می‌تواند نقطه شروع عملی باشد؛ هرچند مقدار مناسب بسته به وضوح، محتوا و نیازمندی‌ها ممکن است بیرون از این بازه باشد.
این پیشنهاد با راهنماهای رایج و منتشرشده رمزگذاری هم‌خوانی دارد. برای مثال، مستندات کیفیت HandBrake برای بسیاری از کاربردهای x264 در 1080p مقدار تقریبی RF 20–24 را پیشنهاد می‌کند.
من آزمایش کنترل‌شده مشابهی روی فیلم‌های بلند یا تصاویر سینمایی ممتاز انجام نداده‌ام. بنابراین نمی‌توانم ادعا کنم CRF 20 همیشه بهینه است، CRF 22 همواره کافی است یا فیلم خاصی با CRF 30 حتماً غیرقابل‌قبول خواهد بود.
روش درست این است که صحنه‌های نماینده را انتخاب کنید، آن‌ها را در چند سطح کیفیت رمزگذاری کنید، روی نمایشگر موردنظر مقایسه کنید و نقطه‌ای را پیدا کنید که فشرده‌سازی بیشتر به‌طور محسوس به تصویر آسیب می‌زند.
اگر قرار است ویدئو بایگانی شود، دوباره ویرایش شود یا منبع رمزگذاری‌های بعدی باشد، یک نسخه اصلیِ باکیفیت را جدا از نسخه فشرده مخصوص ارائه نگه دارید.
11. چرا از پیش‌تنظیم veryslow در x264 استفاده کردم؟
CRF یکی از جنبه‌های کیفیت فشرده‌سازی را کنترل می‌کند، اما پیش‌تنظیم x264 تعیین می‌کند رمزگذار چه میزان تلاش صرف یافتن تصمیم‌های رمزگذاری کارآمد کند.
x264 پیش‌تنظیم‌هایی از بسیار سریع تا بسیار کند دارد. به‌طور کلی، پیش‌تنظیم‌های کندتر زمان CPU بیشتری مصرف می‌کنند و ممکن است در کیفیت بصری مشابه، بازده فشرده‌سازی بهتری داشته باشند.
پیش‌تنظیم‌های medium و veryslow را روی یک منبع یکسان مقایسه کردم. در سطح کیفیت آزمایش‌شده، veryslow فایل کوچک‌تری تولید کرد.
برای رمزگذاری آفلاینی که یک‌بار انجام می‌شود و خروجی آن بارها استفاده خواهد شد، زمان پردازش بیشتر می‌تواند ارزشمند باشد.
به همین دلیل -preset veryslow را انتخاب کردم.
بااین‌حال، این تنظیم همیشه بهینه نیست. اگر ویدئوها باید فوری پردازش شوند، منابع CPU گران باشند یا صف بسیار بزرگی از کارها وجود داشته باشد، slow یا medium ممکن است تعادل عملیاتی بهتری فراهم کنند.
پیش‌تنظیم عمدتاً پیچیدگی رمزگذاری و بازده فشرده‌سازی را تغییر می‌دهد. این تنظیم H.264 را به کدکی دیگر تبدیل نمی‌کند و ذاتاً فایل خروجی را با گوشی‌ها ناسازگار نمی‌سازد.
12. برای ویدئوی انیمه از تنظیم animation در x264 استفاده می‌کنم
وقتی منبع شامل انیمیشن طراحی‌شده یا تصاویر به سبک انیمه باشد، همراه x264 از -tune animation استفاده می‌کنم.
این تنظیم با CRF متفاوت است. گزینه tune برخی تصمیم‌های رمزگذار را متناسب با ویژگی‌های بصری خاص تغییر می‌دهد. تنظیم animation برای محتوایی با لبه‌های طراحی‌شده، بخش‌های رنگی یکدست و حرکت سبک‌پردازی‌شده در نظر گرفته شده است.
بنابراین ترجیح من این است:
- انیمه یا انیمیشن طراحی‌شده:
-preset veryslow -tune animation. - تصاویر زنده معمولی: تنظیم animation را خودکار فعال نکنید؛ با تنظیمات پیش‌فرض رمزگذار شروع کنید یا گزینه tune مناسب را جداگانه بسنجید.
مهم است کارکرد این گزینه را اشتباه نفهمیم. -tune animation تضمین نمی‌کند کیفیت به‌شکل محسوسی بهتر شود یا فایل‌ها کوچک‌تر شوند. این گزینه رفتار رمزگذار را تغییر می‌دهد و نتیجه به محتوای ویدئو بستگی دارد.
مقایسه جداگانه‌ای با CRF ثابت و تنظیم animation انجام دادم. در همان مقایسه خاص، فعال‌کردن این تنظیم حجم فایل خروجی را حدود 6% بیشتر کرد و شباهت اندازه‌گیری‌شده تصویر را اندکی بهبود داد. تفاوت بصری کوچک بود.
مقایسه اصلی حجم فایل‌ها با CRFهای 22 تا 32 بدون تنظیم animation انجام شد. بنابراین نباید فرض کرد حجم‌ها و نسبت‌های دقیق فشرده‌سازی آن آزمایش پس از فعال‌کردن -tune animation هم یکسان می‌مانند.
بااین‌حال، برای ویدئوهای انیمه ترجیح می‌دهم از تنظیم مخصوص انیمیشن استفاده کنم و حجم و کیفیت حاصل را به‌عنوان بخشی از پروفایل رمزگذاری همان محتوا ارزیابی کنم.
تنظیم اختصاصی رمزگذار را باید همیشه تغییری وابسته به محتوا دانست، نه ارتقایی همگانی برای کیفیت.
13. تنظیمات پیشنهادی FFmpeg من برای ویدئوهای کوتاه انیمه مخصوص موبایل
برای یک ویدئوی معمولی انیمه با دامنه دینامیکی استاندارد SDR که واقعاً به تبدیل کدک نیاز دارد، دستور زیر نمایانگر پروفایلی است که به‌عنوان نقطه شروع استفاده می‌کنم:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4این دستور انتخاب‌های اصلی را روشن می‌کند:
-c:v libx264از رمزگذار نرم‌افزاری H.264 استفاده می‌کند.-preset veryslowبازده فشرده‌سازی را بر سرعت رمزگذاری مقدم می‌داند.-tune animationتنظیمات مختص انیمیشن را فعال می‌کند.-crf 30هدف کیفیت ثابت با فشرده‌سازی تهاجمی انتخاب‌شده برای این نوع ویدئوی کوتاه را اعمال می‌کند.-profile:v highپروفایل H.264 با پشتیبانی رایج در دستگاه‌های جدید را انتخاب می‌کند.-pix_fmt yuv420pویدئوی 8 بیتی با نمونه‌برداری رنگی 4:2:0 تولید می‌کند.-map 0:v:0نخستین جریان ویدئو را انتخاب می‌کند.-map '0:a:0?'نخستین جریان صدا را در صورت وجود انتخاب می‌کند.-c:a aac -b:a 128kاگر صدا وجود داشته باشد، آن را با AAC متداول رمزگذاری می‌کند.-movflags +faststartفراداده آغازین MP4 را به ابتدای فایل منتقل می‌کند.
این فقط یک نمونه است، نه دستوری همگانی برای همه ورودی‌ها. نیازهای دقیق ویدئوی منبع ممکن است رسیدگی بیشتری بخواهند.
به‌ویژه محتوای HDR و 10 بیتی را نباید بدون مدیریت درست رنگ، کورکورانه به SDR با عمق 8 بیت تبدیل کرد؛ زیرا ممکن است رنگ‌ها نادرست شوند، جزئیات بخش‌های روشن از بین بروند یا نوارهای قابل‌مشاهده در گرادیان‌ها پدید آیند. فراداده چرخش تصویر، نرخ فریم متغیر، نسبت ابعاد پیکسل، منابع درهم‌بافته، چیدمان‌های صوتی نامعمول و محدودیت‌های ناسازگار وضوح تصویر هم نیاز به توجه دارند.
اگر نرخ فریم و ابعاد منبع از ابتدا مناسب باشند، حفظ آن‌ها معمولاً مقایسه را آسان‌تر می‌کند و از تغییر بی‌دلیل اندازه یا حرکت جلوگیری می‌کند. مگر در صورت ضرورت، نرخ فریم ثابت را به منبعی با نرخ فریم متغیر تحمیل نکنید؛ زیرا تبدیل ممکن است فریم‌ها را تکرار یا حذف کند. اگر اندازه را تغییر می‌دهید، نسبت ابعاد نمایش را حفظ کنید و مطمئن شوید ابعاد با قالب پیکسل 4:2:0 انتخاب‌شده سازگارند. وضوح، نرخ فریم یا سطح H.264 بسیار بالا ممکن است از توان رمزگشایی دستگاه‌های قدیمی فراتر برود؛ بنابراین گاهی برای سازگاری باید آگاهانه وضوح یا نرخ فریم را کاهش داد.
14. نقطه شروع محافظه‌کارانه‌تر FFmpeg برای ویدئوی باکیفیت
اگر وفاداری ویدئو به منبع بسیار مهم‌تر از حجم فایل است، با CRF پایین‌تر شروع کنید و خروجی را بسنجید.
برای مثال، دستور زیر نقطه شروع آزمایشی معقولی برای ویدئوی زنده متداول با SDR است:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4پیش‌تنظیم slow در این مثال صرفاً نقطه شروع عمومی و کاربردی است، نه ادعایی مبنی بر بهتر بودن آن از veryslow. اگر زمان رمزگذاری اضافه پذیرفتنی باشد، استفاده از veryslow هم منطقی است.
این پروفایل باکیفیت پیشنهادی برای آزمایش است، نه تنظیمی که آزمایش من روی ویدئوی کوتاه آن را اثبات کرده باشد.
برای ویدئوی ممتاز، مقادیر CRF نزدیک 18، 20 و 22 را بیازمایید و سپس براساس نتیجه‌ای که می‌بینید انتخاب کنید. دانه‌بندی یا حرکت دشوار شاید تنظیمات متفاوتی بخواهد و نسخه‌های اصلی آرشیوی ممکن است به فشرده‌سازی بسیار محافظه‌کارانه‌تری نیاز داشته باشند.
15. ویدئو را بی‌دلیل دوباره رمزگذاری نکنید
فشرده‌سازی اتلافی ویدئو بدون هزینه نیست. رمزگذاری دوباره فایل فشرده‌شده می‌تواند عیب‌های تازه‌ای ایجاد کند، حتی وقتی خروجی شبیه منبع به نظر می‌رسد.
پیش از تبدیل کدک، بررسی کنید آیا فایل اصلی همین حالا نیازهای سازگاری، حجم و کیفیت شما را برآورده می‌کند یا نه.
اگر فایل از قبل ویدئوی سازگار H.264 و صدای AAC دارد و هیچ تغییر تصویری لازم نیست، کپی مستقیم جریان‌ها ممکن است بهتر از یک رمزگذاری اتلافی دیگر باشد.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4این عملیات جریان‌های فشرده‌شده را بدون رمزگذاری دوباره کپی می‌کند. می‌تواند چیدمان ظرف را تغییر دهد و درعین‌حال از یک مرحله دیگر افت کیفیت ناشی از فشرده‌سازی جلوگیری کند.
این روش معمولاً مانند کاهش کیفیت از طریق رمزگذاری دوباره، حجم فایل را کم نمی‌کند.
اگر ویدئوی موجود از قبل کم‌حجم، سازگار و از نظر بصری قابل‌قبول است، شاید بهترین بهینه‌سازی همان حفظ فایل فعلی باشد.
16. به‌جای اعتماد به حجم فایل، ویدئوهای رمزگذاری‌شده را اعتبارسنجی کنید
خروج موفق FFmpeg به‌تنهایی ثابت نمی‌کند ویدئو همه شرایط را برآورده کرده است.
ابتدا جریان‌های خروجی را با FFprobe بررسی کنید:
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4کدک، قالب پیکسل، ابعاد، نرخ فریم، مدت و جریان‌های صدا را کنترل کنید.
سپس کل خروجی را رمزگشایی کنید تا برخی خرابی‌ها یا خطاهای رمزگشایی شناسایی شوند:
ffmpeg -v error -xerror -i output.mp4 -f null -در آزمایش‌های فشرده‌سازی، خروجی‌های ساخته‌شده از منبع یکسان را مقایسه کنید. متغیرهای مهم را ثابت نگه دارید و هر بار فقط یک تنظیم اصلی را تغییر دهید.
ویدئوی خروجی را در حال حرکت تماشا کنید، جزئیات ظریف را بررسی کنید و به گرادیان‌ها، بخش‌های تاریک، اجسام متحرک و متن توجه کنید.
در صورت امکان، از معیارهای عینی مانند SSIM، PSNR یا VMAF برای تکمیل مقایسه‌های بصری استفاده کنید. یک امتیاز بالا را دلیل نامرئی بودن همه عیب‌ها ندانید.
در پایان، ویدئو را روی دستگاه‌های نماینده و در شرایط کار با فایل دانلودشده امتحان کنید. اطلاعات پشتیبانی مرورگرها ارزشمند است، اما وقتی سازگاری هدف اصلی باشد، آزمون پخش واقعی اهمیت ویژه‌ای دارد.
17. مطمئن شوید فایل‌های MP4 به‌درستی به کاربر تحویل داده می‌شوند
تنظیمات خوب رمزگذاری نمی‌توانند ضعف در ارائه ویدئو از طریق وب را جبران کنند.
برای پخش تدریجی معمول MP4، سربرگ درست Content-Type: video/mp4 را تنظیم کنید و در مواردی که دریافت بخشی از فایل یا جابه‌جایی در ویدئو لازم است، از درخواست‌های بازه بایتی HTTP پشتیبانی کنید.
گزینه +faststart در FFmpeg اطلاعات آغازین MP4 را به ابتدای یک فایل معمولی منتقل می‌کند. این کار به بارگذاری تدریجی کمک می‌کند، اما کیفیت تصویر را بهتر یا نرخ بیت را کمتر نمی‌کند.
یک عنصر ساده ویدئو در HTML می‌تواند یک فایل MP4 با H.264 ارائه کند:
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>ویژگی preload فقط راهنمایی برای مرورگر است، نه محدودیتی قطعی برای دانلود. سیاست‌های پخش خودکار مرورگر نیز ممکن است نیاز داشته باشند ویدئو بی‌صدا باشد یا صدایش قطع شده باشد.
اگر صفحه چند ویدئو دارد، از دانلود فوری همه آن‌ها خودداری کنید. بارگذاری ویدئوها فقط هنگام نیاز می‌تواند مصرف اینترنت موبایل را کاهش دهد و سرعت پاسخ‌گویی ادراک‌شده را بهتر کند.
برای کلیپ‌های کوتاه موبایل، بهینه‌سازی زمان‌بندی دانلود می‌تواند به‌اندازه کاهش حجم فایل رمزگذاری‌شده اهمیت داشته باشد.
18. کدام قالب و سطح کیفیت ویدئو را انتخاب کنیم؟
پاسخ درست به چیزی بستگی دارد که می‌خواهید بهینه کنید.
| هدف شما | نقطه شروع پیشنهادی |
|---|---|
| یک فایل با سازگاری گسترده برای وب و دانلود | MP4 + H.264 + AAC در صورت وجود صدا |
| ارائه در مرورگرهای جدید با چند گزینه قالب | AV1 یا VP9 همراه نسخه جایگزین H.264 |
| بیشترین فشرده‌سازی در دستگاه‌های پشتیبانی‌شده | AV1 را ارزیابی کنید |
| محیط پخش کنترل‌شده و سازگار با HEVC | MP4 + HEVC را در نظر بگیرید |
| کلیپ کوتاه موبایل که حجم فایل در آن مهم‌تر است | پس از آزمایش نمونه‌های نماینده، x264 CRF 30 را در نظر بگیرید |
| انیمه یا انیمیشن طراحی‌شده | x264 را همراه -tune animation ارزیابی کنید |
| فیلم‌های باکیفیت یا ویدئوی ممتاز | با CRF محافظه‌کارانه‌تر نزدیک 20 شروع کنید و بیازمایید |
| رمزگذاری آفلاین که زمان CPU کمتر اهمیت دارد | x264 با slow یا veryslow را در نظر بگیرید |
| پردازش سریع با منابع محدود CPU | x264 با medium یا slow را در نظر بگیرید |
| ویدئوی موجود از قبل شرایط را برآورده می‌کند | آن را نگه دارید یا بدون رمزگذاری دوباره ظرفش را عوض کنید |
| بایگانی یا ویرایش آینده | نسخه اصلی باکیفیت را جدا از فایل‌های مخصوص ارائه نگه دارید |
19. تصمیم نهایی من و آنچه آزمایش واقعاً ثابت کرد
پس از بررسی قالب‌ها، سازگاری، بازده رمزگذاری و نتایج واقعی فشرده‌سازی، یک پروفایل کاربردی برای ارائه ویدئوهای کوتاه مخصوص موبایل انتخاب کردم.
قالب انتخابی MP4 با H.264 بود؛ چون سازگاری قابل‌پیش‌بینی در مرورگرها، گوشی‌ها، فایل‌های دانلودی و برنامه‌های دیگر برایم مهم‌تر از رسیدن به کوچک‌ترین فایل ممکن با کدکی جدیدتر بود.
رمزگذار انتخابی libx264 با پیش‌تنظیم veryslow بود؛ زیرا امکان رمزگذاری آفلاین وجود داشت و زمان پردازش اضافه پذیرفتنی بود.
برای ویدئوی انیمه از تنظیم animation استفاده می‌کنم، با این آگاهی که رفتار رمزگذار را تغییر می‌دهد و تضمینی برای فایل کوچک‌تر یا نتیجه تصویری بهتر در همه موارد نیست.
برای ویدئوهای کوتاه مخصوص موبایل CRF 30 را انتخاب کردم؛ چون مقایسه من کاهش چشمگیر حجم فایل را بدون تفاوت بصری معنادار در پخش معمولی نشان داد، حتی زمانی که خروجی را روی نمایشگر بزرگ دسکتاپ می‌دیدم.
این نتیجه به‌معنای ایدئال بودن CRF 30 برای فیلم یا تصاویر باکیفیت نیست. برای محتوایی که جزئیات ریز، گرادیان‌ها، دانه‌بندی و وفاداری کلی به منبع مهم‌ترند، آزمایش را نزدیک CRF 20 یا مقدار محافظه‌کارانه مناسب دیگری آغاز می‌کنم. من مطالعه کنترل‌شده مشابهی روی تصاویر سینمایی انجام نداده‌ام، بنابراین آن عدد را مقدار بهینه اثبات‌شده در آزمایش معرفی نمی‌کنم.
مهم‌ترین نتیجه این است که هیچ کدک، قالب یا مقدار CRF واحدی وجود ندارد که برای همه ویدئوها بهترین باشد.
اگر بیشترین سازگاری را می‌خواهید و فقط یک فایل لازم دارید، MP4/H.264 انتخاب پیش‌فرض محکمی است. اگر می‌توانید قالب‌های جایگزین ارائه دهید و به‌دنبال فشرده‌سازی بهتر هستید، VP9 و AV1 را بررسی کنید. اگر ویدئوهای کوتاهی رمزگذاری می‌کنید که عمدتاً روی گوشی دیده می‌شوند، آزمایش کنید آیا CRF بالاتر فایل‌های به‌اندازه کافی کوچک و درعین‌حال بدون لطمه به تجربه تماشای مدنظر تولید می‌کند یا نه. برای فیلم‌ها یا تصاویر ممتاز، تنظیمات کیفیت محافظه‌کارانه‌تری به کار ببرید و آن‌ها را دقیق بررسی کنید.
ابتدا نیازهای پخش را مشخص کنید، سپس کدک را انتخاب کنید و در آخر کیفیت فشرده‌سازی را تعیین کنید. نتیجه را روی دستگاه‌ها و در شرایطی که واقعاً اهمیت دارند بیازمایید. این روش از پذیرفتن کورکورانه یک کدک یا مقدار CRF صرفاً به‌دلیل جدیدتر، کارآمدتر یا پرطرفدارتر بودن آن قابل‌اعتمادتر است.