LPX

Бітрейт відео: як оцінити якість, розмір і трафік

Коротка відповідь

Як bitrate, codec, fps і складність сцени формують відео. Калькулятор рахує payload, decimal GB, binary GiB та трафік без міфу «4K = якість».

Зміст статтізгорнути ▾
  1. Bitrate — бюджет даних у часі
  2. Чому 4K не дорівнює кращому зображенню
  3. Playback chain теж має значення
  4. Калькулятор розміру файлу й сукупного трафіку
  5. CBR, VBR і два значення ABR
  6. Export, platform upload і live мають різні обмеження
  7. Як перевірити encode без вигаданого «кращого bitrate»
  8. Рішення за симптомом
  9. Підсумок
  10. Зворотний розрахунок: який average bitrate поміститься в ліміт
  11. Кілька audio tracks, subtitles і thumbnails
  12. Чому «новіший codec» не є автоматичною перемогою
  13. Сценарії, де однаковий потік розподіляється по-різному
  14. Джерела

Бітрейт відео: як оцінити якість, розмір і трафік

Коротка відповідь: bitrate показує, скільки бітів за секунду виділено відео або всьому медіапотоку, але сам не є оцінкою якості. Однакові 8 Mbit/s дадуть різний результат для статичної лекції й конфеті, 24 і 60 fps, H.264 та AV1, швидкого й повільного encoder preset. Для розміру складіть video й audio bitrate, помножте на секунди та поділіть на 8. Контейнер, metadata і streaming overhead рахуйте окремо. 4K означає більше пікселів у кадрі, а не гарантію збережених деталей.

Bitrate — бюджет даних у часі

Позначення 8 Mbit/s означає приблизно вісім мільйонів бітів за секунду за десятковим префіксом. У media tools частіше бачимо kbit/s або Mbit/s, тоді як розмір накопичувача вказано bytes. Вісім бітів утворюють byte, тому без цього ділення оцінка файлу буде завищена у вісім разів. Не плутайте Mbit/s із MB/s.

У VBR миттєвий потік змінюється: простий кадр може отримати менше, складний — більше. Для тривалого файлу розмір визначає фактичний average bitrate, а не один peak зі статистики. Якщо застосунок показує bitrate контейнера, у число можуть входити audio, subtitles та службові дані; поле video bitrate описує лише відеотрек.

Контейнер MP4 або Matroska організовує треки, timestamps, indexes і metadata. Codec визначає представлення стисненого зображення, а encoder реалізує рішення про prediction, transforms, quantization і пошук. Розширення .mp4 не каже, чи video всередині закодовано AVC, HEVC або AV1, і не дозволяє вгадати якість.

Чому 4K не дорівнює кращому зображенню

Resolution описує сітку пікселів. Якщо source був м’яким, розфокусованим, зашумленим або вже містив blocking, upscale до 3840×2160 лише створить більше samples із тією самою обмеженою інформацією. Надто агресивне стиснення 4K може стирати текстури й рух гірше, ніж акуратний encode меншої resolution.

Frame rate збільшує кількість зображень на секунду. За незмінного bitrate 60 fps ділить бюджет між більшою кількістю кадрів, хоча temporal prediction може повторно використовувати дані. Спорт, gameplay із швидким camera pan, вода, трава, зерно й частинки важчі для компресії, ніж нерухомий presenter на чистому фоні. Саме content complexity пояснює, чому одна таблиця bitrate не підходить усім роликам.

HDR та bit depth — інші осі. Щоб відрізнити HDR від самої роздільної здатності, перевірте transfer function, colour primaries, bit depth і metadata. Неправильна colour conversion може зіпсувати картинку незалежно від bitrate. Збільшення потоку не виправить clipped highlights або помилковий range.

Codec і encoder version визначають набір інструментів та якість їх використання. Повільніший preset часто витрачає більше обчислень, щоб ефективніше розподілити bits, але приріст не універсальний. Hardware encoder може бути потрібним для realtime, software — для контрольованого offline export. Порівнювати їх треба на тому самому source, однаковій resolution/fps і за фактичним output.

