FFmpeg и общий кодирования видео тред №4 /ffmpeg/
Аноним (Microsoft Windows 10: Chromium based)
29/09/21 Срд 22:48:49
№1
Весь предыдущий тред мы опять срались за кодеки, но я напоминаю, что тред в первую очередь об ffmpeg.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают в ИТТ.
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички в step-by-step how-to стиле для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Самые ходовые видео-кодеки на данный момент - VP9 и H.264. Подробный разбор их режимов кодирования читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда: https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
Бонусом в треде обсуждается youtube-dl - утилита для нормального выкачивания видео с ютуба, вк, порнхаба и ещё миллиона других видеосервисов. Не совсем кодирование, но скорее всего ты тоже этим дерьмом занимаешься, если что-то делаешь с видео, так что давай осваивай тоже нормальную утилиту вместо просмотра рекламы и установки зондов. Тоже опенсорс подо всё, что способно выполнять AND NOT и XOR.
Тред №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/res/3029626.html
>Ав1 по битрейту не просто в два, раза в три лучше 264
Пруфы будут или как всегда?
>>3056496
Зависит от библиотеки кодера. У тебя libx264, libx265 или libvpx?
Ты вообще знаешь что-нибудь о запуске программ из командной оболочки?
>>3056509
Ну, про libx264 попробую завтра с работы днëм рассказать.
> Экстремальный пример
> Подобное видео
> с читабельным текстом
> 186 Кбит/сек
Спасибо за пример.
Четверть текста превратилась в нечитаемую размазню.
Выходит, что AV1 способен сгенерировать инфомусор с шириной потока втрое меньше, чем h.264. Если бы ты сразу уточнил такое, то я бы и спорить не стал. Большинство видеороликов содержат не такое.
Кстати, припоминаю, что ещё полтора десятка лет назад был такой кодек для телеконференций — VP7. Статическая картинка (это когда в кадре человек сидит почти неподвижно и болтает) у него выходили с очень маленькой шириной потока, но остальные сюжеты выходили очень сильно посредственно в смысле эффективности сжатия.
умудрился 40 мин запихнуть в 360p на 50битрейта в 14мб.
Но можно ли лучше?
В идеале там вообще должно быть 5 кейфремов которые будут сменяться по таймингу песни, как в оригинальном видосе.
РАсскажите покажите как улучшить эту еботу.
использовал команду
ffmpeg -r 1 -loop 1 -i 1.jpg -i doomer.mp4 -t 00:41:47 output.mp4
получилось 41мб
потом прогнал через webm_for_retard сделал аудио битрейт 45кб и видео 10кб. Но видать битрейт ставится по максимальному параметру. Поэтому на выходе получил 50 битрейта в среднем
> В идеале там вообще должно быть 5 кейфремов которые будут сменяться по таймингу песни
Вот ты явно не помнишь девяностые годы и видеоформаты, у которых ровно один ключевой кадр был в начале ради экономии байтиков. В них вообще нельзя было перейти на любое время, только ускоренно перемотать с самого начала (если продвинутая программа такое умела).
С твоим гипотетическим файлом выйдет вот что:
— либо любая попытка перемотки будет приводить к прыжку на предыдущий или ближайший ключевой кадр, и только на один из них;
— либо любая попытка перемотки будет приводить к зависанию на какое-то время, пока декодируются и отбрасываются кадры начиная с предыдущего ключевого и до указанного времени;
— либо плеер будет вылетать, потому что во время этого декодирования какой-нибудь буфер не получит данные за заданное время, или найдётся ещё какая-то ошибка.
Видеоформаты не очень подходят для такой оптимизации пустых кадров без изменений, в них обычно не предполагается теоретическая возможность пользоваться данными, расположенными за тысячу кадров, поскольку от декодера ожидается работа с локальным куском потока в буфере, а не с файлом целиком. Если тебе нужно совместить аудио и презентацию несколько картинок, возьми подходящий инструмент. Например, Flash.
(ха-ха-ха, возьмите меня в программу «Аншлаг»)
Если без шуток, то ты можешь использовать YTMND для такой демонстрации. Там, правда, перемотки вообще нет.
https://www.youtube.com/watch?v=wcaZcbain2s
>>3056771
Охуенно анон, как сделал?
>>3056810
Да все эти траблы меня не волнуют. Я просто хочу сделать 40 минутную легкую вебм чтобы форсить ее на дваче
Кстати , ты слегка промахнулся с размером
двач почему то округляет рзамер видосов вверх и тип 20 мб округляет до 20.1
а вот 19.9 для него ровно 20. ПОэтому это говно влезет в /b/ а твой видик нет
>>3056938
Держи
https://0bin.net/paste/aYClIoeL#a0YONiaykhQZwxjnIZ9r+MwIgEuzXpb+swjTDDGAncM
С помощью Mkvmerge файл уменшился на мегабайт, и теперь стало нормально
Мое уточнение было к тому, что не каждый имеет 200гб места на смартфоне/планшете/ноутбуке/компьютере что бы просто посмотреть Love Hina в хорошем качестве
Чем тебе вот эти не нравятся вообще?
https://ny.iss.one/view/1154946
https://ny.iss.one/view/1412863 этот также уже с бд сделан
https://ny.iss.one/view/1215876 здесь меньше вес, но качество хуже наверное.
https://ny.iss.one/view/664955 720п
https://ny.iss.one/view/664960 720п спешлы
https://rutracker.org/forum/viewtopic.php?t=5080133
https://rutracker.org/forum/viewtopic.php?t=5081316
Пять секунд буквально найти.
>>3057775
Сейчас качать bdremux будет только додик, когда уже давно можно смотреть их онлайн, не качая, если конечно не для коллекции.
>https://ny.iss.one/view/1154946
Вот эту я заберу, пожалуй. Благодарю, почему-то не смог найти именно этот торрент.
>Чем тебе вот эти не нравятся вообще?
Мне нужен максимально непохеренный BDRip, что смог бы сохранить приличное качество и не весить как сам BD. Это легче и по структуризации папок, так и не сильно бьет по памяти, ведь у меня огромная датабаза из мультиков, фильмов и музыки на случай Чебурнета. Если же я скачаю 720p с битрейтом пенька, то это уже будет говноедство уровня прослушивания музыки в ВК, или ещё хуже, просмотра японских мультиков с японской озвучкой на shikimori.
Я соглашусь с тем, что 720п действительно смотрится неплохо на 1080p мониторе, сейчас Наруто Шиппуден смотрю и вполне неплохо, однако я стараюсь смотреть в будущее и прибираю к рукам самый оптимальный для меня вариант. 720x480 разрешение, что стандартное для DVD уже выглядит не очень даже на 1080p, про 4K я молчу. Никогда не будешь уверен, останутся ли нынешнии потребляди на 1080p разрешении мейнстримно или же будут продвигаться всё выше и выше с каждым десятилетием, потому лучше иметь наилучшее разрешение и, в идеале, с наиболее оптимальным битрейтом. Я бы скачиывал Remux, но не к каждому мультику/фульму такой найдётся, а самому рипать так на это ещё больше денег уйдет, так что я выбрал такой путь.
тупой дебил на связи. нихуя не понимаю как настроить и пользоваться этим ffmpeg, клиника нахуй, поэтому юзаю xmedia recode. всё вроде бы устраивает, но есть проблема с субтитрами. если я хочу сделать хардсаб, то текст может быть слишком большой/маленький или вырвиглазного цвета/шрифта. настройку это параметра не могу найти. в общем подскажите, есть какое-то решение проблемы (кроме сaмoвыпилa), может там надо сочетание кодеков подбирать или загрузить отсутствующие шрифты/библиотеки/аллаха? ПАМАХИТЕ
вот два примера из разных роликов, как криво он может рендерить
Если у тебя на входе видео с 8 битами на канал (в подавляющем большинстве случаев это так), то на выходе оно не увеличит разрядность, хоть ты его в формат с 16 битами запихни, хоть с 32. Картинка не изменяется, за исключением потерь от сжатия, и никакой особенный монитор не требуется для этого обычного видео.
Перевод в 10-битные значения позволяет улучшить сжатие и/или уменьшить визуальные искажения из-за повышения точности коэффициентов преобразований. В общем и целом, это просто такой промежуточный формат.
Вот эти двое >>3059768>>3059811 излагают близко к реальности. Попробую для интересующихся снова изложить в форме не очень короткого эссе. Заранее прошу прощения, что начинаю сильно издалека.
Основные понятия
1. Изображение в типичном цветном видоематериале представляет собой трëхкомпонентный растр прямоугольную плоскую таблицу из идентичных прямоугольных элементов (точек, пикселей), для каждого из которых определено значение яркости и цвет. Фактически каждой точке сопоставлено три числа, соответствующие трехкомпонентной аддитивной модели цветного зрения человека.
2. Цвет. Наиболее распространëнной моделью воспроизведения цветных изображений для светящихся устройств является аддитивная модель RGB. Иллюзия цветового ощущения для человека создаëтся путëм одновременного излучения (из источника, близкого к точечному) света всего трëх тонов, но варирующейся интенсивности. Значению интенсивности каждого из тонов можно сопоставить по числу, пропорциональному этому значению. Для удобства работы с сигналами преобразования информации и учëта особенностей зрения человека, чаще используется не аддитивная модель XYZ (CIE 1931) или RGB (красный, зелëный, синий), а модель YCbCr, получаемая линейным преобразованием из RGB, и содержащая три компонента - яркость (интенсивность) и два цветоразностных. Если использовать только яркостную составляющую, то из таких точек можно собрать «чëрно-белое» изображение, аналогичное тому, которое воспроизводит нецветной кинематограф. Математически линейное преобразование из RGB в YCbCr определено как система трëх линейных уравнений, где значение каждого из компонентов одной модели равно взвешенной сумме трëх компонентов другой модели. Линейная алгебра представляет такую систему как вектор, составленный из значений компонентов, например YCbCr [Y, U, V], являющийся результатом произведения вектора, например RGB [R, G, B], на некоторую матрицу преобразования M. Такие матрицы определены рядом стандартов, например в BT.709 или в BT.601.[/spoiler]
Изображение как функция
Для упрощения рассуждений, дальнейшее рассмотрение буду вести в отношении однокомпонентного изображения. Общность рассуждений это не нарушит, т. к. каждый из компонентов обрабатывается отдельно и почти единообразно. Допустим, что речь пойдëт только о изображении, составленном на основе только яркостной компоненты.
Итак, изображение (в том случае, который рассматривался изначально) - это дискретный составной объект, который можно представить в виде прямоугольной таблицы, в ячейки которой вписаны числа, пропорциональные яркости точки с соответствующими строке и столбцу координатами точки изображения. Можно взять, например, строку чисел из таблицы и построить зависимость значения из ячейки от порядкового номера ячейки. Зависимость эта для большинства изображений реальных сцен будет содержать избыточность. Так будут довольно обширные области, где значения изменяются в сравнительно небольших пределах, будут области с примерно повторяющимся характером зависимости и т. п. Возникает вопрос, заключающийся в том, можно ли представить информацию о имеющейся зависимости более компактно - использовать для воспроизведения меньше чисел, чем содержит сама последовательность.
Математика успела наработать довольно приличный аппарат для анализа и синтеза специальных объектов моделирующих связь между двумя множествами значений. Такими объектами являются функции. Функция как раз ставит в однозначную (у математиков есть и более суровые обобщения, но сейчас достаточно и школьного определения) зависимость два множества чисел: множество значений функции и множество значений аргумента функции. Для моделирования изображения аргументом функции будет номер ячейки, а значением функции - значение яркости.
Рассмотренная модель без проблем обобщается на функцию двух аргументов, когда моделировать нужно изображение из многих строк.
Анализ функций и изображения
Есть одно из фундаментальных преобразований функций в гильбертовом пространстве, определяемое через свëртку - это преобразование Фурье.
Если рассуждать по-проще, то пусть у нас будет некоторая функция из множества похожих на неë свойствами. Множества такого непростого, что любые функции из него можно складывать и перемножать между собой и ещë с какими-нибудь числами, допустим, действительными. И в результате сложений и перемножений получать тоже функцию, и из этого же множества. Допустим, что в множестве этом хитром допустим не только описанный чуть ранее синтез, но и обратное действие - анализ. Т. е. можно взять из множества любую функцию y(x), где x - это аргумент, который может принимать значение любого числа из множества X. Тогда X - это область определения функции y(x), если для всех элементов множества функция имеет смысл, т. е. значение. Теперь допустим, что мы нашли такое множество функций Z, каждая функция в котором имеет ту же область определения, что и y(x), а если взять и перемножить каждую функцию из Z на какое-нибудь действительное число, а потом такие произведения сложить, то в результате мы получим в точности значения функции y(x). Такая хитрая операция будет (при чтении уравнения в одну сторону) называться разложением функции y(x) на составляющие. Пространство функций, на котором допустимо всë описанное непотребство, у математиков называется гильбертовым. В математической литературе определение гораздо короче, но я надеюсь, что смог объяснить более доходчиво. Возвращаясь к разложению, хочу особо отметить те самые сомножетели, которые были не функциями, а просто числами. Это коэффициенты разложения. Если для разложения функции y(x) по наперëд заданному множеству функций Z (базису разложения) коэффициенты определяются единственным образом, то такое разложение называется ортогональным.
Итак, я напомнил понятия функции, пространства функций, разложения, коэффициентов разложения и ортогональности.
Среди всех известных школьникам элементарных функций есть весьма удобные для вот таких разложений базисные функции - тригонометрические. Синус и косинус. Меняются плавно, являются периодическими, определены и ограничены на всëм множестве действительных чисел, а любая пара таких функций ортогональна на интервале, содержащем целое натуральное число периодов каждой. Т. е. sin(x), sin(2x), sin(3x) и т. д. взаимно ортогональны.
Завтра попробую рассказать про спектры, ДКП-преобразование, интерполяцию и способ синтеза изображения сколь угодно высокого разрешения с отсчëтами сколь угодно высокой точности, если разложение производилось по конечному числу отстëтов с дискретным множеством значений (конечной точностью).
ffmpeg -i a.mp4 -vcodec libx265 -crf 24 b.mp4
в итоге на харкаче проигрывается только звук, а вместо шебм серый экран. чяднт?
Нужно было и в случае с H.265 так же сделать, а не городить сотни форматов, которым нужна и аппаратная поддержка. Сэкономили на отчислениях, но юзер соснул, так как его huishen9998 не поддерживает прогрессивный формат huipizda14.88, аппаратную поддержку которого завезут только в huishen9999, покупай, гой! А так можно было бы купить видяху и проц с поддержкой хевка и раскошелиться на новые только при выходе VVC, всё-таки универсальный стандарт это всегда ради общего блага.
> Нужно было
Разрабатывай свой формат и раздавай, мой маленький грязноштанник, а причём тут поддержка? Поддержку пилить никто не запрещает, её не пилят потому что нет развития сервисов, использующих этот кодек, аппаратура тут не при чём, можно и софтом декодить, ну и гнилой ff отказался от h265 после продажи своего анала гуглу задёшево, если я правильно помню.
> мой маленький грязноштанник
Грязноштанники это те, кто запиливает свои аналоговнеты (государственный капитализм с налётом социализма, например), я же следую стандарту. Стандарт это H.265, он везде применяется, особенно в кино. Аналоговнеты в данном случае это AV1, VP8 и VP9, которые поглотили браузеры. Раз существует практика принудить распространять, пойти на уступки, так её нужно применять дальше.
> отобрать и поделить лицензирование
> Я НЕ ГРЯЗНОШТАННИК МАМ
Вам таблетосы с правой или с левой?
https://www.reddit.com/r/AV1/comments/p8l581/my_testing_with_av1_cpuused_1_to_8_at_crfs_253545/
>это AV1, VP8 и VP9
Они хороши для потокового вещания (искл. АВ1, т.к. он литералли неюзабелен), когда очень важно ужать файлы, но во всем остальном это говно сравнивать с залупой от мпег как-то стыдно. Это совершенно разные уровни. Хотя свободные форматы разрабатывают нихуевые такие корпорации.
Ты тупой уебан
https://test-videos.co.uk/vids/bigbuckbunny/mp4/h265/1080/Big_Buck_Bunny_1080_10s_1MB.mp4
> Они хороши для потокового вещания
Потому потоковое вещание идёт в h264? По крайней мере на ютуб(создателе этих кодеков) и твиче. Они хороши лишь тем, что ютубу за них не надо платить, в остальном это тотальный мусор, даже для хранения информации, если не ставишь целью смотреть 8к или 144p видео на ютубе, то лучше воспроизводить в h264 вообще всё >=360p и <=1080p, здоровее глаза будут.
>На ютабе вп9/ав1 вперемешку.
Подтверждаю. Не так давно обратил внимание на то, что батарейки ноута хватает всего лишь на час видео с ютуба. А там AV1, который на программном декодере грузит процессор под 50-75%. VP9 грузит под 30-50. Но это тоже не комильфо.
> Где? На ютабе вп9/ав1 вперемешку
Запустил стрим на ютубе, например, где вп9?
> vp9 в мп4 завернут
Можно подробнее кто и как завернул?
Ну прогресс не стоит на месте, надеюсь к моменту когда массово платформы будут стримить от 1440 уже в ходу будет адекватный кодек, хотя у меня всё равно не будет достаточной пропускной способности канала, чтобы такой контент оценить.
По дефолту там такая командная строка
-an -c:v libvpx -pix_fmt yuv420p -threads 4 -slices 2 -metadata title="Урок1" -minrate:v 900k -b:v 900k -maxrate:v 900k -bufsize 540k -rc_init_occupancy 3600k -qcomp 0
Попробовал SVT-AV1, тот и нагружает по максимуму, и быстро где-то 0.43x. Но не могу менять битрейт -b:v не воспринимает.
Что скажете за librav1e?
Вот эта бумага:
https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/cloud-computing-quicksync-video-ffmpeg-white-paper.pdf
говорит, что на Xeon E3-1285 (haswell) кодер h264_qsv должен дать под 100 кадров/с даже в режиме veryslow.
Я пробовал на Core i5 4460 с кодером h264_vaapi еле удаётся выдавить 25 кадров/с.
Материал везде 1920×1080, yuv444p.
Как-то слабовато со сходимостью.
Имеется много музыки mp3 320, хочу перекодировать всё в opus 128 или 160 ещё не определился, естественно сначала перегоню mp3 в wav, а уже потом в opus. Это совсем плохая идея или норм?
Не факт, что баг. Вполне может быть, что так и должно быть для VA-API. Годные источники информации по этому вопросу либо сходу не гугляться, либо вовсе не существуют в открытых источниках. В whitepaper используется другой интерфейс для обмена данными с сопроцессором - используется вместо h264_vaapi h264_qsv, подключается через библиотеку libmfx. Судя по описанию, кодер на libmfx совершает существенно меньше транзакций. Плюс, пара постов (похоже, от инженеров intel) на форуме поддержки этого вашего intel вещает о том, что вариант интерфейсной прослойки VA-API менее производительный, чем QSV с libmfx.
По описанию пакета i965-va-driver, он предоставляет возможность использовать кодеры mpeg2, mjpeg, mpeg4asp и h264 через VA-API. При этом есть вариант этого пакета i965-va-driver-shaders с закрытыми прошивками в комплекте, которые позволяют кодировать через VA-API ещë и в h265 (и если я правильно помню, то и в VP9).
По справочным данным ffmpeg wiki и archwiki, haswell должен уметь в кодирование набора, перечисленного для i965-va-driver-shaders, как через VA-API, так и другим (не уточняется интерфейс) способом через QSV.
Если отталкиваться от содержания whitepaper, то они используют собственную сборочку прыщей с графическим стеком из ffmpeg с кодером h264_qsv, QSV-чипа и libmfx где-то между ними. Если посмотреть на описание этой самой libmfx, то там сказано, что haswell не поддерживается, а сопрягать эту ляпоту можно только с intel-media-va-driver-non-free, в котором haswell не поддерживается. Возможно поддержку haswell выкинули при очередном обновлении, а whitepaper отчитывается о работе исторического кода, но это нужно проверять.
Очень жаль, что у меня под рукой оказалось всего два камня, и оба haswell. Нет возможности проверить.
Установка i965-va-driver-shaders кодер h264_vaapi ожидаемо не ускорила. Установленный libmfx1 к драйверу i965 при попытке инициализации h264_qsv подключаться не желает и ожидаемо требует драйвер iHD из intel-media-va-driver-non-free, при инициализации которого возвращается ошибка о неготовности оборудования.
Пока такие дела.
SVT тут причём, это программный кодировщик, работает везде
>>3065897
Если у тебя есть свежий процессор со встройкой, ты можешь делать vp9 видео очень быстро, с хуевым качеством. Как ютуб впринципе https://en.m.wikipedia.org/wiki/Intel_Quick_Sync_Video
> делать vp9
> с хуевым качеством
А он способен выдавать другое качество?
ffmpeg -i input.HDR.HEVC.mkv -ss 1:27:40.875 -to 1:28:19.333 -map 0:0 -map 0:3 -c:v libx264 -preset veryslow -crf 18 -c:a libmp3lame -q:a 5 output.mp4
ffmpeg зависает на стадии декодирования и пишет сообщения типа:
[hevc @ 0x56210338ddc0] Mastering Display Metadata:
[hevc @ 0x56210338ddc0] r(0.6800,0.3200) g(0.2650,0.6900) b(0.1500 0.0600) wp(0.3127, 0.3290)
[hevc @ 0x56210338ddc0] min_luminance=0.005000, max_luminance=4000.000000
[hevc @ 0x56210338ddc0] Content Light Level Metadata:
[hevc @ 0x56210338ddc0] MaxCLL=738, MaxFALL=157
[hevc @ 0x56210338ddc0] Output frame with POC 12.
[hevc @ 0x562103212c40] Decoding SEI
[hevc @ 0x562103212c40] Decoded frame with POC 6.
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
[hevc @ 0x562103212c40] nal_unit_type: 35(AUD), nuh_layer_id: 0, temporal_id: 0
[hevc @ 0x562103212c40] nal_unit_type: 34(PPS), nuh_layer_id: 0, temporal_id: 0
[hevc @ 0x562103212c40] nal_unit_type: 39(SEI_PREFIX), nuh_layer_id: 0, temporal_id: 0
Я не пойму в чем дело, он закончит это когда-нибудь? Или ему нужны дополнительные настройки.
Это же все в детских гадах есть https://hive.blasux.ru/webm/s как ты дожил до своих лет ничего не читая? Штанишки то хоть сам с утра надеваешь?
>Штанишки то хоть сам с утра надеваешь?
Я их не надеваю.
Например
nvenc не может
http://forum.doom9.org/showthread.php?t=175091
intel qsv тоже не может
https://community.intel.com/t5/Media-Intel-oneAPI-Video/2-Pass-Encoding/td-p/995261
и amd vce не может
https://forum.videohelp.com/threads/364197-Two-pass-encoding-How-hard-is-it
Расслабься! Это никому не нужно. Эти аппаратные кодеры нужны не для подготовки качественного материала, а для быстроляпа без большой загрузки ЦП.
По первой ссылке объяснено, что это двухпроходный анализ кадра, а не двухпроходный режим работы всего контроллера ширины потока. Лучнее, что есть в nvenc - это режим без потерь. Конкретно мне трудно представить случаи применения, отличные от:
- говновидео для говностримов,
- быстрый захват без потерь для последующего монтажа.
Решения от Штеуд и Амуде годятся только под первый вариант. Может ли это измениться? Да, может, но пруфов я пока не видел.
Но ты же целевое назначение изменить хочешь. Теперь у тебя не NAS, а числодробилка. Теперь нужна энергоэффективность.
>>3068142
>рассчитать примерную скорость кодирования в зависимости от ЦП?
Можно прикинуть экспериментально. Можно взять какой-нибудь средний контент, и закодировать, оценив скорость в кадрах/с. 4K-исходник «Tears of Steel» подойдëт, можешь качать png-шки.
Как там поживает аппаратное ускорение кодирования VP9 на винде? Если никак, то я лучше буду кодировать в Ав1, ибо интелловский кодер работает быстрее libvpx-vp9
Подскажите видеофильтр ffmpeg, чтоб от краёв к центру экрана шёл чёрный полупрозрачный тон, чем ближе к центру тем более он прозрачный, пока совсем не исчезнет.
Ещё хотелось по такому же принципу (от краёв к центру) сделать увеличение насыщенности цветов.
Делается не так. Создаëтся в любом удобном графическом редакторе соответствующий градиент от чëрного к белому в центре. Экспортируется в тонах серого одна картинка в размер кадра. В фильтрах наложения используется как маска. Делаешь т-фильтр, один из его выходов обесцвечиваешь, поверх последнего накладываешь второй выход т-фильтра с твоей картинкой в качестве маски. Могу попробовать через фильтры ffmpeg командную строчку собрать, если хочешь, но лучше бы в каком-нибудь avisynth/vapoursynth это делать.
>deprecated pixel format used, make sure you did set range correctly
> на сайте вот что про mp4 пишет
Пишут, что MP4 и матьрёшка поддерживаются.
Значит, у нас два варианта развития событий:
1. Мы удалим packed bitstream из потока, сформированного кодером DivX, приведём поток к удобоваримому виду обычного MPEG4 ASP, который можно смело положить в матрёшку или MP4. Телевизор твой должен такое скушать.
2. Если не получится быстренько переделать по первому варианту, тогда перекодируем в h.264.
> Поэтому, буду признателен, если напишешь как, и я сам постараюсь там подшаманить.
Для этого мне нужен твой образец. Возьми любую из серий на твой выбор и ffmpeg.
Если у тебя Windows на x64, то FFmpeg возьми отсюда:
- windows, x64, без libxcb, vaapi, xlib, libdrm, libfdk-aac и frei0r — https://github.com/BtbN/FFmpeg-Builds/releases (бери тот файл, имя которого заканчивается на «-win64-gpl-4.4.zip»);
- windows, x64, без iconv, с libfdk-aac, frei0r, libgsm, libopenh264, libspeex, libsvthevc, libilbc, libvo-amrwbenc, libxavs, gnutls, libaribb24, libbs2b, libcaca, libflite, liblensfun, libmodplug, libmysofa, libsnappy и libtesseract в комплекте, с nvenc, nvdec вместо ffnvcodec — https://github.com/AnimMouse/ffmpeg-autobuild/releases (бери тот файл, имя которого заканчивается на «win64-nonfree.7z»).
Дальше нужно добавить путь к ffmpeg.exe в реестр, чтобы вызывыть короткой командой. Методичка здесь https://docs.microsoft.com/en-us/windows/win32/shell/app-registration
Можно без методички открыть ветку реестра «HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths». Там по аналогии можно догадаться, как сделать нужно.
Делаешь следующее в консолечке, которая у тебя есть:
ffmpeg -hide_banner -t 30 -i "c:\anime\rare things\oldfag tears episode 01.avi" -c copy output.avi
где «c:\anime\rare things\oldfag tears episode 01.avi» — полный путь к файлу с серией, «output.avi» — выходной файл, в котором ты для меня сделаешь 30-секундный кусочек твоего аниме.
Наш итоговый результат по сценарию варианта 1 должен изготавливаться примерно так:
ffmpeg -hide_banner -i "c:\anime\rare things\oldfag tears episode 01.avi" -c copy -bsf:v mpeg4_unpack_bframes episode_01.mp4
Да, я так и сделал, чтобы лишних полтора часа не обрабатывать, но ведь дело не в этом.
>>3076209
Сам вспомнил, что в предыдущих тредах уже поднималась это тема, дело в ключевых кадрах. Поставил -ss на секунду раньше, и секундный фриз пропал. Но всё равно расскажите, как резать в точное время без этих фризов.
>как резать в точное время без этих фризов.
С перекодированием.
Тут есть кроме штуки с ключевыми кадрами ещё штука с прочими всякими потоками. Например, со звуком, продолжительность кадра у которого не просто не равна продолжительности кадра видео, а даже не кратна ей.
Если есть желание свободно монтировать, то добро пожаловать в перекодирование.
количество файлов всегда варьируется и мне приходится вручную перепечатывать. это можно как-то автоматизировать, чтобы если например в папке n файлов начиная с 1 и до n ффмпег сам это определял
Есть файл.мп4 без звуковой дорожки. К нему хочу пришить звуковую дорожку flac.
Но ffmpeg все ругается.
Подскажите команду!
Пикча для привлечения внимания.
Блин, скачал другой ффмпег, там получилось. Но при этом во время тишины в видео теперь какой-то электронный шум. В исходном флаке нет (или практически нет), а в видео почему-то на такой же громкости есть шум.
Использовал такую команду:
ffmpeg -i входной.mp4 -i входной.flac -codec copy -strict -2 выходной.mp4
Если я правильно помню, FLAC не входит в официально поддерживаемые контейнером MP4 форматы содержимого. Пихнуть его туда можно, но за результат никто не отвечает. Тебе нужно просто сделать -acodec copy -vcodec copy в файл MKV.
Если у тебя аудиодорожка флак и режим обработки дорожки copy, то с чего бы там ПОЯВИТЬСЯ некоему лишнему шуму, аудио ведь НЕ перекодируется?
Можешь залить куда-нибудь исходное аудио и получившийся видеофайл, если не конфиденциально? Я понимаю кой-чего в кодировании аудио (в кодировании видео не особо, кек, просто увидел твой коммент, скролля /s/), может быть, подскажу по поводу этого "электронного шума", если пришлешь.
https://en.wikipedia.org/wiki/MPEG-4_Part_14#Data_streams
Уже поддерживается, в общем.
Ты не на спецификации смотри, а на проигрыватель, в который ты этот файл запихнёшь. Если ему десять лет, то и формат выбирай консервативный. Разницы между AAC с большим битрейтом и FLAC ты не услышишь.
>>3077084
>>3077098
>>3077095
Пардон, мужики. Дело оказалось в том, что в видеоплеере был включен нормализатор. Я не вырезал оставшийся после шумодава шум в местах тишины, лишь уменьшил громкость на этих местах с помощью огибающих. Вот на этот остаточный шум нормализатор и аггрился.
Наверно банальный вопрос - нужно три видосика mp4 объединить, обрезать по краям и сохранить желательно без перекодировки. Желательно с минимумом усилий. Виртуалдаб подошёл бы, но он не открывает мои mp4, хотя кодеки есть.
>Разницы между AAC с большим битрейтом и FLAC ты не услышишь.
Всё так, я не аудиофил, заказывающий золотые провода.
Но с некоторых пор ютуб стал хорошо кодировать аудио, если в оригинальном видеофайле аудиодорожка хорошего качества. Ютуб теперь умеет добивать до ~20 кГц. Предположу, что они ввели это, когда запустили Youtube Music.
И вот я бы хотел свои собственные музыкальные заливки посылать ютубу в максимально возможном качестве. (не автоматические видео Artist Name - Topic, которые подсасываются из дистрибьюторов, а именно свои собственные видео на своем канале, в которых есть музыка). Хотя бы для того, чтобы избежать ещё одного прохода перекодирования в цепочке (исходник -> aac 256 в видеоредакторе -> aac на стороне ютуба). Мне не влом залить на ютуб видеофайл с лосслесс-дорожкой.
Вот эта команда нормально работает у меня с последним скачанным ффмпегом.
ffmpeg -i Video.mp4 -i Audio.flac -c:v copy -c:a copy -strict -2 Output.mp4
Только -strict -2 нужно ставить, иначе ффмпег ругается.
Как ютуб там перекодирует, еще не знаю, еще не дообработал до конца видео.
Пожалуйста. Учти, что для точного покадрового разрезания в virtualdub надо указывать в качестве точки B не последний кадр, а СЛЕДУЮЩИЙ за ним (первый кадр следующей сцены), а в avidemux - именно последний кадр, который тебе нужен. То есть virtualdub режет (A, B], а avidemux - (A, B).
Делай так.
1. Используй имена исходных файлов, которые легко описываются некоей маской. Например, .ts, если в папке больше нет никаких ts-ок. Или _.ts, если все нужные тебе файлы начинаются с символа _. Или еще что-то подобное. И обязательно (!!) именуй их так, чтобы алфавитный их порядок был именно тем порядком, который тебе нужен.
2. Создай в папке с этими видеофайлами файл generatelist.bat со следующим содержимым:
(for i in (.ts) do @echo file 'i') > mylist.txt
(вместо .ts подставь подходящую тебе маску)
3. Запусти этот батник, он тебе сгенерирует mylist.txt в этой же папке со строчками вида
file 'filename1.mp4'
file 'filename2.mp4'
file 'filename3.mp4'
4. Создай здесь же файл concatenate.bat с таким содержимым:
"C:\путь\к\файлу\ffmpeg.exe" -f concat -safe 0 -i mylist.txt -c copy concatenated.mp4
5. Запусти его, и ffmpeg конкатенирует твои файлы, используя в качестве источников содержимое mylist.txt.
Не выкидывай эти батники, они работают для любого другого набора исходных видеофайлов, если, конечно, их имена тоже описываются маской, которую ты указал в generatelist.bat.
Ух бля, ебаное форматирование двача съело знаки процентов и хз что ещё. >>3076550, Держи, залил текст моего поста на pastebin без форматирования: https://pastebin.com/emKbgXcX
Пожалуйста. Только сохрани именно копию с pastebin, а не первое мое сообщение, в нем пропали звездочки и знаки проценты, и без них код скриптов превратился в тыкву.
>>3077665
Ты путаешь, на ютуб заливать собирался я, а ты отвечаешь другому анону с другим юзер-агентом. Да, на ютубе максимальное качество - лосси, с этим я не спорил и не собираюсь заливать лосслесс аудио, чтобы получить на самом ютубе лосслесс аудио. Но, во-первых, это минус один проход лосси-кодирования (сначала у тебя в видеоредакторе при экспорте в файл, потом на серверах ютуба в разные форматы аудио, которые отдаются зрителям). Во-вторых, уже сейчас ютуб умеет в аудио довольно хорошего качества, в которое не умел еще 2-3 года назад. Всякие youtube-dl еще не научились выкачивать это и выкачивают fallback аудио предыдущего поколения (и наверняка даже в браузере зависит от клиента), но улучшения есть. Может, в будущем будет еще лучше. Почему бы не загрузить на ютуб лосслесс-исходник, не жалко же.
Это как с битрейтом видеопотока: несмотря на то, что ютуб отдает зрителям очень шакальный битрейт (сколько там, 1 мбпс для 1080p вроде?), лучше все-таки заливать на ютуб видеофайл с битрейтом получше. Два прогона кодирования, где первый - 8 мбпс, а второй - 1, всяко лучше, чем оба по 1.
>заливать чуть больше 1440p (например, 2720х1530)
Звучит как готовый рецепт получить ебовейшее мыло и/или алиасинг от ресайза туда-сюда на "некрасивый" множитель. Особенно если у тебя исходники (из которых ты монтировал своё видео) 1920x1080, ты это при экспорте в редакторе ресайзнул в свою хуйню 2720x1530, а ютуб потом ресайзнул в 2560x1440.
>типа, после перекодирования будет лучше
Ну, да, в этом и суть того, что я написал в сообщении выше. Чем меньше лосси-шагов на пути от исходника к тому, что отдается зрителю/слушателю, тем лучше.
На правах оффтопа: абсолютно рядовая ситуация: музыкант долбоеб и ничего не понимает в технических аспектах кодирования аудио, кодирует свой трек в мп3, отдает лейблу, лейблу похуй, отдает мастеринг-инженеру, который поливает мп3шку готовыми пресетами улучшайзеров, результат отправляется в цифровые магазины и на стриминги, оттуда пиратится снова в мп3, горе-диджей берет эту спизженную мп3 и играет ее в миксе, по незнанию выставив неправильный режим key lock (или аналогичное), что еще сильнее ее шакалит, сохраняет свой микс как мп3, кидает в видеоредактор, чтобы сделать видео со статичной картинкой и этим аудио, сохраняет видеофайл (снова лосси конверт аудиодорожки), заливает это на ютуб, где на серверах еще один прогон лосси, и на выходе получается просто ПОЛНЕЙШАЯ БЛЯДЬ ПИЗДА. Если что, я полностью согласен, что дроч на лосслесс vs качественное лосси в контексте простого прослушивания трека абсолютно излишен и разницу слышит ничтожный процент населения на хорошем оборудовании. Но когда много шагов, как в этом примере (а это повсеместно), то адский шакалинг слышен даже глухому.
> Вроде как в рекомендациях ютуба указан флак
А можно ссылку именно на это? Вообще я предполагаю, что они написали флак как дефолтный пример известного обывателям кодека, из тех, что лосслесс. У них вся справка ориентирована на не особо технически подкованных пользователей. Что такое wav (или pcm), наверное, знают не так много людей. А разницы между исходником в виде wav и исходником в виде flac не должно быть, они хранят в себе буквально побитово идентичную волну.
Покажи мне, где в рекомендованных flac лол, ютуб всегда говорил лейте 1080p 15mb h264 aac mp4, чтобы не кодировать видосики лярд лет. Ему вообще до пизды flac и прочие loseless.
>Но, во-первых, это минус один проход лосси-кодирования (сначала у тебя в видеоредакторе при экспорте в файл, потом на серверах ютуба в разные форматы аудио, которые отдаются зрителям).
А автогенерируемые видео по твоему кодируются из лосси получается.
>Во-вторых, уже сейчас ютуб умеет в аудио довольно хорошего качества, в которое не умел еще 2-3 года назад. Всякие youtube-dl еще не научились выкачивать это и выкачивают fallback аудио предыдущего поколения (и наверняка даже в браузере зависит от клиента), но улучшения есть.
Любой поток из ютуба можно выкачать, если в коде страницы найти прямую ссылку. Покажи мне что там может быть помимо aac 128k и opus 160k. Если бы такое было, в тот же youtube-dlp давно запихнули как нефиг делать. Чет мне кажется ты лапшу вешаешь.
>Почему бы не загрузить на ютуб лосслесс-исходник, не жалко же.
Авторские права дадут на твой видос, даже если он вообще скрыт ото всех. И прощай габелла, тупо удалят, либо не сможешь воспроизвести.
>Это как с битрейтом видеопотока: несмотря на то, что ютуб отдает зрителям очень шакальный битрейт (сколько там, 1 мбпс для 1080p вроде?)
Что ты несешь, не пойму? Какой еще 1мбпс. Там ютуб сам определяет битрейт в зависимости от контента, если статичная картинка ясен пень он не нужен большой. В обычных видосах от 7к до 9к, можешь увеличиваться если движений много.
>лучше все-таки заливать на ютуб видеофайл с битрейтом получше
С дуру можно и по 100к битрейта заливать, crf 18 более чем достаточно.
>А про битрейт видеопотока есть еще хитрость - заливать чуть больше 1440p (например, 2720х1530), чтобы ютуб обработал профилем 4к. Но я хз, работает ли это еще.
Работает, но почему-то додики забывают, что если оригинал не 2k, или хотя бы не апскейл по типу 4k instant, по качество выходит дерьмовее, чем нативное 1080п на ютубе. Таким можно лишь посочувствовать, потому что смотреть противно, особенно если мелкие детали есть.
Нашел, новую статью добавили. Только не понял, что значит
>Обратите внимание, что звуковая дорожка воспроизводится на YouTube только в том случае, если вы добавили ее в программу Звукозамены.
>>3077689
>>3077691
Тэк, похоже, я вычитал это в требованиях отпечатков музыки для правообладателей. Не знаю, насколько это актуально для простых пользователей.
https://support.google.com/youtube/answer/6039860?hl=ru
Ты явно ответил двум людям сразу, но реплайнул только одному. Отвечу на те слова, которые мне:
> А автогенерируемые видео по твоему кодируются из лосси получается.
Автогенерируемые видео (если ты про заливки вида Artist - Topic) кодируются из лосслесс, который присылается дистрибьютором. В большинстве типичных случаев это один и тот же источник для спотифая, для ютуба, для эппла и пр., это агрегаторы типа Labelworx или Distrokid или собственные сервера больших мейджор-лейблов. Они рассылают лосслесс. Ютуб автоматически генерирует видео в виде статичной картинки (квадратной обложки) и аудиодорожки, сделанной из этого исходника.
> Любой поток из ютуба можно выкачать, если в коде страницы найти прямую ссылку. Покажи мне что там может быть помимо aac 128k и opus 160k. Если бы такое было, в тот же youtube-dlp давно запихнули как нефиг делать. Чет мне кажется ты лапшу вешаешь.
Не вешаю.
https://www.youtube.com/watch?v=5k2cDFi3P1U - выглядит как приложенный скриншот. Это не совсем аац 256 и не мп3 320, но гораздо лучше, чем то, что выкачивается ютубдл'ом (и прочими savefrom.net и подобными вариантами). Ютубдл у меня выкачивает в качестве, которое было и раньше. Видимо, это fallback для некоторых устаревающих клиентов.
> Любой поток из ютуба можно выкачать, если в коде страницы найти прямую ссылку
Да, но эти куски потока (с хорошим аудио) с каким-то анальным дрм. Их можно скачать, но они не открываются ни браузером, ни сторонним плеером. А вот если открыть какое-нибудь древнее видео, доступное только в 480p с соответствующей дорожкой, то там аудио "предыдущего" уровня качества в кусках потока как раз открывается чем угодно.
Кстати, если какое-то видео является ЗАПИСЬЮ СТРИМА (т.е. стрима на сам ютуб в прошлом), то у него аудио отдается тоже только "предыдущего" качества.
> Авторские права дадут на твой видос, даже если он вообще скрыт ото всех.
Чего. Если моя аудиодорожка в лосслесс, то детект музыки сработает, а если в аац 384 кбпс, то нет? :)
> Что ты несешь, не пойму?
У ютуба очень плохо с битрейтом. Было всегда и есть до сих пор. Даже всякие трейлеры фильмов, где, казалось бы, большие студии могли бы договориться с гуглом по этому поводу. Мыло пиздец.
Последний вопрос ты задал не мне.
> Ютубдл у меня выкачивает в качестве, которое было и раньше
Чел, там разное качество, и если ты youtube-dl не скажешь какое качать, он решит за тебя.
> Это не совсем аац 256 и не мп3 320
Это aac 128 и opus 115
>https://www.youtube.com/watch?v=5k2cDFi3P1U - выглядит как приложенный скриншот. Это не совсем аац 256 и не мп3 320, но гораздо лучше, чем то, что выкачивается ютубдл'ом (и прочими savefrom.net и подобными вариантами). Ютубдл у меня выкачивает в качестве, которое было и раньше. Видимо, это fallback для некоторых устаревающих клиентов.
Что ты черт возьми такое несешь? По волнам понял, что звук лучше? А может просто opus со временем лучше стал в сравнении с старыми версиями, не? Выше скрин с лоступными аудио выше.
> Это не совсем аац 256 и не мп3 320, но гораздо лучше
Opus 160k должен быть по качеству лучше, что тот, что другой. Включаешь статистику для сисадминов на видео, и смотришь какой кодек играет.
>Да, но эти куски потока (с хорошим аудио) с каким-то анальным дрм. Их можно скачать, но они не открываются ни браузером, ни сторонним плеером.
Открываются, если бы там был дрм, то никакой ytdl, ни savefrom не смог бы их подхватить, даже dash куски качаются ytdl. Короче какую-то шизу несешь. Так что показывай, если найдешь.
>Если моя аудиодорожка в лосслесс, то детект музыки сработает, а если в аац 384 кбпс, то нет? :)
Я ничего не говорил про аас, я говорил бессмысленность заливки на ютуб музыки с правами в общем, потому что рано изи поздно ее пидорнуть, а качество с офф. музыкой ютуба по сути нет, если это не говноремиксы залитые хрен знает кем.
>У ютуба очень плохо с битрейтом. Было всегда и есть до сих пор. Даже всякие трейлеры фильмов, где, казалось бы, большие студии могли бы договориться с гуглом по этому поводу. Мыло пиздец.
Всё нормально там с битрейтом, ютуб ставит настройки адекватные. Просто красноглазым дрочерам не нравится, что нельзя запилить их любимый пердеж и пустословие fullhd в 60мб/с.
> Открываются, если бы там был дрм, то никакой ytdl, ни savefrom не смог бы их подхватить, даже dash куски качаются ytdl. Короче какую-то шизу несешь. Так что показывай, если найдешь.
Из-под новейшей лисы (пишу для учёта клиента) открой то же самое видео, что обсуждалось выше, и посмотри в мониторе сети, какие куски тебе прилетают. Они содержат видео и аудио, но не открываются сторонними плеерами. А вот для видео на ютубе, которые являются записью стрима на ютуб, прилетают куски, которые открываются. И звучат похуже даже на слух (а не только на спектр).
> я говорил бессмысленность заливки на ютуб музыки с правами в общем, потому что рано изи поздно ее пидорнут
Если какой-нибудь альбом Тейлор Свифт, то да, если менее известную музыку - по моей практике, всем похер. Максимум будет стоять монетизация в пользу правообладателя, да ради бога.
> Всё нормально там с битрейтом, ютуб ставит настройки адекватные.
Сравни любой кинотрейлер с динамичными сценами на ютубе и на trailers.apple.com (можно брать прямые ссылки на hd-trailers.net). Разница - небо и земля. Просто современный интернет потихоньку приучает людей к тому, что картинка плохого качества - это нормально. Что ютуб, что Нетфликс, что прочие стриминги. Сплошное мыло, темные области полностью заливаются однотонными полосами. У меня не йоба-монитор, но даже на самом обычном это прекрасно видно.
>Из-под новейшей лисы (пишу для учёта клиента) открой то же самое видео, что обсуждалось выше, и посмотри в мониторе сети, какие куски тебе прилетают. Они содержат видео и аудио, но не открываются сторонними плеерами. А вот для видео на ютубе, которые являются записью стрима на ютуб, прилетают куски, которые открываются. И звучат похуже даже на слух (а не только на спектр).
Да, конечно. Гугловский ютуб не добавил "качественный звук" в свое детище хром, зато в лисе он появился откуда-то. Ты мне по факту принеси пруфы, а не свои какие-то предположения. Какой мониторинг сети нафиг.
>Просто современный интернет потихоньку приучает людей к тому, что картинка плохого качества - это нормально.
Нет. Просто гугл экономит место на серверах, использую самые оптимальные настройки.
> Гугловский ютуб не добавил "качественный звук" в свое детище хром, зато в лисе он появился откуда-то.
Вот только эта ветвь обсуждения была вовсе не про "качественный звук", а про куски потока, не открывающиеся плеерами.
> Ты мне по факту принеси пруфы, а не свои какие-то предположения. Какой мониторинг сети нафиг.
Я тебе "по факту" принес пруф с конкретным видео. Если тебе угодно общаться таким тоном, то продолжай делать это без меня.
Ну и аудио поток по шагам менялся так: eac3-->vorbis-->aac-->opus
Как правильно конвертировать такие вещи?
Как улучшить команду для yt-dlp, чтобы гарантированно брались лучшие видео и аудио?
А то я смотрю -help и ничего не понимаю.
Команду своровал из гуишной youtube-dlg, но в ней нет настроек, которые я там выбирал в гуи.
yt-dlp.exe --newline -i --all-subs -o "D:\Видео\%(title)s-%(id)s-%(height)sp.%(ext)s" --ignore-config --hls-prefer-native --embed-thumbnail --add-metadata "https://www.youtube.com/watch?v=что-то-там"
1 эпизод 1080р весит около гига, но мне абсолютно похуй на качество, так как смотрю ссаные слайсы. на телефоне 16 гб и 12 из них забито музыкой и порнухой, поэтому есть 4гб на маняме. сконвертил хуйню вот таким вырвиглазным образом:
ffmpeg -i 2.mp4
-vf "scale=-2:480"
-c:v libx265 -crf 30 -preset slow
-bf 10
-c:a libopus -b:a 32k
2opus.mkv
на выходе получилось 47.3мб для 24 минут с битрейтом видео 200-300 и 32 аудио. казалось бы, получится ебучая каша из пикселей и аудио как из жопы осла, но смотрю на телефоне и разница не такая уж и большая. по сравнению с оригиналом кажется, что качество упало на 20-30% максимум (в основном потому, что телефон у меня 720р).
насколько же охуенен хевк+опус, при одинаковом качестве оно по размеру файла меньше раз в 10 по сравнению с стандартным х264+аас. и не настолько уж хевк требователен к железу, раз уж мой кирпич спокойно его тянет, а вот ебучий vp9 тормозит в 720р60, поэтому даже видосы с ютуба не могу в вебмах качать.
можно ли как то эволюционировать моё копрофильство и ужать видос ещё сильней при смотрибельном качестве?
Зачем так сильно сжимать звук, оно весит мало, а на просмотр влияет.
Можешь сжать в AV1, для твоих случаев он сожмёт намного лучше чем x265, только времени займет намного больше
Не надо понижать разрешение, кодек достаточно умный чтобы сам понизить разрешение в некоторых моментах, когда нужно, при одинаковом размере будет выглядеть лучше. только если хочешь быстрее закодировать.
Ещё нужно кодировать в 10 бит, лучше качество но дольше немного, и может не открыться на телефоне, допиши -pix_fmt yuv420p10le
Может. Играл в "Боль Максима"? https://yewtu.be/QUXUyItb1ys https://yewtu.be/alHZlAYUE7U ← лучший формат видео эвар. И весить будет очень-очень мало. Жми с 0.2 FPS, будешь такой же непревзойдённой элитой.
И нам скинь, что выдет, интересно
Поставь программку MediaInfo.
Первая ссылка на обычный файл на HTTP-сервере с аудио и видео для клиентов, не поддерживающих потоковую загрузку, вторая — на видеопоток в DASH. Сравнить битрейт и прочие базовые характеристики файлов можно просто посмотрев в их описание:
ffmpeg -i 1.mp4 -i 2.mp4
Если ты подозреваешь, что совместимый со старыми устройствами видеопоток закодирован с несколько более консервативными параметрами, чем у второго варианта, то либо смотри готовые утилиты, которые его проанализируют, либо гугли, в каком из миллиона режимов статистики ffprobe будет нужная тебе информация, скажем, о количестве опорных кадров для декодируемого, и grep'ай нужное.
То есть опорные кадры и уровень H.264 покажет и MediaInfo, и ffprobe -show_streams, так что это пример негодный, а вот в отсутствие метаданных кодера о каких-то его параметрах догадываться можно только проанализировав всё видео.
ебать ты душнила. челик даже не может увидеть разницу в vbr битрейте между двумя файлами, а ты тут ебанутый словарь терминологий высрал, который даже знатокам лень читать.
ответ на его пост проще некуда:
1) ниже битрейт - хуже качество
2) юзай ffprobe
видосы с ютуба кодировать смысла нет, т.к. они и так сконвертированы очень хорошо мощным железом. максимум сможешь потратить 24 часа и ужать 5% без потери качества
на харкач можешь кидать сразу как есть с ютуба, будь то вебм или мп4 (h264/vp9)
> видосы с ютуба кодировать смысла нет, т.к. они и так сконвертированы очень хорошо мощным железом. максимум сможешь потратить 24 часа и ужать 5% без потери качества
у ютуба самые хуевые кодировщики которые стараются сделать как можно быстрее. Их нельзя кодировать потому что они и так сильно сжаты. Процессорный кодировщик может сделать файл в три раза меньше при таком же ужасном качестве, если закодировать исходник
Dash не Качайте, он в некоторых случаях выглядит намного хуже чем остальные. Лучше через браузер посмотреть какой поток отдаёт
Друг, спасибо, конечно, но очень сложно.
Я просто скачиваю прон с порнхаба и yt-dlp почему то по умолчанию считать лучшим видео с более низким битрейтом. Вот я и пытался понять почему. Ему приходится всегда приписывать -F 1080p. А хотелось бы, чтобы он по умолчанию выбирал лучшее разрешение и лучший битрейт.
>ffmpeg -i "!n!" -c:v h264_nvenc -preset slow -loglevel warning -stats -y -qp 24 -c:a copy -max_muxing_queue_size 1024 "!n2!"
Сравнивал попиксельно под лупой, изменений не заметил. Сжимает порой до 15% от изначального размера. Но все равно попадаются видео, которые с такими настройками пережимаются в 200%. То есть, эти редкие видео закодированы еще лучшим способом.
Знаете способы? Предполагаю, что есть энкодеры в связке с ml. Подскажите.
>сильнее пережать видео без заметной потери качества
>nvenc
> h264_nvenc
> Хочу как можно сильнее пережать видео
1) Есть ли легкий способ разделять и соединять обратно видео / вставлять в него другие части?
3 способами разделил видео на 3 части, а потом склеил их обратно:
ffmpeg -i video.mp4 -ss 00:01:00 -to 00:02:00 -c copy cut.mp4
ffmpeg -ss 00:01:00 -i video.mp4 -to 00:02:00 -c copy -copyts cut.mp4
ffmpeg -ss 00:03:00 -i video.mp4 -t 60 -c copy -avoid_negative_ts 1 cut.mp4
1 и 3 способ оказались почти одинаковыми: в Avidemux продолжительность соответствующих частей одинакова, но после склеивания частей из первого способа общая длительность - 44.389 секунд, а из третьего - 44.551 (у оригинала - 44.393). 1-ые части одинаковы по весу, 2я часть 1 способа меньше на 2кб (всего 4мб), а 3я часть 1 способа меньше на 3кб (всего 12мб), склейка 1сп также меньше на 5кб. 2 способ немного в другом месте делил, длительность склейки - 44.004. Во всех склейках в местах соединения видео где-то на секунду зависает и прыгает вперед, но в Avidemux, если не по-обычному смотреть, а поставить на паузу и нажимать на "следующий кадр", то после "прыжка" кадры тут же сменяют друг друга. По звуку разницы не заметил с оригиналом, но я на слух сравнивал.
Гуглил что делать, но там уже надо разбираться в матчасти, а с concat я просто копирую команду из гайда и все готово.
Алсо, длина видео - 44.393. Я опять отрезал 3 куска: 20-44с, 20-45с, 20-50с и по авидемаксу длительность всех трех оказалась 24.650
2) Правильно ли я понял, что эти команды ведут к одному результату:
ffmpeg -i test.ts test.mp4
ffmpeg -i test.ts -c:v libx264 -c:a aac test.mp4
?
Если конвертировать ts в mp4 через
ffmpeg -i test.ts -map 0 -c copy test.mp4
то весят файлы практически одинаково, на глаз разницы нет, в отличие от первых 2 команд. А если конвертировать через
ffmpeg -i test.ts -c:v libx264 -crf 0 -c:a copy LosslessVideo.mp4
то на глаз разницы тоже не заметно, но весит этот файл в несколько раз больше оригинала. Т.е. за редкими случаями этот лосслес не нужон?
3) Если оригинал скачанного видео в TS, стоит ли его перекодировать в MP4?
Когда-то бегло погуглил разницу и почему-то решил в таких случаях в mp4 перегонять, вроде он более универсален и поддерживаем.
Сейчас подумал что херней занимаюсь, у меня на ts воспроизводится, оригинал всяко лучше обработак, да и всегда в будущем можно перекодировать если нужно. Верно?
>Есть ли легкий способ разделять и соединять обратно видео / вставлять в него другие части?
Нет.
>3 способами разделил
Правильный только первый.
>длительность всех трех оказалась 24.650
А давно avidemux умеет в переменную частоту кадров?
>Правильно ли я понял, что эти команды ведут к одному результату:
Сегодня да. А завтра нет. Подстановки неявных параметров могут быть изменены когда-нибудь.
> -map 0
Ты точно уверен, что руководство прочитал?
>за редкими случаями этот лосслес не нужон?
Именно так. Но редкие исключения бывают.
>он [mp4] более универсален и поддерживаем.
Зависит от оборудования. На пекарнях в поддержки почти никакой разницы. На смартфонах, скорее всего, будет поддерживаться mp4.
>у меня на ts воспроизводится, оригинал всяко лучше обработак
Вот и хорошо.
>>3077678
248 webm 1920x1080 1080p 498k , webm_dash container, vp9@498k, 30fps, video only, 2.09MiB
137 mp4 1920x1080 1080p 1644k , mp4_dash container, avc1.640028@1644k, 30fps, video only, 6.89MiB
Да ютубу вообще похуй -- они на рандом кодируют.
Похоже, что vp9 круче h264 в 3.3 раза, по мнению ютуба.
271 webm 2560x1350 1440p 6663k , webm_dash container, vp9@6663k, 30fps, video only, 114.58MiB
313 webm 3840x2026 2160p 14795k , webm_dash container, vp9@14795k, 30fps, video only, 254.41MiB
571 mp4 5120x2700 2880p 11451k , mp4_dash container, av01.0.16M.08@11451k, 30fps, video only, 196.91MiB
Или вот это: 2880p кодируется только в AV1. h264 заканчивается на 1080p.
Или вот. Внимание на эти огромные скачки в битрейте. Они покроют любой оверхэд от апскейла: а иногда не покрывают
303 webm 1080x1920 1080p60 2506k , webm_dash container, vp9@2506k, 60fps, video only, 34.93MiB
308 webm 1440x2560 1440p60 8603k , webm_dash container, vp9@8603k, 60fps, video only, 119.88MiB
Или вот тут почему ютуб решил урезать видос в 60 кадров?
298 mp4 1280x720 720p60 1001k , mp4_dash container, avc1.4d4020@1001k, 60fps, video only, 81.12MiB
136 mp4 1280x720 720p 2048k , mp4_dash container, avc1.4d401f@2048k, 30fps, video only, 165.96MiB
ffmpeg -y -stream_loop -1 -i Vid.mov -i "01. Depression Nap.mp3" -shortest -map 0:v:0 -map 1:a:0 -vf "scale=-1:720" -quality good -crf 50 -b:v 0 -c:v libvpx-vp9 -c:a libopus -pass 1 -an -f null NUL && ffmpeg -y -stream_loop -1 -i Vid.mov -i "01. Depression Nap.mp3" -shortest -map 0:v:0 -map 1:a:0 -vf "scale=-1:720" -quality good -crf 50 -b:v 0 -c:v libvpx-vp9 -c:a libopus -b:a 256k -pass 2 out.webm
Если отбросить двойной проход, то всё работает как надо. Если делать именно так, то -shortest игнорируется и первый проход длится вечность.
Пиздец. Спасибо, анон. Я эту двупроходную хуйню собирал по кускам и что делает этот флаг даже не задумывался. Пиздец как логично же, что в первый проход аудио игнорируется.
Раз уж тред всё-таки живой то вот какой вопрос. Я в основном монтирую в премьере, а потом уже конвертирую в вебм чтобы залить в дискорд. Какой-то момент из игры например. И вот задумался что наверное надо бы делать вебм на с х264 а чего-то минимально сжатого. Стал использовать pro res 444hq. И конвертация вебм стала дольше, да и вес итогового файла немного увеличился. Значит ли это что можно немного crf убавить для такого же, условно, результата, как был на h264?
При сжатии с потерями из картинки выкидываются малозаметные детали, она становится проще для последующих пережатий, если они будут. Изменение скорости кодирования, скорее всего, связано с переводом формата изображения в 4:2:0. Если у тебя битрейт не на уровне блюреев и разрешение не огроменное, то никакой заметной разницы перекодирование из студийных форматов по сравнению с промежуточным H.264 высокого качества не даст. И вообще, смотри глазами, а не гадай по циферкам.
Вот короче длительность конвертации в вебм:
мов8bit.mov:0:05:52.664996
мов16bit.mov:0:06:05.906732
мп4.mp4:0:03:18.052003
Качество 16бит и 8бит идентичное, потому скриншот не прикладываю. Весят файлы одинаково. Но хэш суммы разные. Мп4 похуже всё-таки пережил конвертацию. А вот скриншоты оригинальных файлов различаются сильно меньше.
Итак. Вебм из такого материала кодируется 3:18, как и из мп4. Второй раз отошёл от компа и было вообще 3:08. Что касается качества, то выглядит немного лучше вебм из мп4 (хотя хуй знает на самом деле) и хуже того, что сделано из pro res.
Потому что он напутал всё в кучу. Для кодирования без потерь надо отдельно скачивать форк x264vfw. x264 значит, что никакого аппаратного ускорения там нет, а vfw (video for windows) – что контейнер avi. Показываю на примере вегаса.
Почему охуевший ютуб с недавного времени все 10+ мин видосы кодирует в dash формате, они там офигели. 6к битрейта h264 для 1080p, на некоторые вообще 3к всего дает. Я думаю чего все видосы мыльные стали последнее время тех кого смотрю, прочекал их все и буквально везде dash.
Хочешь макс. качества и самый низкий размер, то кодируй через процессор, вот что хотели сказать.
Насчет редких видео тут сам высчитываешь средний битрейт в зависимости от фреймрейта и разрешения видео, и есть ли быстрые движения в видео.
Смысл в том, что у меня цепочка такая:
Футаж из OBS через NVENC -> Монтаж в премьере -> пережатие в вебм.
И вот хочется не терять качество из-за промежуточного звена в виде премьера. Это по большей части перфекционизм и повод попердолиться, нежели реальная какая-то задача практически важная. Что касается 4:2:2, то это не мой выбор, а особенность pro res. Потому я и отказался от него.
Собственно тут же даже нельзя сказать что "из вот такого кодека лучше сжимается вебм". Тут просто ффмпег выбирает разный битрейт при том же crf. Хотя, мне показалось, что таки при меньшем битрейте качество у вебм из ut video лучше чем из h264.
Именно в 4:2:2 и 4:4:4 кодировать нет смысла вообще, только если ты изначально не запишешь видос в таком качестве, новых цветов там не появится. Это не говоря о том, что поддержки в инете массово этих почти форматов нет, чтобы поделится, либо для стриминга. Будет как дискорд крашится, либо не воспроизводить.
Также имеет смысл, если в фотошопе сделал картинку, гиф, анимацию и хочешь сохранить цвета, по крайней мере я так думаю. В пост скину как влияет пережатие из оригинального 4:4:4 в 4:2:0. vp9 как-то херово перегоняет в 420.
У тебя футаж через nvenc пишется 4:2:0 8 bit сто пудов. ProRes тебе вообще не нужен, h264 с максимальным битрейтом для 1080п 60000 кбпс хватит, чтобы потерь не было, как минимум для глаза, но тут от настроек кодировщика зависит еще конечно.
Я так и делаю.
Пишу видос>Монтаж в Premier/AfterEffects>а тут уже либо через Voukoder, но там меньше тонких настроек и всякие баги, крашы вылезают, либо h264 60mbps, потому что люблю держать ориг, а потом уже его как хочешь и во что хочешь кодируй.
Так я говорю, что я специально в 4444 и 422 не кодировал и не собирался.
В voukodere не нравится что нет 2pass, хотя в фича реквестах помечена как Done. Ну и контейнер мп4, ёбнутые что ли? Качество выше значительно, как и размер файла.
Попробовал через avisynth + фреймсервер. Какой-то кринж на костылях, фреймсервер ещё и платный. Так и не звёл. Гайд протух кажется.
>В voukodere не нравится что нет 2pass, хотя в фича реквестах помечена как Done
Это да, я так и не понял как его завести.
>Ну и контейнер мп4, ёбнутые что ли? Качество выше значительно, как и размер файла.
Не понял, что ты хотел сказать.
>Попробовал через avisynth + фреймсервер. Какой-то кринж на костылях, фреймсервер ещё и платный. Так и не звёл. Гайд протух кажется.
Да гайд ультрадревний и очень давно протух, тогда даже avisynth plus не было. Видел его обновленную версия, даже она протухла.
>Не понял, что ты хотел сказать.
Ну я просто привык что vp9 = webm.
Меня ещё дрочит что кодируешься такой в формат, который типа "lossless", а из него получается мутная залупа, по сравнению в pro res или конвертацией прямо из премьера в вебм. Ну и где ваш ёбаный лосслесс блядь?
Если ты про voukoder говоришь, так ты в настройках формата, 3 вкладка вроде. Там mp4, webm, mkv есть точно. Vp9 по идее вообще не поддерживает контейнер mp4. Звук на opus ты тоже не поменял, а у тебя aac там оказца.
>Меня ещё дрочит что кодируешься такой в формат, который типа "lossless"
Если ты про пресет, то они кастомные писанные фиг знает кем. Я ими никогда не пользовался, они трогают тонкие настройки. Можешь сам проверить во вкладке видео. Loseless в принципе не нужен.
Это Cruelty Squad. Шизоидный феномен. Очень круто, но не для всех конечно. Визуал сам понимаешь. Вот хороший обзор.
https://youtu.be/pExqMxNEG1E
Ты слишком запариваешься имхо. Ставь x264 crf 14-18 и всё, если определенный размер 2pass vbr высчитываешь для каждого видео битрейт.
Если макс качество реально, то записывай в 4:4:4, если для себя, но смысла как говорил немного, в итоге для дискорда все равно сожмешь до шакалов и 4:2:0.
Там есть и 2pass, и webm.
>Ты слишком запариваешься имхо.
Да. Но я пока этой хернёй страдал чуть больше узнал про ffmpeg и сопутствующие вещи, подрочил питон немножко (кек) и вообще. Короче, развлекался как мог.
>>3086129
>Ставь x264 crf 14-18 и всё
Не, ты что, х264 это сильно хуже vp9, зато быстрее. vp9 с crf35 оптимально. Если не лезет в 8мб, то заливаю на teknik.io, у меня там премиум (сейчас вроде только подписка, а я урвал вовремя). Там, в отличии от облаков всяких, ссылка на видео файл превращается в нормальный embed.
>Да. Но я пока этой хернёй страдал чуть больше узнал про ffmpeg и сопутствующие вещи, подрочил питон немножко (кек) и вообще. Короче, развлекался как мог.
Да я пынемаю, сам в начале такой ерундой занимался, поэтому и говорю. А зачем тебе питон вообще?
>Не, ты что, х264 это сильно хуже vp9, зато быстрее. vp9 с crf35 оптимально.
Вот кстати не всегда, из-за некоторых тонких параметров можно сжать в маленький размер красиво с x264, но vp9 в большинстве случаев лучше конечно, но x265 равно или чуть лучше. Просто последнее время слишком долго кодирует у меня vp9 speed 0 с максимальные параметрами.
Анон, у меня простой вопрос. Я пока что новичек в теме енкодинга и вот провожу некоторые експерименты. Закодировал один и тот же видос с одинаковым присетом и размером выходного файла в mp4 и в mkv. Закинул в прогу, которая рассчитывает качество и она показывает пиздец какую разницу. Помотал немного оба видоса и вроде как на mp4 больше мыла на границах объектов.
Верно ли то что mp4 добавляет мыла? Просто я всегда думал что это такой же контейнер как вебм или матрешка, и разницы между ними нету, кроме поддержки самого контейнера на разных устройствах.
Нет, у тебя какая-то другая настройка всё портит, или ты что-то критичное не указал. Ты должен быть в состоянии вытащить поток видео из одного контейнера и вставить в другой, а потом наоборот, а потом ещё и ещё, и разницы с кодированием напрямую в них не должно быть.
Как я понял, дело не в mkv или mp4, у тебя mkv видео в прогрессивной развертке 480p, а mp4 в черестрочной по англ. интерлейсед 480i. Можешь погуглить чем отличаются, но в кратце интерлейдед это когда 2 когда совмещаются один, особенно понятно когда смотришь видео на плоскостях появляются полосы в видео, в общем разрешение в 2 раза ниже по факту, поэтому такие результаты.
Можно также пример на старых консолях по типу ps2 реальное разрешение игры 320x240p, а выводит она картинку на телек в 480i.
Сегодня весь контент в прогрессивной развертке, поэтому пишут 1080p например, кроме телевизионных передач, записей, трансляций по типу k-pop концертов еще.
Какие параметры курить? Или просто ебануть битрейт в 500к и все?
Потому что сжимает исходя из ожидания куда человек смотрит на видео.
https://ru.wikipedia.org/wiki/Constant_Rate_Factor
>>3086358
>>3086525
Я для кодирования юзаю StaxRip. Уже некоторое время его использую, много функционала и настроек. Мне надо было пережать несколько видосов и я решил попробовать разные присеты. Вчера ебался долго с этим и никак не мог понять в чем разница, решил спросить, вдруг помогут, что и произошло
Чересстрочная развертка хуй знает как включилась, никогда такого раньше небыло. Посмотрел через mediainfo и везде пишет что прогрессивная. Может быть это баг. На днях проверю, так как сейчас нету времени. Всем спасибо
>А зачем тебе питон вообще?
Я только сейчас понял что ты спрашивал зачем мне питон в этом всём занятии. Ну, я написал хуитку, которая по очереди конвертирует все файлы в папке. Можно было бы просто батник замутить, но я питон лучше знаю.
Нет, CRF использует психовизуальную модель. То есть субъективно качество будет выше, хотя объективно нет. Плюс, по моей практике, даже при vbr простые сцены не сжимаются сильно, в то время как cqp и тем более crf очень сильно реагируют на сложность картинки. Запись проводника виндовс и 3д шутера могут разительно отличаться по размеру, в то время как vbr просто стремиться уложиться в целевой битрейт и будет недостаточно экономить на простых сценах и недотрачивать на сложные.
Да. Там отличие где-то в мегабайт.
>>3086922
Да по большей части ничего не значит, ведь битрейт разный. Вот сейчас посмотрим при cbr.
Итак, вот сравнение вебм из разных промежуточных источников с cbr 6M/сек. Прилепил значение битрейта, ибо cbr конечно всё равно варьирует битрейт, просто в очень ограниченном диапазоне. У меня битрейт показывает только если навести мышкой.
Третий скрин это сравнение вебм по совершенно левому референсу. Кроме одной вебм. Поможет понять насколько важен нам вообще каждый параметр. VMAF разработана чтобы заменить собой все остальные метрики и, в целом, мне она действительно кажется наиболее хорошей метрикой. На неё я и буду смотреть.
Учитывая итоговый размер, я остановлюсь на h264 с максимально доступным в премьере битрейтом.
>ProRes тебе вообще не нужен, h264 с максимальным битрейтом для 1080п 60000 кбпс хватит, чтобы потерь не было, как минимум для глаза, но тут от настроек кодировщика зависит еще конечно.
>Я так и делаю.
Теперь и я так делаю.
Вот эта строчка с википедии это оно и есть:
Метод же CRF сжимает похожие кадры неодинаково: это происходит за счёт того, что учитывается движение объектов. Визуально человек различает больше деталей в неподвижных объектах, чем в движущихся, поэтому программа сжатия видео может отбросить больше деталей (увеличить сжатие) на движущихся элементах и сохранить больше (увеличить детализацию) на неподвижных. Субъективно такое видео будет казаться качественней.
Он был прав не в том, что из h264 сжатие лучше по сравнению с lossless, а в том, что при высоком битрейте нет никакой разницы, если это всё равно будет неумолимо сжато во много раз. И это изначально очевидно любому человеку, не одурманенному пердолингом ради пердолинга, ибо хоть сколько-то значимая разница не всегда видна даже при покадровом сравнении с лупой.
Противоречия нет. И crf и cqp гораздо лучше адаптируются под сложность картинки. Я не знаю как под капотом, но запись из OBS (nvenc cqp) может сильно отличаться по весу в зависимости от сложности картинки (игра vs проводник). Я давно очень с этим столкнулся, мне кажется разница была чуть ли не раз в 10, но боюсь напиздеть. Проверил бы, но я РАБотник, дома буду не скоро. Может того же самого можно добиться с огромным диапазоном vbr, не знаю. Но CRF, по сравнению с CQP, ещё и учитывает что человек смотрит на движущиеся предметы в кадре и потому сильнее сжимает статику, чтобы меньше сжимать объекты в фокусе внимания.
Так я с этим и согласился.
>не одурманенному пердолингом ради пердолинга
Алло, этот тред не про шизиков, которые жмут 10 секунд два часа ради гомеопатической прибавки качества? Тогда зачем он нужен? Webm for retards скачал и погнали.
Забавно, что
>что из h264 сжатие лучше по сравнению с lossless
похоже на правду, если сильно захотеть и принять за истину что Ut Vid это lossless (а они утверждают что это так) и что VMAF всему голова и самая правильная метрика.
>разница не всегда видна даже при покадровом сравнении с лупой.
На первой стадии моего шизоисследования разница была очень заметна без лупы. Закинь пнг в папку и полистай. Разница серьёзная и именно из-за того, что
> неумолимо сжато во много раз
Очень шумные текстуры, да ещё и в движении, при сжатии превращаются в мыльные jpeg пятна. А вот prores в этом плане показал себя значительно лучше.
Но эти вебм нельзя было использовать в FFmetrix, ибо оригинал, нужный для референса, сильно длиннее итоговых вебм, а через copy выходит классическая проблема с ключевыми кадрами и первые пара секунд точно вырезанного фрагмента вышли статичной картинкой.
Записанные на второй стадии куски не столь показательны. Было бы разумно загрузить тот же уровень Cruelty Squad и попрыгать там под запись ещё раз, но, в принципе, уже не интересно. Потому что:
>при высоком битрейте нет никакой разницы, если это всё равно будет неумолимо сжато во много раз. И это изначально очевидно любому человеку, не одурманенному пердолингом ради пердолинга, ибо хоть сколько-то значимая разница не всегда видна даже при покадровом сравнении с лупой.
Уже указал с чем здесь не согласен, но вывод то тот же: кодировать в h264 с максимальным битрейтом и не ебать мозги. Это быстро в первичном рендере и при перекодировании в вебм и даёт почти топовый результат по некоторым метрикам в FFmetrix. По совокупности это победитель нашего конкурса! Ураааа! Поздравляю всех с докторской степенью в сжатиенауках. Возможно именно эти знания подарят на путь к бессмертию или, хотя бы, к лекарству от рака.
> Я не знаю как под капотом, но запись из OBS (nvenc cqp) может сильно отличаться по весу в зависимости от сложности картинки (игра vs проводник). Я давно очень с этим столкнулся, мне кажется разница была чуть ли не раз в 10, но боюсь напиздеть.
У меня в OBS на AMD AMF настроен обычный VBR 20000-30000 kbit/s, но при этом при записи какого-нибудь статичного документа в ворде наблюдаю на мониторинге 500-1500 kbit/s.
> Противоречия нет.
>>3086952
> Вот эта строчка с википедии
> отбросить больше деталей (увеличить сжатие) на движущихся элементах и сохранить больше (увеличить детализацию) на неподвижных
>>3086957
> сильнее сжимает статику, чтобы меньше сжимать объекты в фокусе
Да это просто я обосрался, да. Сломанный телефон в моём мозге. Понять, простить.
The human eye perceives more detail in still objects than when they’re in motion. Because of this, a video encoder can apply more compression (drop more detail) when things are moving, and apply less compression (retain more detail) when things are still.
Почему h264_nvenc не умеет работать с crf? В чем подстава?
Подожди, аналог crf есть.
Пример
-c:v h264_nvenc -preset:v p6 -tune:v hq -rc:v vbr -cq:v 19 -b:v 0 -profile:v high
https://superuser.com/questions/1236275/how-can-i-use-crf-encoding-with-nvenc-in-ffmpeg
CQP с -qp тоже можно,но это чуть другое.
Спасибо. Вообще я уже воспользовался CQP, но эти параметры тоже попробую для общего развития.
Сначала с помощью -vf fps снизил частоту кадров, получил 250Мб из 1Гб (с 48 кадров до 30). Затем с -qp 37 пожал материал до 50Мб и теперь вполне можно грузить куда захочу. Единственный минус - долгая обработка фильтром fps. Вот бы было что-нибудь побыстрее.
Скриншот не захотел вставляться.
> Вот эта строчка с википедии это оно и есть
В этой строчке описывается работа параметра qcomp, который присутствует далеко лишь не во всех энкодерах, потому рассказы про crf использует какую-то там модель, кроме модели постоянного уровня качества оставлю цитатерам википедии.
Ты прав, я слишком узколобо воспринял слово "психовизуал", изменение уровня квантования в сценах подходит, независимо от наличия параметров подстройки этих изменений. Мне надо крепко думать, прежде чем строчить ответы.
1. Лучше менять фпс и разрешение перед конвертацией в вебм или во время?
2. Что там за тема с -r. В чём отличие от фильтра fps?
Ну то есть ты поставил 23 и файлы у него жирные. Ну не знаю, может ты качество снизишь? Я правда в 22 пишу и меня устраивает. Поставь 30, зайди в шутан какой-нибудь и резко води камерой. Посмотри что получилось. Двигайся в сторону меньшего размера/большего качества. Так найдёшь оптимальное качество. При 22 там сложно вообще встретить артефакты, есть куда двигаться. Вопрос уровня "я газ вдавил в пол, подходит ли моя машина чтобы не давить людей?"
*Конвертировать а не записывать
> 1. Лучше менять фпс и разрешение перед конвертацией в вебм или во время?
Чё, какая разница
> Что там за тема с -r. В чём отличие от фильтра fps?
Фильтр именно преобразует частоту, а r можно использовать даже без перекодирования видео
>Вот, оказывается, что между """"""лосслесс"""""" кодеками есть разница.
Конечно между ними есть разница? То, что они не теряют информацию, не означает, что они абсолютно идентично её представляют для воспрозведения. Это означает, что между ними можно эту информацию переводить свободно, ничего не теряя. Или ты про какой-то лосслесс, который при перекодировании теряет, но всё равно лосслесс себя называет? Я, признаюсь, не специалист по ним.
Всем уважения.
Кодирую на некропеке с i7 четвертого поколения, соответственно 4\8 и квиксинк. Выиграю ли я время обработки, если "обновлюсь" на зион примерно такой же новизны, но в котором зато будет, например, 14\28 без квиксинка (и чуть ниже частоты)? Т.е. насколько зависит скорость кодирования на процессоре от количества ядер\потоков?
Если важно, я пользуюсь VapourSynth через Hybrid.
Лучше либо прописывать в адресной строке проводника cmd (самый удобный вариант), чтобы консоль открылась сразу в текущей папке, либо в самой консоли переходить в папку с файлами с помощью команды cd (муторно), а не класть файлы рядом с ffmpeg.
> прописывать в адресной строке проводника cmd (самый удобный вариант),
Shift + ПКМ по пустому месту в Проводнике, в Windows 7 переведено как "Открыть окно команд".
>>3092779
Ты находишься не в этой папке. Сам ffmpeg находит потому, что путь к ffmpeg указан в PATH (напиши echo %PATH%, чтобы увидеть).
С результатом все абсолютно нормально, кроме того единственного, что макаба сжирает превью.
Не знаю где тут кринж, это взято из вики, только убрано зацикливание картинки, потому что неправильно общая длительность считалась и не фиксилось. И добавлен рейскейлинг с борама, тут тоже работает.
Да шапку читай там написано, чего я тебе?
Входные файлы. Потом потоки - они не нужны, они были в вики примере чтобы прерывалось через shorten, но shorten некорректно работает, так что просто обозначение потоков осталось, можно стереть. Потом настройки звука - они для вебм, но процесс не крашат, может работают. Потом рескейлинг, тут чето надо чтоб картинка была в джипег, иначе рапидорасит. Потом какой-то костыль из вики, который должен фиксить превью, но не фиксит. И выходной файл. Все просто тут.
Меня все устраивает что только плохо вот - нет превью, это абу свинью подложил. А вегас выдает тяжелые файлы, либо шакалит картинку. Можно что из вегаса вываливается перегнать через борам, но будет вебм тогда, а не мп4. Пизда короче.
Так и подумал, что ты из шапки взял пример, только он протух лет 5 как и годится разве что для общего развития ньюфажек, и написан этот пример именно под вебм, и поэтому у тебя неверно работают команды. Иначе сложно объяснить, зачем пихать ворбис в мп4. Зачем тебе вообще мп4, если ты заливаешь на харкач? Что за борам и нахер он нужен? Кринжанул с тебя.
>протух лет 5
То есть надо перелопатить всю документацию, потом потусоваться пару дней на реддите, потом косяки с макабой учесть и вот тогда, через недельку, можно будет пользоваться вашей этой фигней? Оно тогда не нужно, я лучше в неосилляторы запишусь с такими времязатратами.
>зачем пихать ворбис в мп4
Дак в шапке не написано как в мп4 звук настраивать по качеству. Ну а вдруг сработает. В худшем случае ничего не будет делать. Превью нет явно не от этого, а от загона картинки не в цикл, а просто на вход. Еще х пойми почему картинку пидорасит иногда, даже jpg нужно загонять в пейнт и делать jpg из снова jpg, видимо, что-то меняется.
>Что за борам
Народная прога с интерфейсом вырезать куски из видео делать вебм. Больше она не умеет.
Борам с 19 года не обновляется. Я уже год назад из него не мог копировать некоторые команды потому что они были неактуальны.
А так да, ффмпег это как бы не очень простая штука, кроличья норма, где сдвинувшись чуть глубже попадаешь на новый уровень дополнительных опций, которые гомеопатически что-то меняют. И документация у них довольно ебаная. Хотя, они все такие.
>То есть надо перелопатить всю документацию, потом потусоваться пару дней на реддите, потом косяки с макабой учесть и вот тогда, через недельку, можно будет пользоваться вашей этой фигней?
Не каждый инструмент молоток, чтобы, только взяв в руки, начать им махать. Да и даже молотком можно пользоваться неумело и зарядить себе по пальцам.
Команда применил из официального мана:
ffmpeg -i file.mp4 -vf scale=-1:720 file_720.mp4
В начале конвертации пишет такое:
frame= 151 fps=0.0 q=31.0 size= 0kB time=00:00:02.62 bitrate= 0.1kbits/s dup=15
frame= 263 fps=0.0 q=31.0 size= 0kB time=00:00:04.48 bitrate= 0.1kbits/s dup=15
frame= 410 fps=394 q=31.0 size= 512kB time=00:00:06.96 bitrate= 602.2kbits/s dup=15
Вот эти строки с 0kB так и должны быть или это косяк? При проигрывании выходного файла звук идёт, но изображение стоит на месте в первую секунду-две. В выводе ffprobe видно, что исходник по длительности превышает результат кодирования на 50 мс.
Куда вообще смотреть, чтобы понять, что за хуета и почему эта поебень проёбывает кадры? Как зафиксить?
Этот "телефонный" кодек ты слышишь во всех видео на ютубе, в том числе и музыкальных. И качество даже лучше будет чем обоссанные 128к асс саундклауда, да даже его платного 256 аас. Буквально лучший кодек для сжатия аудио сегодня, до 17к слушать можно.
Stream #0:0 -> #0:0 (h264 (native) -> vp9 (libvpx-vp9))
[Parsed_subtitles_0 @ 0000000000788b40] Shaper: FriBidi 1.0.5 (SIMPLE)
[matroska,webm @ 000000000287a3c0] Could not find codec parameters for stream 3 (Attachment: none): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[matroska,webm @ 000000000287a3c0] Could not find codec parameters for stream 4 (Attachment: none): unknown codec
[Parsed_subtitles_0 @ 0000000000788b40] fontselect: (, 400, 0) -> ArialMT, 0, ArialMT
[Parsed_subtitles_0 @ 0000000000788b40] fontselect: (, 400, 0) -> ArialMT, 0, ArialMT
А это что тогда?
Ну вот на 2678v3 12/24 тестовый видосик FinalFantasyVIIRemake минуту. В сцене нет дикого экшона, но постоянно движение и повороты камеры туда сюда. В итоге, в тяжелых сценах движения 15фпс, средние 20фпс, легкие почти без движения 25фпс. В среднем 17-20 где-то. Проц загружается на 70% в среднем по всем 24 потокам, у меня он без анлока турбобуста и обычного на всё хватает.
14/28 будет быстрее где-то на 10%-15% макс, даже с анлоком, потому что лимит ТДП 145ватт.
Этот же видосик в h264 кодируется в 70фпс, завершился за 55 секунд, считай в 4 раза быстрей h265. Загрузка уже постоянно на 100%.
Параметры:
ffmpeg -i FFVIIR.mp4 -t 1:00 -c:v libx265 -crf 26 -preset slow -c:a aac -b:a 128k outputh265.mp4
encoded 3600 frames in 241.35s (14.92 fps), 4474.59 kb/s, Avg QP:33.87
ffmpeg -i FFVIIR.mp4 -t 1:00 -c:v libx264 -crf 26 -preset slow -c:a aac -b:a 128k outputh264.mp4
Пиздец. Давно начал считать, что работа с командной строкой очень важна и даёт человеку более разностороннее понимание процесса и того, чем этот человек занимается. Только что убедился в этом вновь: юзера хотя бы можно научить понимать, в какой директории он находится.
Я скачал весь стрим весом 19 Гб и вырезаю из него кусочек, а потом этот кусочек пытаюсь замасштабировать (и возникает проблема, описанная в посте).
В плеерах стрим играется и перематывается без каких-либо проблем, так что сомневаюсь, что файл битый.
>>3094823
В итоговом файле изображение стоит на месте первые 2 секунды, а звук идёт, это какая-то косячная хуйня.
>Это ключевые кадры..
Если ты про I-фреймы, то это дело оно должно само разруливать.
Когда-то писал плеер на Qt+ffmpeg, когда делал функцию перемотки, просто отходил назад от места назначения (если в нём не было I-фрейма), пока не находил опорный кадр, после чего спокойно декодировал уже до места, куда происходит перемотка.
> вырезаю из него кусочек
Кажется, команда сверху ничего не вырезает.
Без перекодирования воспроизведение вырезанного куска оригинального видео может начаться только с ключевого кадра (если не брать костыль, существующий в mov/mp4). Почитай обзорные статейки на тему. Если ты всё равно перекодируешь для изменения размера, просто делай это одной командой с указанного времени, тогда поток пойдёт кодироваться с нужного кадра.
>Кажется, команда сверху ничего не вырезает.
Команду для вырезания я не постил. Пользуюсь этой:
ffmpeg -i file_in.mp4 -vcodec copy -acodec copy -ss 01:01:33 -to 01:02:00 -async 1 file_out.mp4
>Без перекодирования воспроизведение вырезанного куска оригинального видео может начаться только с ключевого кадра
Плохо. Я думал, авторы ffmpeg'a эту хуйню предусмотрели. Может как-то можно сказать ему, чтобы он нашёл ближайший ключевой кадр и обеспечил вставку I-фрейма в начало вырезаемого фрагмента, типа как я делал под спойлером >>3095200 ?
>Если ты всё равно перекодируешь для изменения размера, просто делай это одной командой с указанного времени, тогда поток пойдёт кодироваться с нужного кадра.
Попробую. Но перекодирование нужно не всегда. Поэтому хотелось бы иметь возможность обойтись без него.
>В итоговом файле изображение стоит на месте первые 2 секунды, а звук идёт, это какая-то косячная хуйня.
А, тогда всё правильно работает. Ты вырезал кусок видоса без прошлого ключевого кадра, чтобы такого не было надо перекодировать, либо находить прошлый ключевой кадр и с него вырезать.
FFmpeg тут ни при чём. Видео в принципе так устроено, что рисовать картинку на экране имеет смысл только начиная с ключевого кадра. Начнёшь с промежуточных — у тебя будет каша, пока не придёт тот же ключевой и исправит её.
Можно вместо указанного времени прыгнуть на предыдущий или следующий ключевой кадр и обрезать по нему, в интернете решения описаны не один раз.
>Видео в принципе так устроено, что рисовать картинку на экране имеет смысл только начиная с ключевого кадра.
Я в курсе, спасибо. Речь о том, чтобы как раз этот момент разрулить.
>>3095224
>либо находить прошлый ключевой кадр и с него вырезать.
Есть ли способ попросить ffmpeg сделать это за меня прямо в команде вырезания фрагмента?
ffmpeg -ss 01:07:00 -i video.mp4 -ss 00:01:30 -t 00:00:28 -vf scale=-1:720 cut_720.mp4
Алсо, есть ли вариант перекодирования, но с полным сохранением настроек кодирования оригинала? Раз уж оно само i-frame в начало не вставляет, но надо сохранить настройки оригинала, чтобы не проебать качество исходника?
Для примерного сохранения качества (если с изображением ничего не происходит) при повторном сжатии с потерями надо брать даже больший битрейт, чем на первом шаге. Не тривиальные алгоритмы не «синхронизируют» потери, а выкидывают по новой что-то ещё.
>>3095286
> Команду для вырезания я не постил. Пользуюсь этой:
Мы так и думали, что копи, это было очевидно.. В твоём случае нет смысла делать это в 2 команды, когда можно всё сделать 1..
Меня только смущает, что у тебя -сс перед -ай при использовании видеофильтра.. Разве это работает как надо, или как если бы -сс было после -ай?
>Разве это работает как надо, или как если бы -сс было после -ай?
Исходил из этой хуйни https://superuser.com/questions/138331/using-ffmpeg-to-cut-up-video:
Basically you put -ss before AND after the -i, just make sure to leave enough time before where you want to start cutting to have another key frame. Example: If you want to make a 1-minute clip, from 9min0sec to 10min 0sec in Video.mp4, you could do it both quickly and accurately using:
ffmpeg -ss 00:08:00 -i Video.mp4 -ss 00:01:00 -t 00:01:00 -c copy VideoClip.mp4
The first -ss seeks fast to (approximately) 8min0sec, and then the second -ss seeks accurately to 9min0sec, and the -t 00:01:00 takes out a 1min0sec clip.
>Есть ли способ попросить ffmpeg сделать это за меня прямо в команде вырезания фрагмента?
Вот фиг знает, я через potplayer находил, тк там есть перемотка по ключевым кадрам. Да и сам фрагмент у тебя уже по сути с ключевого режется, на сколько секунд нет изображения настолько и надо прибавить. Также говорят, что типо mp4 можно все равно резать правильно без перекодировани, но я хз как.
Вот чел со стакфлоу пишет.
>With the mp4 container it is possible to cut at a non-keyframe without re-encoding using an edit list. In other words, if the closest keyframe before 3s is at 0s then it will copy the video starting at 0s and use an edit list to tell the player to start playing 3 seconds in.
>If you are using the latest ffmpeg from git master it will do this using an edit list when invoked using the command that you provided. If this is not working for you then you are probably either using an older version of ffmpeg, or your player does not support edit lists. Some players will ignore the edit list and always play all of the media in the file from beginning to end.
>If you want to cut precisely starting at a non-keyframe and want it to play starting at the desired point on a player that does not support edit lists, or want to ensure that the cut portion is not actually in the output file (for example if it contains confidential information), then you can do that by re-encoding so that there will be a keyframe precisely at the desired start time. Re-encoding is the default if you do not specify copy.
Попробуй еще помимо этого команду в конце добавлять -avoid_negative_ts make_zero, когда используешь -c copy, может поможет.
>>3095286
Просто ставь пресет какой-нибудь veryfast или slower и crf 18, либо такой битрейт как у оригинала, будет близко.
>>3095334
Второй вариант внутри параметров кодирования безопаснее и будет правильнее, но ему придется проанализировать всё до врмени нужного отрезка. А ss в начале сразу режет с этого момента, что кстати может также быть причиной почему у тебя обрезается начала, либо наоборот появляется. Но ты же не будешь например часовой стрим анализировать, чтобы там с 40 минуты отрезать.
Этот мусор не умеет скачивать в нормальном качестве из-за ограничений Ютуба
Ставь это и всё https://github.com/jely2002/youtube-dl-gui
Сэйвфром очень ограничен в плане выбора качеств, только дефолтные. Еще там баг иногда бывает с неправильными отметками времени видео.
>>3096188
Да не, мне гуй не всрался, его еще долже запускать и юзать. Я говорю именно ты смотрик видосик, хочешь скачать и под ним выбираешь галочками качество со звуком нужным. Я бы сам запилил, если бы разбирался в программировании. Не знаю почему никто не может нормальный гуи форк сделать, либо расширение. Только был 4kdownloader из юзабельных и вот этот новый вышел недавно, который ты сикнул.
Каких качеств тебе не хватает?
У меня вышло делать с превью. Правда не помню как, я уже удалил эту хуйню ффмпег.
Ну вот конкретно с музыкальной картинкой вроде дело было что обязательно надо в поток картинку пускать, как в примере в шапке, а не просто на вход. Из-за этого пердолинг с длительностью не избежать, но превью выходит зато на дваче. Удалил все потому что пошли косяки со звуком, кодеки разные пробовал и качество, все равно звук с артефактами на высоких, прям слышло.
Хуесосный пиздоглазый дваждыобоссаный всемивыебанный зумерогнойный пориджедебил, ты? Да, ты.
Дилемма при ремуксе bluray mkv
Аноним (Microsoft Windows 10: Firefox based)
03/01/22 Пнд 21:47:58
№448
Качаю только оригинальные копии bluray-дисков. Чужие ремуксы весят в полтора-два раза меньше, что просто не может быть без ебаного пережатия, а зачастую о пережатии написано прямо в шапке раздачи.
Смотреть оригинальные ts-видеофайлы невозможно, во всех плеерах они вызывают проблемы, поэтому приходится ремуксировать в mkv.
Здесь то и возникает главная проблема - дилемма. Если это многосерийное аниме, то там по несколько серий на диске. MovieObject.bdmv тоже один на все эти серии. И если в программу-ремуксер загнать MovieObject.bdmv, то он из допустим 4 видеофайлов с диска выдаст 1 mkv. Но субтитры делятся не по дискам, а по сериям, поэтому в видеофайле с 4-мя сериями нельзя будет использовать все субтитры, можно будет только к первой серии.
Очевидное решение - импортировать в программу ts-файлы, а не MovieObject.bdmv. Но тогда теряются главы, хранящиеся в том злосчастном файле. А мне нужны главы.
Как быть? Что делать, чтобы из исходного bluray получить раздельные видеофайлы с сохранением глав?
> Качаю только оригинальные копии bluray-дисков. Чужие ремуксы весят в полтора-два раза меньше, что просто не может быть без ебаного пережатия, а зачастую о пережатии написано прямо в шапке раздачи.
Надо качать bdremux, там никогда ничего не сжато, в отличии bdrip. Создать remux можно одним кликом с помощью mkvtoolnix
Я не окр-шизик, чтобы перед просмотром каждого фильма сравнивать remux и rip, а потом на протяжении всего фильма трястись и постоянно думать "а нет ли здесь разницы", "а не накосячил ли автор"? Намного проще и удобнее использовать то, что по определению не может быть испорчено. И главы, нужные мне, есть не в каждом рипе.
Есть новые аниме, которые улучшать не нужно.
Всё-равно это тёмные дебри васянства, в которых может спокойно существовать очень много гадостей, не хочу туда лезть. Что задумал автор bd-диска - то и должно быть. Остальное может испортить просмотр своими подводными камнями.
> Что задумал автор bd-диска - то и должно быть.
То-то эту мазню все пытаются спасти дополнительными говнофильтрами поверх.
https://slow.pics/c/0GyP0yZi
https://slow.pics/c/hGj4a7WU
К этому тайтлу не так много раздач, другие весят намного меньше, что говорит о вероятной потере качества. Сжатие ведь не резиновое, даже если remux оригинального диска сжат плохо и очень раздут. К тому же в других релизах могут быть свои проблемы.
Короче буду скачивать оригинальный remux вместе с rip'ом по-приличнее. Из remux'а возьму видео и оригинальное аудио, из рипа возьму главы, субтитры и дубляж. Потом удалю исходники. Буду ебаным пердоликом-конпелятором от мира медиа. Лишь бы диска хватило.
С говном мамонта придётся попердолиться, но да хуй с ним. Пошарюсь по раздачам, выберу релиз с апскейлом и отзывами. Буду надеяться, что раз уж у релизера хватило прямоты рук сделать нормальный апскейл - хватит и на рабочие временные метки. Если нормальный апскейл сделали за бугром - скачаю иностранный рип и в добавок русский рип ради сабов.
Есть видео, и есть два файла с одинаковыми сабами в срт и асс формате. Мне нужно было добавить их в видео, без разницы какой.
Я использовал синтаксис ffmpeg -i input.mp4 -i input.srt -map 0:0 -map 0:1 -map 1:0 -c:s mov_text output.mp4 и у меня все получилось, за исключением того что сабы начали дублироваться, одна строка повторялась два раза.
Потом сделал ffmpeg -i infile.mp4 -i infile.srt -c copy -c:s mov_text outfile.mp4 результат тот же самый.
Пробывал через -vf ass, результат ошибки на пикрейлтид, что я упускаю подскажите пожалуйста?
Ты бы хоть бы нормальный вовыод скинул, всё скрылл. Скриншот дублирования сабов не прислал, люди не экстрасенсы.
https://trac.ffmpeg.org/wiki/HowToBurnSubtitlesIntoVideo
Ты бля ебанутый? Ремукс это исходные, никак не сжатые данные с блюрей диска. Эту всю хуйню можна как минимум в 2, а то и в 4 раза сжать без видимых потерь качества, что и делают рипперы. Или ты думаешь что сделаешь лучше за великие пиндосские умы человечества? И да, на рутрекере в основном очень хуево сжимают, на няшке есть релизы где норм сжимают, там просто по особенному эта вся хуйня делается и не одним человеком, и не на одном компе рендерится зачастую, а сразу по сетке на нескольких компах.
>Можешь подробнее объяснить?
Есть gui программа, она раз в неделю крашится. Есть небольшой велосипед на autoit, он отслеживает этот краш и делает дамп памяти, вот я хочу ещё добавить запись экрана за несколько секунд до краша, чтобы проще было понять где проблема
Алсо:
1. Отдельно склеил 5 беззвучных файлов - пик 2 сверху; 4 файла со звуком - нет ошибок, потом к беззвучным приделал нормальные - пик 2 снизу.
2. Склеил 1 беззвучный файл + 3 нормальных - пик 3. НО: звука нет во всем output, а не только в первой части.
3. Склеил отдельно нормальные файлы без ошибок, потом склеил беззвучный и норм склейку - пик 4, этих ошибок столько, что нельзя прокрутить до их начала. Output проигрывается до конца беззвучной части и зависает.
> Пользоваться нормальным редактором по типу premiere
Да я тут уже разобрался с тем, что мне нужно.
> а не пердолится и фиксить таймкоды, которые ломаются
Эти фрагменты рассчитаны на склеивание, программа, которая обычно это делает, похоже именно ффмпегом пользуется.
>>3100599
> пустить тишину
Чего?
> чтобы ему было к чему приклеивать звуковые дороги
Нужно оставить все как есть, только склеить. Когда я склеил все с самого начала, вроде все получилось как надо, на вид и слух проигрывается нормально. Но эти цветные ошибки меня напрягают.
ПЕРЕКАТ
ПЕРЕКАТ
ПЕРЕКАТ
ПЕРЕКАТ
ПЕРЕКАТ
https://2ch.hk/s/res/3101682.html
https://2ch.hk/s/res/3101682.html
https://2ch.hk/s/res/3101682.html
https://2ch.hk/s/res/3101682.html
https://2ch.hk/s/res/3101682.html
https://2ch.hk/s/res/3101682.html