Сжатие видео и декодирование | Введение

Не так давно мы уже обсуждали качество картинки в обзоре первых мини-ITX Brazos . Если вычитали этот обзор, то помните, что там было несколько неожиданных результатов, полученных при анализе возможностей платформ по кодированию/декодированию видео. Большинство результатов были одинаковыми: качество видео на выходе было одинаковое для продуктов Intel и AMD. При этом результат, полученный при использованиии CUDA от nVidia сильно отличался от предыдущих. Любое видео, которое мы пропускали через него, содержало заметное количество блочных фрагментов в сценах с активным движением. Нас об этом предупреждали, но надо было это увидеть своими глазами, чтобы понять, как плохо обстоят дела.

Все это и побудило нас провести тесты качества изображения, о которых пойдет речь в дальнейшем. После нашего исследования Brazos много вопросов осталось без ответа. Может быть они и не были уместны в предыдущей статье, но вполне заслуживают отдельного изучения.

Сжатие видео и декодирование | Кодеки и декодеры

Перед тем, как перейти к серьёзным тестам, надо прояснить несколько простых вещей. Важно различать кодеки и контейнеры файлов. Например, файлы Blu-ray часто появляются с расширением.m2ts. Но формат контейнера BDAV (blu-ray Disc Audio/Video) обычно выступает в качестве обёртки для хранения. При этом можно использовать три кодека – MPEG-2, H.264 и VC-1.

Какая же всё-таки разница между кодеком и контейнером? Вспомните ваш последний отпуск. Ваш чемодан, в данном случае, это "контейнер". Багаж это контент (видео, аудио, субтитры и другая информация), а кодек – это способ, которым вы впихиваете всё (данные) в ваш чемодан, чтобы всё поместилось. Вы можете класть вещи в чемодан аккуратно сворачивая (один кодек), или прессовать их в рулоны и обматывать скотчем, чтобы побольше влезло (другой кодек). Это верно для любого мультимедиа контента. Например, формат Microsoft AVI (Audio Video Interleave) – это контейнер файлов, но видео в нём может кодироваться разными кодеками, от DivX до MPEG-2.

Когда вы проигрываете что-нибудь на видеоплейере, обычно кодированное видео проходит через декодер, преобразуется в YUV-данные (цветовое пространство) и подаётся на экран. Декодер распознает формат и развёртывает сжатые данные в полезную информацию, которая может обрабатываться и просматриваться.

Есть два типа декодеров: программные и аппаратные. До UVD, PureVideo и Intel GMA 4500MHD видео декодировалось с помощью программных декодеров, которые полагались на мощность процессоров. Поэтому многие компании старались что-либо сделать для проигрывания видео. Но сделать по-настоящему хорошо это удалось только двум из них – CyberLink и InterVideo (сейчас Corel), поэтому тогда ATI и лицензировала PowerDVD декодер для своего декодера ATI DVD. Естественно, программные декодеры съедают большое количество процессорного времени, что хоть и не влияет на производительность современных процессоров, но для мобильных устройств заметно сокращает время жизни аккумуляторов.

Со временем этой проблемой занялись производители графических карт и стали разрабатывать декодеры с фиксированными функциями, которые представляли собой логические контуры в GPU, предназначенные для обработки видео. Сегодня их называют аппаратными ускорителями. Их преимущество было в том, что при работе графического процессора не расходовалось время основного процессора.

Есть несколько интересных моментов. Поскольку декодер обрабатывает видео, достаточно сложно установить параметры качества его работы или эффективности. Вне зависимости от того, проходит ли видео аппаратный или программный конвейер преобразования, данные сильно меняются перед тем, как оказываются на вашем мониторе. Используя ПО, вы не должны сравнивать системы, используемые при декодировании. Хотя при использовании одной и той же системы различные декодеры могут выдавать различные картинки или изменять качество восприятия изображения. Большинство дисков Blu-ray, которые проигрываются на графических картах nVidia или AMD, будут выглядеть одинаково, если вы отключите ускорение в PowerDVD. В обоих случаях видео обрабатывается с помощью ПО на процессоре, выдавая одинаковый результат.

Когда в процесс добавляется аппаратное декодирование, всё выглядит по-другому. Почему? В современных GPU есть специальный блок, занимающийся декодированием и обработкой видеоданных. Это именно та логика с фиксированной функцией, о которой шла речь чуть выше. Аппаратное ускорение декодирования на процессорах Sandy Bridge конструируется и программируется отлично от того, как это сделано на графических картах AMD и nVidia.

Надо четко понимать: нет GPU-декодеров общего назначения. Нет декодеров, которые могут полностью работать на DirectCompute, APP или CUDA. Стремление реализовать такую поддержку заранее обречено на провал. GPGPU предназначен для обработки сырых данных с высокой степенью параллелизма. Но мы говорим о видео, а не о сырых данных. Для обработки картинок приходится делать многое, причём в последовательном исполнении. Декодеры с фиксированными функциями декодируют и обрабатывают видео; они не делают ничего другого. Перенесения этой функции на компьютерные ресурсы более общего профиля было бы шагом назад по сравнению с переносом их на процессор, поскольку в обоих случаях вам придётся работать с программным декодированием.

Компания Elemental Technologies (которая известна своей разработкой Badaboom) уникальна тем, что разработала декодер MPEG-2 на базе CUDA. И это не чистый декодер GPGPU. Части его конвейера, такие как кодирование энтропии, кодирование синтаксиса, декодирование синтаксиса и декодирование энтропии должны исполняться последовательно. Другие части процесса могут быть сконструированы для параллельного исполнения, такие как оценка движения, компенсация движения, разбиение данных на подгруппы, дискретная косинусоидальная трансформация, фильтрация деблокирования, деблокирование конечных результатов. Именно поэтому декодер MPEG-2 Elemental – это половинчатое решение. Часть процесса выполняется на CPU, часть – на ядрах CUDA.

