24 декабря Архивач восстановлен после серьёзной аварии. К сожалению, значительная часть сохранённых изображений и видео была потеряна. Подробности случившегося. Мы призываем всех неравнодушных помочь нам с восстановлением утраченного контента!
На русскоязычном ютубе вообще, как мне кажется, ни одного внятного видео на данную тему нет, всех интересует только ебучий стриминг. Давайте немножко разберемся, если тут есть хоть немного понимающие ребята. А если в тред заглянет кто-нибудь, кто не по наслышке знает, что такое ffmpeg - будет вообще заебись.
Начнем с простого юзеркейса. У меня есть некоторый видеофайл, который весит дохуя. Нужно его пережать, чтобы место освободилось! Тут возникает дилемма: кодировать на камне или на видеокарте? Хочется чтобы и быстро было, и качественно. Но с моими 4/4 об этом можно только мечтать, хули. Поэтому я выбираю карточку, и тут возникает вопрос. В чем разница?
>>240278716 В целом большой разницы между стримингом и простым сохранением как бы нет - видеопоток кодируется одинаково в любом случае. Просто при стриминге это все сразу летит через интеренет на твич, а во втором - в сектора на диске.
>>240278589 (OP) > А если в тред заглянет кто-нибудь, кто не по наслышке знает, что такое ffmpeg - будет вообще заебись. Эх, где же эти анимубляди, когда они так нужны?
>>240278793 Какая разница где кодировать, о чем ты вообще? Ты вообще знаешь что такое кодеки? Все, что ты получишь от кодирования на цпу — это медленную скорость
>>240279745 Да я это и без тебя знал, ты глупый или слепой? Я спрашиваю, при одинаковом битрейте качество будет одинаковым или как? Плюс nvenc не умеет в crf, плюс это НЕ тот же самый h264, прикольно, да? У них разные пресеты и работают они по-разному.
>>240279927 > качество будет одинаковым или как? Так сравни же вживую. Качество должно быть хуже, но незаметно хуже. Без лупы и прямых сравнений не заметишь.
без тестов на конкретном файле это пук для архива надо жать лагарифом минимум 100мбит битрейт уже норма на сегодня, перестань быть нищим и купи 2 тб диск под помойку
>>240279927 Как уже сказал мой коллега >>240280089, ты несёшь хуйню, и хуйня эта базируется на твоём полном непонимании базовых принципов работы CPU и GPU, а так же методов кодирования. Всё зиждется на каком-то магическом мышлении а-ля «ну там же пресеты разные». Предлагаю тебе простой и доступный твоему уровню понимания эксперимент: просчитай один и тот же ролик на ЦП и на ГП с одинаковыми параметрами экспорта и сравни своё «качество», что бы ты ни вкладывал в это понятие. Алибидерчи.
>>240280522 Я тебе говорю у меня 4 ядра 4 потока, я не могу себе позволить на сутки пеку оставить, чтобы он кодировал камнем нахуй, так что только nvenc. Про fast, medium и прочие пресеты знаю, это вроде так называется.
>>240280601 У тебя и твоего коллеги одна проблема - вы зачем-то представляете, что со мной нужно спорить, хотя очевидно, что я нихуя не знаю и пришел задавать глупые вопросы. Внезапно, да? У вас рак мозга, по всей видимости, поэтому ваш священный долг начать высираться, а не объяснить, в чем я не прав. Долбоебы.
>>240278589 (OP) Не знаю о чем тред, но сделал себе батник, в основе которого лежит функция с такими параметрами: >ffmpeg -c:v h264_nvenc -preset slow -qp 24 -c:a copy Пережал ею все видео на пк, сэкономил почти половину места. Предварительно сравнил под зумом кадры из разных видео, почти не заметил разницы.Некоторые видео вообще сжимаются до 10-20% от изначального размера без потери качества.
>>240280952 Тебе уже несколько раз сказали, но ты же не хочешь слушать и огрызаешься. Просто и понятно: разницы в качестве (при одинаковых параметрах экспорта, разумеется) при кодировании на ЦП и ГП нет, разница только в скорости.
>>240281039 bat-файл переместить в корзину, установить Adobe Media Encoder или любой бесплатный GUI к ffmpeg и забыть про редактирование видео из консоли как страшный сон.
>>240281287 А он как, ещё сильнее жмет? Пробовал, но выдало какие-то лютые артефакты (будто изображение было поделено на квадратные слоты). Может это только из-за плеера, но этого было достаточно, чтобы выбрать 264. >>240281530 Собственно и выбрал 24 как среднее. Попробовал все значения скриптом. >>240281526 Что высрать хотел, срусня?
поясните за hevc, всё чаще на трекере встречаю фильмы закодированные в нём, мой тв их не понимает, присматриваю плеер с поддержкой H.265, так чем он так хорош ?
>>240282033 Ну вот у меня есть тестовый 5-минутный ролик, есть смысл его перегонять в 265й, если он и так пережат? Я так понимаю, смысл имеет только работа с raw файлами...
>>240282312 raw файлы это файлы для энкодеров, тебе работать с ними не надо. RAW весят гигабуты в yuv420 у тебя ffmpeg получает контейнер с видео и выдает на выходе готовый контейнер с видео
>>240278793 На карте не будет B-фреймов и будет хуже качество при равном битрейте. Плюс есть несколько кейсов которые фиксированные кодеки не умеют кодировать (одновременная смена сцены и гаммы, говорящая голова и еще пара).
В целом это нихуя для тебя лично не значит. Если хочешь сэкономить место - жми в 265 в main 10 профиле.
>>240282616 >Если хочешь сэкономить место - жми в 265 в main 10 профиле. main10 это СОВСЕМ НЕ для экономии. зачем ему 10битный цвет? Для экономии места хорошо растягивать GOP до 250 и -bf максимум выставлять, с b-pyramid
>>240282657 Этим гавном никто не пользуется, кроме самих мелкомягких
>>240279294 >да и нахуй он нужен если все будут в будущем переходить на 265 В будущем все будут переходить на AV1, ваш 265 нахуй никому не упал, его УЖЕ вытеснил VP9.
>>240282739 С хуяли загуляли? h265 стандарт только недавно на железом уровне внедрили поддержку. Твой VP9 только на топовом железе работает, а надо для большинства.
>>240282718 >зачем ему 10битный цвет? Затем что в этом профиле есть расширение до 1/8 сабпикселя и блоки предсказания 8х8.
>хорошо растягивать GOP до 250 Можно, но это тянет дополнительные тиры в SPS/PPS, которые поддерживает далеко не все железо в хардварном декодировании. Плюс если контент с быстрой сменой сцен ты наоборот соснешь без IDR фреймов по битрейту.
>b-pyramid Если только в x265, т.е. на проце + ты охуеешь это декодировать, половина тель-авизоров будет воспроизводить с артефактами.
>>240282877 >Твой VP9 только на топовом железе работает На любом железе он работает, алло. Весь ютуб на нём. А ютуб смотрят с любого тапочка. И мобилки и ноутбуки и телевизоры. Все поддерживает аппаратное декодирование.
Если ты про кодирование, то иди нахуй, обычному юзеру это не нужно. Но даже там уже внедряют, последние процы мобилок умеют, десятый ген интела умеет.
>>240283048 >Хардварные энкодеры-декодеры на потребительский рынок подвезут - тогда поговорим Декодеры давно уже. Алёша. Энкодеры в последних поколениях железа завезли. Даже мобильного.
>>240283050 >Весь ютуб на нём. На h264, т.к. HLS/DASH нормально не работают с VP9. А VOD параша нужна постольку поскольку в режиме совместимости для калькуляторов без нормальных хардварных декодеров.
>>240283118 >Декодеры давно уже. Алёша. Которые не поддерживают 2/3 тулов из VP9. Даже хром не юзает VAAPI/HWD для декодирования.
>Энкодеры в последних поколениях железа завезли. На карточка нет и не планируется, на мобилах - опять же максимально урезанный профиль с поддержкой на 3.5 телефонах вроде Google Pixel. Формат проблемный, никто не будет ебаться и делать сопроцессор по объемам как второй SnapDragon много смех.
>>240283278 > по умолчанию считается, что смотрят на топовом пека Пиздатое видео, можно смотреть ток на том компе где закодировано. Неблохо-неблохо.
>>240283396 >не для мобилки же. Мобилки давно умеют в HEVC. Разумеется, декодирование и даже кодирование. Ещё мой iPhone 7 умел, а он вышел нефритовый стержень знает когда.
>>240283634 Это хорошо, что там 900я серия. А если я буду смотреть на rockchip, когда мне завезут хардварный VP9? А может, нахуй не нужон этот проплаченный VP9/AV1?
>>240282419 А у меня как раз дефолтные плееры его корректно отображают, а любимыц Light Alloy хуиту выдает. А ещё подефолту находит только libx265, на h265/h265_nvenc выдает ошибку.
>>240280799 Кулити. Есть трабл: при конверте видео из .webm в .mp4 и использовании дефолтных параметров (т.е. не указывая никаких) на некоторых файлых получаю ошибку > 2 frames left in the queue on closing Сам файл .webm проигрывается без проблем Гугл проверял, везде одна хуйня без нормального ответа Добавление параметра -max_muxing_queue_size не исправляет проблему
>>240284283 Это не ошибка. Внутри .webm (по сути то же самое что mp4) в конце лежит несколько пустых фреймов, в твоем файле. ffmpeg не знает что с ними делать и честно об этом говорит. Если длительность видео при просмотре не изменилась (иногда эти фреймы вставляют как стабы для растяжения видеодорожки) - забей нефритовый стержень.
>>240284178 Ну вывод один - на видеокарточке жать в 265 как-то не прикольно, если не трогать настройки, разумеется. Быстро, да. Но размер выходит даже больше, чем у оригинала, то есть пользы ноль. Почему так - я не знаю.
Может, стоит попробовать это >>240284079 ? Сейчас сделаю.
>>240284852 В том, что то что ты описываешь справедливо для VBM, но не для CRF.
>>240284890 >Из-за этой проблему у меня нет выходного файла, в пичке вся инфа Не, он говорит что видео не может быть кодировано из разрешения не кратного 2м, обнови ffmpeg, они это фиксили.
>>240285140 Анончик, я правда не понимаю. Почему энкодер от нвидии не жмет по умолчанию вообще? Размер получается больше, чем у входного файла. Я понимаю, что нужно выставить нужные флаги и все такое, но libx265 с дефолтными настройками пережал действительно отлично - мне понравился и размер, и качество. Как добиться того же, используя мощности видеокарты? Это твой совет >>240284672 ?
PS: Libx265 уменьшил битрейт исходного файла с 2000 до 500 кб, то есть в 4 раза, а hevc_nvenc оставил битрейт нетронутым. ???
>>240286718 Пидорасы. Окей, покажи как ты кодировал с nvenc до этого?
>>240286738 Естественно это декодер, задумка в том чтобы он декодировал и не скидывал на проц, чтобы ffmpeg не мог софтовый кодек заюзать автоматически.
>Так это все для профессионалов. Потрать неделю-другую и будешь "профессионалом". Выбирать параметры для кодека это не то чтобы пиздец какой скилл.
>>240287714 Размер чуть больше, чем при кодировании на ЦП, но в несколько раз меньше и быстро, быстро настолько, что я поссать не успел сходить. Но тут есть подводный камень. Я для теста выбрал максимально хуевое видео - запись со стрима одного быдлокодера - где много статики, код и щакальная вебка.
>>240288486 Добавь эту хуйню, чтобы включились B-фреймы. Если карточка поддерживает то должно еще где-то 20% скинуть по весу: -b_ref_mode:v middle И посмотри что будет по рейтам. А так выбирай битрейты из графика и ебашь. >>240284672
>>240289940 >Intel Video 6000+ Куда там, 630 HD. Ну, по крайней мере, хоть что-то может и ладно. Качество >>240289948 кстати говно, прямо пиздос, а буст к скорости всего 2x.
>>240289940 Анон, а в чем разница между CRF и битрейтом, всмысле, почему для того же 264 часто советуют юзать именно CRF вместо высчитывания оптимального битрейта? А главное, почему nvenc не умеет работать с crf?
>>240290955 >Анон, а в чем разница между CRF и битрейтом Разные стратегии выделения бюджета на битрейт (кеп), соответственно разные инструменты используются. В x264 constant-rate был банально лучше написан и это далеко не универсальная рекомендация.
>А главное, почему nvenc не умеет работать с crf? Умеет, но не через ffmpeg.
>>240284178 > Я у себя на 6 ядрах запускал, AV1 кодировал раз в 20 медленнее This. На ГПУ кодировать надо так-то. Понятно, что сейчас только у 30хх серии есть аппаратная поддержка, но хули, так или иначе за этом будущее. ЦП сосёт.
>>240293622 >Умеет, но не через ffmpeg. А что есть вообще помимо FF на рынке, хоть платное, хоть нет? Мне казалось что это вообще профессиональный инструмент, хотя может я чего-то не знаю?
Ребята, вы тут много написали, все это интересно, но не могли бы вы кратко резюмировать, с каким битрейтом кодировать свои видеомонтажи H264 чтоб и не весили много и глаза не кровоточили? Спасибо
>>240303062 Ну я вообще тред создавал с целью обуздать кодирование на ГП и не могу сказать, что пришел к правильному пониманию того, как же блядь и рыбку съесть (чтобы красиво было) и на нефритовый стержень сесть (чтобы быстро). Дело вот в чем. Когда кодируешь в H264 на камне с параметром crf то получается вообще пиздато, просто смотришь, насколько хуевое качество тебе подойдет и повышаешь crf вплоть до 51. Шучу. Уже на 30 будет каша, средние значения 23-27, в зависимости от исходника. И это просто и понятно, но когда хочешь, чтобы все еще было и быстро, то приходится ебаться с битрейтом в ручную, по кусочку кодируя и делая выводы, где золотая середина. В общем, такие дела.
>>240303963 Че? Не понял, как качество может расти при большем сжатии? Ваще положняк такой: 18 - неотличимо от оригинала, 23 - дефолтное значение, больше 23 на 3-4 пункта - разница с оригиналом ощутима, причем в худшую сторону.
На русскоязычном ютубе вообще, как мне кажется, ни одного внятного видео на данную тему нет, всех интересует только ебучий стриминг.
Давайте немножко разберемся, если тут есть хоть немного понимающие ребята. А если в тред заглянет кто-нибудь, кто не по наслышке знает, что такое ffmpeg - будет вообще заебись.