Що формує якість стисненого відео
Ілюстративна схема: bitrate працює разом із source, resolution, frame rate, codec, encoder і складністю сцени.

Playback chain теж має значення

Навіть добрий файл може виглядати слабко через adaptive downgrade, неправильний display mode, chroma conversion або масштабування. Спочатку підтвердьте, яке representation реально відтворюється, а потім зіставте відеосигнал із можливостями телевізора. Label «4K» у каталозі не показує поточний network variant.

Відстань перегляду й розмір екрана змінюють помітність spatial detail, але стаття не задає вигаданого порогу «людина не бачить». Артефакти banding, ringing, blocking і smearing залежать від сцени й display processing. Оцінюйте власний delivery target на потрібному пристрої, а не лише на preview encoder.

Калькулятор розміру файлу й сукупного трафіку

Формула використовує середні video та audio bitrate. Спершу T = V + A у kbit/s. Далі payload_bytes = T × 1000 × minutes × 60 ÷ 8. Для кількох копій або повних переглядів помножте bytes на count. User overhead застосовується наприкінці як × (1 + O/100). Decimal GB дорівнює 1,000,000,000 bytes, binary GiB — 1,073,741,824 bytes.

Overhead не має універсального відсотка: він залежить від контейнера, кількості треків, segmentation, manifests, encryption і delivery. Значення 2% у прикладі — змінне припущення, яке користувач може поставити 0. Калькулятор не прогнозує cache hit, partial viewing, retransmissions або те, як ABR client перемикатиме representations.

Розрахувати payload, GB і GiB

Контрольний приклад без прихованого коефіцієнта

Введіть 8000 kbit/s video, 192 kbit/s audio, 60 хв, одну копію та 2%. Сумарно виходить 8192 kbit/s. За годину payload становить 3,686,400,000 bytes; після введеного overhead — 3,760,128,000 bytes. Це 3.76 GB у десятковому позначенні або приблизно 3.50 GiB у двійковому.

Для ста повних передач count=100 дає 376.01 GB або близько 350.19 GiB за тим самим припущенням. Реальний CDN bill може рахувати decimal GB, requests, regional egress або cache по-своєму. Для особистого архіву після розрахунку доречно оцінити модель зберігання у хмарі, включно з синхронізацією та резервною копією.

Формула місця й трафіку
Ілюстративна схема: decimal GB та binary GiB — різні одиниці; overhead задає користувач.

CBR, VBR і два значення ABR

CBR прагне тримати rate близько заданого рівня, що корисно для каналу з передбачуваним budget або live ingest. Але «constant» не означає абсолютно однакову кількість bits у кожній мілісекунді: encoder працює з buffer model і windows. Занадто малий buffer обмежує свободу на складній сцені; занадто агресивні параметри можуть порушити вимоги приймача.

VBR перерозподіляє budget: прості інтервали беруть менше, складні — більше. One-pass VBR приймає рішення без повного знання майбутнього; two-pass спочатку аналізує source, потім розподіляє average target. Two-pass не робить поганий source добрим і не є обов’язковим для constant-quality workflow.

Average bitrate encode часто скорочують ABR у encoder UI. У streaming ABR зазвичай означає adaptive bitrate: сервер пропонує ladder окремих renditions, а player переходить між ними за bandwidth, buffer та device conditions. Це принципово різні речі. У статті слово ABR завжди супроводжується контекстом.

Export, platform upload і live мають різні обмеження

Майстер-файл або локальний архів

Якщо першочергове збереження деталей, constant-quality mode часто природніший за target filesize: encoder витрачає стільки bits, скільки вимагає вибрана quality setting. Кінцевий розмір тоді невідомий до завершення. Для архіву не видаляйте source після одного compressed export; монтажний mezzanine та delivery copy виконують різні ролі.

Якщо накопичувач або канал має жорстку межу, average bitrate дає прогнозованіший розмір. Вирахуйте доступний total bitrate з bytes і duration, відніміть audio, залиште overhead, а потім зробіть test encode найскладнішого фрагмента. Не визначайте весь проєкт за спокійним intro: фінальний концерт або grainy night scene може вимагати інший компроміс.

