В сети появился ускоренный при помощи OpenACC x265

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

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

По-моему, и я, и вы сами цитатой из спецификации на них ответили.

1-Моя цель-это сделать так, чтоб ужать видео в 2 раза без существенного потери качества. В силу слабого проца(amd phenom x3 8450), кодирования силами только проца даже на быстрых пресетах, это в лучшем случае 0,6 fps. На пресете placebo, просто астрономическое время(скорость не более 0,07 fps). Результат с прагмами отнють не ванилен, а быстрее в 30 раз имено на этом пресете со включенным фильтром устранения блочности. И причём пресет изменён в исходнике на самый качественные настройки(например -me full --subme 7). Его даже разроботчики не решились воткнуть в пресет, ибо это 3 дня кодирования на 20 минут аниме.

Я думаю вы понимаете, что мой камень не имеет sse4 и выше.

Его даже разроботчики не решились воткнуть в пресет, ибо это 3 дня кодирования на 20 минут аниме.

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

Я думаю вы понимаете

Маниакальное стремление без взвешивания затрат и профита не понимаю.

Потому что оно только с Максвела пошло, не?

уловим ли он на калькуляторе или виден под лупой-это бабушка надвое сказала. Во всяком случае размер менее на 10-20 мб, и качество получше, что приятнее глазу. А 5 сезонов съэкономят таким образом около гигабайта, тоесть ещё 1 сезон можно запихнуть.

А 5 сезонов съэкономят таким образом около гигабайта, тоесть ещё 1 сезон можно запихнуть.

Знаете, что. А я скажу, что это достаточная причина. Играйтесь на здоровье!

c 600 серии. Кеплеры и выше

Качество не фонтан,но вполне сойдет.А захват видео 1080@60 с большим битрейтом без просадок производительности умеет еще кто-то?

c 600 серии. Кеплеры и выше

Кеплеровский nvenc не умеет h265.

1080@60 на том же ютубе - уже стандартная практика

ага, и самое смешное то что самже ютуб не поддерживает vp8 видео в 1080p60 (vp9 вообще никакое не поддерживает)

и про качество «пережатия» ютубом 1080p60 для юзера с 50к просмотрами на видисиках- на уровне «худшего» качества nvenc (битрейт урезается вплоть до 3мб на такое видео)

только для «гигантов» с миллионами просмотров стоит 25мб битрейт

порой лучше 720p30 заливать в активных сценах ради сохранения качества на ютубе

Phenom X3 и видеокарта Nvidia GeForce GT 730

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

пресете placebo

Ну тут вообще но комментс, на просто slow будет значительно быстрее.

Ващет с кеплера, пять лет назад.

Популярности в сети не заметил. Как все стримили h264, так и стримят.

x265

Не нужен. h264 и VP9 хватит всем.

10 bit

Это тем более. Я уже задолбался это добро транскодировать nvenc'ом. Железяки как не жевали десятьбит так и не жуют. И размер файлов в два раза больше.

Зачем два раза одно и то же писать

суровая реальность

Так качество ощутимо разное?

Когда я последний раз смотрел было ощутимо разное. Возможно так же накладывает отпечаток реализация в ffmpeg. В vaapi_h264 три куртилки профайл, битрейт, качество и еще парочка, с таким набором ничего дельного не сделаешь.

10 bit, это смотря на чём смотреть. да и степень пожатия на 10 битах можно более сделать с точки зрения психовизуальных характеристик.

Ну тут вообще но комментс, на просто slow будет значительно быстрее.

Тише ты! Не мешай маньякам оправдывать существование слотовых затычек и новомодных маркетинговых кучек транзисторов на последних камнях Штеуд.

Но это же даёт максимум 10-15% дополнительного сжатия.

Нет. Компенсеация движения даёт от преимущество где-то от 2 до 200 раз в зависимости от содержимого.

Популярности в сети не заметил. Как все стримили h264, так и стримят.

Отвечаете вы не мне, но смею заметить, что ваш оппонент в то сообщение, на которое вы отвечали, вложил тонну сарказма.

Популярности нет вот по каким причинам: - поддержка (программы, сервисы, бытовое железо) пока не столь широка как для H.264; - генитальность компромисса «коэффициент сжатия — скорость сжатия/воспроизведения» (увеличение коэффициента сжатия в 1,5...1,75 раза по сравнению с H.264 hi@l4 при том же SSIM будет стоить чуть ли не 50-кратного замедления при кодировании и двух-трёхкратного замедления при воспроизведении; слотовые затычки помогают немного, да).

Когда, ваш оппонент предлагал посмотреть выше, он, вероятно, имел в виду: 1, 2 и 3. Дополнительно точку зрения отражают посты: А, Б, В, Г и Д.

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

Возможно, реализация в ffmpeg и оставляет желать лучшего, но фундаментальная причина плохого качества «аппаратно ускоренного» кодирования в H.262|H.263|H.264|H.265 лежит в том, что степень сжатия очень серьёзно зависит от оптимальности решения задачи компенсации движения. В большинстве случаев «аппаратно ускоренные» решения (читай — «off-loading») стараются избегать итерационного решения в частности (или обходится минимальным числом итераций) или решения оптимизационной задачи вообще, т. к. итерации и оптимизация вообще очень-очень плохо сочетаются с параллельными вычислениями и, в особенности, с массовым параллелизмом (десятки-сотни-тысячи независимых вычислительных потоков), популярным сегодня.

По утятам в будущем не будут скучать.