Получить лучшее качество при низком битрейте

Никак, чудес не бывает

Два базовых постулата.

Чем меньше разрешение, тем меньше понадобится битрейт.

Чем меньше в кадре движения, тем меньше понадобится битрейт.

Из второго, косвенно следует, чем лучше освещение, тем меньше «движения в кадре».

Всё остальное от лукавого.

Суть вопроса как сделать супер качество при низком битрейте

Никому не рассказывай, если получится.

Чем меньше в кадре движения, тем меньше понадобится битрейт.

Из второго, косвенно следует, чем лучше освещение, тем меньше «движения в кадре».

Значит с одного и того же pov где-нибудь на диком пляже в штиль днём будет меньше инфы залетать в объектив, чем ночью. Запомнил 🤡

P.s. при тех же настройках но CPU качество лучше в разы

Неё при CPU все подругому

А что ты хотел от встройки? Даже на распоследних дискретках хуже чем у программных энкодеров.

Ещё раз. Это основы. Они не зависят от моды, хайпа, глубины твоего незнания.

Формально, да. Короче выдержка - меньше движения. Короче выдержка - меньше шанс, что шелохнётся камера. Лучше освещение, меньше шумов, а шумы - это «движение-шевеление». По этой-же причине, аналоговое видео и звук «сжимаются хуже».

Аппаратные кодировщики нужны для скорости. Хочешь качество — кодируй софтом. Вот и весь секрет крабсбургера.

можно с цветом поработать, палитру в 4 бита загнать

палитру в 4 бита загнать

по биту на каждый цвет, плюс альфа? :)

При этом все кодеки конвретируют цвета в разные вариации YUV форматов: основная черно-белая картинка (высокого качества) с наложенными цветными слоями (низкого качества и по разрешению и по глубине).

через процессор мне вообще не варик

Почему это?

Купи NVIDIA GT 710 с аппаратным h.264 кодеком. Привет из 2014-го.

Ну игры например постримить

Полностью амудешный ноут

Использовать другой кодек (VP9, AV1, H.265), использовать другие параметры сжатия (в случае со сжатием на CPU можно получить большее качество при том же битрейте за счёт большей ресурсоёмкости кодирования)

при тех же настройках но CPU качество лучше в разы

А это как раз типичная ситуация. Может из-за использования float вместо double (видюхи double очень не любят), может из-за каких-то других «срезанных углов», но кодеки на видюхах обычно дают хуже качество, чем софтварные.

битрейд

Это когда биты набигают и грабят корованы?

Ноуты вообще не компьютеры.

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

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

NVIDIA GT 710 с аппаратным h.264 кодеком.

Там нигде не написано что в GK108 засунули блок NVENC.

Кстати не только у меня такие вопросы по поводу супер качество вот еще

https://www.reddit.com/r/linux_gaming/comments/12egm9g/obs_and_amd/

obs это студия по записи с экрана? Тогда напрямую - никак. Она оптимизирована чтобы кодировать в реальном времени, а значит быстро и некачественно. Аппаратные кодеки почти всегда или всегда дают низкое или среднее соотношение битрейт/качество картинки, так что ситуацию не исправляют.

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

Не, самая важная цифра - показатель качества, опция -q в ffmpeg, «квантователь» или «квантизёр» или как то так. Выгоднее оставить оригинальное разрешение, но опустить качество ещё на пару ступеней до нужного размера - так оно выглядит лучше. Ну и эффективней кодиования с постоянным качеством ещё ничего не придумали.

Видеоэнкодеры уже лет 20-30 как безбожно режут всю это залетающую в объектив инфу алгоритмами поиска движения и дельты с предыдущим кадром. 0,15 бита на пикслель - вполне достаточно даже если это не штиль на пустом пляже.

Она один хрен на порядок-два хуже libx264

алгоритмами поиска движения и дельты с предыдущим кадром

Осталось только научится качественно сжимать этот самый «предыдущий кадр» (I-фрейм). Допустим, фон - это пестрая мелкая листва, или другой пестрый мозаичный узор.

При этом есть разные стратегии сжатия. Например.

• Высококачаственный (и большой) I-фрейм и низкокачественные (мелкие) P-фреймы. Визуально - видео с периодически деградирующей «рассыпающейся» картинкой. По умолчанию, стратегия для лайф-потоков, стримов.

• Средне/низко-качественный (и маленьнкий) I-фрейм и средне/высоко- качественные (немаленькие) P-фреймы. Визуально - стабильная или даже периодически улучшающаяся картинка.

Так софтовые энкодеры умеют! Только они медленные и в реальном времени их ничто не вытягивает.

С пестрой мозаичной картинкой у всех кодеков проблемы, вне зависимости от реальности времени. Намек стримерам, любящим сниматься на нескучном фоне.

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

разница аппаратки и софта

В том, что аппартные реализации применяют стратегии лайф-потоков, например со строго периодическими i-фреймами каждые 1-2 секунды, чтобы только что подключившийся зритель не ждал 30-60 секунд, пока не придет i-фрейм.

А такж настраиваются обычно одной цифрой и просто не имеют высококачественных профилей.

Еще не умеют сжимать в несколько проходов с получением видеофайла заранее заданного размера 700 МБ. :)

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

Тред не читал, общие соображения:

1. Если тебе не стримить, а сохранять результат (и особенно потом раздавать его), то никакого GPU-кодирования. Только CPU. Если стримить, то понятно, можно положить на артефакты частично.
2. Используй CRF, а не заданный битрейт. Сэкономишь на простых сценах, за счёт них пропадут артефакты в сложных. Тебе не нужен чёрный экран в 8000 кбит/с.
3. Используй пресет slow или даже slower для ffmpeg.
4. Если ситуация (совместимость) позволяет, используй h265.
5. Если это всё же стриминг, то стримь в 720p. 720p без артефактов приятнее глазу, чем 1080p с артефактами.

Если писать видео, то перекодируй на медленных пресетах.

Если стримить, то никак если через процессор мне вообще не варик.

...лучшее качество при низком битрейте

Это невозможно.

То есть возможно, но при ряде определённых условий.