Сжатие видео и декодирование | История форматов

Декодирование видео на аппаратном уровне у многих экспертов вызывает определённые сомнения. Дело в том, что не каждое решение обеспечивает одинаковую обработку.

Для компании Intel единственной функцией конвейера декодирования видео была компенсация движения, которая существовала в нескольких поколениях графических продуктов (GMA 900, 850, 3000 и 3100). Это означает, что для декодирования потока видео используется программный декодер перед тем, как логические контура Intel выполнят компенсацию движения. Этого не было до последней версии 3100, где мы впервые увидели полное декодирование MPEG-2 на аппаратном уровне. Поддержки VC-1 и Н.264 не было до 4500MHD. GMA 500 не учитывается, поскольку этот продукт для Intel создала компания Imagination Technologies.

Тем временем компания AMD недавно выпустила UVD 3 со своими картами Radeon HD 6000 серии. Изначально UVD 1 поддерживала полное декодирование VC-1 и H.264, в UVD 2 добавлено преобразование частоты и компенсация движения для MPEG-2. В UVD 3 добавлена полная поддержка декодирования для MVC, MPEG-2 и MPEG-4/DivX/Xvid. Отметим, что UVD в картах AMD 5000 серии претерпел ревизию на уровне прошивки. Немало изменений было сделано и на аппаратном уровне, где компания AMD добавила двухпотоковую поддержку декодирования. В Radeon HD 4000-серии уже поддерживалось двухпотоковое декодирование и технология "картинка в картинке", но только в разрешении SD.

nVidia в своих видеокартах GeForce FX начинала с декодирования MPEG-1/MPEG-2 на аппаратном уровне. Первое поколение PureVideo появилось, когда nVidia взяла эти устройства, улучшила деинтерлейсинг и изменение размеров (overlay resizing) и встроила эти технологии в свою серию GeForce 6000. Для большей части таких карт ускорение декодирования ограничено, поскольку исключается преобразование частоты декодирование с переменной длиной. Декодирование Н.264 на аппаратном уровне не было возможным до появления GeForce 6600. Сегодня мы готовы к приходу PureVideo четвертого поколения, где добавляется потоковое декодирование MPEG-4 (Advanced) Simple Profile в сочетании с MVC для контента Blu-ray.

Сжатие видео и декодирование | Поддержка кодирования

До появления технологии Quick Sync, в процессорах не было аппаратного кодирования (для настольных ПК). Практически всё сжатие производилось программно с использованием мощности процессора. Если у вас быстрый компьютер, то вы будете кодировать быстрее. Всё очень просто. В далеком прошлом были времена, когда программные кодеки могли работать только в однопоточном режиме, что очень ограничивало производительность. Времена изменились и теперь сжатие видео можно выполнять несколькими параллельными потоками.

В большинстве случаев мы по-прежнему работаем с программной кодировкой. Отличие в том, что теперь у нас есть кодировщики, которые могут проделывать всю работу с помощью GPU с использованием библиотек GPGPU. В последнее время всё больше звучат голоса о том, что за вычислениями с помощью GPU будущее, из-за гораздо меньших возможностей по обработке параллельных потоков, который может предложить CPU; задачи, о которых мы сегодня говорим, просто не могут выполняться быстро и эффективно (в смысле использования электроэнергии) в процессорах общего назначения. Поэтому пока мы не будем сравнивать кодировщики на базе GPGPU, которые работают с использованием аппаратных возможностей графической карты, с решениями по аппаратному кодированию от Intel.

При кодировании используются аппаратные блоки, которые работает вместе с программируемыми исполняющими элементами (EU – execution unit). Есть ещё один блок обработки медиа-информации, соединённый с EU (Intel называет его сопроцессором), который работает с оценкой движения, подкрепляя программируемую логику. Естественно, то же самое происходит и с задачами декодирования, которые проходят через тот же конвейер, так что дополнительная производительность имеется и там. Запускаем MPEG-2, VC-1 или AVC, а на выходе получаем MPEG-2 или AVC.

В зависимости от используемого приложения каждая компания использует Quick Sync разными способами. Взять хотя бы CyberLink. PowerDVD 10 использует ускорение конвейера декодирования. Проект MediaEspresso вовлечён во всё это гораздо более активно: файл там будет читаться, декодироваться, кодироваться и возвращаться в выходной поток. Затем в PowerDirector, приложении для редактирования видео, вы сможете участвовать в пост-процессинге – накладывании эффектов и композиции кадра, которые делаются перед стадией кодирования.

Сжатие видео и декодирование | Оптимизация транскодирования

Конвейер транскодирования включает в себя чтение файла, декодирование, кодирование видео и вывод. Перед развитием кодирования на базе GPGPU, ПО для транскодирования использовало CPU для копирования данных из видеопамяти (где они находятся после аппаратного декодирования) и пересылки их обратно в системную память, где процессор мог провести стадию кодирования.

Поскольку аппаратный декодер находится на том же чипе, что и GPU, ПО может пропустить копирование данных обратно в системную память (шаг четыре на первой диаграмме). Транскодирование на базе GPU общего профиля позволяет практически весь процесс осуществить на одном кристалле кремния. Но всё это – соображения, касающиеся производительности, а наш фокус сегодня – качество. Вот к нему и перейдём.

