Всё зависит от ваших аппаратных мощностей, входного разрешения + фпс и того сколько всего вы на обработку накрутили) Цифры в 13-19 часов - вполне реальны в случае с фулхд 60 фпс, но конечно, всё зависит и от всех раннее перечисленных факторов.
Согласен, но просто у меня по опыту с ld очень сложно иметь дело, бывает буквально день уходит чтобы по итогу ничего не вышло после перебора всех возможных инструментов, в том числе и ручных. Апскейлеры даже обученные именно на разнице ld и web изданий (Pooh V4 например, и он потому и медленнее остальных, что анализа сетке нужно делать очень много), не спасают никак, спотыкаясь об очень простые артефакты. И такие случаи очень сбивают настрой пытаться что-либо делать с ld.
Здравствуйте, я перепровил данный момент, и как оказывается действительно при большем значении quality, и при меньшем значении битрейта получаются результаты лучше, а при большем значении битрейта - наоборот. Исправляюсь, но то что так вышло - наверное наоборот даже хорошо, ведь при недостаточном битрейте лучше использовать quality=10, а при достаточно большом - quality=0, это будет полезной информацией. Спасибо
Я ценю ваш вклад и то что вы сделали, и уже внес нужные правки, где это было обоснованно(по части bframes и битности это так-то зависит от задач и личных потребностей). А дальше предлагаю фокусироваться на конструктивном диалоге, а не на обвинениях и ценить время друг друга.
Я бы теперь на вашем месте этот ответ тоже доверил ChatGPT...
Я не использую его при написании статей. И с вашей стороны не очень хорошо пытаться принизить мой труд и прибавить себе самому веса подобными утверждениями. К тому же даже если вы действительно в этом сомневаетесь, то раннее я уже ответил на большинство из ваших вопросов где мои утверждения вам показались странными или необоснованными.
Или, скажем, утверждение "я отобрал то, что действительно работает и оказывает значительное влияние на качество изображения, во всех случаях" оспаривает авторитет разработчиков x265, потому что bframes > 8 - это больше, чем в пресете placebo - то есть самом медленном из пресетов, в названии которого польза от выбранного "размена скорости на качество" сравнивается с плацебо.
Возможно тут был недочёт с моей стороны, но и нельзя же утверждать что только из-за bframes пресет назван "placebo", и только из-за него в нём сильно падает скорость, просто в ходе моих экспериментов и проектов с сжатием анимации, такое значение показывало более хорошие результаты.
А "Почти никогда не стоит поднимать планку выше 8 бит" возвращает читателя во времена до H.265. Дело в том, что в H.264 10-битность была в профиле "High 10", для которого нет аппаратных декодеров (не существует то ли вообще, то ли в потребительских устройствах) - телевизоры и приставки в софтовом декодировании захлебнутся, видео будет тормозить, зрители не будучи анимешниками такую тягу к прогрессу не оценят. С приходом H.265 разрядность в 10 бит стала доступна в профиле "Main 10", аппаратные декодеры в него смогли, все вздохнули с облегчением, жить стало лучше, появилась надежда. Проще говоря, предотвращение бандинга теперь стало возможно простым поднятием разрядности, а не дизерингом, расходующим больше битрейта.
В данном случае я пришёл к выводу что 8-битность лучше, поскольку в случае с моим 4к тв, попытка воспроизведения 10-битного и 12-битного видео приводила к подсвинаям или вылетам в видеоплеере VLC. Но я знаю о очевидных плюсах 10 бит кодировании, также это было видно на приложенном изображении, но и также очевидно что его нельзя назвать универсальным параметром.
(а я на всякий случай в вебархив положил)
Опять же, я признаю что на данный момент часть с GOP кажется спорной, но я по моим воспоминаниям, точно его использовал, и точно в этих же командах не было других параметров способных повлиять на результаты, чтобы это было заметно при сравненнии картинок. Возможно что действительно gop был нерабочим параметром, но у меня это не вызывало сбоев при кодировании, что весьма странно и в этом я сейчас с вами согласен.
Эта статья же сгенерирована? Целиком? Страшно предположить, но сгенерированы даже картинки со сравнением результатов?
Не вижу смысла рассматривать данное утверждение. Я человек и могу тоже могу ошибаться и что-то интерпритировать неправильно.
Например, GOP - это не Graphics Output Protocol (исправлено, но...), а Group of Pictures (группа кадров), она не специфична для аппаратного кодирования, а следует из идеи межкадрового сжатия ([IBBPBB]I... - вот [GOP], его длина 6 кадров aka keyframe interval), длина может настраиваться в разных энкодерах и по-разному (минимальная/максимальная/фиксированная, для поиска по ffmpeg: -g, -keyint, -keyint_min, -strict_gop), опция из статьи не существует.
Нет, серьёзно, опция не существует. Unrecognized option 'gop'. Гитхаб по repo:FFmpeg/FFmpeg /"-?gop"/ тоже говорит, что не существует (он найдёт только -header_insertion_mode gop). ffmpeg -h encoder=hevc_amf > hevc_amf.txt - пусто. Команда невалидная, но картинка с результатом есть. "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?".
Хороший вопрос насчёт gop, я писал статью несколько месяцев назад, и абсолютно уверен что использовал gop, оттуда же и картинки, но сейчас я действительно не могу найти такой опции. Мне надо понять как так получилось. Уверенность конечно - не оправдание, но я буду очень удивлён если это окажется не так. Да и банально какой смысл мне набивать статью чем-то несуществующим и к тому же писать для этого недействительную команду в то время когда все остальные команды рабочие?
Однако до программного [аппаратного, по контексту] кодирования с доступными более чем 200 параметрами [господи, зачем?] ещё далеко.
Почему я не могу это упомянуть? Это ведь действительно так. Я кстати по вами раннее приведённой команде "ffmpeg -h encoder=" и полчуил количество параметров для аппаратных решений, а вот для программного пришлось полезть в документацию x265.
AMF - не блок GPU, а библиотека для аппаратного энкодера VCE, который появился на кристалле в 2011, до 2016 к нему лишь получали доступ не через AMF.
Да, данный момент я действительно не учёл, и на вики об этом есть информация. Я не проверил данный момент, а на гитхабе amf об этом напрямую не упомяналось. Но я нашёл самый ранний релиз там же, поэтому и не полез на вики касательно данного момента. Отталкиваясь от этой даты я нашёл и дальнейшие детали, относительно того какие линейки видеокарт тогда выходили и т. д.
в случае аппаратного кодирования даже процессор пятилетней давности будет превосходить его [...] в возможностях самих специализированных блоков
Имелось ввиду что новые алгоритмы добавляются более часто чем в аппаратных решениях, и что т.к. программный кодек един для всех прозиводителей процеесоров, то и самих возможностей у него больше, в отличие от разных аппаратных решений для того же hevc, хотя это утверждение можно трактовать как полуправду.
Я бы хотел, но так страница статьи будет не очень хорошо грузится на телефонах по мобильной связи. Более практично использовать картинку весом не 2мб, а 200кб, при этом сохраняя высокое качество.
Group of Pictures, да это действительно серьёзная ошибка, уже исправил. Возможно я немного недосмотрел, даже не знаю как так получилось. Ну с кем не бывает - как говорится. И какая-то у вас слишком критическая оценка, чтобы только из-за этого называть статью "несерьёзной")
Сжатие практически отсутствует, я своим глазом это отлично различаю. Как раз для тех у кого меньшая насмотреность, я в некоторых местах дополнительно сделал данные пометки
Вы правы в том, что это не бинарная совместимость в строгом смысле слова - я использовал этот термин как упрощение. ROCm/HIP обеспечивает совместимость на уровне исходного кода через автоматическую конвертацию, а не прямое выполнение CUDA бинарников. При этом суть остаётся той же - разработчику в большинстве случаев не требуется вручную переписывать код, так как HIP автоматически handled большинство различий в архитектурах.
Что касается технических различий (LOP3, размеры shared memory и т.д.) - они действительно есть, и именно поэтому используется промежуточный слой трансляции, а не прямое исполнение бинарного кода. HIP/ROCm абстрагирует эти различия, позволяя достичь практически той же цели - запуска CUDA кода на AMD GPU с минимальными модификациями.
Всё отлично в моём случае. Но опять же из-за того что невозможно натурально сравнить работу напрямую и через ROCm, то нельзя точно говорить о каких-либо цифрах, неизвестен процент потерь. Я догадываюсь что производительность около 80-95%, в той же stable diffusion моя RX 6600 выдает результаты скорости, относительно сопоставимые с RTX 3060.
Всё зависит от ваших аппаратных мощностей, входного разрешения + фпс и того сколько всего вы на обработку накрутили) Цифры в 13-19 часов - вполне реальны в случае с фулхд 60 фпс, но конечно, всё зависит и от всех раннее перечисленных факторов.
Честно говоря, я подобными проектами не занимался, хотя в одной из статей у меня человек о чем-то подобном писал @ED-209
Ууу да, я эту серию видео смотрел))). Но сам пока нигде вживую не видел и в инете тоже(
Согласен, но просто у меня по опыту с ld очень сложно иметь дело, бывает буквально день уходит чтобы по итогу ничего не вышло после перебора всех возможных инструментов, в том числе и ручных. Апскейлеры даже обученные именно на разнице ld и web изданий (Pooh V4 например, и он потому и медленнее остальных, что анализа сетке нужно делать очень много), не спасают никак, спотыкаясь об очень простые артефакты. И такие случаи очень сбивают настрой пытаться что-либо делать с ld.
Здравствуйте, я перепровил данный момент, и как оказывается действительно при большем значении quality, и при меньшем значении битрейта получаются результаты лучше, а при большем значении битрейта - наоборот. Исправляюсь, но то что так вышло - наверное наоборот даже хорошо, ведь при недостаточном битрейте лучше использовать quality=10, а при достаточно большом - quality=0, это будет полезной информацией. Спасибо
Я ценю ваш вклад и то что вы сделали, и уже внес нужные правки, где это было обоснованно(по части bframes и битности это так-то зависит от задач и личных потребностей). А дальше предлагаю фокусироваться на конструктивном диалоге, а не на обвинениях и ценить время друг друга.
Я не использую его при написании статей. И с вашей стороны не очень хорошо пытаться принизить мой труд и прибавить себе самому веса подобными утверждениями. К тому же даже если вы действительно в этом сомневаетесь, то раннее я уже ответил на большинство из ваших вопросов где мои утверждения вам показались странными или необоснованными.
Возможно тут был недочёт с моей стороны, но и нельзя же утверждать что только из-за bframes пресет назван "placebo", и только из-за него в нём сильно падает скорость, просто в ходе моих экспериментов и проектов с сжатием анимации, такое значение показывало более хорошие результаты.
В данном случае я пришёл к выводу что 8-битность лучше, поскольку в случае с моим 4к тв, попытка воспроизведения 10-битного и 12-битного видео приводила к подсвинаям или вылетам в видеоплеере VLC. Но я знаю о очевидных плюсах 10 бит кодировании, также это было видно на приложенном изображении, но и также очевидно что его нельзя назвать универсальным параметром.
Опять же, я признаю что на данный момент часть с GOP кажется спорной, но я по моим воспоминаниям, точно его использовал, и точно в этих же командах не было других параметров способных повлиять на результаты, чтобы это было заметно при сравненнии картинок. Возможно что действительно gop был нерабочим параметром, но у меня это не вызывало сбоев при кодировании, что весьма странно и в этом я сейчас с вами согласен.
В конце ноября статьи уже начнут выходить без этого. Это отнимало слишком много времени, и вы уже не первый кто на это жалуется.
Спасибо за ваш отклик.
Я снёс блок с GOP, пока сам пытаюсь разобраться в ситуации. И спасибо за ваши правки.
Не вижу смысла рассматривать данное утверждение. Я человек и могу тоже могу ошибаться и что-то интерпритировать неправильно.
Хороший вопрос насчёт gop, я писал статью несколько месяцев назад, и абсолютно уверен что использовал gop, оттуда же и картинки, но сейчас я действительно не могу найти такой опции. Мне надо понять как так получилось. Уверенность конечно - не оправдание, но я буду очень удивлён если это окажется не так. Да и банально какой смысл мне набивать статью чем-то несуществующим и к тому же писать для этого недействительную команду в то время когда все остальные команды рабочие?
Почему я не могу это упомянуть? Это ведь действительно так. Я кстати по вами раннее приведённой команде "ffmpeg -h encoder=" и полчуил количество параметров для аппаратных решений, а вот для программного пришлось полезть в документацию x265.
Да, данный момент я действительно не учёл, и на вики об этом есть информация. Я не проверил данный момент, а на гитхабе amf об этом напрямую не упомяналось. Но я нашёл самый ранний релиз там же, поэтому и не полез на вики касательно данного момента. Отталкиваясь от этой даты я нашёл и дальнейшие детали, относительно того какие линейки видеокарт тогда выходили и т. д.
Имелось ввиду что новые алгоритмы добавляются более часто чем в аппаратных решениях, и что т.к. программный кодек един для всех прозиводителей процеесоров, то и самих возможностей у него больше, в отличие от разных аппаратных решений для того же hevc, хотя это утверждение можно трактовать как полуправду.
Я не инжнер по работе с видео.
Я бы хотел, но так страница статьи будет не очень хорошо грузится на телефонах по мобильной связи. Более практично использовать картинку весом не 2мб, а 200кб, при этом сохраняя высокое качество.
Хорошо, вот вам более наглядно, на том же самом jpeg, что и в статье. Говорю же - дело в насмотренности.
Group of Pictures, да это действительно серьёзная ошибка, уже исправил. Возможно я немного недосмотрел, даже не знаю как так получилось. Ну с кем не бывает - как говорится. И какая-то у вас слишком критическая оценка, чтобы только из-за этого называть статью "несерьёзной")
Сжатие практически отсутствует, я своим глазом это отлично различаю. Как раз для тех у кого меньшая насмотреность, я в некоторых местах дополнительно сделал данные пометки
В этом сообщении как раз рассказывается про ZLUDA касательно запуска sd на AMD вк под windows
Вы правы в том, что это не бинарная совместимость в строгом смысле слова - я использовал этот термин как упрощение. ROCm/HIP обеспечивает совместимость на уровне исходного кода через автоматическую конвертацию, а не прямое выполнение CUDA бинарников. При этом суть остаётся той же - разработчику в большинстве случаев не требуется вручную переписывать код, так как HIP автоматически handled большинство различий в архитектурах.
Что касается технических различий (LOP3, размеры shared memory и т.д.) - они действительно есть, и именно поэтому используется промежуточный слой трансляции, а не прямое исполнение бинарного кода. HIP/ROCm абстрагирует эти различия, позволяя достичь практически той же цели - запуска CUDA кода на AMD GPU с минимальными модификациями.
Хотелось бы больше конкретики.
Спасибо! По всей видимости, я действительно зря не решился начать изучать ZLUDA.
Всё отлично в моём случае. Но опять же из-за того что невозможно натурально сравнить работу напрямую и через ROCm, то нельзя точно говорить о каких-либо цифрах, неизвестен процент потерь. Я догадываюсь что производительность около 80-95%, в той же stable diffusion моя RX 6600 выдает результаты скорости, относительно сопоставимые с RTX 3060.