Ждём Ваших отзывов о материале.

Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
За статью можно проголосовать на странице материала.

и платить за всё придётся конечному покупателю, кажется тут конкуренция только вредит

давно пора.
кодировать на проце сущий ад

Это хорошо. Но до появления контента в 8К ещё долго. Даже 4К совсем мало.

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

Так или иначе, уверен, что и до новости никто не сомневался, что все 3 производителя достаточно оперативно будут внедрять поддержку всех новых форматов. Технологии у всех троих для этого есть. И, если ещё вчера AMD была тут бесспорным лидером, то сегодня возможности всех троих производителей видятся примерно равными.

Этот кодинг по факту нужен единицам, вот энергопотребление бы поскромнее сделать...

Сегодня день nvidia?

уже давно, как Кеплер вышел

Мысли не понял.
Что случилось с выходом Кеплера?

Уж лучше нвидиа, чем эппл!

Какой-нить интельский квик синх (когда внедряд поддержку 265 аппаратную) всё равно опять быстрее будит.
А вообще я думаю тем кому нужно максимум качества будут конвертировать на проце))
Ну и с одной стороны лучшее сжатие хорошо..... с другой стороны если будит медленно перематываться (долго тупить) и слишком уж грузить проц - это будит пичально.

palegamer, в сети по-любому есть уже куча видео на этом кодеке. Можно посмотреть насколько тормозить будет. По крайней мере для 1080p на H.265 не тормозит. Для 4К и 8К не знаю.

знаем мы этот VP9. такой тормоз, и не умеет кодировать в многопотоке.

Месье не знает что такое эталонная реализация?

Добавлено спустя 1 минуту:


Этот квик синк читерит, хоть и быстро кодирует. Битрейт получается слишком большим.

Можно пруфы этого?

DXVA Checker на Хасвеллах и Кавери уверенно пишет HEVC_VLD.
Т.е. дело только за сертификацией.
И, представляя себе возможности конвейеров AMD и Intel, нетрудно понять, что они легко справятся.
Вопрос лишь в максимальном разрешении и числе потоков.
Тут на помощь приходит логика: если QS имеет производительность по меньшей мере в 8 раз выше, чем необходимо для декодирования AVC, то, очевидно, что и с H.265 он справится без каких-либо проблем.
Про UVD же - именно он версии 3.0 используется в процессорах Qualcomm, в которых заявляется полная поддержка. Очевидно, что любой GPU AMD тоже справится. В обоих случаях вопрос программной поддержки.

У nVidia же сложнее, поскольку в VP6 ставка при создании конвейера была сделана на iDCT (это позволило подтянуть качество до уровня конкурента), но VLD возможности ограничены. Их хватило на поддержку 4К AVC, но это предел. Т.е. для поддержки новых форматов при высоких разрешениях понадобится новый блок PureVideo. Старые вряд ли удастся чему-то научить. В лучшем случае, они возьмут на себя компенсацию движения и деблокинг, но, зная Хуанга, он нарочно не станет этого делать, чтобы иметь дополнительный довод к покупке Максвелла.

ShadowTM
Что-то сомнительно. Не знаю как там у Intel, но про AMD я читал, что UVD это fixed-function модуль и для каждого формата надо делать явную поддержку в железе, никакие конвейеры общего назначения там ни при чём. Последний на данный момент UVD 4.2 не поддерживает ускорение HEVC и 4K H.264, однако AMD обещают запилить некий HSA-декодер на OpenCL для Kaveri, вроде как даже опенсорсный.

Вы что-то путаете. UVD - Unified Video Decoder. Его суть как раз в универсальности. Из описания ATi к одной из первых версий:



Если Вы чуть почитаете о принципах работы, то поймёте, что только отсутствие программной поддержки может помешать UVD заниматься декодированием синтаксиса и энтропии (самые ресурсоёмкие задачи), а вот уже для компенсации движения и деблокинга действительно нужны аппаратные изменения. Но эти операции без проблем можно выполнять шейдерами, что нагрузит их едва заметно. Собственно строка из чекера фактически говорит нам именно о такой реализации.
Вот как раз nVidia со своим увлечением iDCT вынуждена будет создавать новый блок.



Можно ссылку на информацию об этом?
Скорее всего, речь идёт о некоем универсальном алгоритме анализа и компенсации движения, а так же деблокинга.
И запилят его не они сами, а foundation, поскольку такие возможности будут очень востребованы для всех членов консорциума.
И я очень сомневаюсь, что это будет опенсорс. Ведь колоссальные деньги в HSA были вложены ради получения конкурентных преимуществ над остальными, а не для того, чтобы раздавать наработки налево и направо.

ShadowTM
Когда я искал по этому вопросу, нашёл только это обсуждение. Упоминание про HSA-декодер встречал в разных обзорах Kaveri, например вот тут в самом низу. Логично предположить, что если бы на основе уже существующего UVD потом можно было бы просто добавить поддержку HEVC через драйверы, писать OpenCL-декодер было бы совершенно незачем.

именно кодить на нём лучше всего (за эти деньги) - быстрее ничего нет, чем полноценный кодек H.264, а не всякие унифицированные.