Сжатие видео и декодирование | Транскодирование: проблемы с CUDA?

Эта статья выросла из ранних тестов качества, которые мы проводили в процессе описания настольных ПК Brazos. По нашему мнению, принесение качества в жертву производительности – плохая мысль.

Когда мы впервые увидели скриншоты тестов качества, различия нельзя было не заметить. Кодировать с использованием CUDA получается хуже, и представители nVidia, побывавшие у нас в лаборатории, проблему признали.

Вы можете самостоятельно познакомиться с этим различием, загрузив на свой компьютер реальные клипы . Мы выложили три примера на ZumoDrive: сжатие видео с использованием CUDA, на платформе Ion с аппаратным ускорением и выключенным декодированием и сжатие видео на AMD E-350 с включенным аппаратным декодированием. Посмотрите их с начала до конца и сделайте вывод самостоятельно. Различие наиболее заметно в сценах с обилием движения. Лучше всего эти артефакты описываются словами блочность и пикселизация, ухудшающие качество картинки.

Мы провели очень грубое сравнение, используя четыре устройства: ASRock E350M1 с Е-350 , Athlon II X2 с 880GITX-A-E на базе 240-е, IONITX-P-E с Intel Celeron SU2300 и IONITX-L-E на базе Atom. Два устройства с чипсетами nVidia Ion должны выдавать одинаковый результат, если использовать аппаратно ускоренное сжатие видео и декодирование. Два других устройства недостаточно мощные для того, чтобы обеспечить поддержку аппаратного кодирования. Поэтому мы сравниваем качество CUDA с чистым ПО и с двумя платформами AMD, где поддерживается аппаратное ускорение декодирования.

Тоже самое происходит со всеми тремя устройствами, использующими аппаратное ускорение декодирования. Можно заметить, что то, что выходит из декодера и затем обрабатывается в процессоре на стадии кодирования, практически одинаково. Если вы будет сравнивать картинки, полученные с помощью только ПО и с помощью аппаратного декодирования, показанные выше, то увидите, что декодированный контент одинаков, а различие появляется на CPU или GPU.

Запомнив всё то, о чем мы сейчас говорили, перейдём к более серьёзным тестам транскодирования.

Сжатие видео и декодирование | Тестовая конфигурация

Мы настроили параметры кодирования видео в соответствии с профилем iPad программы MediaEspresso 6.5. Это единственный способ обеспечить одинаковые условия при сравнении времени транскодирования между различными приложениями. В некоторых случаях не удается установить одинаковые требования. Например Badaboom превосходит всех по скорости аудио 160 кбит/с (для профиля iPad). Аудио влияет на время транскодирования в меньшей степени, чем видео, но всё же вносит свой вклад.

Сжатие видео и декодирование | Проверка качества аппаратного декодирования

С транскодированием трудно разобраться, потому что в нём участвует различное оборудование для декодирования. Хотя такие программы, как Windows Media Player 12 или PowerDVD могут использовать практически универсальные API-вызовы для DXVA (используемые для аппаратного ускорения декодирования), оборудование, реально занимающееся обработкой, устроено по-разному. Только по этой причине мы уделим особое внимание выходу после декодирования.

Есть целый ряд проблем, с которыми нам предстоит справиться. Когда вы проигрываете видео, для сравнения разных вариантов вам надо взять одинаковое количество кадров. Два последовательных кадра в одном клипе могут сильно отличаться друг от друга, поэтому вам надо быть абсолютно уверенным, что вы сравниваете один и тот же кадр на разных платформах. Используя VLC, это просто сделать, поскольку вы чётко фиксируете время и снимаете скриншоты с помощью специальной встроенной функции. Но это означает, что вы ограничены декодером VLC, который использует только часть декодирования в конвейере. Он не использует компенсации движения или преобразование частоты, даже когда вы используете аппаратное декодирование. Более того, не поддерживаются решения Intel, значит с программным декодированием будут сражаться только решения AMD и nVidia.

Поэтому нам надо найти способ использовать нечто вроде WMP12 и получать кадры из видео рендеринга. Это достаточно простое решение. WMP12, PowerDVD и другие современные видео-плейеры – все используют новый компонент MediaFoundation под названием Enhanced Video Renderer (EVR). Обычно, когда вы берёте скриншот с экрана WMP12, то ничего не получаете, поскольку он используется в режиме наложения. Если вы загрузите DirectX 11 SDK, там есть установки на панели управления, которые позволяют делать мгновенный снимок с экрана, что решает проблему тестирования аппаратного декодирования. Снятие картинки с экрана делается с помощью старой программы DirectDraw, но это происходит после её рендеринга с помощью EVR. В этот момент видео останавливается на паузу и не передаётся больше в виде потока данных. DirectDraw позволяет нам захватить изображение на экране. И то, что мы захватили, представляет собой именно то, что мы видим каждый момент на экране.

Проблему захвата конкретных сцен можно решить через незащищенное копирование сегмента workingprint на базе Blu-ray из Iron Man. Перед завершением любой кинокартины ее издатели используют этот "сырой" вариант, чтобы накладывать на него спецэффекты, анимацию, добавлять и убирать отснятые сцены, менять озвучивание. Workingprint содержит информацию о времени кадра с точностью до сотой доли секунды. Это очень важно, чтобы извлекать для нашего тестирования одни и те же кадры. Сделать это совсем не просто, вам придётся максимально повысить уровень внимания и много часов кликать мышью, взбадривая себя бесчисленными чашками кофе. Только тогда вы сможете проанализировать всё, что хотите.

