Новости

Повний тест якості кодування звуку YouTube

  1. Визначення доступних форматів
  2. Як Google кодує відео для YouTube
  3. аналіз аудіо
  4. Vorbis
  5. AAC
  6. Відтворення в браузері
  7. Відтворення через Flash Player
  8. Відтворення через HTML5
  9. Відео без VP9
  10. Аналіз результатів
  11. висновки
  12. Інформація від спонсора

Всім відомо, що на YouTube, крім музичних кліпів, є ще безліч роликів, по суті представляють собою музичні треки з підставленої статичної картинкою (наприклад, обкладинкою альбому). Особливо їх кількість зросла з тих пір, як сервіс Last.fm став використовувати музику з кліпів YouTube в своєму веб-плеєрі.

Логічно припустити, що якість аудиопотока варіюється в залежності від обраного якості відео (240p, 360p і т. Д.). Однак я не раз відзначав в роликах на YouTube чутні артефакти кодування, навіть при досить високій якості відео.

Мене стало долати цікавість, і я вирішив з'ясувати, яким же чином YouTube кодує звук в завантажуваних роликах, і як все це відтворює. У підсумку, паралельно з аналізом якості аудіо, я також визначив, які відео потоки доступні для онлайн відтворення в кожному окремому випадку.

Щоб виконати найбільш повну перевірку, я створив спеціальне відео з безкомпромісним дозволом 4K Fullframe, 4096х3112 пікселів (співвідношення сторін 1.32: 1), частотою 29.970 кадрів / с, зі статичним зображенням (біла заливка) і тестовим файлом RMAA 24 / 44.1 PCM в якості звукової доріжки. Ось, що вийшло на виході, після завантаження відео на сервіс:

Визначення доступних форматів

Як показав мій тест, на сьогодні (жовтень 2014 року) сервіс YouTube головним чином використовує кодування H.264 / MPEG-4 AVC з роздільною здатністю до 4096х3112 пікселів, WebM / VP9 з дозволом до 2862x2160, а також деякі профілі WebM / VP8 і H.263 для кодування з дозволами 360p і нижче. Для кодування аудіо використовуються кодеки AAC, Vorbis і MP3.

Давайте розберемося з форматами більш докладно.

Після установки останньої версії плагіна скачування з YouTube для завантаження виявилися доступні наступні потоки:

MP4 (Video) 4K - H.264 / AVC 4096x3112 (оригінальна дозвіл)
MP4 (Video) 1440p - H.264 / AVC 1896x1440
MP4 (Video) 1080p - H.264 / AVC 1422x1080
MP4 (Video + Audio) 720p - H.264 / AVC 948x720 + AAC 192 kbps
MP4 (Video) 480p - H.264 / AVC 632x480
MP4 (Video + Audio) 360p - H.264 / AVC 474x360 + AAC 96 kbps
MP4 (Video) 144p - H.264 / AVC 190x144
WebM (Video) 2160p - WebM / VP9 2842x2160 (позиціонується як 4K, т. К. При співвідношенні сторін 16: 9 це 3840x2160)
WebM (Video) 1440p - WebM / VP9 1896x1440
WebM (Video) 1080p - WebM / VP9 1422x1080
WebM (Video) 720p - WebM / VP9 948x720
WebM (Video) 480p - WebM / VP9 632x480
WebM (Video + Audio) 360p - WebM / VP8 474x360 + Vorbis ~ 128 kbps
WebM (Video) 240p - WebM / VP9 316x240
WebM (Video) 144p - WebM / VP9 190x144
FLV (Video + Audio) 240p - H.263 / Sorenson Spark 316x240 + MP3 64 kbps
3GP (Video + Audio) 240p - H.263/Simple@L1 316x240 + AAC 32 kbps
3GP (Video + Audio) 144pp - H.263/Simple@L0 176x144 + AAC 24 kbps
AAC (Audio) 256 kbps
AAC (Audio) 128 kbps
HE-AAC (Audio) 48 kbps
Vorbis (Audio) ~ 192 kbps
Vorbis (Audio) ~ 128 kbps

