Хахах...где ваши 8 ядер?Интел как обычно штампует клоны процессоров с немного возросшей производительностью.

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

Yalg твич вообще "платформа" а не программа захвата-записи. обс для н264 можно выставить цпу кодирование... более того цпу кодирование выдает качество выше чем аналогичное на гпу но тут вопрос больше "шашечки или ехать".

mag_ai Под посредниками программы и подразумевались.

Как то в KM плеере выставил ЦПУ декодирование с кучей доп. настроек для максимального качества. Так FullHD фильм на i5 3470 стал тормозить! Так что современные ЦПУ по-прежнему крайне слабые для повседневных задач, а приемлемая скорость достигается за счёт ухудшения качества картинки. Иначе будет тормозить. Кодинг и декодинг с помощью ГПУ - это ещё бОльший компромисс с гораздо более суровыми потерями ради доп. ускорения.
-
Современные 4-хядерники отстали от реальности на много лет. А 8-20 ядерники слишком дорогие. Вот к чему приводит отсутствие достойной конкуренции.

Я не спорю с тем, что есть ряд задач, где число ядер пропорционально увеличивает производительность.
Вот только зада, работающих с 1-2 ядрами заметно больше и, в итоге, в усреднённой производительности именно 4 ядра на сегодняшний день являются оптимальным выбором. Ну, кроме тех пользователей, которые выбирают процессор под конкретные нужды, в которых есть профит от числа ядер.

Что же до кодирования, то там давно трудятся GPU, которые никаким CPU не компенсировать. Более того, там есть составляющие, требовательные к производительности одного единственного ядра и получается, что замена 4-х ядерного Intel на 8-и ядерный AMD сегодня роняет итоговую производительность на величины до 40% в зависимости от контента, с которым ведётся работа.

Добавлено спустя 2 минуты 27 секунд:


Заблуждение. Небезосновательное, поскольку был такой период, когда ничего, кроме CUDA енкодера не было доступно, а качеством тот не поражал.
Но сегодня ситуация совсем иная и GPU от CPU кодирования сегодня отличается только затраченными временем и электроэнергией.

Это когда на видиках у младших карт полноценный аппаратный блок, а у старших - программный? По моему до сих пор сохраняется подобная фигня.

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

ага вот только специализированные материалы и программы для обработки видео с вам почему то не согласны. в интернете много сравнений разных алгоритмов и кодеков и стоп сценами. нв и амд кодер делает кучу мусора что н264 что н265 ед плюс н265 на цпу кодируется очень очень медленно и отрывок в 5 минут можно кодировать от 30 и больше минут.

Давайте сначала разберёмся, о чём мы. Мы ведь о кодировании? Т.е. работа по изменению уровня сжатия, разрешения, контейнера, либо декодера. Мы не о декодировании в реальном времени говорим. Которое, кстати, аппаратно так же в большинстве случаев (не во всех, конечно) демонстрирует более высокое качество, чем программное. Более высокое качество при софтовом кодировании возможно лишь на системах с CPU заметно мощнее среднего при весьма заметной нагрузке на CPU. Впрочем, даже тут будет работа для шейдеров, которую CPU просто не в состоянии выполнить в реальном времени.

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

Собственно, есть ещё QuickSync, но это - отдельная тема и там уже всё не так однозначно.

Добавлено спустя 3 минуты 46 секунд:


Пример некорректен. Всё дело тут в отсутствии нормального инструментария по работе с HEVC. Пройдёт немного времени и Cyberlink, Adobe и Sony (думаю, именно в такой последовательности) создадут движки, способные кодировать h.265 контент силами GPU без потерь в качестве.

С AVC тоже всё начиналось с того, что предлагаемые Nvidia и AMD кодеры львиную долю профита в скорости кодирования получали засчёт потерь качества, а не грамотного переложения задач с CPU на GPU.

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

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

... а с авс реплику вообще не понял. налейте мне 100 грамм а то мозг кипит уже.

Как человек, который регулярно кодирует видео в профессиональных целях, уверяю Вас, что не пройденный, а, как раз, наиболее актуальный.
Никто давно на CPU не кодирует. Во всяком случае, сколько-нибудь объёмные материалы. Другой вопрос, что постепенно уходит сама необходимость кодирования, поскольку всё чаще изначальный контент идёт не в RAW, а вполне удобоваримом сжатом формате. Сжатом, кстати, отнюдь не программно.



Повторюсь: заблуждение. Просто Вы давно не интересовались вопросом. Года, например, 4 как. Если не говорить о новых форматах, то на существующих движках качество никак не различается в зависимости от типа кодирования.

ShadowTM недавно кодировал 1+ час видео с бредовой вечеринки (алилуя попросили) на своем задрипаном атлоне х2 встало мне это в 8+ часов с двумя прогонами н264. и чему вы меня хотите научить? что мол программы нужно не так а вот так компилировать? или что? у меня на минуточку 960 максвелл он может аппаратные нв экнодер толку от него мало. на выходе я вижу разницу в качестве...

... но я подозреваю что вы мне щас начнете петь о том что нужен был "топовый паскаль" или купить радеон 400 серии. ага ага прям слушаю. (сарказм)

Вашей 960 более, чем достаточно, чтобы с TrueVelocity перекодить то же за 40-70 мин.
Не стану утверждать, что качество было бы выше, ибо не ведаю, чем и с какими настройками кодили Вы, но с уверенностью скажу, что не ниже, или ниже, но неотличимо глазом.
Причём, если и ниже, то точно не из-за кодирования с привлечением GPU, а, из-за целесообразности конкретных настроек.

Причём, в Вашем случае узким местом станет даже не относительно слабая карта, а CPU (нет AVX и слабый однопоток). Так что замена карты на более мощную, скорее всего, ничего бы не изменила. От архитектуры и новизны карты тоже зависит очень мало, как и от её производителя - важна лишь её производительность в FP32.

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

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

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

Это точка зрения человека, который этим занимается и точно знает, о чём говорит. И "навязывается" она, как Вы выразились, тому, кто где-то что-то читал. Да и то давно. Отчего ж не навязать человеку, который явно заблуждается?



А! Так вот почему во всех студиях повыкидывали серверы с Теслами/Фаепро и заменили их на ноутбуки с QuickSync!
Вам самому не смешно эти глупости писать?
Все эти DXVA блоки используются либо для декодирования в реальном времени, либо, как в случае с QuickSync, кодирования с экономией энергии.
Но сравнивать с кодированием GPGPU - глупо и бессмысленно, поскольку оно и намного универсальнее и быстрее. Не то, чтобы в разы - на порядки, в отдельных случаях.

Например, компьютер из профиля (там сейчас 2хТитан Блэк) собран исключительно для работы с видео. Так вот, кодирование двумя картами в ряде случаев (жирный RAW) приводит к тому, что узким местом становится дисковая подсистема. А это рейд из Реводрайвов.

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

Сколько уже новостей было про перенос анонса этого каби лейка.. А из новшеств будет только более продвинутая поддержка hevc.

Интел как всегда стоит на одном месте в домашнем сегменте, за это время можно было уже продавать i7 с 6 ядрами, а i5 прикрутить hyper-threading к 4 ядрам.