Последняя тема, о которой хочется поговорить – это масштабирование. Когда вы смотрите диск Blu-ray на экране с разрешением больше или меньше 1920х1080, поток видео данных должен пройти через масштабирование, чтобы соответствовать большему разрешению. Чтобы минимизировать эффект масштабирования, мы проигрываем видео на "родном" экране 1920х1080. "Умные" декодеры не будут выполнять масштабирование для "родного" разрешения. Но не все декодеры разумны, тем не менее – именно в процессе масштабирования качество изображения может быть улучшено. Более того, декодеры различаются по способу получения данных. Некоторые предпочитают блоки 8х8, другие – иной размер. Для нас важнее всего – конечный результат. Только так можно зафиксировать реальное различие.

Сжатие видео и декодирование | Везде ли качество декодирования одинаково?

В тех местах, где задействована работа с цветами, модуль от AMD активно их меняет в процессе проигрывания. На транскодирование видео это не влияет, поскольку вы реально не проигрываете видео, то есть – не посылаете поток данных на рендеринг. В nVidia и Intel цветовой профиль определяется в приложении по умолчанию. Для AMD мы оставили возможность его корректировки, чтобы вы могли заметить разницу.

Если забыть о насыщенности картинки, UVD 3 выглядят хуже, чем Intel Clear Video HD (CVT) и четвёртое поколение PureVideo (VPDAU4). Это особенно заметно вокруг лопастей вертолета в правой части картинки. У краев лопастей нет искажений, а фигуры рабочих на грузовике менее смазаны – это означает, что алгоритмы компенсации движения Intel и nVidia копируют движение камеры более аккуратно.

Следующая сцена относится к концу фильма, когда один из героев – Родс – едет к месту сражения Обидая и Тони. Здесь движение очень активное, поэтому эти три кадра было труднее всего получить. Очень сложно определить, как сработали Intel и nVidia. AMD сработала не очень хорошо: видно как яркий свет порождает эффект "гало" вокруг ламп на улице. Если даже отключить возможность манипуляций с цветом, то у переднего бампера машины видна зернистость.

В сценах с хорошим освещением сложнее различить качество UVD 3 пока вы не отключите возможность манипуляций с цветом. После того, как это сделано, вы замечаете, что решения от nVidia и AMD передают изображение офицера на заднем фоне немного гранулировано. Даже после того, как управление цветом передано приложению, вы можете видеть, что некоторые манипуляции с цветом всё же присутствуют. Если пристально сравнивать изображения nVidia и Intel, то nVidia чуть светлее.

На последних изображениях, камера медленно наплывает на Гвинет. Цветовое насыщение от AMD в этом случае имеет большое значение, поскольку сцена более живая. Правда, надо отметить, что яркость в ней настолько агрессивна, что затуманивает многие детали. nVidia представляет сцену более чётко. Вы видите больше деталей, но, в общем, в картинке можно заметить гранулярность. А вот Intel удаётся достичь оптимального сообщения между чёткостью и детализацией.

Сжатие видео и декодирование | Программное декодирование

Программное декодирование – совсем другое дело. Пока мы работаем с одними и теми же исходными данными, мы получаем одинаковый результат, независимо от того, кто производитель оборудования.

Когда вы используете аппаратный декодер, видеоданные проходят "конвейер", который использует DXVA API для аппаратно-ускоренного декодирования. Поток данных может обрабатываться по-разному в различных устройствах с использованием одного и того же декодера. Пользователи могут не знать, сколько конвейеров DVXA используется. Именно поэтому аппаратное декодирование на WMP12 и PowerDVD может создавать разные картинки, хотя в обоих случаях используется EVR и аппаратно-ускоренное декодирование.

Для программного декодирования мы используем FrameShots, чтобы обрабатывать выбранные кадры. Поскольку в этом случае используются программные декодеры, мы не можем проделать с их помощью первую часть нашего анализа. Более того: мы не можем сравнить результаты с картинками, полученными с помощью аппаратно-ускоренного декодирования WMP12. Почему? Потому что эта программа не использует EVR. Она использует Video Mixing Renderer 9 (VMR9). По этой причине мы можем сравнивать программные кодеки только друг с другом.

FrameShots использует обычный фильтр DirectShow, который производит обработку после видео-декодера, но до рендеринга. Это означает, что мы до некоторой степени устраняем рендеринг видео из параметров, влияющих на качество, этого нельзя сделать с WMP12. Различие теперь в том, что используется DS-фильтр для получения конкретных блоков видеоданных.

Различие в изображениях трудно заметить, но если вы посмотрите на границы объектов, например, на нос белого самолёта справа, чуть большие искажения возникают при использовании декодера ffdshow. В обоих случаях используется одна картинка, но искажения встречаются в различных её частях. Поэтому выбрать одну лучшую из двух картинок сложно. Неровная линия остаётся неровной линией.

Посмотрим, насколько качественно изображаются взрывы. Оказывается, что при стремительном движении, картинки выглядят очень похоже. Гораздо больше различий можно заметить в более статичных сценах. Мы хотели показать скриншоты взрыва при аппаратном декодировании, но из-за высокого разрешения картинок мы не смогли выложить их на наш сервер. Поэтому они выложены на ZumoDrive , желающие могут с ними ознакомиться самостоятельно.

В заключение, когда вы используете FrameShots, не установив ffdshow, то это будет сделано по умолчанию следующим декодером. У нас это был Н.264 декодер из нашей референсной установки MainConcept v2.0.0.1555. Эта версия декодера нам неизвестна, поэтому мы использовали её "втемную", отключив аппаратно-ускоренное декодирование в нашем сравнении качества декодера MainConcept H.264. Мы знаем, что в ffdshow недавно добавили ограниченную поддержку DXVA, но этот элемент ещё не входит в последние стабильные сборки.