Завантаження на платформу

Платформа зазвичай перекодовує ingest у власні representations. Її рекомендований upload bitrate — вимога до вхідного master, а не обіцянка playback rate або perceptual score. YouTube, наприклад, розділяє таблиці за resolution, frame rate та SDR/HDR; ці значення треба повторно звіряти в офіційній довідці, а не копіювати як стандарт відео.

Не варто навмисно upscale слабкий 1080p лише заради label, якщо це не частина контрольованого workflow. Платформа все одно не відновить втрачену texture. Після технічної підготовки можна перейти до українського контенту на YouTube, але редакційний вибір теми не залежить від encoder settings.

Live encoder

У live немає другого проходу й часу на довгий offline preset. Video + audio bitrate, protocol overhead і retransmission behavior мають поміщатися в стабільний uplink із запасом для fluctuations. Перед ефіром треба виміряти стабільну швидкість upload кабелем у той самий час доби, а не брати рекламний maximum тарифу.

Якщо інші клієнти заповнюють uplink backup або camera upload, encoder queue росте й frames можуть drop. Тоді корисно керувати конкуренцією за домашній канал, але shaping не створить відсутню ISP capacity. Спочатку знизьте ingest rate або resolution/fps до стабільного режиму, а потім налаштовуйте queue policy.

ABR playback ladder

Ladder містить кілька узгоджених renditions з окремими resolutions/bitrates. Player обирає variant за throughput estimate, buffer і декодером. Один «4K stream» може тимчасово перейти на нижче representation, тому network problem іноді маскується як м’яка картинка без явної паузи. Інтерактивний cloud stream особливо чутливий до latency; матеріал про вплив мережі на хмарний геймінг розкриває іншу сторону цього delivery.

Три різні задачі bitrate
Ілюстративне порівняння: export, live ingest і ABR delivery мають різні обмеження.

Як перевірити encode без вигаданого «кращого bitrate»

  1. Зафіксуйте source. Resolution, fps, scan, colour, audio й duration мають бути відомі.
  2. Назвіть delivery. Local archive, platform upload, live ingest або ABR rendition мають різні constraints.
  3. Змініть одну змінну. Порівнюйте bitrate або preset, не одночасно codec, scaling і denoise.
  4. Візьміть складні сцени. Рух, grain, gradients, titles і darkness виявляють різні артефакти.
  5. Перевірте target device. Hardware decode, HDR mode й network variant можуть змінити результат.
  6. Запишіть size й runtime. Encode time та compatibility є частиною компромісу.

Pixel peeping одного кадру не показує temporal pumping, motion smear або seek behavior. Дивіться фрагмент у русі, перевіряйте audio sync і точку scene cut. Для критичного матеріалу зробіть кілька коротких encodes та blind A/B, приховавши назви файлів. Це не створює універсальний perceptual threshold, зате відповідає вашому source і display.

Перекодування вже стисненого файлу накопичує втрати. Якщо потрібен інший delivery format, повертайтеся до найкращого доступного master, а не до завантаженої копії платформи. Denoise може полегшити compression, але також стерти texture; його оцінюють як творче втручання, не як безкоштовну економію bitrate.

Рішення за симптомом

Файл завеликий: перевірте, чи показане число належить video або container total, потім зменште average target, duration, audio tracks або resolution/fps за потреби. Картинка сиплеться в русі: дайте encoder більше budget, повільніший придатний preset або менш складний output; не підвищуйте 4K label. Live dropped frames: локалізуйте uplink congestion і buffer, а не тільки quality preset.

На платформі гірше, ніж локально: дочекайтеся завершення всіх renditions, перевірте поточне playback representation й official ingest guidance. На одному TV немає HDR: дослідіть весь signal chain, EDID, app і mode. Bitrate може бути достатнім, але невідповідний codec/profile або colour metadata зупинить правильне відтворення.

Підсумок

Зворотний розрахунок: який average bitrate поміститься в ліміт

