Комментарии 144
Самый продвинутый - AV1, к тому же не требующий лицензирования в отличие от HEVC. Единственный минус: за качество придется заплатить скоростью кодирования.
SVT-AV1 довольно близок к libx265 по скорости кодирования (на современном процессоре).
Тот, кто минусует, может объяснить, за что именно? AV1 действительно разрабатывался как ещё более эффективный по сравнению с HEVC. Но по вычислительной нагрузке он ещё более "тяжёлый", примерно на порядок.
Я как-то ковырялся с ffmpeg и кодировал коротенькое видео. В итоге скорость там была примерно 1 секунда за час, а итоговый размер все равно оказался больше чем x265
Смысл сжатия видео - сделать его меньше, если вы задали настройки, что итоговый битрейт получился выше чем у исходного видео, в этом не особо много смысла. Если не угадали с crf, то tbr (target bitrate rate) позволит получить предсказуемый результат. А скорость кодирования это да, для большинства будет стоп-фактором.У меня на 12700 трехчасовое видео на 2м пресете кодируется сутки :)
Чем выше значение, тем лучше качество, но и вес тоже больше.
Была еще одна альтернатива - зафиксировать качество кадра. Позволяло избежать многопроходового кодирования и не рисковать, что установленный битрейт будет недостаточным для сцен с быстрыми движениями.
Теоретически, видео размером 100 МБ при минимальных потерях при сжатии кодек HEVC уменьшит на 50%, H264 — на 30-35%, а AV1 — на 60%.
А если видео размером не 100 МБ, то проценты будут другими? И "при минимальных потерях" - это каких? На каком видеоматериале это оценивалось, по какой методике? Откуда взяты цифры, и почему "теоретически"?
Все эти проценты зависят от сложности кодируемого видео.
Эта часть не требует уточнения в данной статье. Даже если усложнять этот абзац, то придем к одним и тем же выводам, так что я сразу сжал данную информацию в таком выводе.
Да просто непонятно, зачем тут мегабайты вообще, если дальше всё в процентах. Тогда и пишите что-нибудь вроде: "видео размером 100 МБ при минимальных потерях при сжатии кодек HEVC уменьшит до 50 МБ, H264 — на ... мегабайт" и т.д.
Насчет "не требует уточнения" - дело Ваше. Просто все рассуждения о качестве при оценке кодирования видео обычно сопровождаются хоть какими-то оценками или измерениями. Откуда взяты все эти проценты, на основании чего эти числа написаны в статье?
Теоретически, видео размером 100 МБ при минимальных потерях при сжатии кодек HEVC уменьшит на 50%, H264 — на 30-35%, а AV1 — на 60%.
Какое видео? Если несжатое, то любой кодек его сожмет не на проценты, а в десятки раз. Для примера несжатый FullHD - это примерно 1500 мегабит в секунды, а неплохого качества сжатый - 15, сжатие в 100 раз. А если сжатое - то чем? Считается, что HEVC примерно вдвое меньше H.264 при равном качестве, что согласуется с "HEVC уменьшит на 50%", но как тогда понимать "H264 — на 30-35%"? H.264 лучше самого себя на треть? Не покажете источник, откуда вы взяли эти проценты?
Битрейт на человеческом языке — это довольно абстрактное понятие. Количество выделяемого веса (битов) на одну секунду видео.
Битрейт - величина потока данных, измеряется в битах в секунду. С каких пор это вдруг стало абстрактным понятием?
С тех пор, как битрейт (CBR) стал VBR;)
Скорость движения бывает постоянной, а бывает переменной. Тогда и скорость, внезапно - абстрактное понятие?
Верно, сама скорость не становится абстрактной, став переменной. Думаю, имеется в виду, что битрейт как качественная или количественная оценка кодирования не такая явная, как те параметры, которые передаются кодеку в командной строке в процессе кодирования.
Да.
Скорость бывает мгновенной, бывает средней. С битрейтом примерно так же.
Как раз для оценки кодирования измерение битрейта подходит лучше, чем параметры, которые передаются кодеру. В зависимости от характера видео (сложности, наличия мелких деталей в кадре), одни и те же параметры кодирования могут выдать разный результат.
Вот именно, анализ полученного битрейта говорит о характеристиках самого видео, но не параметров кодирования, а вот анализ значений параметров кодирования позволяет судить о применяемых алгоритмах кодирования и оценивать качество кодирования применительно к конкретному видео (те самые сложность, мелкие детали, движения, переходы). Ниже было хорошо сказано, что при кодировании блокбастеров потребуется большое число проходов, и оценить сложность и качество кодирования одним лишь полученным битрейтом - и есть, как мне кажется, весьма абстрактная задача, делающая битрейт абстрактным параметром. В отличии от того-же количества проходов.
оценить сложность и качество кодирования одним лишь полученным битрейтом
Никто и не предлагал оценивать сложность и качество кодирования одним лишь полученным битрейтом. Речь о том, что битрейт сам по себе - не абстрактное понятие, а вполне конкретное и измеряемое. Какое при этом за ним стоит качество - это уже другой вопрос. Особенно, если для понятия "качество" никаких других метрик не предлагается.
В отличии от того-же количества проходов
Количество проходов - это количество проходов. И как, по-вашему, можно количеством проходов оценить сложность и качество кодирования? Просто "чем больше проходов - тем выше качество"? А само качество как и чем измеряется?
Качество можно, например, оценивать чисто визуально, замыленностью стоп-кадров при просмотре. Но согласен, битрейт сам по себе лишь лишь техническая характеристика потока, лишённая абстрактности. А вот при просмотре конечного видео с одинаковым (похожим) битрейтом но разным кодированием (с разным тем-же числом проходом) может дать разные по субъективной оценке качества результаты.
Для оценки качества существуют вполне объективные, т.е. измеряемые метрики, а не только визуальная оценка, что субъективно.
Многопроходное кодирование само по себе не факт, что позволит значительно повысить качество при одном и том же битрейте. Это, опять-таки, зависит от сложности кодируемого материала.
Всё верно, для оценки качества кодирования лично я ориентируюсь именно на визуальную, априори субъективную, оценку полученного материала. Подскажите, какие есть объективные, измеряемые метрики оценки качества? Битрейт прошу не предлагать;) (шутка) - я действительно не знаю, как оценивать качество материала цифрами, на ум приходит разрешение, кадров в секунду, и ... почему-то, больше ничего:(
Оценивать можно разницу между исходным и перекодированным видео. Кое-что об этом написано здесь.
Спасибо, весьма познавательная статья! Цитата: "...результирующее значение (метрик) характеризует лишь количественное отличие от оригинала без оценки его качества в привычном понимании...." Таким образом, оцениваются соотношение сигнал/шум, искажения цветности, яркости, контрастности, движения и т.п. с разной степенью корреляции метрики с субъективной оценкой качества человеком, с малой в оценке PSNR (вероятно, самой быстрой) и с большой в VMAF (вероятно, самой ресурсоёмкой). Предлагаю оставить отнесение битрейта к абстрактной величине на усмотрение автора.
Название программы я не помню, но была в 2000-х программа которая покадрово сравнивала исходник и пережатый файл и цифрах и картинках показывала проблемные места, где артефакты были выше установленного пользователем минимума. Кажется @3Dvideo имел к разработке этой программы отношение.
PS https://compression.ru/video/codec_comparison/introduction_en.html
Раньше думал, что кодеков видео очень много, типа divx, Xvid, mpeg 1...4 и и.д.. Приходилось ставить codec pack, ато какие-то видео не запускались и требовали установить кодек. А сейчас, оказывается, всего 3 осталось. А что с другими стало, они просто не актуальны стали? Или это те же кодеки, только новые версии?
Можно считать их мертвыми на данный момент. Они устарели. Конечно никто никуда не пропадал, но ими вне специфичных задач, нету смысла пользоваться. Есть ещё всякие prores от apple, но у меня не про это статья.
А что касается запуска видео, то ну просто установите VLC и бед знать не будете.
Их и сейчас много, но они узкоспециализированные.
Из потребительских остались только MPEG, они же h264/265/266, они же AVC/HEVC/VVC, и свободные кодеки от Гугла и ко VP/AV1
Отдельное место в аду заготовлено для китайских хакнутых кодеков mpeg, которые любят пихать в камеры наблюдения и т.п.
MPEG - это не название конкретного кодека. Есть MPEG1 и MPEG2, например.
В камеры наблюдения пихают MJPEG который перечисленным даже не родственник. Отличается хорошим соотношением сложности закодирования к сжатию, почему и применяется в камерах.
Уже давно не пихают mjpeg, сильно устарел.
MPEG и JPEG соседние группы в рамках одной организации по стандартизации. Грубо говоря, I-frame кодируется как jpeg-картинка, а остальные кадры как изменения относительно этой картинки. Сейчас к этому добавили более хитроумные методы кодирования, ну и jpeg на месте не стоит.
Для качества нужно переменный битрейт и минимум два прохода. А если есть резкие переходы от статичной картинки к динамическим сценам с перепадами яркости, то можно и три прохода.
Кстати, за это профили/пресеты и отвечают. По возможности, "для себя", лучше не стесняться. Что бы потом, не было мучительно больно за криво пожатое с удалённым оригиналом.
ПС. Эх, были времена... 0,3 к/с... :)
Для максимального качества, как самоцели, используется тот же CRF, это самый современный алгоритм для переменного битрейта.
Два прохода кодирования нужны исключительно когда необходимо получить максимальное качество при заранее известном конечном размере файла. Чтобы максимально точно вписаться в размер какого-то носителя.
Во всех остальных случаях CRF даст лучшее качество, но не особо предсказуемый размер.
1/2 Проход создаёт карту битрейта по динамике сцен, так как кодировщик не знает, когда что случится.
Особенно это заметно по первым кадрам перехода статичной сцены, в ультрадинамичную, или на стыке резкого перехода яркости (очень ярко - очень темно, или наоборот). Особенно подобные косяки вылезают на ультрабольших экранах с диагональю метра полтора и выше.
Немного качеству помогают и разные опорные кадры, для правильного раставления которых, опять же необходимо знать расположение сцен.
Если выводить техническую информацию, то в фильмах с большим количеством подобного добра, карта битрейта устаканивается к 5-7 проходу.
Дальнейшее улучшение можно добиться индивидуальной матрицей квантизации.
1/2 Проход создаёт карту битрейта по динамике сцен, так как кодировщик не знает, когда что случится.
Кодировщик знает, что происходит прямо сейчас и этого достаточно. Что будет дальше не имеет абсолютно никакого значения, если у вас не стоит цели ограничить битрейт, чтобы уместиться в заданный размер файла.
CRF дает наилучшее качество всегда. В этом суть алгоритма использующего фактор постоянного оценивания. Не обращать внимание какой битрейт требуется для сцены, а использовать такой, чтобы получить заданный уровень качества. Карта битрейта для него бесполезна.
Самый продвинутый это h266 :)
Исходить при выборе кодека нужно из возможностей аппаратного декодера устройства воспроизведения. Если брать первые умные телики как образец, то там и h264 может не завестись при некоторых настройках.
Если кодировать архив хоумвидео для уменьшения места, то нужно брать аппаратный AV1 или HEVC и кодировать с переменным битрейтом. Чем выше разрешение, тем круче кодек разумнее использовать.
B-фреймы я бы большими не делал, как и GOP, т.к. это выйдет боком в случае битовых ошибок.
Имелось ввиду что h265 самый продвинутый среди представленных ранее в статье вариантов. И не в плане качества кодирования, а количества параметров кодирования и их влияния на картинку, то есть он более гибкий чем остальные варианты.
У вас критериев нет по которым выбирать. Я вообще с трудом представляю бытовой кейс кодирования видео. Архив домашнего видео? Тогда лучше оставить кодек с исходника. Кассеты оцифровывать? Тут нет смысла использовать крутые кодеки, разрешение маленькое.
Аппаратный AV1 не подходит для уменьшения веса, т.к. профили в нём зафиксированы. Для качества и низкого размера нужно использовать процессорные svt-av1, svt-av1-psy, Av1an.
Сам пока остановился на Av1an, как наиболее продвинутом варианте с разбиением видео на несколько сцен и обработкой в параллельном режиме. Так же там сейчас разработчик пилит возможность распределённого кодирования (по сети), что позволяет ускорить кодирование во много раз: разбиваем файлы на сцены и каждая сцена кодируется на отдельной машине. Кодирование фильмов и стримов многочасовых можно в 10-100 раз ускорить.
Периодически пробуют кодирование видео по сети. Только мало кому оно необходимо.
Профили в каком-то софте вы имеете ввиду?
Я тестил на утилите nvenc с videohelp. Вполне рабочие основные опции.
У меня получается 500 фпс с 2pass full и 600 фпс без мультипрохода на транскодинге CRF с AVC 1080р25.
Подскажите, пожалуйста, какой кодек качественнее передаёт детали при плохом освещении и при каких настройках? Исходная запись h.264 с видеорегистратора, видно что идёт человек в брюках, распознать можно метров с 20, после перекодирования в h.265 VBR с CRF даже с минимальным значением этот же человек появляется без ног, которые появляются где-то уже метрах в 7. Приложение MediaCoder для Windows. Остановился на CBR с битрейтом 1350, чтобы не увеличивать размер файла. Детализация ну так себе, но хотелось бы укладываться в объем 1- слойного DVD. Может как-то можно улучшить качество (при плохом освещении) при том же объёме видео на выходе?
С AV1 как-то не получается. Вообще.
Скорее всего у вас изначальное разрешение и битрейт низкие. Любое транскодирование ухудшает качество. Для начала попробуйте такие же настройки как и в оригинале, но с другим кодеком.
2048х1152 при 128 кбит/с (скорее всего ошибка). Сомневаюсь что стоит пробовать.
Через mediainfo смотрите. Это софт такой.
128 кбит наверно звук
Это недоделанная китайская экшн- камера для велосипеда с длительным временем записи. Поэтому и для звука и для видео в свойствах по 128 кбит. Медиаинфо показывает от 18.3 мегабит в тёмных сценах до 24.3 мегабит днём. Недоделанная - она тяп-ляп пишет при плохом освещении. Таких камер, кстати, хватает. Ночью получаются какие-то детали на акварельном фоне. Плюс в ней фонарь, который должен иметь 2 режима яркости и стробоскоп, но там только вкл/выкл. Плюс нет никаких настроек, нет съёмки фото. А всё это вроде как заявлено. Нет, не слетевшая прошивка. Новой не удалось добиться. Похоже что внешне одинаковы, но производители разные, поэтому и прошивка другая. И описание от другой камеры.
Такие камеры в принципе не адаптируют для сьемки ночью, в отличии от настоящих для наблюдения (но подсветка всё равно нужна для любых). Может быть софт типа Zoneminder может делать коррекцию налету и сохранять уже пережатым.
Zoneminder разве не софт для видеонаблюдения? Речь о перекодировании.
Камеры у меня есть, которые не делают акварель. Но 3 часа записи мне сильно не хватает. В данный момент работаю с тем что пишет долго.
Буду с фильтром пробовать. В данный момент просто нет исходника с нужным сюжетом.
Я думал над тем, чтобы использовать камеру видеонаблюдения с видеорегистратором, тогда уж проще автомобильный использовать (3 штуки купил, ни один не решился установить). Но встаёт вопрос влаго- и пылезащиты.
Для видеонаблюдения. Принимает на вход поток с вашей камеры, делает фильтры и сохраняет с другим кодеком. Или тоже самое на ффмпег
Вы мне хорошую мысль подсказали. Думал. Искал. Может и не нужно никакое перекодирование? Адаптер HDMI-AHD и писать с компьютера на видеорегистратор с h.265? Сжатие/ качество почти максимальное, для моих задач выше крыши, да ещё перекодирование видео 6 часов займёт... 6 часов!
Думаю, может какая ардуинка пойдёт для этой цели?
Я не очень понимаю какую именно задачу вы решаете. Что куда пишете? Так-то решений масса каких угодно
Исходная задача - улучшить детализацию в видео, записанного при плохом освещении. Перекодированное видео заметно теряет детали.
Но, к сожалению, само перекодирование занимает в 4 раза больше времени, чем продолжительность видео. Камеры 3. В итоге просто не успеваю перекодировать.
Но здесь хотя бы одна задача решается. С временем. А качество... Видимо только увеличивать битрейт. Либо оставить как есть.
Для хорошей работы кодека надо подготовить картинку - отфильтровать шумы.
Например фильтром Neat либо чем-то подобном, что доступно в используемом ПО.
Спасибо. Никогда не задумывался об этом. Возможно я что-то не так раньше делал с фильтрами, просто пропадали детали.
Пробуйте Neat - простой и аккуратный фильтр.
например в этой статье есть пример результата
В ходе моего недавнего проекта я вручную обработал 124 серии из разных мультфильмов в качестве Blu-ray с помощью алгоритма устранения шума (Neat Video)
С 10-битным цветом не пробовали сжимать?
Пробовал. Лучше. Но VLC не нравится, а пока только он у меня 10-битный цвет воспроизводит.
Откуда в видеорегистраторе возьмётся 10 бит в исходном видео?
Ниоткуда. И с 8битным исходником может выйти лучшее качество за счет другого квантования.
Хотелось бы увидеть реальный пример, на котором видна существенная разница. А то и в обсуждаемой статье на изрядной части картинок разницы либо вовсе нет, либо я не пойму, где её увидеть предлагается.
Увидеть предлагается в тёмной темноте, где 8битный цвет даёт различимые полосы, а 10битный цвет за счёт размешивания краёв этих полос делает их труднозаметными.
Обычно "увидеть" - это про картинку, а не слова.
Я не вижу разницы, честно.
Больше ступеней яркости - равномернее градиенты. На 8 битах будут заметны ступеньки.
А может, при кодировании в 10 бит какая-то дополнительная фильтрация работает?
Да и тоже, разница видна, но если на нее явно не показать, неспециалисту заметить её сложно.
Если на пальцах объяснять, лучше качество при перекодировании получается за счёт большего количества разрядов, в математике это выглядит как деление целочисленных чисел. 8-битное отбрасывает дроби, а 2 дополнительных разряда при 10-битном их учитывают. Конечно лучше исходной картинка при 10-битном кодировании не станет, если не применяется дополнительный фильтр, но при 8-битном при перекодировании может стать хуже.
Есть у меня подозрение, что при 10-битной обработке арифметика используется и вовсе 16-битная.
Может даже и 32 и 64, и даже с плавающей запятой. Но здесь речь о квантовании.
Собственно, примеры Вам показали.
Есть один нюанс - как шумы в младших битах. Как шумы оцифровки, так и результат вычислений. Когда у вас всего 8 бит - то это будет заметнее.
PS Когда появилась возможность сжимать видео на видеокартах, то мне попадалось утверждение ,что качество результата хуже из-за разных упрощений вычислений для болле простых графических процессоров, чем у CPU.
Одна проблема - чтобы кодировать, например, в реальном времени 4K 50 fps в HEVC на CPU, требуется нереально мощный процессор. Слышал, что одна американская контора на какой-то выставке демонстрировала такой кодер, но там был какой-то процессор вроде Intel Ultra с 24 ядрами, емнип.
Спасает ситуацию то, что пользователи теперь нетребовательны к качеству картинки - смотрят на маленьком экранчике телефона. Это не те, что 20 лет назад покупали "домашний кинотеатр" - многоканальный звук, отдельный медиацентр-компьютер с пультом у телевизора.
Ну так если в проц кодер встроен, то какие проблемы?
У меня на Snapdragon 7+ gen 2 в камере включается 4K@60fps. Вроде хватает процев помощнее при этом.
https://nanoreview.net/ru/soc/qualcomm-snapdragon-7-plus-gen-2
Вот пример, на 8 битах небо распалось на отдельные полосы, а на 10 битах сохранился плавный градиент. x264, preset slower, 2Mbit/s
Мало вводных данных, какой исходный битрейт, разрешение?
2048х1152, битрейт от 18.3 (плохая освещённость) до 24.3 (день) мбит.
Вводные вполне неплохие, для регистратора. Если картинка все же плохая, то дело в матрице, или китайцы как то намудрили. Тут мало что можно сделать быстро. Если есть время и мощности, как минимум можно почистить шумы (темпорально) и обработать видео в целом ( задавить света и поднять тени в приделах стопов матрицы) и только потом пережать, CPU можно достичь неплохого сжатия, но все что ближе к плацебо h265, это долго. Сравнивал качество кодеров Nv и Амд, амд явно лучше на низких битрейтах. Да Винчи быстр, попробуйте его, качество точно сохраните, но тут все индивидуально.
Спасибо.
Пока не получается найти подходящий сюжет. К сожалению тот оригинал, с которым была хорошо заметна проблема, и от которой так и не смог избавиться, удалил.
От фильтров в своё время отказался, потому что видео становится "пластилиновым". Сейчас поиграл с разными настройками, пластилин заметно. Есть пара более- менее приемлемых вариантов, но сюжет смотрел в ч/б. Потом как-нибудь найду, что очень сильно деградирует после кодирования, буду с ним экспериментировать.
Если у Вас пластилин, то явно что то делаете не правильно. Научитесь делать правильно. Если не получается, есть ИИ, например топаз (модели рея, нюкс)
Ну прямо пластилином назвать нельзя, но неестественность присутствует. Тот, кто не видел оригинала, не поймёт что не так.
Да мне, по большому счету, нужна прорисовка мелких деталей при плохом освещении. Хотя бы не сильно хуже чем в оригинале. Не художественное видео. Но уж точно не так, как описано выше, в самом первом вопросе.
Приложение MediaCoder для Windows.
Попробуйте Handbrake разок.
К сожалению, H265 (и AV1 вроде тоже) по-другому используют макро блоки, нежели H264, и хотя это может помогать сжимать данные лучше, если речь идёт о шуме или тёмных участках – оно просто может съесть детали, которые вам нужны.
Для тёмных сцен или для сохранения "Film grain" – H265 часто просто не лучший выбор, ну или надо прямо очень повозиться с настройками.
Вот одна статья с наглядным примером того, как H265 может использовать "бОльшие блоки" для более неподвижных или тёмных частей изображения, примерно как в вашем примере, но при этом оно может убрать детали, которые вам нужны.
Также, может быть разница между Hardware и Software Encoding, нужно сравнивать и это. Хорошее видео про "hardware encoders" от инженера Intel (и GamersNexus).
Спасибо большое. Да, представляю как h.265 работает. Наверное нужно будет с h.264 разбираться. Может от него удастся получить более приемлемое качество. Но источник видео однозначно нужно менять. С какого-то момента камера в условиях плохого освещения акварельные пейзажи создаёт. Да и подводит иногда. Полного заряда аккумулятора, бывает, хватает всего на 4 часа.
Столкнулся с неприятной вещью. На Sjcam SJ7 записал белку, которая с водопоя побежала наверх по склону оврага. Днём. При перекодировании любым кодеком её просто нет. Может вообще я предъявляю слишком высокие невыполнимые требования к кодекам? А всё видео нужно просто писать на 2- слойный bluray без попытки перекодировать?
Пробуйте кодировать в несколько проходов - два-три прохода могут сохранить детали.
Многопроходное кодирование обеспечивает необходимое перераспределение количества битов на каждый кадр для достижения максимального качества (оценка качества программными средствами это отдельная очень большая проблема) как правило используя метрику PSNR. Во всяком случае многопроходное кодирования должно давать результат лучше чем однопроходное, так как кодек на проходе после первого будет заранее иметь информацию о всех типах фреймов на всём протижении ролика, и их сложности для кодирования.
https://zoltan0.livejournal.com/11021.html
Многопроходное кодирование может предложить огромные преимущества по сравнению с однопроходным. Используя статистику, собранную при первом проходе, кодировщик может оценить, с разумной точностью, "стоимость" (в битах) кодирования любого заданного кадра при любом заданном квантователе. Это делает возможным намного более рациональное, лучше спланированное распределение битов между дорогими (высокодинамичными) и дешевыми (малодинамичными) сценами. Смотрите qcomp ниже, чтобы узнать некоторые идеи о том, как можно это распределение настроить по Вашему вкусу.
http://www.mplayerhq.hu/DOCS/HTML/ru/menc-feat-x264.html#menc-feat-x264-example-settings
Спасибо больше. Но я всё-таки больше по опыту согласен с этим. https://habr.com/ru/companies/ruvds/articles/845202/comments/#comment_27356700
Большое количество проходов позволяет вписаться в желаемый объем. Да, он важен для меня, если задаться целью ограничиться одним DVD на 6-часовое видео. Я раньше только 2-проходное кодирование использовал. Сейчас немного другая задача. По сути заставить кодек понять, что для меня является важным на видео. Видимо я сам для себя до конца не могу сформулировать задачу. Сейчас буду искать сцены, где удаляется или искажается нужное мне. Как оказалось, происходит это не только при плохом освещении. Фильтры чудес не делают. Они ожидаемо ухудшают детализацию. Буду читать статьи, искать где и что пропустил.
3-проходное кодирование вроде бы что-то дало (вырезал кусок видео с белкой), но то же самое сделал с обычными настройками (CBR 1350). И там она есть. А вот при воспроизведении полного видео она чудным образом пропадает.
В MJPEG все кадры "ключевые"(опорный кадр) т.е. фактически фотоснимки. А в современных кодеках их стараются делать как можно реже. Покрутите значение GOP/GOV для этого фрагмента
В схеме, расположенной выше, видно, что P и B-кадры, по сути, опираются на I-кадр, т.е. содержат информацию об изменениях относительно I-кадра. Именно поэтому I-кадр и получил название "опорный кадр". Частоту, а точнее период следования опорных кадров, указывают в виде параметра GOP length (Group of Pictures), либо GOV (Group Of VOPs). Это цифровое значение указывается числом (10, 32, 64, 100, …), которое показывает сколько кадров (P и B) следует между опорными I-кадрами.
***
А вот теперь представьте себе, что для темпа видеоввода 25 к/с и значения GOP=100 мы получаем опорный кадр для работы видеоаналитики каждые 4 секунды!!! Какая точность и задержка у нас будет, хотя бы в детекции движения? За 4 секунды может произойти многое, а алгоритмы видеоанализа этого могут и не заметить, т.к. опорные кадры до возникновения происшествия и после будут одинаковыми.
Камера Sjcam SJ7, кодек h.264. Но да, надо уменьшить GOP. В крайнем случае лишних секунд 20 перед белкой добавлю чтобы проверить.
Из-за того, что VBR, как ни улучшай качество, не даёт нужную картинку, остановился на CBR. Уменьшение GOP в этом случае ожидаемо ухудшает видео в целом (на ключевые кадры уходит меньше объём, поток постоянный), то есть при данном конечном объёме файла либо с GOP не ниже 0-100 (это даёт только ухудшение видео), либо нужно увеличить битрейт и объём файла. Применение фильтров визуально всё-таки ухудшает качество. То есть сначала можно уменьшить немного объём видео на выходе, увеличить немного битрейт, и не выиграть в качестве.
Если в художественных видео можно увеличить объём конечного видео (они имеют меньшее время записи), то с большими архивами придётся оставить как есть. AI рекомендовал использовать AV1, но не получается у меня с ним вообще ничего.
Просто надеялся что как в своё время 2-проходное кодирование решало проблему быстрых и медленных сцен, так может и сейчас придумали что-то для хорошего и слабого освещения. Ну то есть для хорошо освещённых сцен один битрейт, для плохо освещённых выше, но в кодеке сделано всё с точностью до наоборот. Вместо того, чтобы вытягивать детали в темноте, он их просто сглаживает, закрашивает.
Такое впечатление, что там что-то в оригинале необычно. Возможно сильные шумы.
PS В таком случае лучше оставить оригинальное видео.
Можно сказать - пёстрое видео. Осенний парк, разноцветные листья. И белка на их фоне, конечно, не сильно выделяется. Само видео на 1-слойный bluray без перекодирования не влезет.
Вот если бы можно было склеивать видео с разными кодеками... Дневное с h.265, ночное с минимальным сжатием, либо вообще оригинал...
Возможно пробовать надо другой кодер. Многопроходовое кодирование как бы это и должно делать - определить где необходимо адаптивно поменять GOP/битрейт/профиль для сохранения качества/деталей.
Сейчас все озабочены стримингом, может в этом дело. Я бы попробовал софт старых версий - лет 10 назад. Что нибудь старое вроде TMPGEnc 4.0 XPress/TMPGEnc Video Mastering Works.
А вот пресет это отдельный параметр или он устанавливает значения других описанных параметров?
Отдельное спасибо за cropdetect, не знали.
Иногда перекодируем старое видео, которое уже сложно найти, почти всегда с полосами.
Еще из двух спасительных фильтров для старых видео это - деблокинг (убирает квадраты которые почти всегда есть в старых видео) и автоуровни (обычно старые видосы почему-то пересветлены). pp=al/hb/vb в командной строке. Правда не знаем (может кто в курсе?) совместимы ли они с либами кодинга на nvidia (кодируем обычно на проце).
Делал для домашней коллекции переконвертацию 4К видео в h264 (VerySlow) и h265 (placebo) с тем-же разрешением с максимальным качеством видео на выходе.
Так вот, на фильме "Дрожь земли" на стоп-кадре невооружённым взглядом видно, что h264 выдаёт более качественную картинку, а h265 её нещадно мылит.
Всё зависит от кодера, его настроек и битрейта.
Для ffmpeg
h264: -vcodec libx264 -preset VerySlow
h265: -vcodec libx265 -preset placebo
ffmpeg - лишь один из кодеров. В нём же самом можно кодировать аппаратно на GPU от NVidia и Intel, например, и они дают разные результаты.
Если это всё, то вы с сильно разным CRF кодировали.
Тогда прошу подсказать "правильные" параметры для h265, которые дадут качество хотя-бы такое-же как h264.
Я использовал самые качественные пресеты и там и там.
В итоге самый качество от h264 оказался гораздо более лучше, чем у вышедшего позднее h265. Не говоря уже о времени кодирования.
для правильного сравнения именно качества кодеков, вам необходимо было сравнивать их с данными параметрами:
h264: -vcodec libx264 -preset veryslow -b:v 2000k (можете указать своё значение)
h265: -vcodec libx265 -preset veryslow -b:v 2000k
Только в таких равных условиях, мы можем говорить о качественной разнице самих кодеков. У кого будет меньше артефактов и искажений - тот и будет качественнее.
Т.е. вы ограничиваете битрейт потока, но не качество?
Факт того, что качество h264 будет выше при отсутствии такого ограничения Вы отвергаете?
Другими словами, Вы почему-то апеллируете к потоку, когда я изначально говорил, что h265 откровенно мылит, если мы стремимся к качеству исходника.
Или всё-таки при таком-же качестве полученного видео у h265 уже не будет преимущества в размере файла?
Если не сложно, давайте изучим качество, на примере "Дрожь земли".
Для h264: -vcodec libx264 -preset VerySlow
Для h265 вы постараетесь указать параметры, где видео будет не хуже.
Больше интересуют фрагменты с развевающимися волосами героев на фоне прерий.
P.S. Второй раз редактирую ответ, извините. Но для меня реально это интересно, фильмотека занимает довольно много места и заявленная экономия h265, если она реально есть, меня очень даже выручит.
Думаю что все мы скажем Вам ОГРОМАДНОЕ спасибо за науку.
Не являемся специалистами, сразу оговорим.
Лично у нас h264 показывает ощутимо лучшие результаты на видео плохого качества. То есть если изначально качество видео было оцифровка vhs или небольшое разрешение или жесткая пережатка в квадраты или еще что-то, то h265 делает из видосов плавающую кашу (мало того, что детали теряются, так еще и изображение плавать начинает), а h264 картинку почти не портит. При это размер получается примерно одинаковый.
А вот если речь про современное видео без сильной пережатки (оригинал с гоупро или телефона), то h265 отлично уменьшает размер почти не теряя детали, а вот h264 проигрывая в уменьшении размера жестко теряет четкость.
crf (или как там его) используем 20/24 - под настроение (кстати дефолтовый в h265 вроде 20, а вот в h264 24), режим slow.
Тоже такое замечал скачивая пару фильмов с просторов, H264 сохранял "film grain", тогда как 265 откровенно замыливал, как вы и говорите, хотя 265 был даже больше по размеру.
Судя по всему это из-за того, как оба кодека используют "макро блоки": в h264 они фиксированы 16х16, а h265 может их как-то сам изменять то меньше, то больше. Из-за этого может получаться, что в тёмных сценах h265 просто будет брать бОльшие блоки и объединять их все вместе, по сути теряя детали. Хорошо для меньшего размера – частенько получается плохо для мелких деталей.
Ну и плюс есть разница между софтверным и железячным ускорением: софт будет дольше, но, зачастую, лучше качества, хотя и не всегда. Ну и от бренда зависит, так у AMD видео энкодеры даже сейчас хуже, чем у Nvidia были пару лет назад, или Intel и Apple.
Ответил тут с несколькими ссылками, если комментарий одобрят, должно будет всё отобразиться.
Отличная статья, больше бы статей на тему ffmpeg
А что, их прямо мало?
Ну и где ИИ, который определяет параметры кодирования из анализа источника?
А может кто знает с каким кодеком рутуб работает? Ресурс жрет как не в себя. Яндекс.Станция макс (2021 год) захлебывается при воспроизведении видео с рутуба, просто перестает реагировать на голос, с 10 раза удается докричаться. Старенький айпад вообще не воспроизводит.
Youtube на голову выше в этом, везде работает… К сожалению, о минусах рутуба с технической стороны маловато написано.
В плеере Рутуба в браузере доступна весьма подробная техническая информация:
Техническая информация
Video Id:1ba709634e43fa0f1621814ad8e9e4ef
Bandwidth:82 mbps
Codecs:avc1.640029 | mp4a.40.2
Buffer:(0, 0), (0, 212) | 13 | 212
Screen Resolution:1920x1080
Video Quality:1280x720 | 1670 kb
Edge | Dive:river-3-331.rutube.ru | undefined
isLive | isDVR:false | false
Auto Quality Enabled:true
Current Quality:4
Playback Position:29 / 1665.2149999999897
Last Ad Name:
Volume | Muted:41% | false
Current Domain:https://rutube.ru
Player Version:1.65.0-wdp
Date:Mon Sep 30 2024 11:27:49 GMT+0300 (Москва, стандартное время)
User Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 YaBrowser/24.7.0.0 Safari/537.36
ScreenO Lock API:falseИспользуется самый распространенный и поддерживаемый всюду H.264.
Но вот битрейт для видео судя по всему Рутуб так сурово как YouTube не ограничивает. В итоге если автор видео загрузил его с битрейтом выше чем у фильма на Blu-Ray диске, но все еще в поддерживаемом формате - вашей колонке придется это как-то воспроизводить.
Вероятно в приложении Рутуба стоит реализовать более щадящий автоматический выбор качества, а не крутить 2К на всём подряд.
Перекодировал давеча домашнюю библиотеку, хотел добиться универсального формата для воспроизведения на всех моих устройствах. Т.е. это веб-браузеры на основе хрома(Android+windows+chromecast) ну и нативное воспроизведение через VLC. В итоге пришел к тому, что видео нужно x264, звук mp3/aac. Всё это в контейнере mp4. + в довесок выяснил, что chromecast не дружит с 6-канальным звуком, пришлось принудительно "добавить" стерео дорожку, там где ее нет... В общем не знаю как там будет с i-устройствами, но пока что результат меня устраивает.
Самый продвинутый это h266
Автор, расскажите о том, как заставить libx265 использовать полностью все доступные треды. Сейчас при 32 тредах (16-ядерный рызен) один инстанс ффмпега при кодировании в x265 жрёт тредов сильно меньше 32х, да и те что жрёт -- не на 100%. Для макс. использования процессора приходится стартовать несколько инстансов. Но хотелось бы наоборот -- 100% загрузки всех тредов одним инстансом.
Вот только в реализации h265 декодера в ffmpeg (а так же в остальных open-source, так как они используют одну и ту же библиотеку) есть очень досадный баг: http://github.com/strukturag/libde265/issues/423 который убивает напрочь любой live streaming с ними
Даже не углубляясь в вопрос, я не рассматриваю в статье какой-либо live streaming с ffmpeg.
Не только же в live streaming кодируется поток, в приложениях OverTheTop весь поток транскодируется, и при доставке контента потребителю через интернет пакеты могут теряться... А в целом, спасибо за статью, я по-другому начал смотреть на видеокодеки! :)
Проблема в том, что opensource реализация h265 декодера только одна и ее используют все (в том числе gstreamer и vlc). На данный момент в линуксе этому багу не подвержены только аппаратные кодеки от nvidia и рокчипа.
указание большего или меньшего значения CRF в большей степени зависит от скорости вашего накопителя, нежели от процессора
Какое отношение уровень качества видео имеет к скорости накопителя? Вообще никакого.
В худшем случае, от скорости накопителя будет зависеть скорость кодирования, но никак не CRF.
В целом, статья совсем не убедила перейти с Handbrake или StaxRip на предложенную командную строку
В хендбрейке те же опции, что и в статье, только через ГУИ.
При CRF-кодировании ограничение битрейта нужно для того чтобы новая порция данных успевала считаться с диска или загрузиться по сети, а также учитывается размер буфера на плеере. Без ограничений на сложной сцене битрейт может так сильно скакнуть, что слабый плеер не успеет подгрузить фрагмент и будет фриз.
В хендбрейке те же опции, что и в статье, только через ГУИ.
Ну, у автора же посыл, что к чёрту все эти удобные штуки, побежали в командную строку, там всё гораздо интереснее
При CRF-кодировании ограничение битрейта нужно для того чтобы новая порция данных успевала считаться с диска или загрузиться по сети, а также учитывается размер буфера на плеере
Мы же говорим про кодирование, а не про воспроизведение?
Каким образом я, перекодируя видео, могу предвидеть, какой там буфер у заранее неизвестного плеера и какие там скорости будут у совершенно мне неведомого носителя?
В общем, я впервые слышу, что при выборе CRF надо учитывать параметры носителя и плеера. Возможно, для специальных случаев, но явно не "для дома, для семьи". Не могу представить, чтобы HDD даже 10-15 летней давности (SATA-II, правильно помню?) не тянули полноценный блюрей, не говоря уже о пожатых видео
Я вам говорю для чего эта технология сделана, как человек, который это настраивает на практике для широкого круга девайсов.
Домашние кейсы у всех разные, у автора об этом ни слова. Для разных случаев будут разные кодеки и настройки. Просто для архива лучше взять новейших кодек и кодировать в CRF с максимальным качеством. Если нужно крутить это из домашнего облака на разных умных теликах и телефонах, нужно выбирать соответственно, то что поддерживается и уже думать про буферы\битрейты.
Я не нашёл на что вы отвечали в изначальном комментарии, просто решил написать о технологии.
Вы название статьи читали?
А также данный абзац?
H264 — воспроизводится без проблем практически везде, но имеет оскорбительно плохую эффективность в сжатии видео в сравнении с другими актуальными кодеками. AV1 — открытый кодек, который сжимает видео более эффективно, чем HEVC, но требует значительно больше ресурсов как для кодирования, так и для декодирования, что, несмотря на его свободу от лицензий, делает его непригодным для использования за пределами таких онлайн-кинотеатров, как Netflix или Amazon Prime, которыми как раз и поддерживается его развитие.
Исходя из названия статьи, ну чисто логически же можно было понять что основной упор идет на hevc и я не буду рассказывать о чем-либо кроме него. Так и вот в цитате и самой статье я ни один раз упоминал что hevc это не центр вселенной и мироздания. Что для ваших "домашних кейсов" есть разные кодеки тоже упомянуто в цитате.
Серьёзно, ваши сообщения уже больше подходят на спам. Вы уже ни один раз игнорировали доводы из статьи, хотя вроде её и читали...
Говоря о спаме, вы оставляете комментарий в ветке где мы обсуждаем CRF... Или вы за мной по всему Хабру будете ходить?
Скажу прямо, ваше вступление про кодеки малосодержательное и спорное по большинству утверждений. О чем вам тут неоднократно написали разные люди.
Если бы вы написали: вот мой перевод к опциям кодирования ffmpeg применительно к HEVC, подобных комментариев бы не было.
Если вы не знали, кодированное в помощью crf может иметь пики битрейта в разы больше, чем исходный blu-ray. В Blu-ray битрейт ограничен на 62.5 Мбит, уровнем 4.1. В crf я получал и по 200 мбит пики, когда средний битрейт на видео был меньше 10 мбит.
Конечно жёсткий диск это тянет, а вот если вы решите записать на DVD, то увидите, что в местах пиков у вас фризы, диск не тянет 200 мбит.
Но главное тут, что аппаратный декодер может не тянуть, если аппаратный декодер только до уровня 4.1, то он так же спокойно может фризить на этих пиках. Хорошо когда аппаратный декодек поддерживает уровни 5 или 5.2, тогда он это спокойно переварит.
ffmpeg это кайф , надо будет почитать
Даже сам вопрос о том, что такое кодек, ставит многих в тупик. Можно легко услышать ответ: «.avi, .mkv, .mp4...», но это лишь контейнеры, которые в большинстве случаев содержат видео, аудио и другие данные. А кодек — это преобразователь видео/аудиосигнала.
В рамках улучшения статьи, где даны краткие справки о HEVC, h264 и других кодеков, можно было бы добавить также и этимологию слова "кодек". Мне стало интересно, как оно образовано и пришлось заглянуть в вики:
Ко́дек (англ. codec, от coder/decoder — шифратор/дешифратор — кодировщик/декодировщик или compressor/decompressor, слово «кодек» образовано по тому же принципу, что и слово «модем») — устройство или программа, способная выполнять преобразование данных или сигнала.
Кодирование с кодеком HEVC простым языком — гайд на FFmpeg. Высокое качество, но низкий вес