На рынке есть целый ряд программных декодеров. Мы использовали только некоторые отладочные варианты ffdshow (сборка 3154) и MainConcept для сравнения; все программные декодеры различны.

После этого уместно продемонстрировать интересный график. Оказывается даже с одинаковыми программными декодерами можно получить различные результаты. Когда проигрывается незащищённое видео Н.264 в PowerDVD (сборка 10.0.2325.21), результаты для аппаратно-ускоренного декодирования показывают спад использования процессора до 5% для всех трёх графических конфигураций.

Нечто странное происходит, когда отключается аппаратно-ускоренное декодирования. Теоретически, всё должно происходить на процессоре Core i5-2500K. При работе только с программным декодированием происходит совсем иное. Снижение активности в GeForce GTX 580 приводит к снижению уровня использования процессора (не забывайте, декодирование происходит на процессоре). При использовании интегрированной графики Intel загрузка возрастает незначительно. Вероятно, это результат использования ресурсов HD Graphics, которые в другом случае были бы высвобождены для ядер процессора. А вот добавление карты Radeon HD 6970 повышает уровень загрузки процессора более значительно. Если вы посмотрите на график, то увидите всплески производительности, которые происходят в тех местах, где программный декодер работает с обработкой сцен, требующих большую производительность.

Скорее всего это была проблема в Cyberlink. Мы запросили у Corel копию WinDVD. Результаты говорят сами за себя. Независимо от того, какой GPU вы используете, загрузка CPU должно быть одинаковой при условии, что вы используете один и тот же программный декодер.

Сжатие видео и декодирование | Транскодирование Blu-ray

Мы выяснили, что есть чёткие различия между аппаратно-ускоренными декорами и даже между программным декодированием. А что же со сжатием видео? Чтобы ответить на этот вопрос, мы начинаем следующий этап тестирования.

Мы использовали лучшие карты, которые можно купить – AMD Radeon HD 6970 и nVidia GeForce GTX 580.

Когда речь заходит о транскодировании видео, MediaEspresso – единственная программа, которая смогла обработать Iron Man на Blu-ray размером 31.2 Гбайт. При работе MediaConverter 7 и Badaboom мы столкнулись с ошибками аудио-кодека, поскольку никакое ПО не распознаёт TrueHD. Важно отметить, что если вы используете Quick Sync, то вам придётся выбрать установку Performance или Quality. Это недоступно, если вы работаете с картами nVidia или AMD.

Как показывают результаты наших тестов, самое узкое место возникает на стадии декодирования. Если вы используете кодирование АРР или CUDA, то получаете небольшой выигрыш (больше для CUDA), но самый большой выигрыш получается, если вы включаете аппаратно-ускоренное декодирование. Использование кодирования АРР и UVD 3 на карте Radeon – худшее, что вы можете сделать для производительности. Любая другая комбинация – быстрее, включая использование только программного кодирования. С помощью CUDA вы получаете мизерный выигрыш в 4 секунды с включёнными аппаратными возможностями (по сравнению только с PureVideo).

Оборудование Intel Quick Sync демонстрирует более впечатляющие показатели. А при настройках "Quality" используется не такое агрессивное масштабирование. То, что мы видим – это эффект более низкого битрейта при использовании программного кодирования.

Хотя клип H.264/AC3 BDAV на 665 Мбайт имеет такой же битрейт, что и фильм на 31.2 Гбайт, видно, что аппаратно-ускоренное декодирование даёт гораздо лучшие результаты на Radeon HD 6970 и GeForce GTX 580. Core i5-2500K с технологией Intel Quick Sync даёт существенный прирост только с настойками "Quality" и аппаратным ускорением кодирования.

Отметим, что ArcSoft MediaConverter использует либо аппаратное либо программное транскодирование. Он не обеспечивает гибкого управления, которое предоставляет CyberLink. Но с ним транскодирование идёт гораздо быстрее. Если перейти к цифрам, то оказывается, что MediaConverter лучше оптимизирован для многопоточности. Речь идёт о преимуществе более чем минута по сравнению с MediaEspresso.

На примере небольшого клипа видно, что AMD APP работает быстрее, чем чисто программное решение, но не намного. К сожалению, использование АРР в MediaConverter всё же медленнее, чем работа только на процессоре. Как это ни удивительно, но лучшие результаты получаются с более старым компьютером и более медленным процессором, но с современной графической картой. Новый Core i5-2500K – просто слишком быстр.

В итоге – Quick Sync заметно превосходит CUDA и АРР по производительности кодирования и декодирования. Различия между AMD и nVidia менее очевидны, их сложно вывести из плученных результатов. Может быть причина в использовании файлов Blu-ray с высоким битрейтом?

Сжатие видео и декодирование | Скорость транскодирования небольших клипов

Мы загрузили три клипа с разрешением 1080р (контейнер Н.264/MOV) из набора трейлеров с сайта Apple, чтобы использовать клипы с битрейтом, более пригодным для хранения (около 9.5 Мбит/c), с которыми мы сталкиваемся ежедневно. Поскольку мы более заинтересованы в работе GPU, будем использовать только аппаратное кодирование, когда есть такая возможность.

Когда речь заходит о более мелких файлах и меньших битрейтах, то использование только CPU всегда оказывается более медленным, чем использование GPGPU или аппаратное кодирование с использованием Quick Sync.

