Сжатие видео и декодирование | Длинное заключение
Пришло время перевести все сказанные слова в качество картинки. По сути дела, это заключение.
APP, CUDA или Quick Sync?
Качество изображения – это не точная наука. Мы все привыкли к тому, что декодеры специально созданы так, чтобы маскировать ошибки некачественного видео. Логические контуры Radeon UVD или GeForce PureVideo всегда стараются улучшить плохое видео по мере возможности.
В идеале хотелось бы использовать один и тот же программный декодер во всех тестах. Но при этом не менее важно, чтобы декодер не маскировал возможные ошибки, которые вы и пытаетесь выявить, чтобы провести сравнение между качеством различных видеофайлов. Такие потребительские декодеры, как MediaFoundation, CyberLink, Arcsoft и Badaboom – все они предусматривают коррекцию ошибок. Они пытаются сделать видео чуть лучше и это прекрасно. Но если вы хотите сравнить качество различных видео, то это совсем другое дело.
Нам не удалось выявить очевидного победителя. Транскодирование видео на АРР по нашему мнению выглядит не очень хорошо в MediaConverter от Arcsoft. Intel в Badaboom выглядит блочно (правда у Elemental есть оправдание – она пока ещё на стадии альфа-тестирования), а у CUDA есть несколько серьёзных проблем с MediaEspresso. Более того, мы не уверены, что в принципе можно вынести определённое суждение по поводу работы программного кодирования. Оборудование может быть прекрасным, референсная библиотека отличной, но человеческий фактор в виде программиста может испортить качество видео.
Как отличить плохое транскодирование видео от хорошего
Обычный пользователь сделать этого не может. Давайте поговорим о разных видеоплейерах, которые используют разные кодировщики и декодировщики. Например – Apple. Он использует видеодекодер Broadcom в сочетании с CoreAnimation в своих медиа-устройствах. RIM, Nokia и Samsung – у всех этих компаний есть собственные декодировщики и программы для рендеринга. Любое тестирование обычно производится при фиксировании одних параметров и изменении других. Например, при тестировании качества кодирования имеет смысл менять только битрейт. После этого надо использовать один программный декодер для просмотра видео. Если возникают проблемы, то вы переключаетесь на кодирование источника разными кодировщиками и пробуете их комбинации, чтобы устранить проблемы.
Единственный способ отличить плохо декодированное видео от хорошо декодированного – сравнить начальное изображение в разных медиа-плейерах и разных графических конфигурациях. Даже в одной такой конфигурации плохое видео будет одинаково плохо проигрывать на большинстве плейеров. А хорошее видео всегда будет выглядеть хорошим. Если вы не хотите потратить месяц на сравнение качества видео, единственное, что вы можете сделать – убедиться, что транскодированное видео выглядит хорошо на ваших программных плейерах и оборудовании.
Что надо использовать для кодирования
Вы используете спектрометр, чтобы калибровать ваш HDTV? Вы страдаете перед сном по поводу компенсации движения? Вы просматриваете ваши любимые ТВ-шоу только на дисках Blu-ray вместо того, чтобы скачивать его через Netfix или Hulu поскольку вас не устраивает качество картинки? Если вы – фанат качества, тогда вам потребуется программное кодирование и декодирование, которое не допустит аппаратное ускорение к вашему контенту. Это единственный надежный способ для получения качественного видео.
В самом худшем сценарии аппаратное ускорение даст вам 75% качества и очень небольшое ускорение по сравнению с процессорным транскодированием. В самом лучшем случае вы получите 99% качества и четырёхкратное ускорение по сравнению с работой процессора. Если же вы торопитесь или не заботитесь о качестве видео, которое просматриваете в разрешении 960х640 на вашем iPhone 4, то это совсем не так плохо, как думают любители совершенства. Всегда есть обратно пропорциональная зависимость между скоростью и качеством.
Если вы мобильный пользователь и вам нужно провести транскодирование с использованием имеющейся батареи ноутбука, то Quick Sync – самый правильный путь для достижения цели (пользователи настольных компьютеров с меньшей вероятностью будут использовать этот вариант, потому что Quick Sync не работает с дискретной графикой). Транскодирование на базе GPU использует обычное оборудование, а работа с Radeon HD 6970M или GeForce GTX 480M мгновенно съест ресурс вашей батареи.
Может результат GPU быть качественным, как на CPU?
Мы задавали этот вопрос самым разным людям. Почему кодирование с аппаратным ускорением (даже с Intel Quick Sync) дает такие неадекватные результаты? Получили два разных ответа. Некоторые сравнивают ситуацию с появлением многопоточного программирования. Должно пройти немало лет, чтобы появились приложения, которые будут оптимизированы под использование нескольких ядер. И если подождать достаточно долго, то появятся более качественные референсные библиотеки. Intel, nVidia и AMD фокусируются на том, чтобы ускорить работу – именно это мы видели в наших тестах. В ответ на удар в виде Quick Sync от Intel по CUDA один человек сказал "всё это началось три года назад, но сейчас такого различия между результатами нет". Но личный опыт наших коллег говорит о том, что качество видео на платформе Brazos недостаточно хорошо и приходится переходить на транскодирование на базе процессора, чтобы избежать визуальных артефактов.
Есть и другое мнение "дайте время и качество улучшится". Если задуматься, то оба правы. Глава компании Elemental Сэм Блэкман настаивает, что аппаратное кодирование догонит по качеству процессорное кодирование со временем. Вот что он говорит: "Если вы посмотрите на то, что было с Badaboom два года назад и сравните с тем, что мы имеем сегодня, то увидите колоссальный прогресс и я уверен, что кодировщики GPGPU превзойдут процессорные кодировщики в самом ближайшем будущем, если этого уже не произошло".
Другие указывают на то, что H.264 – последовательный кодек и таковы все другие кодеки. Поэтому транскодирование на графических процессорах будет приближаться к качеству процессорного, но никогда его не достигнет. В современных кодировщиках есть много усовершенствований, которые полагаются именно на последовательную структуру видеоданных. При переходе к параллельной обработке многие из этих усовершенствований придётся отбросить. Один из экспертов сказал, что пока у нас не будет кодека, оптимизированного под параллельные вычисления, мы не сможем сильно продвинуться на GPU, во всяком случае в транскодировании. Скорее всего обе стороны в какой-то степени правы.
Последовательная природа всех имеющихся кодеков – это одно из основных "узких мест", влияющих на транскодирование с использованием GPU. В идеале вы хотели бы, чтобы макроблок зависел от своего соседа не по времени, а по положению в кадре. Тогда вы смогли бы обрабатывать больше кадров в параллельном режиме. К сожалению, таких кодеков пока нет. Все будут очень рады увидеть новый кодек, разработанный на основе принципов параллельных вычислений. Надеемся, что именно так будет сделан Н.265 (HEVC).
Вот мы и пришли к концу нашего повествования. Пусть победит лучший GPGPU (или аппаратный) кодировщик.
Небольшой комментарий: мы говорили о качестве картинки в H.264, поскольку это самый распространённый видеокодек сегодня. Декодирование VC-1 и MPEG-2 – это другая история. Когда речь заходит о качестве видео, вполне можно было бы поговорить о качестве звука. Но мы хотели максимально упростить наше обсуждение, поэтому ограничили его.
![Сжатие видео и декодирование - обсуждение в Клубе экспертов THG [ 29 отзывов]](/forum/images/icons/icon5.gif){kind=icon}