Коли відомі maximum file bytes і duration, формулу можна розвернути. Від доступних bytes спершу відніміть або зарезервуйте container overhead, потім помножте на вісім і поділіть на seconds. Отриманий total bitrate включає всі tracks. Після віднімання audio та інших постійних потоків залишається video budget. Якщо ліміт задано в GiB, спочатку множте його на 1,073,741,824, а для GB — на 1,000,000,000.

Приклад: 2.00 GB для 30 хв без заданого overhead дає приблизно 8.89 Mbit/s total. Audio 192 kbit/s залишає близько 8.70 Mbit/s для video. Це арифметична межа, а не рекомендація якості. Якщо container і metadata мають увійти в ті самі 2 GB, зарезервуйте їх до обчислення; якщо платформа має власний cap, звірте, чи він decimal.

Кілька audio tracks, subtitles і thumbnails

Друга звукова доріжка додає свій average bitrate протягом усієї duration. Дві доріжки по 192 kbit/s — не одна 192 kbit/s. Lossless audio може стати помітною частиною total у відео з низьким потоком. Subtitles зазвичай менші, але їхній формат, fonts і bitmap captions змінюють розмір. Chapter images, preview thumbnails та attachments також не входять у просту суму video+audio.

У streaming одна мова може передаватися лише обраному viewer, а manifests описують доступні alternatives. Тому storage суми всіх renditions і traffic конкретної сесії — різні величини. Для архіву складіть bytes усіх збережених tracks; для delivery змоделюйте, які segments і audio реально отримає один client.

Чому «новіший codec» не є автоматичною перемогою

Ефективніший bitstream toolset може зберегти більше деталей за схожого size, але encode speed, decode power, licensing, browser support і hardware acceleration впливають на рішення. Старий телевізор може відтворити AVC без проблем і не декодувати вибраний AV1 profile. Тоді менший файл не завершує задачу користувача.

Для міграції створіть compatibility matrix: target OS/browser/TV, maximum resolution/fps, bit depth, chroma, audio codec і container. Перевірте hardware decode на реальному пристрої, CPU load і seek. Якщо потрібні дві delivery copies, savings одного codec порівнюються з додатковим storage та operational complexity.

Сценарії, де однаковий потік розподіляється по-різному

Запис презентації

Нерухомі слайди добре передбачаються, але дрібний текст карає scaling і chroma subsampling. Замість механічного підвищення bitrate перевірте native capture resolution, sharp text і відсутність повторного resize. Відео presenter може займати окрему малу область, тоді як slides потребують чистих edges.

Концерт у темному залі

Sensor noise, lights, smoke й camera movement створюють постійну непередбачувану texture. Denoise зменшить entropy, але може зробити обличчя пластиковими. Тестуйте короткий фрагмент із найважчим світлом і не визначайте bitrate за денним backstage.

Запис екрана гри

HUD і текст вимагають spatial precision, а швидкі рухи — temporal budget. 60 fps може бути функціонально потрібним, тому зменшення до 30 fps не завжди прийнятне. Якщо channel cap фіксований, порівняйте lower resolution із чистішими edges проти 4K зі smearing на motion.

Сімейний архів

Тут важливі довгострокова сумісність, metadata і резервні копії. Delivery copy для телефона не повинна замінювати original camera file. Розрахуйте сумарні GiB, закладіть кілька незалежних копій і збережіть checksum; bitrate калькулятор оцінює media payload, але не redundancy policy.

Bitrate — це вимірюваний data budget, а якість — результат source, codec, encoder, resolution, fps, colour і складності сцени. Рахуйте bytes математично, називайте GB та GiB окремо й задавайте overhead явно. Для якості робіть короткі контрольовані encodes на важких фрагментах.

4K корисний, коли source має деталі, delivery їх зберігає, а display відтворює. Якщо бюджет затісний або source слабкий, більше пікселів лише розподіляють ті самі обмежені bits. Вибирайте параметри під workflow, а не під універсальну цифру з чужої таблиці.

Джерела

ОМ
Олег Марченко
Редактор LPX

Пише про домашній інтернет і техніку з 2014 року. Всі поради перевіряє на власній двокімнатній квартирі з бетонними стінами.

Всі статті автора →