Також, дуже рідко, в відео присутні потоки Opus ( приклад ).

Як бачимо, деяка логіка тут проглядається. Так, у нас є три групи, відповідні трьом стандартам:

1) H.264 + AAC
2) WebM / VP9 + Vorbis
3) H.263 FLV / 3GP + MP3 / AAC

Як Google кодує відео для YouTube

Тут хочу звернути вашу увагу на те, за яким принципом Google кодує відео для YouTube. По-перше, Google зберігає на сервері вихідний файл (скачати його можна через бекап-сервіс Google Takeout). Відразу після завантаження файлу на сервер Google кодує його в формати H.264, H.263 і VP8. Що ж стосується VP9 - то тут компанія Google придумала якась хитра умова, згідно з яким в цей формат кодуються тільки популярні відеоролики. Проаналізувавши свій канал, я з'ясував, що в цей формат закодовані в основному популярні відео, у яких більше тисячі переглядів. Хоча деякі відео з досить великою кількістю переглядів (і навіть лайків), таки не були закодовані в новий формат, я все ж припустив, що для кодування в VP9 необхідно досягнення певної кількості переглядів, лайків, або деякої комбінації цих значень.

Для перевірки своєї теорії я завантажив вищенаведене відео і почав кампанію по накрутці його переглядів / лайків. Цікаво, що буквально на наступний день YouTube цю справу «просік» і заморозив кількість переглядів на 301-му (втім, через три дні кількість переглядів знову почала зростати). Це відома хитрість, але на результат тесту даний момент не вплинув: на третій день після завантаження відео я помітив, що на його сторінці для скачування нарешті стали доступні потоки VP9.

Не можна сказати, що такий результат однозначно підтвердив мою теорію, але він її і не спростував. Хоча, тепер у мене з'явився варіант, до якого я схиляюся в більшій мірі: Google кодує VP9 ні до досягнення певної кількості переглядів, а при тривалому високому трафіку звернення до цього відео. І такий варіант дійсно більш логічний - так YouTube може ефективно знижувати навантаження на канал (т. К. VP9 має швидкість потоку в два рази менше, ніж H.264).

аналіз аудіо

Повертаючись до наших потокам: далі ми перевіримо, в яких випадках використовуються ті чи інші потоки, але зараз давайте зупинимося на якості аудіо.

Перш за все хочу відзначити, що звукові доріжки, що йдуть окремо, в foobar2000 (додано: підтримка DASH починається з версії foobar2000 1.3.7) і WMP відтворюватися відмовилися. Щоб з'ясувати причину, я пустив в хід шістнадцятковий редактор. Виявилося, що у випадку з AAC це зовсім не чистий RAW потік (без заголовків), як я думав спочатку, а потік спеціально упакований Google'ом в контейнер DASH (Dynamic Adaptive Streaming over HTTP) . Так, якщо стандартний (відповідний специфікації) файл-контейнер MP4 AAC починається з «ftypM4A», то Google'овскій AAC файл починається з «ftypdash». Що ж стосується Vorbis - незважаючи на те, що плагін для скачування визначає його як OGG, насправді це потоки в контейнері WebM (про що говорить і значення MIME-Type, що повертається сервером).

Таким чином, для правильного відтворення звукові потоки Vorbis слід зберегти в * .webm. Для AAC же можна скористатися консольної програмою ffmpeg з приблизно такою командним рядком: ffmpeg -i input_file -acodec copy output_file.m4a.

Що стосується потоків відео + аудіо (MP4, WebM, FLV, 3GP), то вони успішно відтворюються в foobar2000 без будь-яких маніпуляцій, і тепер ніщо не заважає нам проаналізувати якість всіх наявних звукових доріжок.