Единственное исключение здесь – это AMD в MediaConverter. По какой-то причине мы получаем большее время транскодирования, когда выбираем декодирование на базе UVD3 и АРР-кодирование. К сожалению, MediaConverter не позволяет раздельно устанавливать эти параметры, поэтому мы не можем узнать, какая часть конвейера замедляет весь процесс. Мы уведомили компании AMD и Arcsoft о ситуации и они ответили, что работают над разрешением проблемы. Этой аномалии нет в работе CyberLink MediaEspresso.

Сжатие видео и декодирование | Качество транскодирования

Теперь пора переключиться с источника Blu-ray на трейлеры, которые мы транскодировали на предыдущей странице. Поскольку мы указываем ссылки на источник контента и результаты нашего транскодирования, мы не можем использовать оригинальный контент Blu-ray из-за закона об авторских правах.

Прежде всего, хочется поблагодарить компанию Elemental Technologies за разрешение первого тестирования Badaboom 2.0. Компания пока находится на начальной стадии развития, поэтому всё это – предварительные результаты. Но мы решили включить эту предварительную версию в наш тест, поскольку именно её настоятельно рекомендует компания nVidia после обсуждения наших тестов Brazos. Поэтому несмотря на ранний этап своего развития именно этот продукт может ответить на наши вопросы, связанные с качеством. Но поскольку мы работаем с бета-версией, не будем представлять результаты тестов.

AMD APP

Здесь две аномалии. Вы наверняка заметили, что лампочка на ошейнике Дуга ярче в MediaConverter, а в Badaboom этого кадра нет (там просто другое изображение). Обе программы генерируют файл, которые не совпадают друг с другом, это значит, что где-то происходит смещение. И это не результат человеческой ошибки, поскольку мы используем обработку конкретных фреймов в режиме off-line. Есть нечто специфическое в использовании CUDA в MediaConverter и Badaboom. Учитывая, что Elemental находится в стадии разработки, вполне можно ожидать некоторых ошибок и проблем, связанных с энтропией, которые влияют на процесс сборки, но их несложно устранить. Проблема с MediaConverter более серьёзна, поскольку мы используем общедоступную версию для использовании CUDA (по непонятным причинам последняя бета-версия не распознаёт GeForce GTX 580).

Забыв о проблемах "трекинга", посмотрим на низкое качество результата после MediaEspresso. Оно проявляется в сценах с панорамированием или когда есть плавный переход в следующую сцену. CUDA выглядит лучше при работе с MediaConverter, чем с MediaEspresso, но лучше всего выглядит результат после Badaboom. Это говорит о том, что есть какие-то проблемы с использованием CUDA в двух первых приложениях. Стоит отметить и то, что видео после Badaboom и MediaConverter демонстрируют небольшие проблемы при предсказывании движений, которых нет в MediaEspresso.

Intel Quick Sync

Результат работы MediaEspresso – лучший из всех трёх тестируемых программ. Конечно трудно выбрать лучшее среди столь одинаковых изображений, но этому можно только радоваться. Если забыть о проблемах с "трекингом", результат у Badaboom чуть более зернистый, чем три остальных. Даже установки параметров "Performance" и "Quality" для MediaEspresso демонстрируют меньше отличий, чем можно было предположить. Без сомнения, результат от установок Quality использует больший размер файла, но различие можно будет заметить только в областях активного движения или с маленькими деталями (волосы, к примеру).

Сжатие и декодирования основным процессором

Если вам надо выбрать лучшее качество видео на выходе между вариантами с использованием аппаратного обеспечения с програмным, то надо обратиться к решениям AMD и Intel (Quality setting) в Cyberlink MediaEspresso, решению от Intel в Arcsoft MediaConverter и решению от nVidia в Badaboom.

Худший выбор

Худший (или может быть наименее оптимизированный) выбор – это решение Intel в Badaboom, оборудование AMD в MediaConverter и nVidia CUDA в MediaEspresso. Различие между худшим и лучшим вариантом в MediaEspresso и MediaConverter достаточно велико и заметно. В Badaboom различие между CUDA и Quick Sync незначительны.

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

Сжатие видео и декодирование | Как же всё сложно

Мы много часов провели в беседах с экспертами, включая сотрудников из CyberLink, Arcsoft, Elemental, nVidia, AMD, Microsoft и Intel, о проблематике тестирования качества транскодирования. В результате этих обсуждений возникла потребность прояснить ситуацию. Прочитав эту статью, вы можете сделать вывод, что "видео у AMD и Arcsoft несколько туманные", а "nVidia и MediaEspresso вместе выглядят очень чётко". Но это – лишь малая часть истории, она не даёт представления о полной картине.

Мы ставили перед собой задачу разобраться в том, можно ли с уверенностью сказать, кто из nVidia CUDA, AMD APP и Intel Quick Sync даёт наилучшее качество при транскодировании видео. Оказалось, что у этого простого вопроса может не быть чёткого ответа.

Почему? Давайте начнем с ПО. Во-первых, у всех трёх приложений, которые мы использовали для этой статьи, различные установки для кодирования видео на iPad (и для многих других профилей работы). Например, величина битрейт по умолчанию в MediaEspresso – 3 Мбит/с. MediaConverter использует 4 Мбит/с. В Badaboom – 2.5 Мбит/с. Но даже, если все эти установки мы сделаем одинаковыми и равными 3 Мбит/с, а также приравняем и все другие параметры, то сравнение всё равно не будет правильным. Чтобы установить одинаковый битрейт в MediaConverter, мы должны создать обычный профиль H.264 MP4 и вручную выбрать битрейт вместе с другими параметрами. Это действие меняет весь процесс. Когда вы выбираете профиль, есть параметры, которые не задействованы в пользовательском интерфейсе, но влияют на результат. Поскольку MediaConverter больше не использует профиль iPad, это сразу становится недостатком.

