Полный тест качества кодирования звука YouTube

Всем известно, что на 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 дБ. Шум имеет равномерный спектр от 150 Гц до 16.5 кГц. Он также накладывается на сигнал 1 kHz -60 dBFS и присутствует в канале с продолжительной тишиной, даже если в это время в соседнем канале есть полезный сигнал.

Тут я немного «покопал» и обнаружил, что этот странный частотно-ограниченный шум проскакивает также и у libvorbis 1.3.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 всеми пятью браузерами:

Обратите внимание на графу 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'ом — какого-то логичного объяснения этому я на данный момент найти не могу. Можно только предположить, что в будущем алгоритм подключения плеером звуковых дорожек будет усовершенствован.

На этом всё. Спасибо за внимание и, конечно же, за помощь в проведение теста. Удачи вам и хорошего настроения!

[Обсудить на форуме]