Отже, з урахуванням всіх аудіо і відео файлів, у нас є 11 доріжок. Забігаючи вперед, скажу, що доріжка, яка використовується в WebM / VP8, ідентична окремому потоку Vorbis ~ 128 kbps. Тобто, у нас є сім доріжок AAC, дві доріжки Vorbis і одна MP3.

Перш за все давайте проаналізуємо частотні зрізи:

Vorbis ~ 192 kbps - 22 kHz
Vorbis ~ 128 kbps - 19.1 kHz
AAC 256 kbps - 22 kHz
AAC 192 kbps - 18.7 kHz
AAC 128 kbps - 15.9 kHz
AAC 96 kbps - 15.1 kHz
AAC 48 kbps - 12.8 kHz / 16.5 kHz with SBR
AAC 32 kbps - 9.3 kHz
AAC 24 kbps - 8.1 kHz
MP3 64 kbps - 9.7 kHz

Таким чином, на якісне звучання у нас претендують дві доріжки Vorbis і дві-три доріжки AAC. Тепер давайте ближче подивимося, що вони собою представляють.

Vorbis

Взагалі кажучи, на даний момент контейнер WebM підтримує як Vorbis, так і Opus. Підтримка ж декодування браузерами цих форматів аудіо вже ідентична , І тому досить дивно, що Google все ще використовує Vorbis. Ну, що ж, маємо те, що маємо.

Я проаналізував потоки Vorbis і насамперед виявив, що на вхід кодера Vorbis скоріше за все був поданий PCM потік не 24, а 16 біт - це відбилося на динамічному діапазоні записи. Далі я оцінив динаміку зміни бітрейта доріжки 192 kbps і порівняв її з динамікою для libvorbis 1.3.4 -b 192. Результати виявилися вельми і вельми схожі, однак у Google'овского Vorbis виявилася одна дивина: на фрагментах з тишею у нього утворився цифровий шум з рівнем -90 dBFS, причому кодер закодував його з бітрейтом близько 130 кбіт / с (через що середній бітрейт виріс до 97 кбіт / с в порівнянні з 44 кбіт / с для libvorbis 1.3.4).

Фрагмент закодованого сигналу RMAA: виник шум і сигнал 1 кГц -60 дБ
Фрагмент закодованого сигналу RMAA: виник шум і сигнал 1 кГц -60 дБ. Шум має рівномірний спектр від 150 Гц до 16.5 кГц. Він також накладається на сигнал 1 kHz -60 dBFS і присутній в каналі з тривалої тишею, навіть якщо в цей час в сусідньому каналі є корисний сигнал.

Тут я трохи «покопав» і виявив, що цей дивний частотно-обмежений шум проскакує також і у libvorbis 1.3.4, але тільки якщо на вхід подається 16-бітний сигнал; і у libvorbis, на відміну від кодера Google, цей шум присутній тільки на тлі тони 1 kHz -60 dBFS:

4, але тільки якщо на вхід подається 16-бітний сигнал;  і у libvorbis, на відміну від кодера Google, цей шум присутній тільки на тлі тони 1 kHz -60 dBFS:

Що ж це за шум? Поміркувавши, я прийшов до висновку, що це може бути шум 16-бітного квантування, обрізаний Vorbis'ом відповідно до моделі ATH (Absolute Treshold of Hearing, абсолютний поріг чутності). Але чому Google Vorbis сприймає цей шум як корисний сигнал (там де повинна бути цифрова тиша, неважливо якої розрядності), і чому він взагалі себе так дивно веде - загадка. Як би там не було, у кодера Google проблем з цим шумом побільше, ніж у libvorbis.

Ситуація з потоком 128 kbps виявилася аналогічною - приблизно однакове розподіл бітрейта, за винятком кодування шуму кодером Google; в результаті середні бітрейти 31 і 61 кбіт / с для libvorbis і Google Vorbis відповідно.

В цілому можу підсумувати, що Google користується досить схожим, злегка відмінним від libvorbis 1.3.4 алгоритмом, що забезпечує хорошу якість.

AAC

