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

Блюрик, мобилка, камера, стрим - h265. Делаем рип - работаем с h265. На выходе зачем 20ГБ h264, если можно сделать 10ГБ h265 грубо говоря.


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

Вот вы и доказали окончательно свою неадекватность и осведомлённость в теме, в которой считаете себя про. Любое временное сжатие (h263 h264 h265 и т.д.) однопоточное по своей природе. Т.к. для обработки следующего кадра нужно знать результат обработки предыдущего. И нельзя так просто взять и параллельно гору кадров обработать и сжать. Тоже касается и деления кадра на огромное число частей - чем их больше, тем больше будет косяков и нестыковок. Когда используем более одного потока необходимо использовать предсказания. В вычислительной технике вообще все расчёты выполняются с определённой степенью точности, а не абсолютно точно! И чем больше потоков параллельно, тем больше предсказаний, тем они дальше, тем ниже точность и больше ошибок. По этой же причине х264 всё ещё не могут сделать более 8 ядер поддержку и аппаратные решения так сливают софтовым.
Ну и всё это написано везде, даже в руководствах по h264 и h265. Легко в том числе спрашивается у разработчиков, которые и так давно устали отвечать одно и тоже. Даже в википедиях должно быть расписано. Я тут только на бытовом уровне разбираюсь и не пытаюсь доказывать, что h265 хуже везде, чем h264 или mpeg2...


ну вот и где ваши тесты? а где в интернете? сплошной неадекват идёт.
Смотрю тесты в интернетах - вот жеж блин незадача, а результаты то с моими почти совпадают

На рузенах что 16 ядер, что 32 - одинаковые результаты. А мейнстрим 8 ядер в 265 менее двукратного отставания от 32 ядер. 2700х тоже, что 1700, только частоты выше. И 8700к тут есть и быстрее, чем рузен 2700х при всего 6 ядрах, против 8 за счёт АВХ2. 7960 и 7980 - одинаковые результаты, хотя ядер больше у 7980. И 7960 быстрее, чем 32 ядер рузен в 1.5 раза. А всё потому, что у х265 максимум 16 ядер и инструкции вплоть до авх512 поддерживаются..

еще раз это не отменяет того фактора что скорость и качества обработки будет на таком уровне что этого будет достаточно для слепого сравнения даже на быстрых сценах и только при увеличении на стопкадре можно будет заметить разницу. а если не ковырять грязное белье оно не пахнет (с) народная мудрость
далее поток от того что вы его сжали современным кодеком не станет качественней в нем будет ровно столько же ошибок сколько и было + ошибки кодирования и как мне известно количество ошибок кодирования для н264 и н265 в одинаковых пресетах одинаковое давно не интересовался темой, но вроде там было число 0,0012% это для н264 даже если у н265 оно ниже увидеть все тысячные процента вы не сможете даже обладая количеством глаз как у паука.


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


у вас то совсем никаких (с)

очередной бред... про количество ошибок и константу... У 265 и 264 разная степень сжатия при одинаковом качестве. И качество в отношении видео - это относительная величина, измеряемая метриками и выражаемая обычно в процентах от исходника или в тех же дБ. Если делать в одинаковый размер, то невооружённым глазом разница будет сразу заметна, между 265 и 264 (если не делать в обоих случаях очень высокий битрейт). Если делать в одинаковое качество, то у 265 будет намного меньше вес.
При сажтии всего 2 варианта. Или оно без потерь (самый идеальный вариант) и качество 100%, уменьшение веса идёт за счёт математики с устранением избыточности (тоже, что и архиваторы аля 7zip, winrar и т.п. только заточенные под видео). Или оно с потерями. И количество этих потерь напрямую зависит от алгоритмов и способов применямых и от битрейта.

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

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

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


именно, что у вас никак, только ложь и пустословие. А у меня и самостоятельно проверено с результатами в базе. И в интернетах в обзорах результаты схожие.

derp как же достало что отвечая на пост оказывается его дописали... но вот вам тесты "нормальные" без всякого левого матрешку в мп4 без черт его знает какими настройками и оценка "временем". вот тесты с оверов - https://overclockers.ru/lab/show/92304_ ... luchshe#12 в нормальных человеческих условиях с результатом в к/с... внимание результаты для топа интла это 27,86 а для топа амд 30,6 как не странно победа за амд. Ы

(а на ваше говно я уже задолбался отвечать пойду попью кофейку отвечу когда захочу)

упоротость не знает границ. По твоей же ссылке победа за 8700к с 6 ядер на 5.0 32к/с, против 2700х с 8 ядер на 4.2 31к/с (4.2*8=33.6, против 5.0*6=30). И декодирование 1878 на 8700к 5.0, против 1637 на 2700х 4.2. Хотя больно низкая разница, может версия х265 древняя или настройки хитрые. И там нет 32 ядер рузенов и т.д., чтобы было видно, что производительность перестаёт увеличиваться с ростом числа ядер.
Собственно, я прав, что подтверждено в огромном числе статей, тестов, самими разработчиками и исходный код х264 и х265 можно посмотреть. А с вашей стороны кроме лжи, нуля пруфов и оскорблений нет ничего.
И даже здесь я уже приводил примеры и даже вон чуть выше самовыпил со ссылкой на этот же сайт.

derp так чувак для слепых:

я никогда не писал что внимание зен и зен+ дают равную с кофейниками производительность в авх операциях. напротив я писал что авх128 бит и +2 ядра дают сопоставимый с интел выхлоп что собственно подтверждают адекватные тесты. собственно если интел пойдет на внедрение авх512 в дектопах (в чем я очень сомневаюсь даже 8 ядерники на 2066 платформе и ниже обладают только половинчатой производительностью в операциях авх512 и только 10+ ядер имеют полную) то амд на своих будущих ядрах с авх256 предложит сопоставимую с интел производительность в операциях авх (потому что у интел будет 8 ядер, а у амд 12 вероятней всего).

собственно после этого пояснения ты идешь отдыхать в чс. гудбай)))

очередной самовыпил на одной странице.


и тут же ещё один самовыпил, т.к. 16 ядер интел с авх512 в 1.5 раза быстрее, чем 32 ядра от амд с авх1.

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

Насколько я понимаю при новых фишках NVIDIA (аля RTX), гораздо сильней будет нагрузка на процы, где как раз инструкции avx512 особенно с дополнением nvvi, будут очень актуальными.