Во вторых, надо поговорить о кодировщиках и декодировщиках. Практически невозможно выбрать один наилучший декодировщик при таких несопоставимых результатах. Например, если вы используете HD Graphics 2000 или 3000 в MediaEspresso, Badaboom или MediaConverter, вы всегда используете кодировщик и декодировщик из библиотеки Intel MediaSDK. Cyberlink использует только свои проприетарные кодировщик и декодировщик на оборудовании AMD и nVidia. Badaboom вообще не поддерживает кодирование на базе АРР, а CUDA-кодировщик был разработан компанией самостоятельно. А вот Arcsoft и Cyberlink используют референсную библиотеку nVidia, чтобы транскодировать на nVidia GPU. Если вы смотрели наши ролики, то знаете, что использование одной и той же библиотеки не гарантирует одинаковый результат.

Даже если игнорировать проблемы выделения конкретного кодировщика, сравнение различного оборудования в одном и том же приложений может привести к большому количеству проблем. Для кодирования, управление скоростью, выбор моды (Inter/Intra, 4x4, 8x8, 16x16 блоков), опция кодирования (B frame) – всё это влияет на качество видео. Один из программистов как-то отметил, что параметры кодирования, используемые в разных библиотеках, могут не быть одинаковыми. Например, может быть так, что MediaEspresso использует макроблок 4х4 в АРР и 8х8 – в CUDA.

И всё-таки: отчего же получается плохое видео? Один из производителей ПО рассказал нам, что он использует Elecard StreamEye Studio, чтобы анализировать транскодированное видео. Но что проиcходит, когда под вопрос встают входные материалы? Когда вы транскодируете видео, сначала надо пройти декодирование, а затем – кодирование. После этого, каждое активное действие с транскодированием видео заставляет его пройти через другой декодер и определенный рендеринг. Это означает, что вы смотрите на свои данные через четыре линзы. Если вдруг возникает ошибка, откуда она берется? Научный подход советует нам изолировать как можно больше переменных. Это означает, что мы не должны менять разрешение при транскодировании, не должны менять скорость передачи кадров или профилей CABAC. Только при тестировании параметров один за одним удастся изолировать реально действующие факторы. В любой ситуации нельзя забывать, что мы просматриваем видео через несколько "линз", даже когда мы используем нечто столь же хорошее как StreamEye Studio. В этом случае вы используете декодер Elecard и специфический рендеринг, чтобы получить кадры для анализа.

Ни одна компания не дала нам доступ к своему кодировщику, так, чтобы мы могли извлечь кадры из буфера, поэтому мы не смогли оценить изображения, не изменённые плеером (то есть после декодирования и рендеринга).

На уровне кодека обычно используется анализ PSNR (пиковое отношение сигнал/шум), но также, в случае работы со звуком, этот анализ не точный. Этот метод конечно хорош, но имеет очень мало промышленных стандартов. Различные инструменты вычисляют PSNR по-разному. Один из разработчиков рассказал нам, что компания Textronix однажды продала устройство за 50 тысяч долларов для анализа изображений, но при этом вы могли использовать только референсные изображения компании. Какой же вывод можно из этого сделать? Эксперты AMD рассказали нам, что инженеры компании используют измерения PSNR, только чтобы убедиться, что используется одинаковый протокол и точки отсчёта.

Кое-кто говорил, что анализ H.264 проще, чем MPEG-2. Естественно, стандарт H.264 имеет более жёсткие требования декодирования, в нём допускается меньше погрешностей (по факту всё происходит с точностью до бита). Ещё один из методов – проанализировать поток данных (bitstream), чтобы понять совместимость результата, но это не скажет вам ничего о качестве видео – хорошее оно или плохое. Несовместимый поток может выглядеть хорошо, а совместимый – плохо. Это может происходит в таких видео, где есть ошибки треккинга.

Ситуация усложняется ещё и тем, что хорошие декодеры (программные или аппаратные) могут быть плохи для кодирования. Это означает, что видео, где вы можете видеть какие-то визуальные артефакты могут появиться в VLC и не появиться в PowerDVD или WMP12. Нет универсального кодека, который мог бы быть лучшим во всём, поэтому всегда будут ошибки в изображении, в зависимости от транскодирования и работы декодирования/рендеринга для воспроизведения картинки. Поэтому даже если нашли проблему в кодировании и декодировании, как вы отличите плохое видео от хорошего видео? Аппаратное декодирование типа UVD или PureVideo корректирует ошибки на уровне промежуточного ПО в процессе работы (как память с ЕСС), поэтому даже если вы программист, пишущий ПО для кодирования, вам сложно будет понять, где возникают ошибки.

Естественно, вы можете отличить видео 360p от 1080p. Но сможете ли вы отличить плохую работу транскодирования на разрешении 480р от хорошей? Если у вас немного параметров для оценки качеств видео, то эта задача становится сложной. А что это значит для вашей семьи – мамы, дедушки или младшего брата? Как они могут понять, что полученное из простого для пользования транскодирования видео, это то, что они хотели увидеть?

По мнению экспертов, это основной вопрос всей видео-индустрии. Если у вас нет времени на подробное объяснение всех тонкостей ответа на него, то короткий ответ – вы можете сделать вывод, когда увидите очевидную ошибку. "Вы можете узнать ответ только когда посмотрите". Именно это и произошло с CUDA-кодированием в нашем обзоре платформы Brazos. Здесь не надо смотреть весь ролик, чтобы понять, что ситуация достаточно плоха.

