FFmpeg и общий кодирования видео тред №11 /ffmpeg/
Аноним (Microsoft Windows 10: Chromium based)
03/10/23 Втр 04:46:00
№
1
В прошлый раз мы обсуждали азы и тонкости сжатия, а также срались и шитпостили.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
https://www.youtube.com/watch?v=9kaIXkImCAM
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Подробный разбор режимов кодирования основных кодеков читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда (частично устарело): https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
Актуальный гайд по кодированию от анона из треда №5 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
P.S. Для проверки отображения на дваче вашего нестандартного медиаконтента специально существует аж целая доска: https://2ch.hk/test/
Тред №0: https://2ch.hk/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html
Тред №2: https://2ch.hk/s/arch/2021-09-23/res/2979843.html
Тред №3: https://2ch.hk/s/arch/2021-11-13/res/3029626.html
Тред №4: https://2ch.hk/s/arch/2022-03-10/res/3056070.html
Тред №5: https://2ch.hk/s/arch/2022-06-29/res/3101682.html
Тред №6: https://2ch.hk/s/arch/2022-09-16/res/3144406.html
Тред №7: https://2ch.hk/s/arch/2022-11-14/res/3181555.html
Тред №8: https://2ch.hk/s/arch/2023-04-27/res/3205384.html
Тред №9: https://2ch.hk/s/arch/2023-07-25/res/3239508.html
Тред №10: https://2ch.hk/s/res/3301315.html
vb посчитал, получилось 311, нормально?
Как можно сделать спектрум на ffmpeg? Ну там же с помощью мат преобразований не обойтись? Тут уже начал смотреть в сторону вегаса хуегаса.
https://discuss.pixls.us/t/ffmpeg-scripting-to-create-an-scrolling-spectrogram/32943
https://www.cloudacm.com/?p=3105
Как дать av1an отрезок видео? В ffmpeg есть -ss и -t, а тут от ffmpeg можно использовать только фильтры.
Понял. А как в showwaves поменять амплитуду максимальную?
-b:v 1300k
А потом с таким
-b:v 1300k -maxrate 1800k -bufsize 1800k
В итоге файлы одинакового размера. И качества одинаковое (довольно херовое).
Эти параметры дополнительные вообще на что-то влияют? Или просто забить хер на них.
> 1300k
> 1800k
Ты эти числа с потолка взял что ли?
Если ты не знал, то твои битрейты примерно подходят для 480p и ниже.
> Эти параметры дополнительные вообще на что-то влияют?
> -maxrate 1800k -bufsize 1800k
Влияют, если ты пишешь свой клон ютуба или подстраиваешься под скорость считывания данных дисководом с диска.
Для webm на двач они не нужны.
Для домашнего транскода не нужен даже -b:v. Всё что тебе нужно для домашнего транскода это подобрать -crf.
>для домашнего транскода
А для недомашнего?
На лицензию нужно смотреть.
VP8/9 устарели уже
Посоветуйте музыку, на которой можно проверить потери аудиокодеков.
В смысле, эффективно проверить. Чтобы в одном треке были все возможные проблемы для кодека и я мог убедиться в их отсутствии.
Слишком простая музыка, такую любой кодек сожмёт без проблем.
У тебя на компе музыки подходящей нет, что ли?
https://files.catbox.moe/q2aqun.mp3
https://files.catbox.moe/v1x3h8.mp3
https://files.catbox.moe/86jt6r.flac
https://files.catbox.moe/0xu8rl.mp3
https://files.catbox.moe/5fult8.flac
Только ты копаешься с давно решённым вопросом. Уже десять лет назад ничего интересного не было в кодировании аудио, потому что везде был Opus, и куча результатов профессиональных и любительских тестов со готовыми значениями битрейтов для той или иной ситуации. Поскольку для аудио ширины каналов в подавляющем большинстве случаев хватает, теоретические вопросы запихивания целого оркестра в 32 кб/с при помощи каких-нибудь перспективных методов кодирования индустрию не особо волнуют. По идее, многопользовательские игры с передачей не только голоса (вроде VR-чатов) всё ещё могут желать значительно уменьшить объём пересылаемого всем присутствующим аудио или поднять его качество, но это, как мне кажется, не слишком большой рынок.
>Уже десять лет назад ничего интересного не было в кодировании аудио, потому что везде был Opus
А как же xHE AAC v2? Я всё не могу решить, лучше ли он опуса или хуже. У него есть оптимизация для стерео, если звук в обоих каналах не сильно отличается друг от друга. Ещё, почему-то, на всех сайтах советуют кодировать opus указывая битрейт вместо vbr.
Ну смотри
https://hydrogenaud.io/index.php/topic,120997.0.html
https://hydrogenaud.io/index.php/topic,121099.0.html
https://hydrogenaud.io/index.php/topic,120936.0.html
https://hydrogenaud.io/index.php/topic,120081.0.html
https://hydrogenaud.io/index.php/topic,119333.0.html
На сверх низких битрейтах преимущество однозначно на стороне xHE AAC, он же USAC.
На низких битрейтах (в раёне 64 kbps) уже не так однозначно, но всё ещё на стороне USAC.
Но ты скорее всего будешь кодировать на битрейтах повыше, от 96 kbps. И тут разница в звуке сходит на нет но проявляются проблемы нового кодека, такие как:
— слабая совместимость. Мало какой софт умеет его декодировать. Про аппаратную совместимость я вообще молчу. ffmpeg не умеет например.
— Контейнер mp4. Это проблема, потому что та же Apple придумывала костыли в тегах просто чтобы заставит воспроизводить его в gappless режиме. Работает только в их экосистеме и в фубаре.
— Интеграция декодера в ffmpeg это тот ещё глючный костыть из-за которого сам фубар вылетает.
>>3367431
Говорю же, нету спроса на новый универсальный формат с заметным скачком в скорости и качестве, пропускная способность аудио в типичных применениях не ограничивает. Посмотрите, где используется (x)HE-AAC, AAC-BSAC: цифровая радиотрансляция, сотовые сети, спутниковое вещание. Везде, где эфир общий, поделен на каналы фиксированного размера, и больше, чем есть, тебе не дадут (либо для этого требуются огромные инвестиции, государственная поддержка и планирование на десять и более лет), поэтому для увеличения числа потоков или их качества приходится изощряться. Не знаю, что нужно, чтобы высококачественное аудио (а не речеподобные передачи) от «на 128 кб/с можно кодировать чем угодно, средний слушатель не заметит» перескочило на «на 64 кб/с можно кодировать кодеком X, средний слушатель не заметит». Какой-нибудь европейский канал решит через спутник сразу 20 языковых дорожек слать, и захочет кодировать только отличия? Но для этого нужно иметь что показать с 20 вариантами дубляжа. Кроме того, существует интернет, в котором связь двусторонняя, и пользователь может переключаться между независимыми дорожками высокого битрейта столько раз, сколь надо.
Правильно ли я понимаю, что контейнер nut не поддерживает av1?
Ты не в тот тред вошел. Я не стану разбираться с твоей софтиной.
>Почему иногда (а может быть, теперь - всегда), когда я кодирую webm в vp9 через xmediarecode
Так кодируй ffmpeg-ом! С ним хоть какая-то диагностика будет.
> FFmpeg и общий кодирования видео тред
> не в тот тред вошел
ты ебанутый?
>>3368617
я че, ебанутый, хуйней какой-то заниматься?
>хуйней какой-то заниматься?
Видимо, так и есть.
И тут у меня появилась задача сделать видеопоток, что-бы видео выводилось не только у меня в софтине, а можно было бы к нему еще каким-нибудь плеером прицепится. Как это вобще делается? Как из пачки фоток постоянно идущих друг за другом сделать видеопоток? Мне сказали что ffmpeg умеет все, но я знатно так прихуел читая его доку. Может анон занимался +- чем-то похожим и архивную статью какую-нибудь подкинет.
https://ffmpeg.org/ffmpeg-formats.html#image2-1
> Image file demuxer.
>This demuxer reads from a list of image files specified by a pattern. The syntax and meaning of the pattern is specified by the option pattern_type.
> A sequence pattern may contain the string "%d" or "%0Nd", which specifies the position of the characters representing a sequential number in each filename matched by the pattern. If the form "%d0Nd" is used, the string representing the number in each filename is 0-padded and N is the total number of 0-padded digits representing the number. The literal character ’%’ can be specified in the pattern with the string "".
> For example the pattern "img-%03d.bmp" will match a sequence of filenames of the form img-001.bmp, img-002.bmp, ..., img-010.bmp, etc.; the pattern "im%%g-%d.jpg" will match a sequence of filenames of the form i%m%g-1.jpg, i%m%g-2.jpg, ..., i%m%g-10.jpg, etc.
> 3.12.1 Examples
>
> Use ffmpeg for creating a video from the images in the file sequence img-001.jpeg, img-002.jpeg, ..., assuming an input frame rate of 10 frames per second:
>
> ffmpeg -framerate 10 -i 'img-%03d.jpeg' out.mkv
>
> As above, but start by reading from a file with index 100 in the sequence:
>
> ffmpeg -framerate 10 -start_number 100 -i 'img-%03d.jpeg' out.mkv
>
> Read images matching the ".png" glob pattern , that is all the files terminating with the ".png" suffix:
>
> ffmpeg -framerate 10 -pattern_type glob -i ".png" out.mkv
Видимо? Видимо в чем?
Этот тред про ffmpeg. Мы не должны разбираться в твоих гуях, которые в большинстве случаев надстройка над ffmpeg.
>>3368677
Спасибо анон. Для 10 гц получается мне нужно сейвать 10 фоток, делать видос, удалять 10 фоток. сейвать следующие 10 фоток и так по кругу? А как будет работать ffmpeg, когда 10 фоток удалены, а новые я еще не сохранил? + mkv файл же будет разрастаться. В любом случае больше спасибо, буду вчитываться и ставить эксперименты.
Нет. Ты устанавливаешь фреймрейт такой каким он был в исходнике.
Сейвать тебе надо все кадры.
В итоге у тебя будет видос, ну допустим у тебя 10 кадров в секунду, и всего кадров 1000. Тогда у тебя будет видос на 100 секунд с кадровой частотой 10 гц.
Может ты удаляешь кадры потому что у тебя места мало на диске. Тогда делай порционно.
Во первых, определись с размером GOP. Для максимального сжатия ставят 10 секунд. Для быстрой перемотки 1 секунду.
Во вторых, определи кадровую частоту исходника.
Теперь вырази размер GOP в кадрах по формуле: размер GOP (в секундах) * количество кадров в секунду.
Затем определись с остальными параметрами кодирования видео: кодек, битрейт/crf, пресет/cpu-used. Сохраняй во временный файл сегмента, допустим segment001.mkv
Также создай файл segments.txt и запиши в него:
file segment001.mkv
Повторить по мере прохождения увеличивая номер сегмента в названии.
Для склейки введи команду:
ffmpeg -f concat -i segments.txt -map 0 -c copy видос.mkv
Если всё получится, сегменты можно удалять.
Бесконечный поток кадров идёт, в этом вся соль, не нужно записывать видео. Нужно что-бы кадры куда-то шли, но нигде не сохранялись, а когда мне нужно я бы открывал какой-нибудь плеер типа vlc и мог просматривать что там вот сейчас льется.
Что-то типа usb-камеры, подключаешь ее - открываешь плеер и смотришь. Может я конечно вообще думаю не в ту сторону и нужно обмазываться написанием драйверов, чтобы самодельная железка определялась как камера, но мне кажется это вобще убийство )
само собой я могу хранить какое-то количество кадров на диске, в пределах разумного.
Тогда тебе нужно считывать кадры с самого устройства непосредственно.
Во первых VLC сам по себе умеет открывать потоки и устройства для воспроизведения. ffmpeg тебе для этого не нужен. Просто покопайся в менюшках
так тоже не получится, пакеты с устройства идут с самописной шапкой, своей софтиной я уже их разбираю и делаю пикчи png bmp tiff, вобщем всё могу.
Доложите состояние аппаратного кодирования в AV1 в 2023 году.
Тогда придумай как вывести твои кадры в pipe. Ну чтобы можно было сделать так: прога | mpv -
У ffmpeg оно называется image2pipe. Сделай так чтобы вывод соответствовал формату. Тогда может и VLC и MPV откроют.
Последнее поколение карточек от nvidia, amd и intel умеет кодировать AV1. Это всё что я могу сказать по этому поводу.
>У ffmpeg оно называется image2pipe
Спасибо! Буду ковыряться.
Ты ебанутый? Это тред не только про ффмпег, так в оппосте написано.
Ну так бери помогай тому анону с его гуёвиной. А я с ней не работал и желания разбираться с ней не имею.
Наименее базированный пользователь GNU.
Ты с какой целью использовал дегенеративный сленг?
Но всё равно базированный.
ffmpeg это база. Гуи под него лишь надстройка.
Есть ли для этого однокнопочный гуй или надо курить пердольные гайды? Для отшакаливания надо качать ремуксы или уже отшакаленные x264рипы пойдут?
Попробуй просто масштабнуть видос в разрешении с дополнительными пикселями.
>scale=iw2:ih2:flags=neighbor
>>3369555
Вы думаете я про однокнопочной гуй просто так спросил чтоль? Что вы сходу грузите-то?
Тебе доверено слушаться, а не морозиться.
> уже отшакаленные x264рипы пойдут
Очевидно нет.
> или надо курить пердольные гайды
там не сложно на самом деле. Гайд здесь https://kokomins.wordpress.com/2019/10/10/anime-encoding-guide-for-x265-and-why-to-never-use-flac/
Мне безумно понравился видосик с крутящейся кассетой. Я клею на него разную музыку в вегасе (да, можно через ffmpeg, но я добавляю название в видеопоток).
Есть ли кодеки, которые сами залупят маленький повторяющийся фрагмент видео, чтобы семиминутный трек не весил 20 метров?
Если это можно сделать вручную через ffmpeg - то какой командой?
>Очевидно нет.
А как же тогда все эти хевк релиз группы на няхе делают своим релизы? Они там в источниках указывают релизы от сабсплиз, ерай, етк. А сабсплиз и ерай просто рипают кранчи в х264, не?
https://superuser.com/questions/1598469/loop-video-to-audio-without-increasing-its-file-size
Неожиданно, но самые первые мультимедийные решения начала девяностых годов вроде QuickTime как раз имели возможности по склейке фрагментов в нужном порядке, наложению на часть кадра с нужными координатами, вставке статичных картинок в нужный момент и так далее. На основе этого делались всякие приложения и игры. В MOV/MP4 есть edit lists, позволяющие нарезать, сдвинуть, зациклить куски видео или аудио, но их никто не поддерживает, кроме видеоредакторов и Apple'овских программ.
Само собой, название наложить можно фильтром в ffmpeg, хоть это и не важно.
Перечитай реквест и перепроверь, что ты принёс.
>в хевк
Хуйня затея. Кодируй в svt-av1 - намного лучше соотношение размера и качества. Я сжал примерно в 12 раз, сохранив визуальную прозрачность (без потерь) качества, за исключением потерянного зерна пленки (шума).
Единственная проблема - некоторые серии одного из тайтлов не хотят сжиматься в svt-av1, начиная с какой-то минуты значительно проседает скорость и раздувается размер. Их я кодировал в vvc, и там прозрачное качество занимает примерно в 8 раз меньше оригинала.
Чтобы вырезать и сжать с привычными параметрами кусок только что снятого видео для отправки по телеграму, например.
Кому это может понадобится?
Телеграм сам сжимает твоё видео перед отправкой.
Телефоны в принципе не предназначены для обработки больших объёмов данных. Они греются, разряжают батарею и никак не охлаждаются.
>Кому это может понадобится?
Мне.
Естественно фо фри и желательно, чтобы это был софт, хотя можно онлайн-сервис и даже с рекламой, но с каким-то вменяемым количеством.
Есть в ffmpeg фильтры для визуализации аудио. Добавишь сверху фильтр с тенью, говноблюр, выберешь цвета неоновые под ретро, и готово.
Готового примера нет %%для тупых и ленивых?
>Можно ещё указать film-grain=8 если у вас в видео есть шумы, перед сжатием они будет применён алгоритм убирающий шумы, и в видео записана информация как их воссоздать, за счёт чего степень сжатия и качество видео возрастает очень сильно.
Что-то не могу найти инфу по этой фигне, как оно работает, у меня выдаёт ошибку (см.пик)
Подскажите плиз чо не так делаю.
Ты чё то не то прописал в командлайне. Перепроверь.
ffmpeg -i "1.mp4" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 5000k -svtav1-params tune=0:irefresh-type=1 film-grain=8 svt.mkv
Да вот как-то так прописал, без команды film-grain=8 норм работает.
Должно быть так:
ffmpeg -i "1.mp4" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 5000k -svtav1-params tune=0:irefresh-type=1:film-grain=8 svt.mkv
Спасибо тебе анончик, так всё работает
А я теперь просто гопоте велю мне команды составлять.
>Актуальный гайд по кодированию от анона из треда №5
>libsvtav1
>Два прохода пока не поддерживается в ffmpeg
А сейчас?
Как сделать, чтобы под виндой ффмпег по умолчанию запускался с приоритетом процесса ниже среднего?
Использовать вызов /start /belownormal ffmpeg.exe -a -b -c -d.
Если программа не позволяет это настроить, использовать ffmpeg.bat, который будет вызывать ffmpeg-real.exe и передавать ему все параметры (или по крайней мере пытаться, учитывая экранирование). Или простенькая программа-обёртка, которая будт делать то же самое.
Никуда они не деваются. Просто от проигрывателя в браузере - огрызок (странно, да?) который не умеет в несколько дорожек в файле и во встроенные субтитры.
Подожди, я думал что я вшил субтитры в само видео. А это оказывается в mp4 формате есть место под субтитры? А как тогда наложить субтитры?
Желтым на видео - хардсаб - когда прямо на картинку намазано. Чтобы добавить нужно перекодировать с фильтром. С потерей качества, натурально. Убрать - никак.
https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo
Белые сабы - софтсаб, это просто дорожка сабами в виде текста встроенная в контейнер. Можно добавить еще, можно убрать, можно отображать, можно не отображать - видеопотоку от этого ни горячо ни холодно.
Cложна, а есть более простой путть без всяких консолей? Просто кинуть видео и субтитры, и чтоб видео сшилось одной кнопкой?
>другой кодек
>другой битрейт
>файл вырос на 33%
Кто бы мог подумать!
Ну а как сделать по нормальному? Почему нет программ где можно просто сшить файлы
Da.
Если прямо га твой вопрос отвечать, то
ffmpeg -i infile.webm -c copy outfile.mp4
Имена файлов подставлять шелл-скриптом по вкусу. Возможно, понадобится что-нибудь вроде
ffmpeg -fflags +genpts -i...
Но ты учти, что сегодня mp4-контейнер - это такой mov на стероидах, пытающийся в универсальность уровня матрëшки. Быстрее всего, не все программы и устройства смогут в vp9 и opus внутри mp4.
Зачем их конвертировать в мп4? Хороший формат же.
И ещё, как влияет Keyframe interval и Max B-Frame на размер\качество видео ?
Что-то внятной инфы на русском найти не могу в интернетах.
Нельзя залить в твиттер
мимо
Почему откуда я качаю видео в формате мп4?
ffmpeg -hwaccel auto -y -i "/storage/emulated/0/Movies/video.mp4" -vn -q:v 5 -c:a copy -ab 128k -ar 44100 -strict experimental "/storage/emulated/0/Download/video.webm"
Как установил? Какую ошибку?
Ну вот анончик где я ебусь в глаза потому что до этого я нормально черезо него гонял и все работало, потом начала вылезать эта ошибка
Скачал с плеймаркета через форку gspace на моего китайца
нет спасибо
Говно, спок. Без тебя уже нашел решение
-b:v 1000k
-minrate 1000k
-maxrate 1000k
-bufsize 1000k
>>3381417
Все гуи поделки на мобилках это кал нормально не работающий, хз что они там делают с либой, может под мобилки как-то модифицируют, но у меня все что я пробовал ебали мозг. Лучше реально через термукс пользоваться, там хотя бы либа оригинальная будет.
Нет. Без перекодирования нельзя.
Проблема в том, что lossy кодеки преобразуют обычное стерео во всякие там joint stereo, mix side stereo. Там нет отдельного потока данных для левого и правого каналов.
5 минут на 20 мб это 559 kbps на весь поток.
Если без звука, то на видео все 559 и уйдут.
Если звук моно, то 559 - 32 = 527 kbps.
Если звук стерео, то 559 - 64 = 495 kbps.
Далее вопрос каким кодеком ты собираешься сжимать.
Выбор аудио кодека зависит от формата контейнера. Если webm, то просто выбирай libopus. Если MP4, то тебе надо кодировать в AAC.
А вот с кодеком AAC у ffmpeg всё сложно. ААС с профилем LC посредственно справляется с выбранными мной битрейтами (32 на моно, 64 на стерео). А ещё у дефолтного в ffmpeg AAC есть баги по психоакустике. Тебе нужен профиль HE-AAC, кодировать в который могут только qaac и fdk-aac.
Выбор видеокодека тоже зависит от контейнера. Если MP4, то libx264. А ещё пропиши "-vf scale=-2:360" (если видео горизонтальное, или "-vf scale=360:-2" если вертикальное). А ещё поставь "-preset veryslow" чтобы максимально сохранить качество. Можешь даже плацебо поставить, я разрешаю.
Если WEBM, то тебе надо выбирать между libvpx-vp9, libaom-av1, однопроходным libsvtav1 или через pipe загнать видеопоток в SvtAv1EncApp чтобы оно кодировало в 3 прохода. Но взамен ты можешь поднять разрешение до 480p.
Ты хотел готовый commandline. Я тебе дам 3, для случая когда звука нет, когда звук моно и когда звук стерео. Рассматривать я буду только WEBM/VP9. AV1 изучай сам.
Без звука:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 550k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 550k -cpu-used 4 -pass 2 -an output.webm
Моно:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 2 -ac 1 -c:a libopus -b:a 32k output.webm
Стерео:
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 490k -cpu-used 4 -pass 1 -an -f null /dev/null && \
ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 490k -cpu-used 4 -pass 2 -c:a libopus -b:a 64k output.webm
Заебись, спасибо. Да, там без звука слава богу. Буду пробовать, а то я сколько не конвертил, качество в полном говне выходило
>А вот с кодеком AAC у ffmpeg всё сложно. ААС с профилем LC посредственно справляется с выбранными мной битрейтами (32 на моно, 64 на стерео). А ещё у дефолтного в ffmpeg AAC есть баги по психоакустике. Тебе нужен профиль HE-AAC, кодировать в который могут только qaac и fdk-aac.
Молодца. Теперь всё правильно сказал. Горжусь тобой!
Давай рассуждать логически. Возможно, VLC куда-то теряет ключевой кадр в начале или пишет его в том формате, который декодер на устройстве (вероятно, аппаратный) не понимает. Это странно, но стоит проверить, какой профиль выбирается, какие размеры буферов и так далее, и сравнить с тем, что поддерживается на смартфоне.
Более вероятно, что у тебя выдаётся в MP4 голый поток пакетов аудио и видео, как при вещании по сети, а плеер просто несколько секунд пытается найти в файле каталог или хоть какие-то опорные точки, либо индексирует его от начала и до конца. Смотри, как выбрать файловый формат, содержащий метаданные о длине и индекс.
Тебя забанировали. Это всё из-за адблок детекторов мать их.
Ну я не стал ебаться со всем этим, закодировал в Handbrake с теми же настройками и проблема пропала.
Error 1337: wrong thread
> указать формат MP4-файла
> ВОТ ЭТО Я ЗАЕБАЛСЯ, ВОТ ЭТО БЫЛО ТЯЖКО
ffmpeg -i input.mp4 -force_key_frames 00:00:09,00:00:12 tmp.mp4
ffmpeg -i tmp.mp4 -ss 00:00:09 -t 00:00:03 -c:v copy -c:a copy out.mp4
> -ss 00:00:09 -t 00:00:03 -c:v copy -c:a copy out.mp4
Так и делою. Не попадает куда надо, нужно точно перед первым словом песни.
> ffmpeg -i input.mp4 -force_key_frames 00:00:09,00:00:12 tmp.mp4
Пережимать заново начинает, хуйня какая-то. И так уже пережатое до квадратов.
Ключевые кадры независимые, остальные кадры зависят от них. Если ты без перекодирования режешь не по ключевому кадру, то все кадры от начала до ближайшего ключевого кадра сломаются, потому что они зависимы от отсутствующего ключевого кадра. Так что надо либо перекодировать, либо резать начало по ключевому кадру, а их расстановка зависит от настроек предыдущей итерации энкодирования.
Почему нельзя перекодировать только начало и конец, а потом склеить с незатронутой серединой?
Можно. Ты просто не знаешь, что прячется за словом «склеить».
https://superuser.com/questions/1644273/how-to-cut-video-in-multiple-place-and-combine-them-without-re-encoding-using-ff
Чтобы декодер не сошёл с ума, стыкуемые куски видео должны иметь не только одинаковое разрешение и прочие параметры и механизмы кодирования, но и использовать совпадающий интервал внутренних отметок времени, помещаться в заданный размер буфера, и так далее. При кодировании видео целиком кодировщик за всем этим следит. При кодировании куска видео следить за тем, что происходит в момент стыка, придётся тебе. Кроме того, синхронизацию аудио и видео надо настраивать так же, как в оригинале (но тут легче обрезать под финальную длину и разделить на отдельные дорожки, а потом собрать).
Фактически, ты должен понимать, из каких элементов состоит видео, закодированное в выбранном формате, и как оно хранится в выбранном контейнере, чтобы всё это проверить при склейке и указать правильные циферки.
Картинки в JPEG технически тоже можно пытаться сохранять только в отредактированных местах, чтобы не шакалить нетронутые блоки. Теперь попробуй найти графические редакторы, которые такое развлечение предлагают.
Конец можно резать в любом месте, речь только про начало.
Разве любой видеокодек это не сжатие каждого кадра а-ля жпег? В мп3 ещё бы "ключевые фреймы" какие засунули, чтобы директкат не мог обрезать ровно.
Как ты думаешь, почему это вдруг Apple в последний момент присоединилась к альянсу Open Media?
Очевидно же, что если бы AV1 был бы таким же говном как и его предшественники, ни Apple, ни Nvidia, ни AMD, ни Intel и шагу бы не сделали для аппаратной поддержки этих кодеков.
На самом деле я подозревал, что склеивание не тривиально, т.к. были с ним проблемы в прошлом, у кого-то в браузере не открывалось склеенное мною видео.
>>3386299
Разумно.
Не имеет смысла. Лучше просто перепакуй их в нужный контейнер при помощи -c copy.
Использовал svt-av1 -preset 2, -crf 10, tune=0,scd=1,enable-overlays=1 и все равно картинка не дотягивает до простого рипа h264, который практически идентичен оригиналу до пикселя. Даже HEVC можно добиться такой картинки, если отключить sao, intra-smoothing и снизить crf. С libaom еще хуже качество вышло. AV1 удаляет много деталей, мылит, предлагает какие-то хаки с фейковым грейном на уровне декодера. Ну его нахуй, лучше использовать старый скуфский x264, который прослужил 20 лет и прослужит еще столько же. AV1 чисто сделан, чтобы занизить битрейт и нагрузку на сеть для больших компаний и смотреть на каком-нибудь телефоне или планшете. Даже не знаю, что там будет с VVC и AV2.
Чё ты ноешь? Мы тут сжимаем AV1 чтобы битрейты уместить до 5 мегабит на Full HD. Для нас некритично если какая-то мелкозернистая деталька пропадёт в процессе сжатия. Всё равно в движении некогда их рассматривать.
Но если тебе важен pixel perfect и visually lossless, и ты готов тратить гигабайты чтобы всё это сохранить, то специально для тебя господа с торрент трекеров разработали методологию сжатия в x264. Короче, тебе даже сжимать ничего не надо, просто качай BDRip.
Можно и с помощью ананаса, если на кнопки любишь нажимать.
Как же мне по нраву масонские символы: циркуль и наугольник, есть в них что-то тайное, великое, нашедшее отражение даже на официальной геральдике, вроде той же ДДР.
Работаю в шараге мухосранска на 20к рыл. Так там офф. символ этой шараги - циркуль с наугольником. Основана эта шарага, как полагается, жидом.
1. Исходник.
2. preset 2, crf 20 что уже считается оверкиллом для 1080p. Зернистость полностью пропадает, а её остатки превращаются в дерганные артефакты.
3. То же самое только с film-grain=20:film-grain-denoise=0, уже лучше, но если увеличивать grain, то начинает резать глаза и будет виден искусственный паттерн, как будто по экрану кто-то тряпкой водит.
Ну основал и основал, деньги платит, рабочим местом обеспечиват.
>сжатие каждого кадра а-ля жпег
ты только что гиф
>Разве любой видеокодек это не сжатие каждого кадра а-ля жпег?
Нет. Есть кодеры без компенсации и поиска движения. Самые растространëнные бытовые из них — это mjpeg и dv. Но они всем классом уже лет двадцать как сданы в утиль — не выдержали конкуренции. Из современных вариантов того же класса в живых остался только DCP — один из вариантов применения контейнера MXF с несжатым звуком (PCM) и последовательностью отдельных кадров изображения, сжатых jpeg2000. Применяется DCP, чтобы доставлять фильмы в imax-кинотеатры.
>В мп3 ещё бы "ключевые фреймы" какие засунули, чтобы директкат не мог обрезать ровно.
mpeg layer 3 поток можно разделять тоже не «ровно», а по кадрам. В кадре mpeg layer 3 помещается 1152 отсчëта.
Добро пожаловать в реальный мир!
Это в шапку надо спасибо
> pipe загнать видеопоток в SvtAv1EncApp чтобы оно кодировало в 3 прохода.
тут немного не понял поясни пожалуста
> между libvpx-vp9, libaom-av1, однопроходным libsvtav1
какое различие принципиальное однопроходный быстрее?
будь добр помоги поебаться скачал пакет отсюда https://github.com/tanersener/mobile-ffmpeg
В термуксе написал сначало pkg update
Затем pkg install ffmpeg выдало пик
нужно разархивировать или куда? Как первый раз залез в эти блудни
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Ffmpeg.md#piping-from-ffmpeg-into-the-standalone-encoder
> какое различие принципиальное однопроходный быстрее?
Да, но он не может адекватно распределить битрейт по времени.
Кодирую hevc_nvenc с заданием качества через "-cq:v", в консоле пишется битрейт, которому я склонен доверять, ибо он блять меняется в зависимости от значения cq.
А в mediainfo все время какой-то сильно завышенный битрейт, причем он почти не меняется при измеении cq.
Что это за хуйня?
Очевидно, битрейт одного потока не может превышать битрейт всех потоков целиком, написанного выше (или просто получаемого делением размера файла на продолжительность).
Дело в том, что форматы контейнеров в общем случае никак не взаимодействуют с потоками с переменным битрейтом. (Хотя могут иметь индекс опорных точек, по которым можно догадаться, в районе какого примерно смещения находится нужный элемент. В потоках с постоянным битрейтом все элементы одного размера, так что при декодировании можно просто вслепую поделить пропорционально объём файла и начать искать в окрестностях полученного адреса начало кадра. Это конечно, технология девяностых годов и годится разве что для AVI.) Кроме того, большинство кодеков выдаёт формат потока, ориентированный на вещание по сети или в эфире (а не исключительно на чтение из файла с произвольным доступом), и поэтому делит его на множество независимо декодируемых элементов, чтобы начать это делать можно было в любой момент (с незаметной на практике задержкой). В результате, чтобы вычислить какие-то характеристики всего потока (например, средний битрейт), его требуется просканировать от начала до конца, обработав каждый. Именно поэтому для видеопотока MediaInfo часто не показывает битрейт или размер данных: таких метаданных в файле просто нет, а для их вычисления требуется прочесть весь файл, что чаще всего совсем не нужно пользователю.
В твоём случае может быть два варианта:
— Это поле на практике можно (или рекомендуется) использовать для того, чтобы сообщить декодеру, какой пиковый объём данных может к нему попасть, чтобы тот заранее выделил себе нужный объём памяти. Тогда ошибка в названии, и следует писать «максимальный битрейт».
— MediaInfo берёт значения первого элемента или нескольких, и дальше в файл не смотрит. Вероятно, количество информации там отличается в большую (ключевой кадр и обилие движения заставки) или меньшую (просто чёрный экран) сторону от среднего.
Точно то же самое было при появлении VBR MP3, многие программы показывали битрейт только первого фрейма или неправильно считали какие-то другие цифры. Там пришли к нестандартному хаку, когда дополнительная информация о потоке внедряется прямо в аудио в виде фрейма, не влияющего на воспроизведение.
> 5 минут на 20 мб это 559 kbps на весь поток.
И как ты это расчитал кстати? Помню формула была какая-то
1 Мегабайт это 1024 Килобайта
1 Килобайт это 1024 байта.
1 байт это 8 бит.
1 килобит это 1000 бит.
(20102410248)/1000 = 167772.16 килобит.
1 минута это 60 секунд.
167772.16 / (560) = 559,24 килобит в секунду.
У меня поплыла разметка, поэтому пощу заново.
1 Мегабайт это 1024 Килобайта
1 Килобайт это 1024 байта.
1 байт это 8 бит.
1 килобит это 1000 бит.
(20 1024 1024 8) / 1000 = 167772.16 килобит.
1 минута это 60 секунд.
167772.16 / (5 60) = 559,24 килобит в секунду.
Как же мне надоела эта разметка.
(20 х 1024 х 1024 х 8) / 1000 = 167772.16 килобит.
167772.16 / (5 х 60) = 559,24 килобит в секунду.
Тебя не смущает, что у тебя кило в одном месте означает 1000, а в другом 1024?
Да, видео не перекодировано. Аудио в основном тоже, по возможности, как минимум в оригинале и официальных дубляжах. В одном контейнере может быть собрано много разных озвучек и субтитров.
Это уже нюансы. Но если тебе интересно подушнить, давай подушним.
Есть кило-/мега-/гига-/тера- байты. А есть киби-/меби-/гиби-/теби- байты.
На самом деле килобайт соответствует православным 1000 байт. А Кибибайты соответствуют как раз таки 1024 байтам. И так далее.
Причина по которой я не использовал название приставок МЭК в посте в том что я их не помню наизусть, и без википедии и не вспомнил бы. А ещё так не модно. Корпорация Microsoft ввела моду в своей винде называть кибибайты килобайтами, и так оно в массы и пошло.
А само видео блюрей в каком формате идет? Разве видео не зашифровано, чтобы не копировали?
Так ключи декодирования можно спереть из лицензионных программ и устройств при желании. Ты не в курсе, что в интернете существует большая открытая энциклопедия?
https://en.wikipedia.org/wiki/Blu-ray#Digital_rights_management
https://en.wikipedia.org/wiki/Advanced_Access_Content_System
>Корпорация Microsoft
Майкрософт тут не при чём. Мебибайты были удобны погромистам, потому что кратны степеням двойки. Мегабайты/мегабиты были удобны телекомщикам, потому что кратны мегагерцам. Универсальной единицы нет.
То ли телекомщики оказались весомее, то ли в те времена считать передачу данных была важнее, чем хранение, но прижились именно десятичные приставки. Битрейт, кстати, чисто телекомовский термин, там десятичные килобитывсеки.
По такой аналогии может существовать dvdremux, vhsremux и тд?
>vhsremux
>Это блять нереально без постоянного курения документации использовать
Примерно так. У меня для того, чтобы не лезть в документацию каждый раз есть
$ history | grep "^ffmpeg"
Документация должна быть под рукой, да, но и запомнить то, что не шпаргалке, нетрудно — но, конкретно в моëм случае, лишено смысла.
> dvdremux
Посмотри на раздачи DVD-дисков, там просто копируют содержимое VIDEO_TS целиком. Другое дело, что MPEG2 далеко не новый кодек, и тот же уровень качества можно достичь при меньшем объёме, закодировав современным. Другое дело, что некоторые видео настолько плохи, что лучше их вообще не пережимать, чтобы не портить дальше, поэтому они хранятся как есть.
> vhsremux
Там аналоговый сигнал, алло.
Впрочем, как с лазердисков оцифровывают читаемый сигнал прямо с датчика с большим запасом при помощи Domesday Duplicator, а потом декодируют картинку программно ld-decode (а не аналоговой схемой в проигрывателе), так и для кассет есть vhs-decode. Для профессионально записанных кассет получается очень хорошо:
https://odysee.com/@therewinding:4/wdw-epcot-center-souvenir-program-1983:b
Только надо помнить, что шум на изображении — фикция, артефакт формата хранения, а не часть оригинала. Если его убрать, видео станет более замыленным (и более соответствующим тому, что показывали реальные телевизоры), но тогда мы потеряем часть реальных данных, прячущихся в шуме.
В YouTube-телевизоре популярный видеоблогер как раз видео выпустил на эту тему.
>Посмотри на раздачи DVD-дисков, там просто копируют содержимое VIDEO_TS целиком
Рад за них. Речь про удобный контейнер же, а не портянка с диска, которую хуй знает как проигрывать.
Удалить там мусор всякий, меню. Разве не то же самое и в бдремукс делают?
> закодировав современным
При любой перекодировке качество падает. Хочу оставить видео как есть.
>vhs-decode
VHS оцифровывают. Судя по гайдам c digitalfaq, для максимального качества используют профессиональный видеомаг. с внутренним TBC + внешний TBC + особая карта захвата и комп под winxp для нее, видео идеальное, без помех. Видео весит как блюрейник. Стоит билд несколько тысяч баксов. Конечно качество видео также зависит от состояния видика и кассеты.
Но я имел ввиду цифровые кассеты, с которых по идее можно просто скопировать файлы.
>цифровые кассеты, с которых по идее можно просто скопировать файлы.
DV или какой-либо аналогичный формат. Подключают камкодер с кассетой через 1394 или usb. Дальше варианты — на прыщах есть dvgrab. У последнего на выходе либо raw, который ffmpeg, вроде бы, разбирает, либо avi с dv и звуком pcm. avi такой есть почти любой редактор. Но dv - это штуковина уровня mjpeg: предсказания и компенсации движения нет, компрессия около 5:1. Ширина потока данных ограничена у dv жëстко. Съëмка с высоты роста человека превратит лужайку травы в месиво из блоков.
> мусор всякий, меню
Там, говорят, техника дошла уже до того, чтобы краткие содержания генерировать. Фильм, следовательно, сам становится «мусором», его можно и не смотреть.
> хуй знает как проигрывать
20 лет назад, действительно, могло быть сложно обычному пользователю DVD-диск воспроизвести, если он не в реальном или виртуальном приводе. Ну и объём по тогдашним временам был ого-го. С тех пор много воды утекло, попробуй более свежие версии программ.
> При любой перекодировке качество падает.
Мощное заявление. Вот я использую кодирование без потерь, «качество» упало? Нет, это буквально те же самые данные. Вот я использую кодирование с потерями, «качество» упало? Нет, если настройки таковы, что визуально средний (вариант: самый придирчивый) человек отличий не заметит. Вся индустрия кодирования с потерями стоит на том, что человек не является идеально воспринимающим механизмом, а ты тут шатаешь основания.
Просто если на картинке каша из макроблоков, то кодировать их (без обработки), задирая битрейт, нет никакого смысла.
> Хочу оставить видео как есть.
Ну так запихни нужную дорожку в любой другой контейнер, вот тебе и ремукс. Только особых преимуществ по сравнению с копированием диска нет.
> особая карта захвата и комп под winxp для нее
О, потёк аудиофильский эякулят. «Такого больше не делают», «специалисты высшей пробы», «уникальный экземпляр, повторить невозможно».
Я уже назвал проект, в котором никаких секретов нет, просто АЦП (недешёвый, с частотой и разрядностью дискретизации, достаточной для работы с сигналом прямо с датчика) и дальнейший разбор в цифре с любой необходимой точностью и любыми методиками интерпретации.
> Но я имел ввиду цифровые кассеты, с которых по идее можно просто скопировать файлы.
Если ты про DV, то по FireWire это делается чуть ли не встроенными в ОС средствами. Есть и специальные программы, которые реагируют на ошибочные блоки и несколько раз пытаются прочесть нужные места. Принцип тот же самый, что и в ddrescue, поскольку это тоже цифровое устройство хранения данных.
https://www.youtube.com/watch?v=YGPIqJ4_ssI
>Только особых преимуществ по сравнению с копированием диска нет.
А должны быть?
Обнаружил забавную хуйню, что можно вычислить примерный размер будущего видео еще на ранних стадиях кодирования.
Даже если битрейт переменный, он все равно в рамках файла примерно одинаковый.
-vcodec copy
Главное чтобы там уже было что-то совместимое с матрёшкой. А то есть тут неподалёку индивидуумы, которые хевк в мп4 пихают и жалуются что половина браузеров не открывает это говно.
разве мкв это контейнер, в который можно что угодно запихнуть?
Назови мне браузер, который поддерживает hevc, но не открывает hevc в mp4.
Я слишком тупой или это и правда бессмысленный набор символов? Как из этого понять, какой битрейт мне нужен для того, чтобы получить файл 25 МБ продолжительностью 11 секунд?
В байте 8 бит. В кило-хрени 1000 хреней (или 1024, если используются бинарные префиксы). В мега-хрени 1000×1000 хреней (или 1024×1024). Можно не гадать, как округлять, а написать точное значение в битах в секунду. Потом вычитаешь из общего битрейта на весь файл битрейт аудио, остаток остаётся для видео.
Метры в километры и мили переводить умеешь?
И правда, ларчик просто открывался. Спасибо.
ffmpeg -ss 0.0 -i input -map_metadata -1 -map_chapters -1 -c:a copy -to 406.0 output
>не убирает главы
Это рядом с -map_metadata -1 ДО настроек кодировщика: -map_chapters -1
Это в конце перед указанием выходного файла:
-movflags disable_chpl
Причина: главы пишутся в 2 разных форматах, второй - для пидорасов на эппле, пиздец просто.
> Моно:
> ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 1 -an -f null /dev/null && \
> ffmpeg -i input.mp4 -vf scale=-2:480 -c:v libvpx-vp9 -b:v 520k -cpu-used 4 -pass 2 -ac 1 -c:a libopus -b:a 32k output.webm
Делал по этому подогнал формулу под своего видео, ффмпег просто встал ничего делает чяндт
При этом, если запустить его, поставить на паузу, выбрать дорожку, кот. была копирована из movierip2.mkv вместо добавленной - тогда перемотка работает нормально и ничего не виснет.
ЧЯДНТ?
Хм, а вот через mkvtoolnix всё получилось нормально. Непонятно...
Раньше кодировал в blender, как я понял туда встроен тот же FFMPEG (см.пик) и при этом видосы закодированные в AV1 там не тормозят при перемотке, в любую точку видео перескакивает моментально.
Так вот можно как-то оптимизировать кодирование через FFMPEG ?
У тебя не должно быть таких лагов. Попробуй обновить libdav1d до последней версии.
Сколько fps у твоего видео? Если 24, то поставь такой-же Keyframe interval. Если 30, оставь как есть.
Вопрос не по теме: зачем тебе realtime пресет? Если нужно срочно видео, у тебя есть h264. Если комп не тянет AV1, юзай h265.
И если речь о встроенном в ffmpeg aac, повысь битрейт до 320.
Пощади, оставь хотя бы h264
Ну даже реалтайм пресет AV1 выдаёт результат заметно лучше, чем H264, поэтому и юзаю его.
А вот на счёт ключевых кадров было подозрение, т.к. по дефолту FFMPEG вроде ставит 160.
Попробую ставить такой же keyframe как и у фпс, спасибо.
Если ты не указываешь явно интервал ключевых кадров, то он может быть настроен под видосики времён DivX. Ещё настройки упаковки в контейнер или создания индекса могут быть непонятно какими.
в ролике отрендереном в ffmpeg задержка в секунду, а второй вообще без задержки.
С чем это связано не могу понять.
Начни с того, что возьми командную строку, с которой ffmpeg запускается из Blender, выбери все содержательные параметры, повтори и посмотри на результат. Вон там что-то про размеры блоков в muxing, ты у себя это указываешь?
Короче нашел проблему, если кодировать c CRF - видео перематывается с задержкой, хз как работает этот режим битрейта, а вот с постоянным битрейтом такой проблемы нет, всё шустро летает.
То есть ну бля, вы прям руками каждый раз прописываете имя файла и путь к нему? Это ж обосраться как неудобно. Или видео, с которыми работаете, надо предварительно складывать в папку куда установлен сам ffmpeg?
Я не троллю, я правда не понимаю. У меня лежит там штук сорок видео с ютуба, допустим, мне их надо перекодировать чтобы сраный премьер про их принимать начал (хули дебилы из адоба поддержку vp9 сами не сделают, блядь, заебали) - мне их надо туда-сюда по папкам таскать или названия им всем поменять на короткие, чтобы точно не опечататься забивая их в ffmpeg? Я просто не понимаю нахуй, вы это делаете за пять минут левой ногой попивая кофе, как?
>То есть ну бля, вы прям руками каждый раз прописываете имя файла и путь к нему?
В kde можно перетащить иконку файлика мышкой, чтобы имя под указатель в консолечке вставилось. В шиндошс 10 так в кмд.езе тоже можно.
Плюс, есть подсказки интерпретатора по tab.
>обосраться как неудобно
>предварительно складывать в папку куда установлен сам ffmpeg?
Да. На прыщах к исполняшке ffmpeg путь всегда известен, т. к. она лежит в системном каталоге для исполняшек. На шиндошс с незапамятных времëн в реестре есть веточка
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
В неë можно ffmpeg добавить, чтобы как в прыщах запускать ffmpeg в любом текущем каталоге.
А ещë в прыщах в kde и в других средах, как правило в файловых менеджерах есть возможность в текущем просматриваемом каталоге запустить командную оболочку. Удобно сделано, для людей.
>хули дебилы из адоба поддержку vp9 сами не сделают, блядь, заебали
Коммерческий интерес у них. Используешь коммерчнское ПО — привыкай к интересам барина и чувству ранга!
>мне их надо туда-сюда по папкам таскать
Можно запускать ffmpeg в каталоге с этими последовательностями. Кстати, а современный Премьер кушает avisynth/vapoursynth хотябы через что-нибудь, чтобы тебе не перекодировать последовательности?
> или названия им всем поменять на короткие
Вот это хорошая мысль. Даже вне зависимости от ffmpeg и командных интерфейсов. Способ именования файлов — великая вещь, если способ этот вдумчивый.
>Я просто не понимаю нахуй, вы это делаете за пять минут левой ногой попивая кофе, как?
Да. При определëнном навыке это делается легко и просто. Даже несложные регулярные выражения сходу сочиняются после практики. Люди, вообще, обучаемые — это их видовая особенность.
2,Если при конвертации поставить битрейт больше, чем у оригинала, произойдет что со звучанием? Не ухудшится?
3,Моно нужно меньше битрейта, нежели стерео, или я ошибаюсь?
> На шиндошс с незапамятных времëн в реестре есть веточка
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
В неë можно ffmpeg добавить, чтобы как в прыщах запускать ffmpeg в любом текущем каталоге.
Есть переменные окружения, а про ветку реестра я впервые слышу.
Какие батники павершеллы и питоны используют
ладно, вот вам всем задачка.
есть "несжатые" хромакейные сурсы, но слишком уж большой размер у этих синих шакалов.
жму handbrakом, все здорово, размер меньше в десятки и сотни раз, новых шакалов не прибавляется, но на границах между синевой и обектом повялется ттакая темно-синяя рамка. я не эксперт, наверно дело в цветовом пространстве?
lagarith и Ut Video, вроде в RGB, нужно сжать в любой формат и кодек, уменьшив рамер и не проебав цвета
>Есть переменные окружения, а про ветку реестра я впервые слышу.
Сосач образовательный
https://learn.microsoft.com/en-us/windows/win32/shell/app-registration
Вероятно, у тебя разрешение каналов цветности становится в два раза меньше, потому что ты не указываешь иное.
https://ru.wikipedia.org/wiki/%D0%A6%D0%B2%D0%B5%D1%82%D0%BE%D0%B2%D0%B0%D1%8F_%D1%81%D1%83%D0%B1%D0%B4%D0%B8%D1%81%D0%BA%D1%80%D0%B5%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F
Видео в 4:2:0 годится только для финального продукта (трансляции, файла), потому что дальше с ним ничего не сделать из-за потери чёткости. Многие каналы и студии просто запрещают использовать такие материалы.
Кроме того, артефакты сжатия никуда не деваются, даже если тебе их не видно, и будут портить чёткие границы. Если ты уверен, что они никогда не вылезут (например, объекты всегда будут гораздо меньшего размера), то можешь экономить. Если там будет какое-нибудь автоматическое выделение контуров или оценка позиции объектов, то работать проще будет с оригинальными циферками. Само собой, и цветокоррекция никакого сжатия не позволяет.
Конечно, во многих случаях сжатие с потерями с высоким битрейтом нормально закроет проблему, но если ты не понимаешь, что потребуется от материалов, не порти их.
>есть "несжатые" хромакейные сурсы, но слишком уж большой размер у этих синих шакалов.
Как последовательность организована? Контейнер? Кодек? Цветовое пространство? Колориметрия? Каналы?
>жму handbrakом, все здорово
>на границах между синевой и обектом повялется ттакая темно-синяя рамка.
Если ты делаешь, не думая, то почему удивляешься чудесам?
>нужно сжать в любой формат и кодек, уменьшив рамер и не проебав цвета
Так сведи сначала, а потом жми! Или у тебя другая задача?
оказался прав, на 4:4:4 границ нет, либо почти незаметные глазу. фон правда светлее становится, с остальными цветами непонятно.
>>3393483
> Контейнер? Кодек? Цветовое пространство?
яж написал
Ut Video ULRG
Lagarith Lossless (LAGS)
бывает еще какой то 24 bits RGB (RV24)
пара сотня таких файлов размером 2-40+мб в 480р в среднем и продолжительность до 1-7 секунд. считаю такой размер слишком уж избыточным, учитывая исходники.
да лослесс все дела, но если на границах артефактов не вылезет то один хуй никто и не заметит разницы
> фон правда светлее
разобрался. в .avi похоже нет данных о цв пространстве и handbrake автоматом лепит своё. если выбрать кастом но ничего не вписывать, то норм
> пара сотня таких файлов размером 2-40+мб в 480р в среднем и продолжительность до 1-7 секунд. считаю такой размер слишком уж избыточным, учитывая исходники.
> да лослесс все дела, но если на границах артефактов не вылезет то один хуй никто и не заметит разницы
Попробуй монтажные/промежуточные кодеки, вроде prores 4444 или DNxHS с соосветсвующим профилем.
а какую прогу посоветуешь под это?
ffmpeg последних версий умеет кодировать и то и другое.
Но документация по DNxHD получше будет, мне так кажется. Я только prores пробовал выводить.
эх, ну пошел шапчку читать от корки до корки
> оказался прав
> оказался
А ответ на 2×2=? ты тоже будешь голосованием определять? Тут не догадываться надо, а просто знать.
Ты можешь тупо сохранить видос в гиф и обратно. Можешь по умному прогнать видос через palettegen. https://stackoverflow.com/questions/60477430/create-256-color-palette-video
Спасибо, буду разбираться как сделать качественную гифку.
Нашел гайд по гифкам, мб кому пригодится, оставлю тут:
http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html
Так тебе только визуальный эффект нужен, или чтобы GIF хорошо сжимался? Во втором случае лучше пользоваться редакторами и руками выделять статичный фон. Мельтешение пикселей, выдаваемое автоматическими конвертерами, вообще никак не сжимается, глупо делать идиотского размера файлы.
Надо чисто для визуального эффекта.
Так не работает:
ffmpeg -y -i 1.mp4 -i palette.png -filter_complex "[0][1]paletteuse , dither=bayer:bayer_scale=2" output.gif
Разобрался методом научного тыка:
ffmpeg -y -i 1.mp4 -i palette.png -filter_complex "[0][1]paletteuse=dither=bayer:bayer_scale=2" output.gif
Если ты делаешь что-то в видеоредакторе, то просто наложи такой фильтр на нужный объект.
В ffmpeg совсем не обязательно делать GIF, ты можешь и видео сохранить. Только сжатие эти пиксели размажет, поэтому надо либо несжатый формат брать, либо в том же filter_complex добавлять увеличение в 2-3-4 раза (само собой, исходник высокого разрешения можно перед приведением к меньшему числу цветов уменьшить во столько же раз).
Bayer даёт регулярную сеточку, остальные алогритмы (из представленных) — случайные точки. Между кадрами видео они могут распределяться по-разному, одни — двигаться, другие — стоять на месте.
Источником палитры может служить не только само видео, но и любой файл с любой другой палитрой, например, стандартные 16 цветов или набор оттенков одного или нескольких цветов.
Ну вобщем конвертнул сначала в гифку с дизерингом, потом гифку обратно в AV1 при этом дизеринг почти полностью сохранился при низком битрейте. Каефная штука этот ваш FFMPEG, а ещё сегодня попробовал как работает стабилизация, результат шикарный.
Спасибо анончики.
Видос ради теста.
Вот эти точечки на большинстве устройств и в большинстве ситуаций люди даже не заметят. Либо в 2-4-8 раз меньше цветов делай, либо пиксели крупнее и очевиднее.
Да так же думаю, сначала рендерить в низком разрешении и апскейлить в два раза с flags=neighbor, а вот как кол-во цветов уменьшить пока не догнал.
Ну ты хоть параметры для palettegen просмотри разочек.
Какие преимущества в этих Nonfree билдах ?
Ну, смотри. Лицензии разных кодеков внутри ffmpeg и доступных в виде статически скомпонованных с ffmpeg сторонних библиотек неоднородны. Если соответственно варианты сборки:
- GPL-совместимый, включающий только куски кода, которые по условиям GPL можно компоновать и поставлять,
- не совместимый с GPL вариант сборки, всë ещë отвечающий более широкому пониманию «свободного ПО», и содержащий больше кодеков,
- несвободные варианты сборки, при которой в ffmpeg включаются несвободные кодеки — из актуального это libfdkaac (aac-кодер от института им. Франнофера).
Это всë очень актуально, если сборка у тебя была для шиндошс в один исполняемый файл. Бери в этом случае сборку от animouse. На прыщах зачастую ffmpeg из репозиттория сделан в виде кучи файлов и библиотек с динамической компоновкой — и там бывает достаточно из того же репозитория установить libfdkaac, чтобы ffmpeg его подхватил.
Вопрос 1: Зачем?
Вопрос 2: Кто твой клиент?
Планирую сделать стриминговый сервис, так что клиентов может быть много(от 1 до 3). Зачем? Для себя.
Всё равно ничего не понятно. Зачем тебе стриминг для себя? Почему нельзя предварительно транскодировать в один .mp4 или .webm файл? Зачем городить костыли из кучи фрагментированных ts файлов в перемешку с плейлистами, которые откроются только у яблочных? Браузеры так-то поддерживают только mp4 и webm контейнеры.
Реально все эти HLS, MPEG DASH применимы только в двух случаях: когда тебе нужна адаптация к меняющейся пропускной способности канала передачи данных, и когда тебе надо готовить разные версии одного видео для широкой аппаратной поддержки и высокого качества.
>которые откроются только у яблочных
Ясно, ты явно не разбираешься в теме. Этот HLS буквально везде: twitch, netflix, goodgame и так далее, он абсолютно везде используется.
Это ты не понял.
HSL, MPEG DASH это протоколы, работающие внутри HTTP.
А я говорю про контейнеры. Ты говорил что собираешься паковать сегменты в TS. Этот контейнер поддерживают только яблочные устройства.
Браузеры поддерживают mp4, а если быть точнее то фрагментированный mp4.
А ещё ты так до сих пор и не дал внятного ответа на вопросы которые я задал тебе ранее.
>А я говорю про контейнеры. Ты говорил что собираешься паковать сегменты в TS. Этот контейнер поддерживают только яблочные устройства.
>TS
Если посмотреть в запросах браузерных, то сервер возвращает .ts файлы, все работает и везде поддерживается.
>А ещё ты так до сих пор и не дал внятного ответа на вопросы которые я задал тебе ранее.
Не знаю что тебе ответить на твой вопрос. Для себя хочу сделать, чтобы просто было, научиться, какая разница?
И кстати ты так сам и не ответил на мой изначальный вопрос, а развел допросы какие-то, которые вообще к сути дела отношения не имеют. В общем можешь не отвечать, я не ту доску выбрал для вопроса(надо было к погромиздам идти) + уже сам разобрался как мне сделать лучше.
Чем я тебе помогу, если я не знаю что я делаю и зачем я делаю?
Тебе для локального видеохостинга достаточно контейнера mp4. А webm сам по себе умеет в стриминг. Нужно только вывести выхлоп из ffmpeg в браузер клиенту.
Пока что я вижу использование HLS как пердолинг ради пердолинга.
Я пробовал конечно через Adobe Premiere Pro. Я не ебу, хз почему, у него ультраубогий кодировщик. На градиентах черного и серого становятся более чёткие границы.
Как вообще с ним профи работают? Хули он там убого рендерит? Там и настроек толком нет.
а в винде оно не только меняет разрешение но еще и окно плеера движется по экрану
в хроме показывает продолжительность 1 секунду хотя по факту воспроизводится почти 3
в телеге на пк в чате оно воспроизводится просто в рамках одного размера кадра, когда уменьшается то пустота заполняется блюром, а вот в при полноэкранном воспрозивдеении почти ничего не меняется лишь небольшие помехи добавляются и еще телега видит что там не 1 секунда, а пишет как по факту
Вебм поддерживает динамическую смену разрешения. Видео нарезали на кадры, каким-то скриптом изменили их разрешение, потом обратно склеили.
А движение окна видеоплеера тож поддерживает? Если поставить зацикливание в мпв то окно движется. кино и тв не дает ему двигаться. или это связано с изменением кадра, а потом переопределением его позициноирования относительно нового размера кадра?
Разные плееры могут реагировать по-разному, и это проблемы реализации конкретного плеера, а не возможностей вебм.
У меня не двигается, только размер меняется, левый верхний угол остается на том же месте.
Нашел способ через Concatenation, но это довольно геморно, сначала отдельно напилить видос, потом склеить.
Есть ли способ чтобы сразу указать интервалы в видео которые надо вырезать и склеить ?
P.S. Все значения условные. По поводу
>невозможно вырезать из видео кусок длительностью 23 секунды начиная с какой-то секунды
Возможно, но интервалы будут неточные, мне же надо, чтобы до секунды всё было.
>мне же надо, чтобы до секунды всё было.
Тебе надо не до секунды, а, скорее всего, до кадра. Это только с перекодированием. И я бы предпочëл это делать не голым ffmpeg-ом, а каким-нибудь редактором, который в явном виде готовит индекс кадров, и явно заботится о синхронизации. В качестве редактора я бы рассматривал avisynth+, vapoursynth, avidemux.
Нет, мне надо как раз на секунды. Но я уже понял что без перекодировки это нереально сделать, нужно перекодировать, чтобы ffmpeg вставлял свои keyframe'ы.
Вот параметр, если кому-то -force_key_frames "expr:gte(t,n_forced*N)",
где N - интервал ключевых кадров.
С -c:v copy работать не будет, он вам даже не выплюнет что ничего не изменится, он просто проигнорит -force_key_frames
>force_key_frames "expr:gte(t,n_forced*N)",
Это будет работать только для постоянной частоты кадров. Формально, мельчайшей единицей видеопоследовательности будет кадр или поле (в случае чересстрочной развëртки). Разделить последовательность можно с точностью до мельчайшей единицы. Частота кадров не всегда постоягнная и даже из вариантов с постоянной частотой эта частота нк всегда является целым числом. Т. о. не всегда временные метки кадров или полей выражаются в целых числах секунд.
>Это будет работать только для постоянной частоты кадров.
Ошибся. Для остальных тоже будет работать, т. к. gte — это «больше или равно», т. е. ключевой кадр встанет в момент, кратный N (в секундах), если в этот момент есть соответствующий кадр, или ключевым станет следующий за указанным моментом кадр, если кадр точно в момент не попадает.
>Это будет работать только для постоянной частоты кадров.
Я добавляю -r 24 -g N,
где N меняется в зависимости от длины куска.
Попробовал, ровно те же самые опции, но новый многопоточный ffmpeg.
На 30% быстрее, но жрет в полтора раза больше процессорного времени.
Упс, я забыл, что у меня taskset стоит для ффмпега.
Старая версия выдает примерно те же числа, что и новая:
User time (seconds): 427.72
System time (seconds): 1.58
Percent of CPU this job got: 1682%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:25.52
Подскажите, если делать захват экрана, чтобы скопировать таким образом онлайн-видео, можно ли таким методом добиться идентичного качества 1:1?
Или в любом случае необходимы оригинальные файлы?
Идентичного чему? Тому, что ты видишь на экране? Ну запиши без сжатия с максимальной частотой кадров, потом удали повторяющиеся и нормализуй результат под частоту кадров оригинала. Будешь сжимать — сжимай с большим запасом битрейта, чтобы визуально отличия незаметны были. Только вот с экрана писать само по себе неграмотное решение.
Если ты видео без DRM собираешься записывать, то лучше просто копию исходника сохранять по мере получения. Если с DRM, то тебе записывать просто так система не даст.
>Идентичного чему?
Транслеруемому видео.
>с экрана писать само по себе неграмотное решение.
А как грамотно?
>Если с DRM, то тебе записывать просто так система не даст.
В этом и вопрос. Записывают в этом случае экран, web-dl качество получается.
Хорошо, попробуй просто так записать экран при выводе HDCP-потока без китайских HDMI-сплиттеров и прочих внешних хаков.
Можно ли какой-то командой сконвертировать все файлы в папке .m4a в mp3 разом?
Так и раньше можно было энкодить на вк, не?
Вроде только яблочные браузеры поддерживают hevc.
Попробовал.
> export RADV_PERFTEST=video_decode
> ffmpeg -init_hw_device "vulkan=vk:0" -hwaccel vulkan ...
Без RADV_PERFTEST была ошибка:
> Device does not support the VK_KHR_video_decode_queue extension!
Скорость та же, что и с:
> -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
Скиньте табличку что щас актуально в видео и звуке
av1 или чо там
HEVC + xHE-AAC. Контейнер .mp4. Осваивают HEVC (дабавляют в браузеры), через 10-ть лет может и VVC освоят.
Ты блядь нашей смерти хочешь. Мало того что продвигаешь заведомо проблемный проприетарный видео кодек (хотя к гуглу у меня тоже есть вопросы, куда они смотрят). Так ещё и продвигаешь никем и ничем не поддерживаемый аудиокодек. До такого могли додуматься только эффективные менеджеры из Apple. Ну они всегда так делают, ну ты то чё?
> Так ещё и продвигаешь никем и ничем не поддерживаемый аудиокодек
Все актуальные ОС уже поддерживают (Windows 11, Android, macOS).
xHE-AAC:
https://www.audioblog.iis.fraunhofer.com/xhe-aac-windows11
https://www.audioblog.iis.fraunhofer.com/adaptive-bitrate-audiocodec-xheaac-apple-amazon-android
>>3403192
> Мало того что продвигаешь заведомо проблемный проприетарный видео кодек (хотя к гуглу у меня тоже есть вопросы, куда они смотрят).
Да, к Гуглу обратись, они ещё один копрокодек с мылом высрут, создав плюс один никому не нужный копроформат.
Я же, взываю к здравому смыслу: взгляните на стабильность H.264, сколько он беспроблемно просуществовал. И вот, внедряют эффективного наследника, который столько же в потребительском сегменте просуществует. Без VP8, VP9, AV1 и прочего недолговечного пердоцирка.
> До такого могли додуматься только эффективные менеджеры из Apple.
HEVC, HEIC, xHE-AAC делают в институте Фраунгофера, яббло никакого отношения к данному институту не имеет.
Почему twitch и youtube не на них? Я же попросил АКТУАЛЬНОЕ, ну почему вы такие тупые? Просиш гавно, а тебе конфетку суют.
Может у тебя пердоля такая табоичка есть?
В чём его открыть? Пердолиться с плагином под фубар чтобы тот ещё и вылетал? И это ты называешь поддержкой?
> И вот, внедряют эффективного наследника, который столько же в потребительском сегменте просуществует.
Так внедряют, что не могут даже лицензию на HEVC купить, чтобы сделать софтварную имплементацию декодирования. И это Гугл блядь, а не спонсируемые на донаты энтузиасты из Mozilla.
Лучше бы не внедряли. А то блядь пытаются на двух стульях усидеть. И HEVC продвигать стандартом для видео в интернете, и за лицензию не платить.
И главное ведь нахуя? Там же ведь за горизонтом VVC маячит. Неужели нельзя просто пропустить поколение?
> делают в институте Фраунгофера, яббло никакого отношения к данному институту не имеет.
Да я про внедрение. Это ведь их бизнес стратегия: внедрять у себя никем не поддерживаемые форматы, чтобы держать своих потребителей на коротком поводке своей экосистемы.
> табоичка
Что?
>>3403086
> Скиньте табличку что щас актуально в видео и звуке
А это и так всем известно.
Для mp4: h264 + aac.
Для webm: (AV1, VP9, VP8) + (Opus, Vorbis)
В теории ты можешь запихать кодеки из webm, например опус в mp4. В стандарт добавили, но лучше не надо, а то у меня в firefox может не открыться.
Для AV1: https://gitlab.com/AOMediaCodec/SVT-AV1
Для VP9 тоже есть свой SVT, но он только для зеонщиков. libvpx-vp9 жмёт медленно и плохо. Для себя кодировать не рекомендую. Единственная альтернатива это HEVC, но он не для WEBM, а скорее для MPV.
VP8 сейчас актуален только внутри картинок в WEBP. В видео H264 его победил.
По поводу Opus можно порекомендовать только одно: ffmpeg -i audio.flac -ac 2 -c:a libopus -b:a ПОДСТАВЬ_БИТРЕЙТ audio.opus
Многоканальные дорожки лучше кодировать через opusenc.
Vorbis не особо актуален. Если нужна инфа, проси отдельно.
Про AAC мне надоело повторять. Вкратце, если у тебя в ffmpeg нет libfdk_aac, а у тебя его скорее всего нет, то ты сосёшь.
А прям таблички табличной у меня нет. И я не знаю где мне её брать.
Щас 2024 на дворе, а ты мне втираеш кодеки и контейнеры которым лет 10 уже, я же попросил актуальные
>если у тебя в ffmpeg нет libfdk_aac, а у тебя его скорее всего нет, то ты сосёшь.
Эта информация устарела на несколько лет
Так они актуальные и есть. Ну знаешь, VP9 существует уже давно, а я только недавно купил телефон с аппаратным декодированием VP9. Точно так же будет и с AV1.
Ты просил новые, а не актуальные. Нет смысла рассказывать про JPEG Xl, когда его ни хром ни firefox не поддерживают.
>>3403291
Ну и где коммиты которые допиливают vbr режим или метод кодирования anmr у встроенного в ffmpeg кодека AAC?
Всё что я видел это минорные файнтюны на базе того же кодека что и был.
Зачем перекодировать видео, если собираешься хранить оригинал?
Я сейчас не имею в виду юзкейсы типа "хурррр, а я перекодирую и удалю оригинал, дуррррр" или "чтобы запостить на Двач". Речь идёт про перекодирование видео и хранение на харде.
Зачем его перекодировать, если есть оригинал? Зачем перекодировать в AV1, если завтра выйдет AV2? И что, потом всё заново перекодировать? Зачем перекодировать в H265, если оригинал в H264?
Только сегодня задумался над этим вопросом, а до этого слепо перекодировал коллекцию в VP9. А вот аудио я без сожаления кодирую в Opus и удаляю подлинники.
> Зачем перекодировать в AV1, если завтра выйдет AV2?
Ну выйдет AV2, который будет кодироваться со скоростью меньше 1 fps, и чё? Улучшения в качестве не бесплатны. Чем сильнее сжатие, тем мощнее должен быть CPU чтобы такое вывозить. А у чипмейкеров там какие-то проблемы с выпуском новых техпроцессов. Утоньшать литографию становится всё сложнее.
Короче, AV2 врят-ли кому то нужен без аппаратного ускорения. Ну может ютуб видео миллионники в него перекодирует, на том и ограничатся.
> Зачем перекодировать в H265, если оригинал в H264?
Ну тут скорее вопрос почему это должен быть именно h265.
Зачем перекодировать вообще? Ну смотри. Допустим у тебя этот h264 в 20, если не в 40 мегабит. И ты хочешь уменьшить до приемлемых тебе 5 мегабит. Каким кодеком это лучше делать? Старым h264, или выбирать между h265 или AV1?
> Допустим у тебя этот h264 в 20, если не в 40 мегабит. И ты хочешь уменьшить до приемлемых тебе 5 мегабит.
Но что именно делает 40 мегабит неприемлемыми, а 5 мегабит приемлемыми? Я хикка, я не буду стримить этот видеофайл для совместного просмотра. Телевизора у меня тоже нет, и все фильмы я смотрю с монитора. Есть ли в таком случае смысл перекодировать видео из родного H264?
> Ну выйдет AV2, который будет кодироваться со скоростью меньше 1 fps, и чё? Улучшения в качестве не бесплатны. Чем сильнее сжатие, тем мощнее должен быть CPU чтобы такое вывозить. А у чипмейкеров там какие-то проблемы с выпуском новых техпроцессов. Утоньшать литографию становится всё сложнее.
> Короче, AV2 врят-ли кому то нужен без аппаратного ускорения. Ну может ютуб видео миллионники в него перекодирует, на том и ограничатся.
Если AV1 и H266 станут вершиной развития видеокодеков, ну хотя бы лет на 15, то тогда это снимает многие мои вопросы. Всё-таки одно дело — перекодировать свою видеоколлекцию раз в 5 лет, и другое — раз в 15 лет. Но всё ещё непонятно, зачем это делать, если я точно собираюсь хранить подлинник.
А, ну и неужели сложно сделать асик для кодирования и декодирования новых кодеков? Просто немного места в процессоре или в видеочипе, которое будет заниматься только одним: кодировать и декодировать видео.
> Есть ли в таком случае смысл перекодировать видео из родного H264?
Если не хочешь заниматься кодированием, можешь не кодировать. Каждый сам определяет, какой битрейт для него приемлем, исходя из свободного пространства, желаемого уровня качества и личных предпочтений.
> Но всё ещё непонятно, зачем это делать, если я точно собираюсь хранить подлинник.
Тогда не кодируй. Вопрос только сколько часов ты будешь хранить и где ты возьмёшь столько места.
> А, ну и неужели сложно сделать асик для кодирования и декодирования новых кодеков? Просто немного места в процессоре или в видеочипе, которое будет заниматься только одним: кодировать и декодировать видео.
Nvidia смогла сделать свой асик только в последней серии RTX 40. Тридцатая только с декодером. Маркетинг ли это, или у них там были трудности, не знаю.
> Ютуб
H.264, VP9. AV1.
> где свежак
На нетфликсе. Но после проёба в суде Броадкому, судя по всему перешли на гугловский копрокодек.
Я так понимаю av1 соснул
Он соснул при зачатии. Так уж вышло, что гугл высирает форматы, которые проигрывают уже имеющимся аналогам. Взять тот же хевц: хевц лучше сжимает, качественнее сжимает, весит почти столько же, сколько и AV1. Но жадность гугла и нежелание платить патентные отчисления кошмару всех пердоликов — Броадкому, создаёт ситуацию, в которой имеем то, что имеем.
>Взять тот же хевц: хевц лучше сжимает, качественнее сжимает, весит почти столько же, сколько и AV1.
Но это же не так, AV1 сжимает лучше на всём диапазоне битрейтов. А хевк, в свою очередь, может проигрывать h264 на более высоком битрейте.
Comparison with parameters list?
Так это ты заявляешь что хевк лучше AV1, ты и тащи свои сравнения. Если погуглить av1 vs hevc, все говорят что AV1 лучше.
Недавно добавили ав1.
Куда? Прям щас открой любой стрим и глянь кодек
Вы не понимаете. Поддержку добавили на стриминговую платформу. А то что стримеры стримлят со старой 1650 и у них нет такого кодека, как и денег на новую карточку, это другое.
А на какие карты добавили ав1?
40-я серия, у Intel arc вроде есть, ну ещё можешь радеоны проверить.
Есть фильм, нужно из него вырезать несколько эпизодов, и слить в один файл, уменьшив размер и качество.
Этот редактор сможет это сделать?
Сможет, но чем больше эпизодов нужно будет вырезать, тем больнее будет попочке.
Декодирование: нвидиа 3000 / радеон 6000. Энкодирование: нвидиа 4000 / радеон 7000.
./ffmpeg -ss 70.72 -t 20.30 -i xxx.webm -y -c copy xxx.mp4
-ss 70.72
начинаем с 70 секунды и 720 милисекунды
-t 20.30
заканчиваем вырезать через 20 секунд и 300 милесекунд
>а на выходе получить к примеру картинки в заданном разрешении и с текстом из каждой строки?
Нашел покачто
ffmpeg -f lavfi -i color=blue:size=1280x720 -frames:v 1 -vf drawtext="fontsize=100:fontcolor=yellow:text='Hello World':x=(w-text_w)/2:y=(h-text_h)/2" -y output.jpg
надо будет батник пилить походу под это дело
Бля, у меня чето шрифты указаные не подгружаются, а все остальное вроде нормально пашет. Че делать то?
>ля, у меня чето шрифты указаные не подгружаются
ебучая винда со своими путями ебет мозги, вот так прописал
./ffmpeg -f lavfi -i color=0xFFFFFF:size=300x100 -frames:v 1 -vf "drawtext=fontfile=C\\:/Users/Nobi/AppData/Local/Microsoft/Windows/Fonts/NotoSansMono_ExtraCondensed-Black.ttf:fontsize=40:fontcolor=0x7F7F7F:text=huipizda:x=(w-text_w)/2:y=(h-text_h)/2" -y test.png
ffprobe даст тебе подробнейшую информацию по всем кадрам в потоке. Есть для фильтрации еë вывода в интернете скрипты.
Если хочется интерактивное средство, то бери avidemux.
Но я даже представить себе не могу, зачем тебе потребовалось то, что ты спрашиваешь.
Спасибо. Ну мне это нужно чисто в познавательных целях, для сравнения результата кодирования разных кодеков.
Вроде да, но заёбно конечно, особенно если сотня кусков надо.
- обрезать "лишнее" видео сверху и снизу
- добавить чёрные полосы слева и справа
Пробовал и -s 640x360, и -vf scale=640:360 - и то и это "расплющивает" квадратные видосы под прямоугольные 16:9.
а ещё есть исходники не просто вертикальные с разрешением типа 1080х1920, а обычное фуллхд, но по факту вертикальное 600х1080, а огромные куски слева и справа - чёрные квадраты. Тут только вручную вырезать -vf crop=600:1080:650:0 нужный вертикальный кусок из центра и потом уже его поворачивать -vf transpose=2 и ресайзить до 640х360
Запердоль скрипт на питоне.
Масштабирование с сохранением соотношением сторон ещё можно реализовать одним командлайном. Но детектинг наличия чёрных полос и где обрезать уже требует пердолинга.
Есть "кинотеатральная" widescreen версия фильма (2.35:1) в виде нетронутого видеопотока с блюрея (ремукс), то есть 1920x1080 с черными полосами.
Есть open matte 16:9 версия в виде hdtv-рипа в 720x576 с неквадратными пикселями (...зачем...), с другим фпс (25 против 23.976) и интерлейс вместо прогрессива. Open matte - это более полный кадр по вертикали по сравнению со стандартным релизом. Такие версии крайне редко выходят официально, они обычно для hdtv или иногда стримингов.
Хочу взять конкретную сцену из фильма и:
1) подложить open matte под widescreen, совместив содержимое кадра, чтобы по центру было максимальное качество с ремукса, а сверху и снизу - LQ куски опен матте, которые были бы "над" черными полями кадра 1920x1080, но естественно не заслоняли осмысленное содержимое кадров ремукса посередине. Готов поебаться вручную в пейнте и выдрочить правильное расположение опен матте кадра прямо пиксель-в-пиксель.
2) экспортнуть результат в набор кадров в пнг
И всё это - в один проход, без перекодирований во всякие h264 десять раз в процессе.
Мнения? Я ебанулся? Возможно, мне лучше перегнать сами исходные видео в наборы кадров пнг, а уже потом как-то наколхозить batch обработку этих синхронизированных друг с другом наборов пнгшек (кроп и прочее)?
Я не очень понял вопрос. Но ffmpeg позволяет делать композицию видео. Там для этого есть фильтр overlay. Вот можешь почитать на тему: https://stackoverflow.com/questions/42519757/ffmpeg-compositing-a-video-within-a-video-in-the-centre
Для подгонки fps можешь использовать фильтры fps или framerate.
Для кропа чёрных полос есть фильтр crop. Для ресайза scale.
Твоя задача загнать всё это в filter complex в правильном порядке и подобрать параметры так чтобы выполнить задачу 1.
По поводу PNG секвенций читай тут https://natron.readthedocs.io/en/rb-2.5/guide/tutorials-imagesequence.html#ffmpeg
Но я бы тебе не советовал бы тебе использовать PNG sequence если ты не знаешь зачем тебе секвенция и почему именно в PNG. Есть lossless видео кодеки, есть монтажные кодеки. Сжатие видео не ограничивается просмотровыми кодеками, вроде упомянутого тобой h264.
Спасибо!
>Но я бы тебе не советовал бы тебе использовать PNG sequence если ты не знаешь зачем тебе секвенция и почему именно в PNG.
Чтобы гифки нарезать.
>Есть lossless видео кодеки, есть монтажные кодеки. Сжатие видео не ограничивается просмотровыми кодеками
Да, само собой.
>Я не очень понял вопрос.
Ну типа вот пикрил:
1 пик - блюрей
2 пик - опен матте вебдл с более полным кадром, но заметно более хуевым качеством
3 пик - гибридный рип, сделанный добрым человеком с прямыми руками, который наложил блюрей (без полос, естественно) на опен матте вебдл
При этом, обрати внимание, опен матте не накладывается на вайдскрин совсем наивно, типа пиксель-в-пиксель с раскрытием блюрейной/кинотеатральной версии вверх и вниз до 1920x1080, а лежит как-то примерно как пик 4, по техническим и художественным причинам.
> Чтобы гифки нарезать.
Перед -i пиши -ss и время начала. А потом перед именем гифки пиши -t и указывай продолжительность.
А ещё там надо пердолиться с палитрой.
Вот тут поподробнее https://superuser.com/questions/556029/how-do-i-convert-a-video-to-gif-using-ffmpeg-with-reasonable-quality
>>3411033
Если эти картинки и есть твоё видео, то я ни виду существенных отличий от обрезанного по центру ремукса.
Там алгоритм простой:
1. Обрезаешь чёрные полосы у ремукса фильтром crop.
2. Из обрезанного видео создаём 2 одинаковых обрезанных видео фильтром split.
3. Масштабируешь одну копию видео так чтобы она заполнила весь холст фильтром scale, после чего обрезаешь его по центру фильтром crop.
4. Объединяешь эти 2 видео в одно фильтром overlay.
>А ещё там надо пердолиться с палитрой.
Если честно, я пока что для гифок из наборов пнг/жпг/бмп использую онлайн-тулзы (да, знаю, зря), которые делали норм.
gifmaker.me делал охуенные цвета ценой не раздражающего дизеринга, который тем более очень уместен для фотографического/киношного материала, потому что похож на киношный ламповый шум. Первые два пикрила.
Но он умер (вот потому и зря), а ezgif ебашит цвета бандингом (пикрил 3), еще и без темпоральной стабильности этого бандинга, что заставляет меня грустить.
А сами пнг для кадров гифки вырезаю из видео с помощью VirtualDub'а, где можно выдрочить с точностью до кадра, сразу указать пропуск каждого второго (если слишком тяжеловесно хуярить все 24/30 родных кадров в секунду), кропнуть содержимое кадра как надо и т.д. Все-таки гуи в этом деле в сто раз удобнее (ну хотя бы для референса, чтобы заранее посмотреть, по каким цифрам резать), чем консоль.
> Если эти картинки и есть твоё видео, то я ни виду существенных отличий от обрезанного по центру ремукса.
Не, это готовый пример под рукой. Отличия - в большей наполненности кадра сверху и снизу. Автор "гибридного рипа" выбрал вариант взять за основу расположение опен матте версии и поэтому чуть-чуть укрупнить / zoom in блюрейную картинку, чуточку потеряв в пиксель-перфект четкости, но также, бывает, делают как на пикрил 4 в моем сообщении выше, оставляя по углам черные прямоугольники или заливая их градиентом интерполяции с краев двух исходных кадров.
>Чтобы гифки нарезать.
>>3411044
Я тебе в воскресенье смогу скинуть батник для пиздатейшей конвертации в гиф через ффмпег, сам писал.
Раньше не выйдет, я не дома.
уже понедельник пиздабол где
>>3411209
уже понедельник пиздабол где
Имагинировал ебало чела который сидит не спит и ждёт когда ему ровно в 00:00 принесут батник на двачи.
Почему нельзя просто отрезать 500 кадров и оставить только остальные 500, и чтоб при этом видео весило 50 мг? Какого хуя видео вырастает до 300 мб?
> Почему нельзя просто отрезать 500 кадров и оставить только остальные 500, и чтоб при этом видео весило 50 мг?
Потому что видео это не набор картинок.
Читай начиная отсюда >>3384593
> Какого хуя видео вырастает до 300 мб?
Потому что ты его перекодировываешь?
Можно отрезать по ближайшему ключевому кадру, это ты зачем-то всё перекодируешь.
> мммаксимально малюсенький mp4-файл
> (видео x264, аудио aac)
> шебмки с видосами
Выбери одно.
H264 уже давно не про максимальное сжатие. А оптимальное пожатие aac требует компиляции своего билда ffmpeg, потому что libfdkaac не входит в публично распространяемые исполняемые файлы по причинам лицензионных ограничений.
> Двухпроходный вариант с crf есть или только на vp9?
Такая вещь не является нормой. Это порождение ограничений libvpx и libaom.
libsvtav1 умеет жать в crf не требуя второго прохода, подобно тому как это происходит в x264 и x265.
Ты ждёшь от меня универсальных гайдов, но таких нет. Но одно я могу сказать наверняка: vp9 устарел, vp8 засохшее говно мамонта.
Причина по которой vp9 устарел заключается даже не в наличии AV1, а в отсутствии надлежащей поддержки. Референсный libvpx-vp9 жмёт медленно и плохо паралелится. Отсутсвуют аналоги не то что x264/5, но даже аналоги svt av1. Тот svt vp9 что есть работает только на некоторых зеонах (то есть на твоём райзене не запустится), не умеет жрать вход из пайпа, и никто даже не чешется улучшать этот самый svt vp9. Аппаратного ускорения сжатия нет и не предвидеться.
В сфере сжатия аудио opus вытесняет aac. Сейчас это серебрянная пуля. Пользоваться им проще простого: -c:a libopus -b:a 64k. Ну можешь битрейт повыше поставить, если у тебя в лимит влезет. Из ограничений только то что в ffmpeg для libopus поддержку многоканала вроде как не завезли и неизвестно когда завезут.
В сфере сжатия видео идёт соперничество между h265 и AV1. H265 берёт широкой аппаратной поддержкой, в том числе и кодирования, а также наличием кодировщика x265. AV1 берёт открытостью, местами лучшим сжатием, поддержкой со стороны браузеров, и перспективами дальнейшего повсеместного внедрения. Уже есть аппаратная поддержка декодирования AV1 во флагманских смартфонах и у карточек nvidia c 3000-й серии. С 4000-й серии добавили аппаратное кодирование.
Какие-то гайды есть, но выбирать параметры кодирования тебе придётся самому, под твои предпочтения.
https://kokomins.wordpress.com/2019/10/10/anime-encoding-guide-for-x265-and-why-to-never-use-flac/
https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/README.md?ref_type=heads
Спасибо, очень развёрнуто. Понятно что всё устарело, кодирую для старых девайсов - они никакие x265, webm и тем более av1 не тащат. Но как оказалось и x264 не всякое жуют!
Мобилка начала десятых играет максимум -preset slow, всё выше - картинки нет, аудио есть.
Смарт-телик середины десятых почему-то вообще в отказ, даже просто -c:v libx264 -c:a aac. "В настоящее время этот формат не поддерживается" и всё. Надо откопать что за модель и что точно он поддерживает.
>Аппаратного ускорения сжатия нет и не предвидится.
Интел умеет.
> всё выше
Выше это в какую сторону?
slower, veryslow, placebo
Там дело не в пресетах, а в профилях и уровнях.
Когда ты включаешь пресет медленнее, он активирует опции, которые улучшают сжатие, но снижают совместимость. Тот же CABAC, количество b кадров, например.
Есть 3 основных профиля и куча производных от них. Основные профили это baseline, main, high.
Baseline самый слабый, когда то для айфонов кодировали в этом профиле.
Main это что-то среднее, вроде как для SD контента.
High это самый сильный профиль, предназначенный для HD контента и включает такие опции как CABAC.
Ну и уровни, которые указывают максимальное разрешение и частоту кадров, которые этот декодер должен декодировать. Там от 1.1 до 5.0 или 5.1, не помню точно.
Читал мануалы на торрент форумах, там рекомендуют кодировать в уровень 4.1 для 1080p. Но это если частота кадров не превышает 30. Уровень 4.2 позволяет уже до 60 fps.
Так вот, профиль и уровень переопределяют настройки пресета. Так что ты можешь поставить хоть placebo, но если ты правильно указал уровень и профиль, то всё должно работать.
Узнать профиль и уровень ты должен в спецификации устройства. Но если такой нет, найди методом перебора. А ещё учти, что чтобы попасть в уровень, тебе возможно понадобится снижать разрешение и количество кадров в секунду. Сам кодировщик этого не сделает.
https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels
> правильно указал уровень и профиль
Ну например так, исходники всякие - от 1280х720 до 4K, от 25 фпс до 60:
ffmpeg -i test.mp4 -vf scale=640:360 -c:v libx264 -preset slow -crf 28 -c:a copy test1.mp4
> scale=640:360
Для сохранение соотношения сторон, насколько это возможно, ты мог бы сделать так:
> scale=-2:360
или так, в случае если ты обрезал чёрные полосы у источника
> scale=640:-2
К сожалению, не существует способа, как вписать картинку в прямоугольник, чтобы выходная ширина и высота видео всегда были чётными, в рамках одной команды ffmpeg. Такое надо считать для каждого видео отдельно, или сделать отдельный скрипт для этого. Также мы не можем в рамках только одной команды ffmpeg уполовинить количество кадров в секунду, когда количество кадров превышает заданный порог, такой как 30 например.
Разрешение 360p при 30 fps примерно соответствует уровню 3.0
> Надо откопать
Так, сосунг ue32j5500aw. В мануале заявлено всё что можно - и h263, и h264, и hevc, и даже vp8. А на сайтах магазинов из всей мультимедии только
> MP3, WMA, MPEG4, DivX, MKV, JPEG
Ну окау, есть скажем 1920х1080 видосы с мобилы, которые я разжал в лосслесс -c:v huffyuv -c:a pcm_s16le, потом фиксил тряску тем же ффмпегом и размножил нейронкой flowframes фпс с 30 до 60 - во что их кодировать, чтобы пошло на этом телике?
проще комп подрубить в режиме моника похоже
Во первых, не факт что твой телик может в 60 fps.
Из его характеристик известно, что у него экран 1920x1080. Из этого следует то, что он должен жрать 1080p видео, типичное количество кадров которого обычно не превышает 30.
Исходя из этого, я предполагаю, что он должен поддерживать профиль high уровня 4.1
Прямо так и пишешь -c:v libx264 -profile:v high -level:v 4.1
Если не будет работать, можешь ещё -bf 3 добавить.
Для этого нужно подключать ffprobe, без скрипта не обойтись.
В линуксе есть touch -r <оригинальный файл> <новый файл>, копирует дату изменение с оригинального файла в новый.
Может в винде есть что-то такое же, ищи.
>уже понедельник пиздабол где
Это называется форс-мажор, сука.
https://pastebin.com/mwUVX4Cq
Таки сляпал всё в единый батник. И x264 с нужным пресетом-качеством-разрешением, и aac в моно с микробитрейтом, и обрезка инфразвука с компрессией, и полное сохранение даты.
ffmpeg поддерживает VVC
На доске /mov/ про фильмы в шапке торрент-треда среди прочего есть гайд о том, что делать, если чуть-чуть недокачался файл из полумертвой раздачи, который сводит с ума видеоплееры, и можно ли это как-то починить.
Вот текущая версия, которую я написал пару месяцев назад: https://pastebin.com/BcQKSVxZ
Как легко заметить, она не дописана в конце (раздел для любопытных аутистов, которым интересно знать, почему так происходит). Причину того, почему может не скачаться конец файла, я отлично знаю и расписал максимально подробно, а вот почему именно недокачанный конец приводит к таким спецэффектам - в этой теме я "плаваю". Знаю ситуацию в общих чертах и также знаю, что линейные редакторы типа avidemux, virtualdub (и в частности mkvtoolnix при работе с содержимым файла) честно дотошно читают весь файл целиком и изучают, что у него лежит на каких таймстампах, прежде чем дать пользователю скакать по нему. Но писать свои додумывания - возможно, откровенно ошибочные - не хочу.
Что бы вы дописали в тот недописанный в конце раздел, или мб даже что бы вы исправили в том, что уже написано?
С меня нихуя, но этот текст будет висеть в перекатах торрент-треда в обозримом будущем и мб кому-то поможет, ну или хотя бы кого-то просветит.
https://github.com/AnimMouse/ffmpeg-autobuild
Используют гитхаб, чтобы бесплатно автоматически собирать кастомный ффмпег с libfdk-aac и прочими плюшками.
И вообще есть ли какие нибудь функции для улучшении картинки при апскейле ?
Пока только нашел как выкрутить резкость (-vf unsharp=x:x:x)
Это в принципе невозможно, только притвориться.
Ты хочешь добавить кадр посередине между двумя. Камера не снимала что там происходило и это никому не известно. Можно только либо интерполировать, либо фантазировать какими-нибудь нейронками.
Интеполяцию ffmpeg умеет: https://ffmpeg.org/ffmpeg-filters.html#minterpolate
>Это в принципе невозможно
Почему невозможно то, бери соседние кадры, вставляй промежуточные, делая новые из соседних через оверлей.
Только смысла в этом немного, всё современное железо такое фуфло на лету делать может при проигрывании, качество видео не улучшится от таких манипуляций.
>>3413517
Проблема в всех этих интерполяторов в том что они не способны отличить реальную частоту кадров от фиктивной. Например в том же аниме нередко рисуют 12 кадров, а кодируют как 23.976 (24000 / 1001). И притом в одном и том же видео может быть как 24 реальных кадра, так и 12.
И если пройтись по такому сурсу нейронками, то будет не плавность, а рваная плавность, поскольку ему нечего интерполировать между одинаковыми кадрами.
И это я ещё молчу про пулдаун из киношных 23.976 в NTSC (29.97 полных кадров). Как такое интерполировать, я даже не представляю.
Потому что то ты там наклеил не имеет отношения к тому что происходило перед объективом. Кадр ты можешь только угадывать или придумывать сам. Любое размытие будет просто мылом, любое наложение даст артефакты типа шестиногих котов
>>3413517
Ну Topaz каким-то методом интерполирует, результат получается неплохой в большинстве случаев, в примере замедленный 2-х секундный ролик 30фпс, но топаз делает это ну очень медленно. Вот и интересуюсь, можно ли что-то подобное замутить в ffmpeg.
Если тупо замедлить без интерполяции, то получается дерганная картинка в 5 фпс с дублированными кадрами.
А также артефакты на стыке кадров (в смысле ракурсов / планов), когда интерполировать последний кадрик предыдущей сцены и первый кадр следующей НЕ надо, а надо тогда уж экстраполировать из двух последних кадров предыдущей сцены.
Но детект смены сцены https://en.wikipedia.org/wiki/Shot_transition_detection - это ДОХУЯ сложная задача, а какой хуйни нейронка нагенерит на плавных сменах кадров, типа фейдов или наездов - представить страшно.
Тебе нужен rife для такого, годных консольных тулзов под это дело вроде не замутили, гугли flowframes
Если тебе без лишней ебли - скачай Avidemux, это линейный редактор с гуи, который работает на ффмпеге. Внизу таймлайн видео, по нему можно скакать мышкой или контролами слева, там есть "перейти на следующий / предыдущий ключевой кадр" (там же рядом для текущего кадра всегда пишется, каков текущий, тебе нужны I-кадры). Кнопками A и B можно выделить нужный тебе фрагмент (кнопка B включительная, то есть кадр B будет последним кадром выреза, а не первым кадром того, что следует за нужным тебе и уже не будет вырезано). Слева для видео и аудио можно выбрать режимы - Copy - это полная копия потока без какого-либо перекодирования, остальные варианты с кодеками - перекодирование в нужный кодек и их настройки и фильтры (кроп кадра сверху и снизу, ускорение и прочее, естественно, это все доступно только при перекодировании). Тебе нужен режим Copy для видео и аудио, в нем начало выделенного фрагмента ОБЯЗАТЕЛЬНО должно быть ключевым I-кадром, а вот если перекодируешь (т.е. создаешь видеопоток с нуля), тогда можешь вырезать начиная с какого угодно кадра.
Вдогонку: там же можно удалить / убрать ненужный тебе фрагмент из видео / из последовательности кадров, если тебе нужно склеить какие-то два фрагмента, которые разделены другим ненужным.
В этом случае две тонкости:
- в случае удаления (а не выделения для рендера / экспорта, как в сообщении выше) кнопка B устанавливает не последний кадр удаляемого, а первый кадр нетронутого, то есть в этом случае вырезание НЕ включительное по B, последний кадр удаляемого фрагмента будет предыдущим до кадра, установленного кнопкой B
- если ты вырезаешь без перекодирования в режиме Copy, то тут уже именно B должен быть ключевым I-кадром, а A (начало удаляемого фрагмента) может быть любым. Потому что можно запросто обрезать хвост любой последовательности кадров, декодируемых друг за другом каждый из предыдущего, а вот НАЧАЛО последовательности (второй нужный тебе фрагмент, следующий за удаляемым куском) обязательно должно быть полным нетронутым кадром. Это, как бы, достаточно "очевидно" и несложно, но советую не запомнить это как факт, а посидеть подумать и, так сказать, "осознать", чтобы потом не путаться.
Удаляется просто: выделяешь на таймлайне фрагмент кнопками A и B и просто нажимаешь Delete. Учти, что если ты куда-то на бумажку записываешь свои монтажные последовательности покадрово, то тайминг следующих за этим кусков съедет (если ты удалил 30 секунд с 0:30 по 1:00, то то, что было 2:30, станет 2:00).
>>3415087
Да я разобрался, то что нужно. Тогда получается мне нужно записывать с частыми ключевыми кадрами.
Подскажите, как кодировать видео так, чтобы ключевые кадры стояли в основном на смене ракурсов / на начале новых шотов, а не равномерно каждые 10 секунд?
H264 в Авидемуксе на пресетах slow, slower, veryslow делает именно последнее. А, например, в ресурсах блюреев (и в исходных .m2ts с блюреев) часто вижу, что ключевые кадры стоят чуть ли не на каждом первом новом шоте (мб не совсем буквально на каждом, но тем не менее). При этом же, например, недавно качал чей-то херовенький блюрей-рип (реенкод в меньший размер) - там ключевые кадры раз в 25 секунд сука, охуенно удобно скакать по файлу (нет). Где эта настройка?
* в ремуксах.
ok google ffmpeg gif palettegen
Весь файл целиком большой, но вот этот кусок вырезан без перекодирования (перекодировал только аудио в AAC для браузеров, видео не тронул и порезал по ключевому кадру).
> Frame rate mode : Constant
> Frame rate : 29.970 (30000/1001) FPS
> [...]
> Scan type : MBAFF
> Scan type, store method : Interleaved fields
> Scan order : Top Field First
Не "просто" интерлейс, а некий MBAFF. Еще Avidemux называет типы кадров не просто I, P, B, а I-TFF, P-TFF, B-TFF.
При этом видеоплеер (MPC-HC) воспроизводит нормально, а вот Avidemux при загрузке видеофайла в него декодирует как "неправильный" интерлейс (невооруженным глазом везде постоянно видны полосы интерлейса при любом движении), и браузер (Firefox) - тоже. В Avidemux не нашел в настройках декодирования чего-либо типа "смены порядка чтения полей" (если дело в этом), в Firefox тем более даже не знаю где искать подобное.
В чем тут дело и можно ли превратить этот файл и подобные ему в "нормально" читаемый интерлейс без перекодирования содержимого?
https://www.afterdawn.com/glossary/term.cfm/macroblock-adaptive_frame-field_coding
«TFF» — это «top field first». Раз они специально отмечают это в типе кадра, то можно предположить, что это нестандартный вариант. В общем случае кодек должен быть готов принять видео с любым порядком полей и выдать после декодирования точно такое же, поскольку он может (точнее, мог) находиться в цепочке инфраструктуры обработки чересстрочного видео, которая складывалась годами или десятками лет. Поэтому просто взять и переделать в один «правильный» формат — не вариант (не говоря о возможных проблемах с пропажами из потока полукадров для отметок времени в начале и конце).
Чинить известно как: находишь референсный декодер, проверяешь, что видео им декодируется правильно, идёшь жаловаться в багтрекер программы с приложением куска своего видео.
В Avidemux есть функция swap fields, меняющая их порядок. Если он просто не умеет получать правильный порядок полей от декодера, то всё исправится одним нажатием. Другое дело, если всё хитрее, и макроблоки с минимумом движения, закодированные с построчной развёрткой, программой отображаются правильно, и только чересстрочные — неправильно. Тогда смена порядка полей исправит чересстрочные части, но испортит картинку в статичных областях. Экспериментируй.
Был какой-то интерполяционный изврат в ффмпег, но получалось всрато - на резких сменах сцены всё квадратится. Нормально делает flowframes.
Какого хрена субтитры двоятся? Маленьким шрифтом и поверх крупным. Или надо обязательно на готовое видео их накладывать, а не генерить его из фоновой пикчи?
Пробуй так
ffmpeg -loop 1 -i background.png -i audio.opus -r 30 -vf "subtitles=sub.srt" -c:v libvpx-vp9 -c:a copy -shortest out.webm
>входное_видео.mp4: это ваш входной видеофайл.
ширина и высота: новые размеры видео после обрезки.
x и y: координаты верхнего левого угла области, которую вы хотите сохранить
И тут я буксанул, у меня не отображается картинка видео в голове для обрезки чтобы правильно обрезать, до этого юзал редакторы с оболочками там хуле хлоп хлоп и готово, а тут координаты какие-то ща конечно же буду на рандом ебашить но мб кто подскажет
Я делаю скриншот в гимпе/фотошопе смотрю координаты
Аналогично вышепостеру прикидываю координаты по скриншоту в paint.net. И это всё-таки удобнее, чем во всех гуях, которые пробовал.
Попробуй ffmpeg заменить на ffplay в команде – заиграет то что ты режешь, помогает для отладки.
Но так да, гуи на то и гуи что в них удобнее визуальные части делать.
Кавычки добавить? Не помогает. Кодировать вавку в опус, а не копировать ffmpeg -loop 1 -i background.png -i audio.wav -r 30 -vf "subtitles=sub.srt" -c:v libvpx-vp9 -c:a libopus -shortest out.webm - тоже всё двоится.
> realtime
> 2pass
Расскажи, как ты будешь кодировать видео, которое находится в процессе получения, и которое закончится в неизвестный момент времени в будущем, в два прохода от начала до конца, чтобы готовый файл имел заданный размер?
Чел, это просто название для более быстрого пресета. Не надо так буквально воспринимать слова, которыми анальники называют всякое. На вики написано что рекомендовано для быстрого энкодинга. Я конечно предполагаю что там может быть несовместимость с 2pass по названным тобой причинам, но я для того в тред и написал чтобы узнать так это или нет (лень документацию читать).
Чел, это просто название для более быстрого пресета. При котором кадры выплёвываются настолько быстро, насколько можно, и их анализ минимален. Настолько, что сохранять в файл статистики просто нечего, поскольку те же циферки (какие-нибудь средние значения и эффективные диапазоны) могут быть получены каждый раз заново простым сканированием при загрузке или копировании кадров. Следовательно, работу в режиме нескольких проходов с такими настройками даже не реализовывали, да и уровень качества несопоставим. Ты понимаешь, зачем нужно кодирование в два прохода, и как оно работает?
Ну вот я и хотел знать совместимы эти режим или нет. Как работает 2pass знаю.
Спасибо за ответ.
1. При захвате видео в имеющемся формате постоянно полосит, но хуже этого - появляется зеленый кадр с черными квадратами, причём довольно часто (на приложенном видео есть).
2. То ли само это устройство такое дешманское, то ли ещё что, но при выборе его в VDub нельзя ни кодеки поменять, он просто отказывается что-либо показывать, и ссылается на ошибку, ни изменить PAL/SECAM, просто все эти вкладки неактивны. Кодеки ставил K-Lite Mega.
3. При некоторых действиях в проге делит изображение на 4 и выебывается.
Захват происходил без сжатия и в 64-, и в 32-битной версиях, сжимал для отправки сюда.
Я в этой теме вообще новенький, и даже хз насколько в правильном месте вопрос задаю, так что если что, пните в нужном направлении.
Для начала выясни, какие возможности настройки есть в твоём устройстве через драйвер, софт производителя или внешние программы. Синхронизация, параметры сигнала, вот это всё. Задача в том, чтобы получить качественную и необработанную исходную картинку, а уже в программе её подновлять как надо. Кодеки и перекодирование финального результата — это вообще не вопрос, делается после захвата и обработки миллионом способов. Никакие «кодек-паки» в 2024 году не нужны.
Да, но прежде всего выясни, какой именно у тебя чип внутри (выпиши идентификаторы оборудования), потому что китайцы в сараях лепят кучу вариантов этих древних устройств захвата из того, что есть под рукой, меняют загружаемые в устройство прошивки, а драйверы под современные системы не пишут. Возможно, придётся искать нормально работающий драйвер и руками добавлять.
Попробуй для записи OBS Studio.
А вообще, может и не мп4. Моя цель состоит в том, чтобы свои вебм массово сконвертировать в формат, читаемый телеграмом. Дело в том, что webm превращается в ФАЙЛ, когда удалить его основу, и без скачивания не обойтись.
>без потери качества
Что не убивает нас, делает нас криножовее
Хотя бы в том что x265 это lossy кодек. А ещё в том что нельзя взять рандомное видео из интернета и сжать его в visually lossless. Там хорошо если если размер файла снизится на 20-30%. Но с учетом generation loss, нет, подобная затея лишена всякого смысла.
Странно что двачеры-анальники ещё не пояснили. Телега поддерживает вебм просто она стесняется в этом признаться. Переименуй свою вебм в мп4 и телега прожуёт видео как полагается. То есть контейнер webm в телеге поддерживается, просто файлы с расширением webm не распознаются телегой как нечто к чему надо эту поддержку применять. Даже перепковывать не надо.
А так, у тебя вопрос не корректный. Говоришь про контейнеры, а в то же время хочешь что-то там конвертировать. В крайнем случае пришлось бы запаковать vp9 и opus в мп4.
шебм (vp8/vp9+vorbis/opus) и mp4 (x264+aac) наверно
Не, я имел ввиду и картинки тоже. Знаю, что большие проблемы с анимацией, из которой прожевался только GIF, ну а из статичных очевидно жрет стандартные jpg, png, еще webp - насчет других не знаю
Ну то есть стоит посмотреть сначала изначально какое видео и с каким кодеком, а потом уже подбирать?
Я потому и спросил здесь, что не хотел тупо перебирать все возможные варианты в /test. Но да ладно, видимо другого варианта нет
Ну не только кодек, а ещё и битрейт, разрешение, fps, и это наверно не полный список.
Если к примеру у тебя видео снятое на телефон. Или даже с камеры. Такое сжимвть можно, при условии что ты потом не будешь из него монтировать.
Ещё жмут блюреи, если делать это осторожно. Но тут учти что с h264 в h264 ты особо не сожмёшь. А с более современными кодеками уже надо поебаться, ибо они имеют тенденцию мылить.
Почему нет? Проигрываются же, только точно не знаю какие настройки оптимальные.
> посоветуйте золотую середину пресета (1-13)
4 ± 2
> и crf
24 ± 8
> svt или aom использовать
svt должен быть побыстрее. Но и libaom никто не запрещает.
>косяк с превью на дваче
Двач это в принципе один сплошной косяк, превью может просто так пропадать, независимо от кодека.
Тебе не нужно ебаться с битрейтом. Просто ставишь -crf 18 и всё.
А если тебя не устраивает битрейт, смирись. Потому что пожатие сильно пожатого окончательно добьёт остатки качества.
Типа так? CRF 2P или 3P стоит использовать?
Зачем кому-то писать программу, которая портит видео просто так?
Так это даже не программа а просто настройка. Да и как можно испортить h264 видео сохранив допустим битрейт AVI исходника.
Может через питон и ffmpeg сделать, чтобы скрипт на питоне считывал битрейт видео и полученную цифру загонял в настройки конвертации и запускал конвертацию.
> 2P или 3P
Никогда не слышал о такой опции в консольный кодировщиках. Могу сказать что многопроходный режим для crf для x264 не нужен.
Очевидно, у тебя неверные идеализированные представления о том, что при пережатии исходника с битрейтом X в битрейт Y теряются только данные, соответствующие разнице X-Y, а при пережатии из одного кодека в другой — разнице между ними. Например, если ты перекодируешь видео в H.264 с заданным битрейтом, а потом результат опять перекодируешь с теми же настройками, а потом ещё и ещё, то с каждым разом результат будет хуже, несмотря на одинаковый размер всех экземпляров. Вдобавок артефакты сжатия старых кодеков вроде резких границ между макроблоками могут перетянуть на себя усилия кодировщика, а содержательная часть картинки станет от этого ещё хуже.
Определение того, какие настройки качества кодировщика приведут к результату, визуально не отличимому для большинства пользователей от качества исходного видео, является сложной задачей, требующей множества тестов с разными типами содержания, разными условиями просмотра и разными участниками. Математически она не решается, математически кадры после кодирования совершенно другие, чем до. Перекодирование финальных (сильно сжатых) продуктов в сравнимые битрейты является пустой тратой электричества. В предложенном варианте оно ещё и портит качество.
Надеюсь, вы меня не побьёте.
Когда-нибудь буду осваивать FFmpeg, но сейчас нужна ваша помощь по VirtualDub2.
Пожалуйста, подскажите.
Имеется видео в формате avi.
Хочу перекодировать в mp4.
У файла изначальные данные такие (pic1).
Когда я кодирую с такими параметрами, ширина видео начинает отличаться от оригинала.
Получаются (картинки под номерами 2 и 4), а нужно чтобы ширина была как у оригинала (картинка под номером 5).
Подскажите, пожалуйста, как перевести в mp4, чтобы ширина была как у оригинала?
Avi и mp4 это контейнеры, которые могут в себе хранить вполне одни и те же видео и аудио потоки.
Так что надо понять зачем ты вообще что-то там перекодируешь.
Хочу, чтобы в телеграме файл отображался так:
(pic1)
А не так:
(pic2)
Попробуй просто свой оригинальный файл переименовать в мп4.
>>3422445
Благодарю тебя за подсказки.
Но не помогло.
В том, что не указал сборку, кодировщик, их версии и вообще год проверки, а также не удосужился разубедиться в своём синдроме утёнка. Может, было такое в какой-нибудь бета-версии, но сейчас (уже давно) таких проблем нет, я их даже не встречал никогда.
> Может, было такое в какой-нибудь бета-версии
В 5.0 (или 5.1? когда там первые потуги по AV1 завезли) стабилке такое было. Года полтора-два назад.
а нах медленный vp9 когда есть h264, vp9 рендерится 1 ядре к тому же
>Реально кодек av1 хуйня ебаная?
не хуйня, на ютубе экономит трафик, картинка не пикселит
Svt-av1 даёт защеку vp9 по качеству и скорости энкода. Минус в том что на телефоне видео тормозит при хардварном декоде. В нормальных плеерах это настраивается, а вот в телеге нет.
>>3422460
Тогда помочь не могу. Я хз что за виртуал даб. И с ави с его приколами я не возился. Вообще непердолики используют handbrake.
На крайняк вот тебе мой скрипт на питоне для конвертации в вп9 и в свт ав1. Нужен, собственно, питон и ffmpeg в переменной PATH. Нужно перетащить нужные файлы на файл скрипта. Делалось для себя и больше ради самого процесса пердолинга. Ну и тестировалось соответственно на узком спектре сценариев.
https://files.catbox.moe/gwl5sv.zip
Зачем жрать капусту если есть картошка? H264 упоминать в треде где челы в консолечке файнтюнят анимешечьку чтобы ffmetrics при том же размере выдавал на 0.0005 выше vmaf это или троллинг или необычайное невежество. Вп9 это золотой стандарт пердольного красноглазого сжатия. H264 это дёшево и сердито и вообще не про эффективность.
Спасибо.
Значит буду потихоньку вкатываться в FFmpeg.
Да ну как бы 90% ффмпега это написать строчку для двупроходного перекодирования в вп9. Ещё 5% это то же самое, но в crf режиме. Ещё 4% это с изменением разрешения и фпс. И оставшийся процент это всякие зернистости, интерполяции, форматы пиксела и прочее.
Вот тебе, собственно, исчерпывающая статья про те самые 95%.
https://trac.ffmpeg.org/wiki/Encode/VP9
Спасибо.
Я сейчас немного не в том настроении, чтобы вкатываться, но когда сил поднаберусь, начну вкатывание с твоей статьи.
Ещё раз спасибо за помощь.
Ну и когда будут новые записи, их нужно будет тоже добавлять к уже имеющимся, соответственно желательно без перекодировки, добавив только новый кусок видео и новую главу.
Не нашёл, как там главы добавить. Сделал через mkvtoolnix.
Попробовал этот форк, созданный для визуальной достоверности.
При использовании tune=3 не так сильно удаляет родинки с лица, как ванильный svt-av1, может быть svt-av1 всё-таки не так безнадежен в плане мыльности, как я думал.
Подскажите пжл. как можно вырезать из файла (видео или аудио) определённые куски по времени, потом слепить их в один и на выходе сделать формат wav? Желательно уже готовыми командами (или даже одной)
Можешь такое попробовать, нашел у себя в архивах.
Мнение о командах братишки из другой борды который пытается в to create highly compressed videos with VP9 that still preserve some semblance of quality?
ffmpeg -i "$i" -passlogfile "${i%.}-360p-256k" -an -vf scale=640:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 384k -minrate 128k -b:v 256k -bufsize 512k -max-intra-rate 371k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 150 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 15000/1001 -row-mt 1 -speed 4 -threads 4 -tile-columns 1 -tile-rows 0 -pass 1 -f null /dev/null \
ffmpeg -i "$i" -passlogfile "${i%.}-360p-256k" -c:a libopus -ac 1 -ar 16k -b:a 24.4k -application voip -vbr 2 -vf scale=640:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 384k -minrate 128k -b:v 256k -bufsize 512k -max-intra-rate 371k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 150 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 15000/1001 -row-mt 1 -speed 1 -threads 4 -tile-columns 1 -tile-rows 0 -pass 2 -f webm -map_metadata -1 -fflags +bitexact -flags:a +bitexact -flags:v +bitexact -y "${i%.}-360p-256k.webm" \
ffmpeg -i "$i" -passlogfile "${i%.}-240p-114k" -an -vf scale=426:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 171k -minrate 57k -b:v 114k -bufsize 228k -max-intra-rate 165k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 75 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 7500/1001 -row-mt 1 -speed 4 -threads 4 -tile-columns 0 -tile-rows 0 -pass 1 -f null /dev/null \
ffmpeg -i "$i" -passlogfile "${i%.}-240p-114k" -c:a libopus -ac 1 -ar 8k -b:a 12.2k -application voip -vbr 2 -vf scale=426:-2:flags=bicubic -c:v libvpx-vp9 -maxrate 171k -minrate 57k -b:v 114k -bufsize 228k -max-intra-rate 165k -auto-alt-ref 1 -colorspace bt709 -frame-parallel 1 -g 75 -lag-in-frames 15 -pix_fmt yuv420p -quality good -r 7500/1001 -row-mt 1 -speed 1 -threads 4 -tile-columns 0 -tile-rows 0 -pass 2 -f webm -map_metadata -1 -fflags +bitexact -flags:a +bitexact -flags:v +bitexact -y "${i%.}-240p-114k.webm" && \
Да. Кодеков кучи, а нагрузка ничтожна. Смысла нет аппаратную поддержку городить.
малютки, нужно видео в 60фпс перекодировать в .avi с кодеками видео vp8 и аудио vorbis, можно это сделать вашим ффмпегом и эсли да то как?
> For libvpx-vp9, the traditional wisdom of speeding up the first pass by using a faster encoding speed setting does not apply; -speed values from 0 to 4 result in the same speed for the first pass and yield the exact same results in the final encode, whereas any speed setting above 4 results in the first pass utilising only a single core, slowing things down significantly. Therefore the -speed switch can be entirely omitted from the first pass, since the default value of 1 will result in fast speed.
Мамкин енкодерер даже официальный гайд не осилил.
Можно, но не нужно. Проблема именно в Vorbis. Используй вместо него MP3.
Вроде как еще можно AAC, но с постоянным битрейтом
> Вроде как еще можно AAC, но с постоянным битрейтом
С замечаниями. Можно и с переменным.
https://en.wikipedia.org/wiki/Comparison_of_video_container_formats#Audio_coding_formats_support
>>3429715
>нужно видео... .avi с кодеками видео vp8 и аудио vorbis,
Можно, но получиться воспроизводиная штука, но довольно дикая. Разновсяческие проигрыватели вряд ли ждут на входе такое необычное. Скорее, к таким кодекам пойдёт матрёшка или webm.
>можно это сделать вашим ффмпегом и эсли да то как?
Можно.
Я попробовал так:
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libmp3lame -b:a 128k out.avi
И вот так:
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -q:a 3 out.avi
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -b:a 128k out.avi
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -b:a 128k -minrate:a 128k -maxrate:a 128k out.avi
Все три последних варианта продуцируют файлы, которые mpv не может проиграть, не ломая синхронизацию. Википедия говорит, что под Windows нет совместимости с фильтрами DirectShow при извлечении vorbis из AVI. И ещё много нехорошего.
При этом AVI с VP8 и MP3 играются без проблем на mpv.
Сделал ещё контрольный файл так:
ffmpeg -hide_banner -i ed-24fps_i420.avi -i ed-24fps.flac -c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 5M -c:a libvorbis -q:a 3 out.mkv
Проверил заодно на телевизоре LG LK6190PLA — из матрёшки vorbis играется, но с искажениями, а из AVI vorbis не играется вообще, о чём телевизор предупреждает.
>Можно, возможно получиться воспроизводимая штука, но довольно дикая.
fix
Ну, и, на всякий случай, напомню, что VP8 комплектовать было бы правильно opus-ом и паковать в webm.
возможно не при обновлении строки, а как-нибудь каждые n секунд залезать в файл и выводить всё что там есть
Если делать так, то всё работает:
ffmpeg -i a.mp4 -i b.mp4 -filter_complex "[0][1]concat=n=2:v=1" -c:v libx264 -crf 30 -an out.mp4
Если, например, делать так, то происходит хз что, куски не клеятся:
ffmpeg -i a.mp4 -filter_complex "[0]split=2[a];[a]concat=n=2:v=1" -c:v libx264 -crf 30 -an out.mp4
Блядь, хули съело буквы, харкач ебаный.
Вот второй пример.
ffmpeg -i a.mp4 -filter_complex "[0]split=2[a][d];[a][d]concat=n=2:v=1" -c:v libx264 -crf 30 -an out.mp4
Не ffmpeg-ом единым такие вопросы решаются. Если тебе уже монтажные операции делать, то ты возьми более подходящие для такого инструменты — avisynth+, avxsynth, vapoursynth. У них синтаксис не очень сложный — осваивается часов за восемь на нескольких примерах. Зато сценарии на этих языках выглядят гораздо более внятно и читаемо.
Чё за милфочка? Есть сурс?
Да это понятно, я в давинчи могу хуячить, но тут шаманил один сценарий в ffmpeg и проебался пару часов с этим concat'oм ебучим, беглый поиск в гугле внятной информации не нашёл по нему, стало интересно, но не настолько, чтобы исходники смотреть.
Решил тут спросить, может кто в курсе.
Нет. Там есть возможность вывести из ffmpeg на стандартный вывод, а его уже перенаправить в исполняшку svt-av1 на стандартный ввод. Если очень хочется именно в ffmpeg использовать библиотеку libsvtav1, то собираешь из исходников svt-av1-psy библиотеку libsvtav1, её бинарник и заголовочники подменяешь в исходниках ffmpeg, и собираешь из исходников уже сам ffmpeg.
Сорри, я собираю в докере, тебе мои методы вряд ли помогут.
В mov кто-то кидал ссылку на:
https://github.com/BtbN/FFmpeg-Builds/releases
Я бы на твоем месте форкнул на гитхабе этот репозиторий, в файле:
https://github.com/BtbN/FFmpeg-Builds/blob/master/scripts.d/50-svtav1.sh
подменил SCRIPT_REPO и SCRIPT_COMMIT, и включил автосборку на гитхабе.
В итоге у тебя будет такой же ffmpeg как в первой ссылке, но с svt-av1-psy.
Вот этот форк лучше https://github.com/yt-dlp/FFmpeg-Builds наверное.
MkvToolnix скачай
https://mkvtoolnix.download/windows/releases/82.0/mkvtoolnix-32-bit-82.0.7z
я там 10 дистров линуксов пролистал прежде чем нашел для виндовса
а че там нажимать чтобы удалить дорожку
Скопируй видео и нужную дорожку в новый файл через map и -c:v/-c:a copy. А затем снеси старый файл
https://www.fosshub.com/MKVToolNix.html
ну допустим вот такой трюк делаю с видосом.
Вопрос: разве при -c:v h264_nvenc у меня не должна видюха нагружаться сильно? Почему-то cpu 80%, а видюха на 40%. Что не так делаю, чтобы видюху по максимуму заюзать?
Чёт не всё так просто в интернете по этому поводу, даже не нахожу результатов тестов cpu vs gpu по скорости выполнения.
А без фильтра как? Какая карта?
А зачем ты юзаешь вместе crf и b:v ?
фильтр это что? 4070super
>>3437931
случайно видать осталось crf, ну убрал его. всё равно также по нагрузке на проц и видюху.
показывает speed=1.48x - это же маленькая скорость?
А может у тебя всё упирается в скорость передачи данных. Попробуй переместить видеофайл на nvme ssd.
>-vf rotate=1*PI/180
>фильтр это что?
нет, разницы нет, что обычный ssd, что m2.
скорость низкая из-за rotate=1PI/180
Действительно, без rotate=1PI/180 видюха на 100% грузится, а цпу на 40%.
И как мне всё же при любых параметрах через видюху юзать ffmpeg? Чё, тут никто через видюху не юзает?
Фильтр просчитывается процессором, видеокарта только кодирует.
> Чё, тут никто через видюху не юзает?
Я пробовал но качество говно по сравнению с процом почему то или я не те настройки выставил
а я crf выставлял и ффмпег дефолтные 2000к кидал
> Я пробовал но качество говно по сравнению с процом
Так и есть, хардварное кодирование в среднем хуже программного, потому что железо не резиновое по разрядности блоков, функционалу и т.д. Кодировать железно имеет смысл если надо быстро и много, а качество можно стерпеть
>потому что железо не резиновое по разрядности блоков, функционалу и т.д. Кодировать железно имеет смысл если надо быстро и много, а качество можно стерпеть
Ну, современное сжатие с потерями (да, и без потерь это в общем случае тоже касается) — это задача оптимизационная. Соответственно, программные решения могут себе позволить рассматривать сколь угодно большое число вариантов кодирования на выбор, чтобы по наперёд избранному критерию выбирать оптимальный вариант. Аппаратные сжималки, как правило, ограничены временем отсечки, за которое решение должно быть найдено с гарантией. Отсюда и типовой способ достижения задачи — параллельно рассмотреть несколько вариантов (включающих в терминах, например, стандарта h.264 как распределение макроблоков, так и векторов движения и квантователей) и выбрать по простому критерию (например, по СКО) один; без пересмотра решения, без этих ваших градиентных поисков, без многокритериальной оптимизации. Максимум, что тут можно на аппаратном сжиматоре — это в две-три итерации попробовать найти решение, чуть более близкое к оптимальному. Ещё, вроде начали завозить в аппаратные сжиматоры двухфакторные критерии вроде «выигрыш по ширине блока в потоке — проигрыш в СКО», но это не точно.
Кроме того, для «по-быстрому» и без «стерпеть», в зелёные слотовые затычки не так давно завезли h.264 без потерь.
Если кто не в курсе, MS-MPEG4 и Windows Media Video 7 и 8 версии лепились из кусков MPEG-4 Part 2 в процессе их обсуждения и стандартизации и случайно подарили миру DivX ;-) 3 и рипчики на 700 МБ, что чуть позже привело к DivX, Xvid и FFmpeg как полноценным реализациям.
https://wiki.multimedia.cx/index.php/Microsoft_MPEG-4
https://web.archive.org/web/20090523080617/http://www.fourcc.org/codecs.php
https://ffmpeg.org/~michael/msmpeg4.txt
Windows Media Video 9 — это уже базовая часть VC-1.
> Соответственно, программные решения могут себе позволить рассматривать сколь угодно большое число вариантов кодирования на выбор, чтобы по наперёд избранному критерию выбирать оптимальный вариант.
Только кодировщик, который день тратит на перебор вариантов для одного кадра, никому не нужен.
Сжатие, то есть поиск более компактного способа записи данных, — интеллектуальная, а не «оптимизационная» задача. Можно сказать, что оптимизируются здесь стратегии перебора этих способов, и делается это не на компьютере, а в процессе исследования и выбора алгоритмов. Как только мы наивно берёмся рассуждать о поиске наилучшей комбинации всех пикселей кадра, близкой к оригиналу, или там о переборе всех возможностей двигать блоки во всех направлениях между кадрами, мы получаем близкую к нулю производительность. Оптимизации уже придуманы, а кодировщик только подстраивает их параметры под характер материала.
Аппаратные кодировщики в видеокартах можно делать лучше, только это по многим причинам излишне. Размер модуля в кремнии, сложность разработки, процент выхода брака, потребление энергии, конечная стоимость продукта доходят до каких-то объективных границ. Кроме того, большинству пользователей это и не нужно. В одних случаях можно задрать битрейт, в других — потерпеть (особенно в одноразовых живых трансляциях, где видео нужно для галочки и даже не сохраняется никуда). Кроме того, это предрешено стандартами, комитеты которых заранее делят легко реализуемые аппаратно части и тяжёлые добавки по профилям, и разработчики чипов в них тоже сидят, внося свои оценки и предложения.
Если посмотреть на рынок сложных аппаратных кодировщиков, то он с домашними пользователями не пересекается. Это либо гиганты вроде YouTube, где одновременно нужны и минимально допустимый на практике битрейт, и максимально возможное качество, и минимальная практическая задержка, и чтобы счёт за электричество в датацентрах не был астрономическим, либо скучные коробки для телевидения, которые выдают нормальную картинку и больше никаких волшебных возможностей не содержат, но зато их можно поставить работать месяцами без перерыва, кодируя поток на спутник для всего континента с минимальной и постоянной задержкой между дыркой для входа и дыркой для выхода. Ограниченный рынок и сложность продукта задают стоимость в тысячи долларов для полупрофессиональных моделей.
↓
https://2ch.hk/s/res/3441805.html
↑
ПЕРЕКАТ