Тут YouTube використовує постійний, строго фіксований бітрейт. Методом аналізу спотворень я вирахував, що для кодування використовується одна з версій кодера FhG AAC , Причому на вхід також подаються 16-бітові дані (молодші 8 з вихідних 24-х бітів відкидаються). АЧХ, і багато в чому спотворення, збігаються для всіх п'яти бітрейтів, ось приклад для 256 кбіт / с:

АЧХ
АЧХ


Інтермодуляції
Інтермодуляції


Фактично різниця між потоками FhG і Google лише в контейнері і парі кілобітах бітрейта. Для FhG Mediainfo доповідає про нібито змінному бітрейті, але при перепакування в ffmpeg на виході також отримуємо значення Bitrate: Constant.

Що можна сказати про якість використовуваного Google кодера AAC (FhG)? - воно досить висока, приблизно нарівні з QAAC. Однак головним недоліком тут є режим CBR, що позбавляє формат гнучкості, здатності адаптуватися до складних семплам. Таким чином лише бітрейт 256 кбіт / с може дати якусь упевненість в якості кодування. 192 кбіт / с може здавати на деяких кілер-семплах, а 128 і 96 кбіт / с підійдуть лише як «прийнятне» якість (хоча на простому матеріалі ці бітрейти цілком можуть забезпечувати прозорість).

В цілому ж, за наявними звуковим матеріалами, спираючись на свій досвід, можу сказати, що якість Vorbis VBR 192 і FhG AAC CBR 256 знаходиться приблизно на одному рівні, проте з огляду на специфічних викривлень Vorbis на транзиента (виявлено в ABX на семплах tiesto-do_you_feel_me і tydi-meet_me_in_kyoto ), Я б все-таки віддав перевагу AAC.

Відтворення в браузері

А тепер, коли ми знаємо, що де у нас в плані звучання, давайте подивимося, як йдуть справи з програванням звуку в браузері. Відтворювати відео будемо через найбільш популярні браузери: Firefox, Chrome, Opera (останні версії на движку Presto і WebKit), Internet Explorer 11. Звук записувався / аналізувався за допомогою SoundForge, ASIO і джерела What U Hear (на X-Fi це дає bit- matched потік). Визначити відтворюється в даний момент аудіо ми зможемо по спектральному аналізатору (так як вже знаємо спектральний склад кожного потоку).

Також не забуваємо, що останнім часом на YouTube є програвання не тільки через Flash, а й через HTML5. Переключитися між HTML5 і Flash плеєрами, а також для перевірити можливості HTML5 програвання для браузерів, можна на сторінці hwww.youtube.com/html5 .

Відтворення через Flash Player

Виявилося, що при програванні через Flash для всіх браузерів і форматів відео подгружается потік AAC 128 kbps. Треба сказати, що це досить дивно і не цілком виправдано.

Відтворення через HTML5

При виборі HTML5 все браузери відтворюють WebM потік. Розклад наступний:

Opera 12: підтримує тільки WebM VP8 з вбудованим потоком Vorbis 128 kbps.
Opera 25: 2160p, 1080p (насправді 1440), 720p, 360p (насправді 480), 240p - Vorbis 128 kbps
Chrome 38: 2160p, 1080p (насправді 1440), 720p, 360p (насправді 480), 240p - AAC 128 kbps
Firefox 32: підтримує тільки H.264 з вбудованими потоками. 360p - AAC 96 kbps, 720p - AAC 192 kbps
Internet Explorer 11: підтримує тільки H.264 з вбудованими потоками. 360p - AAC 96 kbps, 720p - AAC 192 kbps

Відео без VP9

А тепер подивимося ситуацію для тих відео, де немає VP9 і Vorbis. Спеціально для такого випадку у мене залишилося відео з попередньої версії цієї статті, яке до сих пір не закодовано в VP9:

Що стосується Flash-тут все так і залишається: плеєр завжди відтворює потік AAC 128 kbps. Ми ж візьмемо тільки варіант з HTML5.

