Бітова швидкість або ширина відеопотоку (для цифрового відео)
Ширина (або швидкість) відеопотоку вимірюється в бітре́йтах (англ. bit rate) — це кількість оброблюваних бітів відеоінформації за секунду часу, позначається «біт/с» — бітів на секунду. В основному застосовуються величини кбіт/с (англ. kbit/s) - кілобіти в сек. та мбіт/с (англ. mbit/s) — мегабіти в секунду. Чим вище ширина відеопотоку, тим, загалом, краща якість відео. Наприклад, для формату VideoCD ширина відеопотоку складає приблизно 1 мбіт/с, а для DVD складає приблизно 5 мбіт/с. Хоча суб'єктивно різницю в якості не можна оцінити як п'ятикратну, але об'єктивно це так. Формат цифрового телебачення HDTV використовує ширину відеопотоку біля 10 мбіт/с. За допомогою швидкості відеопотоку також дуже зручно оцінювати якість відео при його передачі через Інтернет.
Розрізняють два види керування шириною потоку в відеокодеку — постійний бітрейт (англ. constant bit rate, CBR) і змінний бітрейт (англ. variable bit rate, VBR). Концепція VBR, нині дуже популярна, покликана максимально зберегти якість відео, зменшуючи при цьому сумарний обсяг переданого відеопотоку. При цьому на швидких сценах руху, ширина відеопотоку зростає, а на повільних сценах, де картинка змінюється повільно, ширина потоку падає. Це дуже зручно для буферизованих відеотрансляцій і передачі збереженого відеоматеріалу по комп'ютерних мережах. Проте для безбуферних систем реального часу й для прямого ефіру (наприклад, для телеконференцій) необхідно використовувати постійну швидкість відеопотоку.
Оцінка якості відео
Якість відео виміряється за допомогою формальних метрик, таких, як PSNR або SSI, або з використанням суб'єктивного порівняння із залученням експертів.
Суб'єктивна якість відео виміряється за наступною методикою:
Вибираються відеопослідовності для використання в тесті
Вибираються параметри системи вимірювання
Вибирається метод показу відео й підрахунку результатів виміру
Запрошується необхідне число експертів (звичайно не менше 15)
Проводиться сам тест
Підраховується середня оцінка на основі оцінок експертів.
Кілька методів суб'єктивної оцінки описані в рекомендаціях ITU-T BT.500. Один із широко використовуваних методів оцінки — це DSIS (англ. Double Stimulus Impairment Scale), при якому експертам спочатку показують вихідний відеоматеріал, а потім оброблений. Потім експерти оцінюють якість обробки, варіюючи свої оцінки від «обробка непомітна» і «обробка поліпшує відеозображення» до «оброблений відеоматеріал сильно дратує».
Лекція 2 Стиснення відео
Йдуть дні, вимоги до якості відео постійно зростають. При цьому ширина каналів і ємність носіїв не могла б встигати за цим зростанням, якби не вдосконалювалися алгоритми стиснення відео.
Далі піде мова саме про деякі базові поняття стиснення відео.
Пошук векторів руху для компенсації руху (-: Про це далі ...)
Характеристики відеопотоку
Практично всі знають, що будь-яке відео - це безліч статичних картинок, які змінять одне одного в часі. Далі цю впорядковану множину ми будемо називати відеопотоком. Вони бувають різними, тому тут вкрай корисно провести невелику класифікацію:
Формат пікселя. Піксель не дає нам ніякої інформації крім його кольору. Однак сприйняття кольору сильно суб'єктивне і було докладено багато зусиль для створення систем кольоропредставлення і передачі кольору, які були б прийнятні для більшості людей. Так колір, видимий нами в реальному світі, є досить складним по спектру частот світла, та передати його в цифровому вигляді вкрай складно, а відобразити ще складніше. Однак було відмічено, що трьома точками в спектрі можна досить точно наблизити колір до сприйняття кольору звичайною людиною. Ці три точки: червоний, зелений і синій. Тобто їх лінійної комбінацією ми можемо покрити більшу частину видимого спектру кольорів. Тому найпростіший спосіб представлення пікселя: RGB24, де під компоненти Red, Green і Blue відводиться рівно по 8 біт інформації. І так ми можемо передати 256 градацій кожного кольору і всього 16,777,216 всіляких відтінків. Але на практиці при зберіганні таке практично не використовується, не тільки тому що ми витрачаємо цілих 3 байти на піксель, а й з інших причин, але про це пізніше (про YV12).
Розмір кадру. Ми вже взяли і закодували всі пікселі відеопотоку і отримали величезний масив даних, але він незручний в роботі. Спочатку все дуже просто, кадр характеризується: шириною, висотою, розмірами видимої частини та форматом (про це трохи пізніше). Тут напевно багатьом здадуться знайомими цифри: 640x480, 720x480, 720x576, 1280x720, 1920x1080. Чому? Та тому що, вони фігурують у різних стандартах, наприклад дозвіл 720x576 має більша частина європейських DVD. Ні, звичайно, можна зробити відео розміром 417x503, але не думаю, що в цьому буде щось хороше.
Формат кадру. Навіть знаючи розміри кадру, ми не можемо уявити масив пікселів в більш зручній формі, не маючи інформації про спосіб "упаковки" кадру. У простому випадку нічого хитрого: беремо рядок пікселів і виписуємо підряд біти кожного закодованого пікселя і так рядок за рядком. Тобто виписуємо стільки рядків, скільки у нас висота по стільки крапок, скільки у нас ширина і все підряд, по порядку. Така розгортка називається прогресивної (Progressive). Але може ви намагалися дивитися телепередачі на комп'ютері без належних налаштувань і бачили "ефект гребінки", це коли один і той же об'єкт знаходиться в різних положеннях щодо парних і непарних рядків. Можна дуже довго сперечатися про доцільність черезрядкової (Interlaced) розгортки, але факт, що вона залишилася як пережиток минулого від традиційного телебачення (кому цікаво почитайте про пристрій кінескопа). Звідси й походять магічні позначення: 576i, 720p, 1080i, 1080p, де вказано кількість рядків (висота кадру) і тип розгортки.
Частота кадрів. Для отримання більш-менш якісного відеозображення «в реальному часі» досить переглядати відеофрагмент зі швидкістю не менше 16 fps. Світовим стандартом в кінематографії є 24 fps. Для відеосистем найбільш поширеними є значення 25 fps для відеостандарту PAL і 30 fps для відеостандарту NTSC.
Глобальні характеристики. Всі вищеописане відноситься до локальних властивостей, тобто тих, які відображаються під час відтворення. Але тривалість відеопотоку за часом, обсяг даних, наявність додаткової інформації, залежності і т.п. Наприклад: відеопотік може містити в собі один потік, який відповідає лівому оці, а інший потік деяким чином буде зберігати інформацію про відмінність потоку правого ока від лівого. Так можна передавати стерео відео або всенародно відоме "3D".
Чому відео потрібно стискати?
Якщо ми будемо передавати відео нестиснутих, то ні на що серйозне нам не вистачить ні каналів зв'язку, ні місця для зберігання даних. Нехай ми маємо HD потік з характеристиками:
1920x1080p, 24 к / с, RGB24 і підрахуємо "вартість" такого потоку.
1920 * 1080 * 24 * 24 = 1139 Мегабіт / с, а якщо захочемо записано 90 хвилинний фільм, то буде потрібно 90 * 60 * 1139 = 750 Гігабайт! Круто? Це при тому, що відео фільму дивовижного якості з тим же 1920x1080p на BluRay буде займати 20 Гб, тобто різниця майже в 40 разів!
Очевидно, що відео вимагає стиснення, особливо враховуючи те, що можна скоротити розмір в 40 і більше разів, залишивши при цьому глядача в захваті.
На чому можна заощадити?
Кодування кольору. Напевно багато хто знає, що колись давно телебачення було чорно-білим, але сьогоднішнє телебачення цілком в кольорі. Але чорно-білий телевізор, як і раніше може показувати передачі. Справа в тому, що в телесигналі яскравість кодується окремо від кольорових складових і представляється у форматі YUV , де Y компонента - це яскравість, а U і V - колірні компоненти і все це обчислюється по "чарівній" формулі:
Y = 0.299 * R + 0.587 * G + 0.114 * B
U = -0.14713 * R - 0.28886 * G + 0.436 * B
V = 0.615 * R - 0.51499 * G - 0.10001 * B
Як видно, перетворення лінійне і невироджене. Отже, ми можемо з легкістю отримувати назад значення R, G і B. Припустимо під зберігання Y, U та V ми виділимо по 8 біт, тоді було 24 біта на піксель і так і залишилося. Ніякої економії. Але людське око чутливе до яскравості, а ось до кольору воно не сильно вибагливе. Та й майже на всіх зображеннях кольори змінюють один одного не так часто. Якщо ми умовно розділимо зображення на шари Y, U та V та шар яскравості залишимо без змін, а шари U і V в два рази скоротимо по висоті і в два рази по ширині і того в чотири рази. Якщо раніше на кожен піксель витрачали 24 біта, то тепер витрачаємо 8 * 4 +8 +8 = 48 біт на 4 пікселі, тобто, грубо кажучи, 12 біт на піксель (саме тому цей формат кодування називається YV12). За рахунок колірного проріджування ми стиснули потік в два рази без особливих втрат. Наприклад, JPEG завжди виконує подібне перетворення, але в порівнянні з іншими можливими артефактами проріджування кольору не несе ніякої шкоди.
Міжкадрова різниця. Напевно, кожен, подивившись будь-яке відео, помітить, що зображення не змінюються різко, а сусідні кадри досить схожі. Звичайно, різкі зміни бувають, але вони зазвичай відбуваються при зміні сцен. І тут виникає проблема: як комп'ютер повинен представляти все те різноманіття можливих перетворень зображення? На допомогу приходить алгоритм компенсації руху.
Компенсація руху
Компенсація руху (англ. Motion Compensation) - один з основних алгоритмів, застосовуваних при обробці і стиску відеоданих. Алгоритм використовує схожість сусідніх кадрів у відео послідовності і знаходить вектори руху окремих частин зображення (зазвичай блоків 16x16 і 8x8). Використання компенсації дозволяє при стисненні багаторазово збільшити ступінь стискування за рахунок видалення надмірності у вигляді співпадаючих частин кадрів. Використовується не тільки при стисненні, а й при фільтрації відео, зміні частоти кадрів і т.д.
Рішення проблеми стиснення стало першочерговим завданням, починаючи з самої появи цифрового відео. Для оцінки візьмемо відеоряд з наступними параметрами:
Розмір кадру: 720x576 (Стандартний розмір для Європейського телебачення (PAL), 414720 пікселів)
Частота кадрів: 25 к / сек (Також стандартно для PAL)
Колірна модель: YV12 (YUV 4:2:0) (16 біт на 4 пікселі + 8 біт на кожен = 12 біт на піксель)
У підсумку на запис або передачу однієї секунди такого відео без застосування стиснення потрібно 14,8 мегабайта без урахування звуку та службової інформації. Для зберігання півторагодинного фільму вже буде потрібно 78 (!) Гігабайт.
Практично в будь-якому відео сусідні кадри схожі, мають спільні об'єкти, які, як правило, зміщуються один щодо одного. І цілком природно бажання закодувати відео так, щоб об'єкти не кодувалися багаторазово, а просто описувалися деякі їх усунення.
Приклад роботи алгоритму
У зв'язку з високою обчислювальною складністю алгоритмів розпізнавання образів і недостатньої точності їх роботи застосовують різні методи, що дозволяють швидко знаходити вектори руху (природно, не без втрат).
1. Завантажується поточний кадр.
2. Кадр ділиться на блоки (наприклад 16x16).
Поділений на блоки кадр
3. Проводиться обхід блоків (кожен блок в даному випадку обробляється окремо).
4. За рахунку одного блоку проводиться обхід деякій околиці блоку в пошуку максимальної відповідності зображенню блоку на попередньому кадрі в межах цієї околиці.
Наочна ілюстрація пошуку: зображений попередній кадр (той в якому проводиться пошук) і три блоки нового кадру, який ми хочемо наблизити фрагментами попереднього
5. Таким чином, після завершення пошуку ми отримуємо набір векторів, який вказує "рух" блоків зображення між кадрами. Ці вектори можуть бути природним чином використані для створення зображення скомпенсованого кадру, який краще наближає кадр для якого здійснювалась компенсація руху.
Тут показаний скомпенсований кадр з векторами руху для кожного блоку (точка - це нульовий вектор)
Різниця до компенсації руху
Різниця між оригіналом і компенсованими кадрами
Як видно, різниця між скомпенсований кадром і поточним значно менше, ніж між нескомпенсованими кадрами
З урахуванням обсягів інформації при стисненні зображень ми можемо зберегти вектора руху майже безкоштовно. Зробили це і потім стиснули зображення скомпенсованою міжкадровою різницею (алгоритмом стиснення статичних зображень). А так як на другій картинці відверте місиво, то алгоритм стиснення зображень повинен коректно з такими речами працювати. У силу великої надлишковості таких зображень вони стискають дуже сильно. Але якщо кодек стискує їх занадто сильно, то й виникає ефект блочності. Старі алгоритми ніяк не враховують зміни об'єктів по яскравості і саме тому по телевізору видно блочность президента при спалахах фотокамер
Проблеми реалізації
Перше питання, яке виникає при написанні алгоритму компенсації руху: "Як оцінювати" схожість "фрагментів зображення?"
Варіантів може бути декілька:
Обчислення SSD (суми квадратичних відхилень). Для пари блоків дає хороші результати з якості (особливо при еталонних тестах, так як метрика PSNR (обчислюється на основі середнього квадратичного відхилення) найбільш поширена), але вимагає значних витрат ресурсів (множення операція повільна, навіть таблиця квадратів не сильно прискорює процес) і сильно чутливий до зміни яскравості. Чим менше SSD - тим більше схожі блоки.
Порівняння за характерним точкам. Може виконуватися дуже швидко (за рахунок обходу лише невеликого числа точок), але може дуже погано корелювати з більш якісними метриками.
Обчислення SAD (суми абсолютних різниць). Виконується за розумний час і дає прийнятний результат за якістю (але має низьку стійкість до шуму). Реально застосовується і має хороші швидкісні показники за рахунок використання SIMD розширень (які дозволяють виконувати безліч вирахувань одночасно без використання "інтелектуальних" коштів процесора по распаралелюванню обчислень).
Найбільш часто використовується обчислення SAD.
Друге питання більш складне: "Як шукати потрібний блок?"
Повний перебір (Full Search). В деякій області навколо оброблюваного блоку відбувається перебір координат шуканого блоку. Якщо маємо блок 16x16 і область пошуку ± 32 x ± 32, то нам потрібно буде 4096 раз порахувати SAD для кожного оброблюваного блоку. Це повільно, але дає гарантовано кращий результат по заданій метриці.
Пошук за шаблоном. Виконується швидко, дає не кращі результати.
Спіральний пошук. Вважається, що чим ближче блок до поточного, тим більша ймовірність того, що він шуканий. І його точність зменшується від центру до країв області пошуку. Має додаткову перевагу. Довгі вектори погіршують стисливість поля векторів. При спіральному пошуку на незмінних ділянках завжди стоять нульові вектори.
Організація послідовностей кадрів. У першу чергу кодек повинен бути чутливий до зміни сцен. Визначити це достатньо просто, так як компенсація руху відпрацює в цьому випадку потворно. Кадр початку нової сцени логічно зберегти "як є", оскільки він ні на що, що раніше зустрічалося, не схожий. Такі кадри називають опорними (I-frame).А далі йдуть кадри, до яких застосовувалася компенсація руху, тобто вони залежать від опорного кадру і один від одного. Це можуть бути P-frame або B-frame. Перші можуть спиратися тільки на попередні кадри, а останні можуть спиратися на лівого і правого сусіда. I-кадр і всі його залежні кадри утворюють GOP (group of pictures). Від використання бі-кадрів є ряд переваг: швидка навігація (бо попередні бі-кадри не потрібно декодувати) і те, що вони мають найменший розмір серед всіх кадрів фільму, ну і трохи нижча якість (але швидке чергування з більш якісними кадрами робить це малопомітним для глядача).
Надмірність вихідних даних. Навіть після виконання всіх стискаючих процедур потік коефіцієнтів має надмірність. Далі може застосовуватися різні методи стиснення без втрат. У кодеку H.264, наприклад, є два варіанти CABAC і CAVLC, що реалізують арифметичне стиснення з потужною ймовірнісною моделлю і реалізують Хаффмана з простішою моделлю.