Все это, конечно, можно отнести к мелким придиркам и обвинить автора в том, что он приводит примеры для увлекательного рассказа своей истории. Но если вы транскодировали большие объёмы видео, то знаете, что индустрия очень тщательно изучает все кодеки. На подробное изучение кодировщиков и декодировщиков тратятся тысячи долларов.

В наших тестах мы обнаружили, что 3-5% транскодированного видео имеют очевидные ошибки. В кадрах, показанных чуть выше, ясно видны артефакты, которые можно описать как срыв изображения в WMP12. В этом можно обвинять процесс рендеринга, но это не всегда правильно. Для этого конкретного видео – это ошибка программного декодирования, поскольку артефакты появляются только при проигрывании в WMP12 с HD Graphics 3000.

Аналогичная ошибка появляется и в видеотрейлере Up!, что свидетельствует о плохой работе транскодирования. Этот артефакт появляется во всех видео-плейерах, независимо от конфигурации оборудования.

Сжатие видео и декодирование | Внутри чёрного ящика

Итак, мы установили, что анализ качества видео – дело непростое, пока вы не рассматриваете конкретные ошибки. Но каким образом nVidia и AMD работают с транскодированием с использованием GPU? Более конкретно: как они берут последовательный процесс и превращают его в параллельный?

Многопоточное кодирование – процесс динамический. Когда программное кодирование оптимизировано для многоядерного процессора, каждый поток стремится кодировать конкретный кадр. Однако, весь процесс многопоточной работы контролирует операционная система. Это означает, что программист не может управлять тем, какой из потоков закончит свою работу первым и выделять ресурсы процессора в соответствии с этим. Например, первое ядро может завершить кодирование кадра 80, хотя второе и третье ядро ещё не завершили кодирование кадров 78 и 79. Поскольку для кадра 81 нет специального буфера, битрейт для следующих кадров меняется. Это необходимо делать, чтобы оптимизировать работу в нескольких потоках, иначе они будут ждать один другого и всё это будет очень похоже на работу одного ядра с одним потоком вычислений. Именно поэтому кадр попытка №1 транскодирования кадра 81 отличается от попытки №2.

Это один из путей программирования для многопоточного кодирования. Программисты используют и другие стратегии. Например, вы можете разделить вашу работу на срезы и иметь n срезов на кадр. Вы можете также приписать определённые части конвейера декодирования каждому потоку (например, поиск движений, кодирование макроблоков, кодирование энтропии, управление скоростью). У каждой стратегии есть свои преимущества и свои недостатки. Для адекватного масштабирования, особенно с системами, где есть много процессорных ядер, вы должны делить работу на кадры, поскольку для завершения работы каждой порции конвейера кодирования требуется разное время. В этом процессе можно выделить общую часть для всех кодировщиков – управление потоком данных, но она может быть связана с такими конкретными операциями, как поиск движений и их оценка.

Не только это отличает один кодировщик от другого. Этапы в конвейере кодировки могут не отличаться последовательностью, но весь процесс может. Такие операции, как поиск движений могут существенно различаться у разных кодировщиков. Можно говорить о стартовой точке, основанной на предыдущем кадре или на соседних макроблоках. Вот что говорит Майк Шмит, старший менеджер по работе с цифровым видео компании AMD: "Если вы обрабатываете много кадров (или макроблоков) одновременно, у вас нет возможности использовать predictor. Зная об этом, программисты могут форсировать работу последовательного пути без predictor, чтобы получить одинаковый результат. Этого не должно происходить в реальном коде, поскольку это более медленный вариант работы".

MediaConverter – единственное ПО из трёх, которое позволяет вам выбрать, сколько ядер вы хотите использовать для транскодирования. Если вы работаете на одном ядре, то будете каждый раз получать такой же файл. Это разумно, поскольку всё происходит последовательно. Кадр 81 зависит от кадра 80 находящегося в буфере.

Какое всё это имеет отношение к графическим процессорам? Очень большое. Мы как-то случайно провели тестирование дважды. Размер файла после GPGPU и аппаратного кодирования были одними и теми же, независимо от того, сколько раз мы его обрабатывали. Например, когда производится кодирование на базе Quick Sync и декодирование с помощью MediaConverter, Badaboom или MediaEspresso, мы каждый раз получим одинаковый размер файла. Почему же параллельный процесс ведёт себя, как последовательный?

Естественно, всегда есть вещи, которые выполняются последовательно, как сборка кодированных кадров. Но одинаковый размер файлов означает, что кадр №80 всегда кодируется одинаково. Это происходит и при однопоточном транскодировании. Что же там происходит?

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

Очень трудно было найти ответы на эти вопросы, пока мы не обратились к Майку Шмиту, который руководит группой, занимающейся исследованиями в сфере видео-кодеков. Вот что он сказал: "Хотя всё, что связано с GPU, это параллелизм, процесс аналогичен одному ядру с инструкциями SSE… это 16-битные инструкции. По сути дела, один способ (не единственный способ) программировать шейдеры на GPU – программировать их, как будто внутри SSE есть тысяча инструкций SIMD. Таким образом детерминизм сохраняется и нет элемента случайности. В итоге всё зависит от программиста и от того, как он решает проблему".

Сжатие видео и декодирование | Длинное заключение

Пришло время перевести все сказанные слова в качество картинки. По сути дела, это заключение.

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 – это другая история. Когда речь заходит о качестве видео, вполне можно было бы поговорить о качестве звука. Но мы хотели максимально упростить наше обсуждение, поэтому ограничили его.