Opera 12: підтримує тут тільки WebM VP8 з вбудованим потоком Vorbis 128 kbps.
Opera 25: відтворює тільки H.264 з вбудованими потоками 360p - AAC 96 kbps, 720p - AAC 192 kbps
Chrome 38: 720p, 360p (насправді 480), 240p, 144p - AAC 128 kbps
Firefox 32: підтримує тільки H.264 з вбудованими потоками: 360p - AAC 96 kbps, 720p - AAC 192 kbps
Internet Explorer 11: підтримує тільки H.264 з вбудованими потоками. 360p - AAC 96 kbps, 720p - AAC 192 kbps

Аналіз результатів

Тепер спробуємо осмислити всі зібрані дані і зробити якісь висновки. По-перше, абсолютно незрозуміло, для чого YouTube закодував потоки Vorbis 192 kbps і AAC 256 kbps (ладно, 48 kbps, - він скоріше за все використовується для мобільних пристроїв). І знову ж таки, як то кажуть, маємо те, що маємо.

Організуємо зведену таблицю, що демонструє підтримку HTML5 технологій YouTube усіма п'ятьма браузерами:

Організуємо зведену таблицю, що демонструє підтримку HTML5 технологій YouTube усіма п'ятьма браузерами:

Зверніть увагу на графу MSE & H264: у Chrome підтримка є, а у Opera 25 - немає. А тепер подивимося наші результати для відео без VP9 (тільки H.264). Ми бачимо, що Chrome завантажує для H.264 окремий аудиопоток, а Opera 25 може використовувати тільки відео з уже вбудованим аудіопотоків. Саме так: Media Source Extensions - це технологія, що дозволяє JavaScript генерувати медіапотоків для відтворення через HTML5. Скрізь, де вона підтримується, ми маємо подгрузку аудиопотока «з боку». Єдине, що дивно: Chrome чомусь підвантажує AAC, а Opera 25 - Vorbis, хоча обидва браузера мають підтримку всіх можливих (для HTML5) форматів аудіо.

висновки

Перший висновок напрошується сам собою: якщо хочете отримати максимально якісне звучання, не дивіться відео в браузері. Так як ні через Flash, ні через HTML5 ви не отримаєте найкращі наявні потоки - AAC 256 kbps і Vorbis 192 kbps. Таким чином, для прослуховування краще попередньо завантажувати потоки через спеціальні плагіни для браузерів, або ж користуватися чудовим плагіном foo_youtube в зв'язці з ffmpeg декодерами (так як foobar2000 сам не зможе декодувати Google'овскій AAC) - про його налаштування я напишу в одній з наступних статей .

Також хочу ще раз зазначити волаючу нераціональність використання наявних потоків YouTube'ом - якогось логічного пояснення цьому я на даний момент знайти не можу. Можна тільки припустити, що в майбутньому алгоритм підключення плеєром звукових доріжок буде вдосконалений.

На цьому все. Дякую за увагу і, звичайно ж, за допомогу в проведення тесту. Удачі вам і гарного настрою!

[Обговорити на форумі]

Інформація від спонсора

E-star: найбільший інтернет-магазин навушників. Навушники xiaomi можна саме тут: поспішайте придбати оригінальні моделі за акційними цінами. Гарантія на всі товари.

Що можна сказати про якість використовуваного Google кодера AAC (FhG)?

Уважаемые партнеры, если Вас заинтересовала наша продукция, мы готовы с Вами сотрудничать. Вам необходимо заполнить эту форму и отправить нам. Наши менеджеры в оперативном режиме обработают Вашу заявку, свяжутся с Вами и ответят на все интересующее Вас вопросы.

Или позвоните нам по телефонам: (048) 823-25-64

Организация (обязательно) *

Адрес доставки

Объем

Как с вами связаться:

Имя

Телефон (обязательно) *

Мобильный телефон

Ваш E-Mail

Дополнительная информация: