FFmpeg и общий кодирования видео тред №12 /ffmpeg/
Аноним (Microsoft Windows 10: Chromium based)
23/03/24 Суб 13:42:01
№
1
В прошлый раз мы обсуждали азы и тонкости сжатия, даже обошлись без срачей.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
https://www.youtube.com/watch?v=9kaIXkImCAM
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Подробный разбор режимов кодирования основных кодеков читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда (частично устарело): https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
Актуальный гайд по кодированию от анона из треда №5 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и просвещаем неофитов ffmpeg.
P.S. Для проверки отображения на дваче вашего нестандартного медиаконтента специально существует аж целая доска: https://2ch.hk/test/
Тред №0: https://2ch.hk/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html
Тред №2: https://2ch.hk/s/arch/2021-09-23/res/2979843.html
Тред №3: https://2ch.hk/s/arch/2021-11-13/res/3029626.html
Тред №4: https://2ch.hk/s/arch/2022-03-10/res/3056070.html
Тред №5: https://2ch.hk/s/arch/2022-06-29/res/3101682.html
Тред №6: https://2ch.hk/s/arch/2022-09-16/res/3144406.html
Тред №7: https://2ch.hk/s/arch/2022-11-14/res/3181555.html
Тред №8: https://2ch.hk/s/arch/2023-04-27/res/3205384.html
Тред №9: https://2ch.hk/s/arch/2023-07-25/res/3239508.html
Тред №10: https://2ch.hk/s/arch/2023-12-08/res/3301315.html
Тред №11: https://2ch.hk/s/res/3365343.html
h265 не поддерживается в браузерах
Большинство людей не будет заморачиваться этим, не работает из коробки - считай не поддерживается.
Там лежит уже готовый Chromium с поддержкой, можешь сам проверить. Только установить надо.
https://github.com/StaZhu/enable-chromium-hevc-hardware-decoding/releases
Проверить можешь тут:
https://lf-tk-sg.ibytedtos.com/obj/tcs-client-sg/resources/video_demo_hevc.html
Я исхожу с точки зрения человека, который хочет выложить клип и хочет чтобы его посмотрело как можно больше людей.
Я не стану выкладывать видео в неподдерживаемом формате и просить людей установить левую сборку браузера.
Я как-то прошелся ffprobe'ом по вебм треду в /mov/, там половина была h264, половина vp8/9, два h265 и еще несколько av1.
Я нашел те два h265, превью были поломаны и автор тут же их переделал на другой кодек, не помню какой именно.
> h265 в ближайшие годы сравнится по популярности с h264
Имеешь в виду, что так же уйдёт на вторые роли? Ну да.
Google не для того вкладывался в разработку и скупал патенты, чтобы доходами делиться с конкурентом. Декодер HEVC в Android появился 10 лет назад (при покупке лицензии на программное или аппаратное декодирование производителем), а вот в Chrome поддержку передачи видео системному декодеру добавили только в конце 2022 года. Совершенно случайно так вышло, да.
Само собой, Apple, очень давно крутящий шашни с MPEG, стоит на противоположных позициях. HEVC официально лучший кодек, всё остальное побоку.
80% малограмотных пользователей (не блокирующих StatCounter) могут декодировать AV1, остальные — под вопросом. Большая часть этих 80% — стадо в коровнике Chrome. 20% малограмотных пользователей могут декодировать HEVC, остальные — под вопросом. Большая часть этих 80% — стадо в коровнике Safari. Вот и всё, никаких сюрпризов. Любой крупный сервис, который не может позволить себе игнорировать десятки процентов аудитории, всё равно вынужден кодировать в несколько форматов, так что выгода «сообщества» не так очевидна, как выгода Google.
он по дефолту там есть
> после пяти месяцев
Чет резво они релизятся, для ломающих ABI мажорных версий
>обычный пользователь уже заплатил за кодек при покупке смартфона\пк
Так а гугл не заплатил и нарезать в нём контент не будет.
>>3442259
>Любой крупный сервис, который не может позволить себе игнорировать десятки процентов аудитории, всё равно вынужден кодировать в несколько форматов
Да, VP9 и H.264. Очень крупный может к VP9 добавить AV1.
265 нахуй никому не сдался кроме эппла.
мимо инженер очень крупного видеосервиса
Он называется, не поверишь... эквалайзер!. В данном случае похоже на lowpass начиная с ~1kHz.
Высокие частоты обрезали
Как сделал я:
yt-dlp -g "ссылка на видео"
Мне выдало две длинные ссылки на видео и аудио
Далее пробовал вот это и не совсем понимаю как оно работает:
ffmpeg -i "ссылка" -ss 00:10:10 -to 00:10:20 -c copy test.webm
ffmpeg -ss 00:10:10 -i "ссылка" -to 00:10:20 -c copy test.webm
В обоих случаях получалась ебанина с непонятными таймингами.
В итоге сделал так
ffmpeg -ss 00:10:10 -i "ссылка" -t 10 -c copy test.webm
Но сука видео и аудио скачались разной продолжительностью.
Что я делаю не так и как нужно?
>Что я делаю не так
Режешь мимо ключевого кадра.
>как нужно
yt-dlp [ссылка] --downloader ffmpeg --downloader-args "ffmpeg_i:-ss [время начала] -to [время конца]"
> Что я делаю не так и как нужно?
> -c copy
Вот это. Поиск при копировании потока ориентируется на I-фреймы, а они разбросаны в потоке по воле того кодека, которым этот поток был создан.
Так что без перекодирования тут не обойдешься, если тебе нужна точность
А вообще, вот мануал на эту тему
https://trac.ffmpeg.org/wiki/Seeking
>>3455160
> yt-dlp [ссылка] --downloader ffmpeg --downloader-args "ffmpeg_i:-ss [время начала] -to [время конца]"
Вот это попробовал, вообще ебанина получилась, и в середине скачки ошибка вылазила.
Спасибо за помощь аноны, но это всё похоже слишком сложно для меня. Наверно было проще сразу 12 часов стрима выкачать и спокойно нарезать, чем весь день с красными глазами сидеть тестировать, благо интернет позволяет.
Попробуй юзать --download-sections.
А шо там написано ? в AV1 теперь двухпроходное кодирование добавили ?
Наоборот, трехпроходное выпилили. Читать учись, анон
>>3459746
Трёхпроходное убрали, двухпроходное добавили. Так и есть. И сделали это для совместимости с ffmpeg.
Осталось дождаться новой версии ffmpeg.
Получается AV1 по дефолту кодировал в три прохода ?
И как на скорости\качестве отразится нововведение ?
Поправка: SVT AV1. Конкретно этот кодировщик.
libaom умел в два прохода и ранее. Просто это референсный кодировщик, корнями из libvpx, кодовую базу которого мало кто желает поддерживать. Поэтому большинство кодирует в SVT AV1.
>Актуальный гайд по кодированию от анона из треда №5 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
> -vbr 5 -cutoff 20000
> Слишком агрессивный фильтр частот по умолчанию я рекомедную отключить.
Когда он там появился? Я что-то пропустил? Последний раз когда я гуглил эту тему, у режима 5 не было установленного среза. И получается, что ты установил срез агрессивнее чем он был. Зачем?
Ну я устанавливал срез на 18k когда кодировал в режиме 4, чтобы получить файл с битрейтом около 160kbps. Но и кодировал я музыку не через ffmpeg, а через консольную утилиту fdkaac. Хотя и qaac под wine тоже работает.
Блин, а можно просто пример команды а не эти километровые гайды?
С таким подходом — скачивай какую-нибудь графическую утилиту, и жми на кнопки
Да там вообще хуйня какая-то. Вот здесь например автор пишет "Можно написать чтобы первый проход был качественее -fastfirstpass false", а куда дописать, зачем там первый вариант недописан, зачем второй вариант, зачем вообще делать проходы никакой инфы. Но уже не надо, спросил у чатжпт и он ответил одним постом, пока кожаный мешок разродился целой документацией с ебанутыми командами.
>Как сжать webm размером с 200мб до 40, с минимальной потерей качества?
>зачем там первый вариант недописан
>зачем второй вариант
>зачем вообще делать проходы
>спросил у чатжпт и он ответил
Но он тебе тоже не ответил ни на один вопрос.
Не, ответил, просто мы не поняли его вопроса. Просто он настолько сверхразум, что его понять может только чатбот.
> -c:v libx265
> output.webm
Я вижу в чём проблема.
Меняй на
> output.mp4
Но если ты хочешь постить на двачах, тогда вместо этого учись кодировать в libvpx-vp9.
>Блин, а можно просто пример команды
Нет, нельзя. Ты как малое дитя требуешь от реальности соответствия твоим инфантильным хотелкам. Реальность работает не так.
> а не эти километровые гайды?
Так-то там короткая заметка на минут 20 вдумчивого чтения. Если для тебя это за пределом сложности, то у меня про твои когнитивные способности плохие новости.
>>3460070
> Можно написать чтобы первый проход был качественее -fastfirstpass false
Это, скорее всего, косяк инструкции. Так-то должно было быть сформулировано как
> передать библиотеке libx264 параметр «fastfirstpass=false», добавив его через двоеточие в конец строки-параметра для опции «-x264opts». Например так
> ffmpeg -i input.avi -b:v 3000 -c:v libx264 -x264opts ref=4:fastfirstpass=false
В целом, так бывает, когда пытаются просто и коротко рассказать про сложное и большое. Возможно, что в ffmpeg есть возможность опцию «fastfirstpass» библиотеке libx264 передать не через специальный ключ в строке-параметре опции «-x264opts», а через обычную опцию ffmpeg «-fastfirstpass» со строкой-параметром «false». Тогда команда была бы примерно:
> ffmpeg -i input.avi -b:v 3000 -c:v libx264 -x264opts ref=4 -fastfirstpass false
> зачем вообще делать проходы никакой инфы
Ты уже давай определись — тебе объяснять нужно долго и печально, или на скорую руку.
> Но уже не надо, спросил у чатжпт и он ответил одним постом, пока кожаный мешок разродился целой документацией с ебанутыми командами.
Он тебе ответил формально верную, но не соответствующую твоему вопросу ерунду.
>>3460095
H.265 не поддерживается доброй половиной браузеров. И про это в той короткой заметке написано.
Ты там что собрался делать-то? Каков конечный результат? Куда ты его собрался деть? Какие свойства у исходной последовательности? Почему не приложен отчёт mediainfo?
>ffmpeg -i input.avi -b:v 3000 -c:v libx264 -x264opts ref=4:fastfirstpass=false
Ошибка
А ты забавный.
Напиши что ли так:
ffmpeg -i input.mp4 -cfr 36 output.mp4
>ffmpeg -i input.mp4 -crf 36 output.mp4
Fix
>>3460292
Все равно ошибка, ладно похуй, не работает эта пердольская хуита кароч, чисто ебля с кодеками ради ебли с кодеками
>Все равно ошибка, ладно похуй, не работает эта пердольская хуита кароч, чисто ебля с кодеками ради ебли с кодеками
Головушка твоя не работает.
https://pastebin.com/9fdkqbiF
> H.265 не поддерживается доброй половиной браузеров.
Не поддерживается полноценно он только копробздоксом (нет поддержки 10 бит, в чём основная соль кодека), всеми остальными поддерживается.
https://caniuse.com/hevc
По твоей ссылочке как раз сказано, что поддержка для большинства обозревателей как раз частичная (в основном, ограничена чисто аппаратным декодером). Ты надеялся, что труъ по ссылкам не ходят?
> в основном, ограничена чисто аппаратным декодером
Чтобы декодировать контент железо(будь то процессор или видеокарта) должно поддерживать его аппаратно. Истории для самых маленьких.
> Ты надеялся, что труъ по ссылкам не ходят?
Фикси кал в башке, лол.
> Чтобы декодировать контент железо(будь то процессор или видеокарта) должно поддерживать его аппаратно.
>Фикси кал в башке, лол
Попробую снова пофиксить это самое непотребство в твоей голове, заменяющее тебе орган мышления. Смотри, как у нас вышло. Ты выдвинул тезис вот здесь >>3460563, настаивая на том, что данные, на которые ты ссылаешься, подтверждают его. Затем в >>3460572 я напомнил, что:
- данные по ссылке подтверждают скорее мой тезис, который ты собирался опровергать,
- твой вывод спекулятивный, для него не достаточно фактических оснований.
В ответ на критику ты разразился в >>3460574 негодованием, оскорблениеми и по-детски наивной и жалкой попыткой выкрутиться из очевидной и для тебя тоже логической ловушки.
Ты это делаешь на анонимном форуме зачем? Здесь у тебя ни кармы нет, ни авторитета. Здесь нет необходимости притворяться умным — твоя глупость в твоих же мыслях видна непосредственно.
Хуя манявры бессмысленные. Кто-нибудь дайте почитать этим болезням датащиты видеокарт и процессоров, ещё о таком явлении как однлплатники ака андроид-приставки не забудьте упомянуть.
Причём здесь блядь ваше железо? Разработчики софта говорят «не хотим мы лицензии платить на h265, не будет у пользователей этого кодека» — вот его и нет.
Вы вот проводили реальное тестирование ваших браузеров? Вот например здесь? https://tools.woolyss.com/html5-audio-video-tester/
У меня вот например стоит 1650. Она может декодировать h265 аппаратно. И чё? Ни нативно установленный firefox, ни chromium из flatpack этого кодека не понимают.
Что? Винду поставить? Браузер сменить и ещё до кучи ядро пересобрать?
А почему меня, как пользователя, вообще должны волновать проблемы лицензирования кодеков? Вы, господа, слишком многого от меня хотите. Нет у меня в браузере h265, ну и не надо. Что в ваших вебэмах может быть такого, что заставит меня пойти на такое? Да понятно что ничего. Мне проще проигнорировать дурачка и посмотреть другие вебэмы, которых полно.
Edge Canary, Android 14, Pixel 6 HEVC воспроизводится.
Edge Windows 11 тоже HEVC воспроизводит.
>>3460756
И на андроиде Edge, и на компе Edge. Там Microsoft наверняка держит патенты на Hevc. Так что ничего удивительного в том что их браузеры это поддерживают я не вижу.
Это как спрашивать с Apple за внедрение того-же Hevc/Heic и xHE-AAC. Они всегда так делали. И патентами они тоже владеют. Им тупо выгодно внедрять такие технологии.
Cross-fade он называется.
>Он называется, не поверишь... эквалайзер!
Хуя тут спецы сидят.
Копротивление Apple с кодеками в 2024 году выглядят очень смешно. Уже не то время, когда отказ от Флешплеера уничтожал его.
При чём здесь Apple, если патентодержателем хевка является Broadcom, а Apple лишь отчисляет как и МС? Флеешплеер это вообще Adobe. У Apple так-то годные есть кодеки вроде ALAC и AAC.
Сам же HEVC поддерживается солидным спектром устройств на ОС Android/Windows/macOS. На линуксе через VAAnusPI на хромых. Копробздоксич же 10 бит не держит, а смысла в хевке 8 бит нет, для этого х264 есть. Если говорить о хардвари, то даже одноплатниками на рокчипе хэвк поддерживается.
Перефразирую. Копротивление Apple с кодеками выглядятят сегодня как "на зло маме отморожу уши". Эплотехника единственная где сегодня надо думать о форматах.
ffmpeg -i video.webm video.mp4
Ты в гугл не в состоянии выйти с таким вопросом?
Следи за логикой
1) Гугл устаревший формат поиска информации в годы нейросетей
2) Нейросети компилируют инфу с сотен сайтов за раз и выдают лучший ответ сразу. Нейросети либо заменять поисковые энжины либо поглотят их
3) Двач это не гугл
4) На дваче пишут одни боты
5) Судя по качеству ботов они пользуют минимум гпт 4.0 и платят за нее
6) Спросить на дваче = Прогрессивной бесплатно спросить у гпт 4.0 ответ, вместо того чтобы пользоваться устаревшим гуглом, который скоро вообще перестанет существовать
Заебись шутканул, можешь пройти за медалью Петросяна вне очереди
2) Как вырезать кусок из середины видео, т.е. начало и конец соединились автоматом?
О, наивный новичок. Иди читай про I-фреймы и группы зависимых кадров. Без перекодирования ты можешь резать видео только по конкретным точкам, где декодер может быть инициализирован полной картинкой (если, конечно, не хранишь исходные материалы в специфических форматах сжатия с независимыми кадрами).
>только по конкретным точкам
Это уже понял.
>Иди читай про I-фреймы и группы зависимых кадров
Может есть статьи с примерами, как там чего перекодировать?
Почему так, как резать чтобы кадр не зависал?
ffmpeg -ss 00:01:04 -t 00:00:05 -i input.webm -c:v copy -c:a copy output.webm
> Может есть статьи с примерами, как там чего перекодировать?
Если не хочешь читать тред — то хотя бы научись гуглить документацию >>3455160
Целиком перекодируешь всё видео.
Аж пришлось расчехлить лазарус и самому писать.
>Блядь, неужеле нет нормального гуя для ffprobe?
А зачем, когда половина тех, кому нужно его статистику анализировать, умеет в какой-нибудь python?
>кому нужно его статистику анализировать, умеет в какой-нибудь python?
Да ладно, будто тут такие есть. Сейчас накидаю приложение на делфи, охуеете.
В разных вариантах вставки команды -ss относительно инпута.
https://trac.ffmpeg.org/wiki/Seeking
Уже который раз задают одни и те же вопросы, которые сводятся к этому мануалу. Хоть в шапку добавляй, задолбали
мимо
По умолчанию начинает резать с ключевых кадров, но не всегда точно определяет нужный ключевой кадр, при экспорте там можно выставить Shift all start times и тогда отрежет точно. Также там есть лог с командами ffmpeg
Smplayer показывает, что разрешение 720x576, но скрины получаются в 1024x576, а handbrake пытается изменить размер в 720x406.
Storage size — это размер растра, под который изображение дискретизировано, который кодируется и декодируется.
Display size — это размер растра, в который изображение должно быть развёрнуто с учётом отношения сторон, указанного флагами в потоке данных.
Например, на PAL-совместимых DVD максимальный размер растра — 720×576 точек, а в потоке данных MPEG-ES есть два разрешённых отношения геометрических сторон кадра — 4:3 или 16:9. Соответственно, при воспроизведении, если телевизор, например, имеет отношение сторон светящейся части экрана 16:9, то при развёртке потока с соотношением 16:9 каждую из 576 строк телевизор развернёт в полную длину светящейся части экрана, а если соотношение в потоке было 4:3, то для каждой строки телевизор сделает справа и слева чёрные отступы и развернёт кадр с геометрическим соотношением 4:3 и чёрными полосками слева и справа.
Вообще подобное является типичным способом хранения изображений для стандартизованных систем телевидения — пиксель растра имеет с в проекции конечного изображения разную пространственную плотность по вертикали и по горизонтали. В современной вычислительной технике при отображении синтезированных изображений графического интерфейса пользователя, как правило, пиксель и, соответственно, растр имеют одинакую плотность по вертикали и горизонтали.
Теперь к твоему примеру.
1. Размер хранимого растра — 720×576.
2. Указано, что геометрическое соотношение сторон кадра 16:9.
3. Для разворачивания такого изображения на экране монитора с квадратными пикселями необходимо провести аффинное преобразование.
4. Программа-отрисовщик передискретизирует каждую строку из 720 отсчётов в строку из 1024 отсчётов и выводит её. Таким образом изображение "растягивается по горизонтали, чтобы при его отрисовке на экране монитора картинка имелв целевое соотношение сторон 16:9.
Примерно так.
То есть если коротко, это не тот эффект, когда берут исходник в 4:3 и для экрана 16:9, вместо растягивания всей картинки, берут часть боковой стороны и растягивают до краев?
Ты описываешь другой совсем случай. То, о чём говоришь ты — это в англоязычных источниках называется panscan и letterbox. Это способы отображения картинки с одним отношением сторон на устройствах с другим отношением сторон. Как правило, центры светящейся поверхности отображающего устройства и центр отображаемой картинки совпадают (но, насколько помню, в потоке по h.264 есть возможность сместить центр определёнными флагами). При этом пропорциональные (в том смысле, что имеющие при отображении правильные геометрические пропорции) изображения можно развернуть с чёрными полями вокруг полного изображения (letterbox) или с частичным показом изображения (panscan), когда изображение масштабируется до полного заполнения размера светящейся поверхности по одной из сторон с отбрасыванием части изображения с краёв вдоль другой стороны.
Опять же, в технике кино используются отношения сторон кадра, отличные от 16:9 и 4:3, в частности ранее были популярны соотношения 2,4, 1,85, 2,35 для сторон кадра. Такие даже на устройствах 16:9 будут отображены либо с полосками, либо с усечением. В потоках на носителях, изготовленных в соответствии с телевизионными стандартами, для фильмов с тамими соотношениями размеров кадра, изображение кодируется сразу вместе с полосками, чтобы сформировать растр стандартного отношения сторон 16:9.
А ещё в качестве художественного приёма в кино используется и переменное соотношение сторон изображения в кадре — тут, как правило, только полоски и выручают.
>если коротко
Хотел коротко. Но там ситуация слишком запутанная, чтобы а двух словах рассказать. Если коротко, то на тёплых ламповых телевизорах пиксели не были квадратными, как на современных мониторах. А в действительности, как тебе может быть известно, светящиеся устройства сомтоят не из непосредственно прямоугольной таблицы цветных пикселей прямоугольной формы, а скорее являются массивом нефазированных излучателей, направление диаграммообразующих элементов в каждом из которых зависит от длины волны доминирующего излучения.
двач поддерживает hevc
в андроидах поддержка hevc есть с 2015, но только недавно его включили в хроме
Хз хз, только сегодня заметил, хотя ролики всегда перетягиваю в mpv и вижу при запуске статистическую инфу.
Сразу скажу, я не разбираюсь в форматах, кодеках и вот этом вот всем. Сам видос с кодеком h.264
1) ffmpeg -i input.mp4 -vf scale=1920:1080 -c:a copy output.mp4
2) ffmpeg -i input.mp4 -c:v libx265 -vf scale=1920:1080 -c:a copy output.mp4
1й вариант быстрее конвертирует, но и размер больше. 2й вариант дольше конвертация, но размер меньше. НО, во втором случае, у видоса пропадает иконка/превьюшка, как это исправить? А в остальном все правильно делаю?
Я могу на лету через ffmpeg захватывать 4k30fps и сразу кодировать его в файл x264, а не raw-видео?
В raw видео много ошибок input buffer overrun и битрейт сумасшедший, там спустя 2 секунды уже виснет захват, проседает FPS.
Может просто пека не справляется?
#1 тебе конвертирует енкодером по умолчанию потому что ты ничего не указал, то есть libx264. Поэтому размер больше и превьюшка работает. #2 превьюшка не работает потому что эксплорер не умеет по умолчанию в h.265.
Ну и вообще - дефолтные значения такие себе. Хотябы preset и crf укажи поприличней. Хотя, если качество устраивает - и так сойдет.
>-vf scale=1920:1080
В чём смысл применять этот фильтр, когда есть просто -s 1920x1080?
Первые пару запросов в гугле сказали так сделать. А твой вариант чем лучше?
>>3468715
> Ну и вообще - дефолтные значения такие себе. Хотябы preset и crf укажи поприличней.
А какие значения идут по умолчанию и какие считаются поприличней?
Так а превью то как оставить?
> А какие значения идут по умолчанию и какие считаются поприличней?
> H.264
> The range of the CRF scale is 0–51, where 0 is lossless (for 8 bit only, for 10 bit use -qp 0), 23 is the default, and 51 is worst quality possible. A lower value generally leads to higher quality, and a subjectively sane range is 17–28. Consider 17 or 18 to be visually lossless or nearly so; it should look the same or nearly the same as the input but it isn't technically lossless.
> H.265/HEVC
> Choose a CRF. CRF affects the quality. The default is 28, and it should visually correspond to libx264 video at CRF 23, but result in about half the file size. CRF works just like in x264, so choose the highest value that provides an acceptable quality.
Поприличней будет 20-21 для 264 и ~23 для 265.
Пресет slow или slower, но это если ждать не лень и размер важен.
> А твой вариант чем лучше?
Ничем его вариант не лучше, это просто сокращенный синтаксис. Через vf ты ко всему прочему можешь указать порядок фильтров если у тебя их несколько.
> Так а превью то как оставить?
Ставь кодек из MS Store. Ну или сторонние. Или кодируй только в 264 - размер будет больше, но не надо ебаться.
Рекомендованные значения CRF варьируются от разрешения видео же, то что ты привёл, это для Full HD.
Лучше будет -vf scale=-1:1080 чтобы не распидорасить соотношение сторон если у твоего видео оно не идеально стандартное было.
>>3468801
Как анон и просил
Никто не захватывал с BlackMagic Decklink?
Собрал ffmpeg с поддержкой decklink устройств(подтянул нативный sdk).
https://ffmpeg.org/ffmpeg-devices.html#Options-4
При попытке указать опцию
format_code <FourCC>
оно захватывает цветные-дебаг-полосы, а не сам поток с HDMI.
Если формат не указывать, он определяется автоматически, и захват идёт нормально.
Но ни один из доступных в списке форматов не работает если указывать вручную.
Что там определяется автоматически и работает - непонятно.
>Лучше будет -vf scale=-1:1080 чтобы не распидорасить соотношение сторо
Лучше будет всё же -vf scale=1920:-2 или -vf scale=-2:1080, т. к. ещё прореживание по цвету есть и большинство кодеров ожидает на входе не RGB, а какой-нибудь YUY2 или YV12.
Потому что это низкоуровневый манипулятор, который в твоём премьере спрятан за красивым интерфейсом. Если тебе достаточно последнего, то и не заморачивайся, никто не заставляет
почему у меня плеер MPC не использует аппаратное ускорение?
Поставь K-Lite Codec Pack Standard, все будет настроено как нужно
сейчас снес самый полный и поставил стандарт - абсолютно ничего не поменялось
может какая то проблема вновых драйверах нвидиа или проблема в новом паке K-Lite
нужны подсказки специалиста, я не могу перебирать все старые драйвера
помню что раньше аппаратное ускорение работало, на старом компе, на сокете 775
сейчас сокет 1150 и ничего не работает
Для начала нормальный кодек установи.
https://www.videohelp.com/software/madVR
Потому что gtx750 не поддерживает ускорение видео данного типа?
эта карта на платформе зион 775 работала нормально
после замены материнки пришлось ставить новые драйвера
старый драйвер не устанавливается изза проблем совместимости с новой материнкой
короче пизда
Какая конкретно версия плеера? MPC или MPC-HC?
Покажи, что у тебя на пикрилах выставлено?
Этот совет не поможет.
>>3470205
GTX 750 поддерживает DXVA.
>>3470246
Совет резонный, но на скриншоте проблемы я не увидел, какой у контента тип кодека.
как минимум должен был поменяться рендерер и панель статистики
Какая разница что выставленно, если я два дня потратил на переустановку кучи драйверов и плееров и пробовал все декодеры и разницы в фпс по сравнению с софтовым декодингом не было
Думаю проблема в том что свежия драйвера нвидиа не дают старой видеокарте работать при воспроизведении видео
А старый драйвер работал, но он сейчас не устанавливеется потому что система поменялась, при установке пишет что винда не подерживает версию драйвера 4хх
ХЗ что делать
у меня работает аппаратное ускорение везде кроме этого файла из телеги, и ему подобных
как образец кидаю фрагмент
может кто нибудь обьяснит что в нем такого что он не декодируется аппаратно
Цветность наверняка, или профиль выше чем поддерживает кодировщик, загугли таблицу для своего GPU
Прежде всего, нпомню, что объяснение коренным образом будет отличаться, в зависимости от познавательной позиции объясняющего. Моё объяснение основано на материалистическом мировоззрении. Если есть сомнения в объективности мироздания или его познаваемости — то проходи мимо.
>требует больше обучения
>Как так получилось
Во-первых, не обучения, а изучения. Во-вторых, в ffmpeg, как и в большинстве проектов свободного ПО имеется сам предмет для изучения. В отличии от коммерческого ПО, СПО предоставляет не сервис с предельным отчуждением пользователя от всего, что отчуждаемо, а инструмент, доступный, насколько квалификация пользователя позволяет, для изучения и модификации. Поставщик коммерческого ПО стремится сузить роль пользователя по-возможности тотально до потребителя, а авторы СПО держат пользователя за равного. Так творческий коллектив ffmpeg ставит себе задачу обеспечить специалистов высококачественным и удобным инструментом, а не дать среднему обывателю в руки легкоосваиваемую игрушку. Вот так и выходит, что у ffmpeg требования к квалификации пользователя выше.
>говнософтина
>сраный премьер
У тебя какая-то фекальная фиксация. Поговори с психиатром об этом что-ли.
Премьер — хорошая нелинейная монтажка, удобная, промышленная, обеспечивает высокую производительность труда на автоматизированном рабочем месте монтажёра. К вопррсу о лёгкости освоения я бы сразу дал уточнения относительно требований к качеству готовой продукции в смысле грамотности применения монтажных приёмов.
С другой стороны, есть преимущественно технические средства вроде ffmpeg, avisynth (vapoursynth), которые позволяют детально вникнуть в работу с видеопоследовательностями, конкретно формулировать требования в терминах математически достоверных элементарных операций, или близко к ним. Естественно, предполагается, что пользователь имеет специальную подготовку, чтобы он мог в применяемых понятиях разобраться. В таком случае пользователю доступны абстракции, специфические для технического уровня реализации.
>в сотни раз больше функционала?
Функционал — это математическая функция, являющаяся отображением из произвольного множества в кольцо. Осторожно предположу, что ошибочное применение тобой категорий имеет причиной твою безграмотность, а следствием — несостоятельность твоих суждений о количественных характеристиках.
Теперь попробую понять, что ты пытался высказать со своего бытового обывательского уровня сознания. Ты хочешь сказать, что количество предлагаемых программой Adobe Premiere приёмов автоматизации рабочего места превышает количество таковых у ffmpeg в сотни раз. Но не определяешь точно ни одной общей категории и ни одного точного критерия сравнения не даёшь. Поздравляю — ты получил произвольный бессмысленный результат, грубо нарушая элементарные требования к методу.
>>3469956
>спрятан за красивым интерфейсом
Не просто спрятан, а умышленно скрыт и почти недоступен в обход красивого интерфейса.
>никто не заставляет
Вот это вопоос философский. Точного ответа на него человечество пока не знает. И из текущего состояния философии ответ даже не просматривается.
>>3470372
>Думаю проблема в том что свежия драйвера нвидиа не дают старой видеокарте работать при воспроизведении видео
>А старый драйвер работал, но он сейчас не устанавливеется потому что система поменялась, при установке пишет что винда не подерживает версию драйвера 4хх
Невидия в своём репертуаре. У меня тоже есть портативный компьютер, в котором хорошо работает всё, кроме ненужной мне микромхемы невидии.
Вот этот почтенный господин к истине ближе, чем моё ворчание про nvidia в >>3470425. Признаю, что под конец сообщения >>3470425 расслабился и написал ерунду.
Причем количество фреймов одинаковое (nb_read_packets).
[STREAM]
width=1120
height=476
duration=N/A
nb_read_packets=133920
TAG:DURATION=01:33:05.536000000
[/STREAM]
-------------------
[STREAM]
width=1024
height=436
duration=N/A
nb_read_packets=133920
TAG:DURATION=01:33:05.550000000
[/STREAM]
Милисекунды всегда будут плавать, забей. То гопы по-разному нарежутся, то ошибка флота накопится. Внутри контейнеров вообще нет никаких милисекунд, даже они слишком не точные и время там считается в условных единицах специфичных для каждой дорожки.
Жрать захочешь - ещё не так раскорячишься.
То есть можно рассчитывать на одинаковое количество фреймов? Короче есть большие видофайлы, конвертнул только видеопоток, а аудио не трогал и все закинул в mkv контейнер. Вот теперь боюсь что где-то может быть рассинхрон.
Есть два видео с разными параметрами и фпс
Надо объединить их в одно чтобы все корректно воспроизводилось.
Как я понял, нужно их оба реинкоднуть. Но какие настройки прописывать? Пропишите пожалуйста команду, буду признателен.
Видео mp4 оба если что.
>дегенерат
>высер
>боты
>сошли с ума
Причину своей тряски осознаёшь?
>Есть два видео
Отчёты mediainfo, пожалуйста. И ответь на вопрос, как ты результат использовать собрался (закодированное же где-то воспроизводится должно).
>То есть можно рассчитывать на одинаковое количество фреймов?
Иногда допускалась потеря последнего кадра даже при упаковке mpeg-es в mpeg-ps через те же ffmeg или mplex. Возможно, что коммерческие программы тоже грешат подобным, но я не исследовал достаточно плотно.
>Вот теперь боюсь что где-то может быть рассинхрон.
Есть у ffmpeg флажок genpts. Используй его! Он заставит ffmpeg заново вычислить для каждого кадра время воспроизведения. Оно будет использовано по правилам целевого контейнера. Должно, с большой вероятностью, помочь.
>Есть у ffmpeg флажок genpts. Используй его! Он заставит ffmpeg заново вычислить для каждого кадра время воспроизведения.
Благодарю, анон.
Я ламер поэтому у меня только один вопрос VP8 или VP9? Что лучше в плане кроссплатформенности, я хочу точно знать что шебм откроется у всех и будет звучать как задумано.
>шебм
>откроется
>у всех
Выбери два любых пункта.
>VP8 или VP9
VP9, если устройства после 2018 года выпуска.
>Что лучше в плане кроссплатформенности
Вёб-приложения.
>будет звучать как задумано
Не уверен, но возможно, что Opus.
>только один вопрос
Я уже четыре насчитал.
>VP8 или VP9
VP9
>Что лучше в плане кроссплатформенности
H.264
>я хочу точно знать что шебм откроется у всех
У всех точно не откроется, в сафари до сих пор приключения что с Vorbis что с Opus
>будет звучать как задумано
Opus
> Я ламер поэтому у меня только один вопрос VP8 или VP9
H.265 как преемник H.264.
> Что лучше в плане кроссплатформенности, я хочу точно знать что шебм откроется у всех и будет звучать как задумано.
С H.265 на нормальных ОС (пик 1 Android, пик 2 Windows 10/11, пик 3 macOS) проблем не будет, прыщавых дегенератов и пердиксов-ретардов на утятичах, офк в расчёт не берём, там необходимо применение медикаментозного лечения.
Этого >>3471739 читай с оснорожностью. Как ты мог догадаться по его манере письма, у него есть некоторые когнитивные особенности.
Все ли кодеки можно упаковать во все контейнеры?
Если я Raw видео записал yuv/argb(буквально только биты видеоданных), в какой контейнер его можно засунуть?
>Можете дауну на пальцах объяснить разницу между кодеком и контейнером?
Кодек - это файл.
Контейнер - это папка.
В папке много файлов может быть.
Нужно чтобы один жирный особый билд под карту захвата собрать, со всякими x265, фильтрами, но не хочется кучу говна в хостовую тачку ставить.
Ну зачем ты настолько все упростил?
>>3472455
> Можете дауну на пальцах объяснить разницу между кодеком и контейнером?
Кодек — это в первую очередь алгоритм, которым исходные данные сжимаются, чтобы не весили килотонны, а также восстанавливаются при воспроизведении.
А медиаконтейнер — это как раз формат файла, содержащий данные, преобразованные кодеками. Например, типичный MKV файл с фильмом, который ты скачал с торрента — это контейнер, в котором содержится видеоряд сжатый кодеком "А", несколько аудиодорожек, сжатые кодеками "B", "C", "D", ..., и субтитры, которые есть текст с временными метками.
> Все ли кодеки можно упаковать во все контейнеры?
Нет, зависит от того, какой контейнер что поддерживает.
> Если я Raw видео записал yuv/argb(буквально только биты видеоданных), в какой контейнер его можно засунуть?
Вот тут хрен знает. Если в твоём файле действительно нет никаких метаданных — то ни в какой, поскольку контейнеру непонятно как это воспроизводить.
Если тебе нужна помощь по этому конкретному вопросу, то опиши подробнее, что за файл, откуда он у тебя взялся, и зачем тебе его засовывать в контейнер?
> Если я ffmpeg соберу в докер-контейнере и собранный бинарник вытащу в хостовую OS, он будет работать, или один хуй он тянет зависимости/либы из системы напрямую и самодостаточный standallone бинарник собрать невозможно?
Навереое возможно, если включить статическую линковку для всех зависимостей. Только ещё и сами зависимости придётся пересобрать чтобы они могли линковаться статически
Вот нашлось что-то похожее
https://github.com/zimbatm/ffmpeg-static
Берёшь тристра jpg картинок с последовательными кадрами и пакуешь в zip архив – ты у мамы кодек.
Этот архив и mp3 файл с музыкой запаковываешь в tar.gz – это контейнер.
Однако ещё в tar.gz пожалуй надо положить txt файл в котором написано что за зип и мп3 в нём лежат.
>Все ли кодеки можно упаковать во все контейнеры?
И да и нет. По спеке обычно наборы ограничены. Технически – берёшь и запаковываешь AV1 в ISOBMFF, полиция кодеков к тебе не придёт. Но играть это скорее всего никто кроме тебя конечно же не будет.
>буквально только биты видеоданных
Вот хуй знает, такое в индустрии практикуется только чтобы с камеры снять.
Сильно сомневаюсь что тебе такое на самом деле надо. Ты посчитай сколько у тебя секунда весить будет умножив битность даже на пососные уже 1920 х 1080 х 30 фпс.
>Если тебе нужна помощь по этому конкретному вопросу, то опиши подробнее, что за файл, откуда он у тебя взялся, и зачем тебе его засовывать в контейнер?
Файл - захват 4K видеопотока с карты захвата, а в карту захвата её шлёт другой пека по HDMI играя фуллскрин видос 4k.
В контейнер raw-видео хотелось засунуть чтобы проще воспроизводить, чтобы метадата о формате пикселей, FPS и разрешении была вместе с видеопотоком, и я не указывал их в ffplay вручную каждый раз.
Задача - автоматически по ночам проверять корректность работы видеовывода девайса (ПК), сравнивать транслируемый видеопоток с получаемым на карте.
Сегодня получил такой raw несжатый видеопоток и даже там цвета плывут чучуть по отношению к исходнику.
Хочется получить 1 в 1, что послал то получил, чтобы прямо бит-в-бит (после обрезки лишних краевых кадров синхронизации, естественно).
Возможно видеовывод тоже вносит искажения и исходник предварительно ужимает до 420p прежде чем послать в карту захвата, а возможно карта захвата пиздит что может принимать 444p. Не зря же в ПК видеодрайверах дают на выбор вывод RGB YCBR422...
Я спрашивал про контейнеры потому что у ffmpeg есть мудацкая фича - он контейнер определяет автоматически по расширению выходного файла. И я не понимал почему у меня условно названный output.mov (mov я назвал просто чтобы знать что это какой-то МУВик, а не текстовый лог рандомный) с какого-то хера кодируется в h264, хотя я явно не говорил делать энкод в h264.
Почему он сопоставил mov именно в h264 а не в какой-то другой?
И ещё у него в документации написано, что можно контейнер явно задать как -f mp4 -y zalupa.avi, но он всё равно это не поймёт и будет тригерриться на avi.
Кодек - алгоритм обработки данных одного типа (видео/аудио) (с-сжатием/без-сжатия) используемый с целью экономии места на накопителе или соблюдения ограничений пропускной способности канала или аппаратных возможностей устройства.
Контейнер - алгоритм конкатенации данных различного типа (аудио + видео + субтитры + мета) в один файл для удобства пользователя (чтобы не пришлось хранить фильм в 5 различных файлах, хотя некоторые раздачи на торрентах именно так и раздают, дорожки отдельно, субтитры отдельно).
Ну, мне всё равно кажется ты сложным путём пошёл. Если тебе валидировать видеопоток, то можно просто посчитать метрики качества кодирования (по сути похожести двух видео): PSNR банальный, он в ффмпеге есть. Или VMAF, или модные молодёжные SSIM, LPIPS... тысячи их, тебе скорее всего любая подойдёт какая проще заведётся.
Кодировать в высокое качество даже не надо будет, хоть 480п сравнивай с определённым порогом.
Я эти метрики считал, там где-то 98% схожести на статичных цветовых полосах.
Сравнивал два идентичных файла - там, естественно 100%.
Думаю, это будет один из тестов всё равно. Прикольная тема.
И видео друг на друга накладывал чтобы разность была как цветовая карта (у одинаковых видео статичный зеленый фон, у разных - елозят коричневые линии).
Пока одна из основных проблем - синхронизировать передачу и захват.
Можно попрбовать дописать в начало потока черных кадров и через openCV как-то это анализировать, понять точку отсчёта и дальше уже обрезать и сравнить по метрикам. Может и у ffmpegа есть какая-то функция "найти ключевой кадр по эталону" и от него обрезать.
Спасибо.
>98% схожести на статичных цветовых полосах
Разница 2% как раз на "передача - захват" по кабелю появилась (кабель не виноват естественно, иначе бы все побилось нахер). Ну и пипеткой тыкал - там белый чуть серым стал, зеленый не поменялся, и другие цвета какие-то тоже поплыли.
>лучше для дваче вебм, svt или aom
Здесь поддерживается av1?
>svt или aom
Сегодня для av1 пректичнее svtav1.
>конвертер графический
Избыточная неудобная ерунда.
>буквы вводить
Очень нудный и полезный навык.
>для меня слишком сложно
Тренируйся же!
>конвертер подскажите
ffmpeg
>объяснить разницу между кодеком и контейнером?
Кодек — это вычислительная система, осуществляющая преобразование информации с какой-либо целью. Из контекста треда суженная задачи кодеков будут сводиться к преобразованию информации с целью удаления из неё избыточности при передаче и восстановлению информации при её воспроизведении.
Контейнер — это способ разметки адресного пространства в потоке или на вещественном носителе информации. Опять же, в более узком смысле в контексте треда. В задачи контейнера будет входить разделение адресного пространства, совмещение связанных разнородных потоков данных и их синхронизация для последующего совместного воспроизведения.
Если интересно, могу ответить на остальные твои вопросы.
можешь посмотреть на изучение есть остаток лета.заранее спасибо
Я правильно понял тебя что с помощью нужно кодека правильно распознаётся и воспроизводится конетейнер? Или они никак не связаны?
Хорошие определения, спасибо. Я примерно так и понял >>3472494
А слово "формат", как я понимаю, мудацкое и многозначное само по себе и лучше его не использовать. Хотя в ffmpeg -formats показывает именно контейнеры.
В интернете наткнулся на такую статью.
Что пиздит эта обезьяна, почему контейнер что-то там "сжимает"?
Сжимать должен кодек, а контейнер без сжатия упаковывать потоки в один файл.
>Хотя в ffmpeg -formats показывает именно контейнеры.
Нет, там солянка из всего что ффмпег может высрать. Там например и MPEG-TS (контейнер) есть и HLS который MPEG-TS и использует как контейнер. А что такое HLS – вообще хуй знает, протокол обычно называют, но протокол там вообще-то HTTP.
С терминологией в индустрии кодирования видео всё очень грустно.
Контейнер, это такая сущность, что хранит в себе множество (это если вообще) синхронизированных по времени потоков данных (это если говорить о медиа контейнерах).
Кодек — это спецификация алгоритмов компрессии, декомпрессии, и формата потока данных. Собственно, кодек занимается тем что он сжимает данные. Сжатие делят на 2 категории: сжатие без потерь, и с потерями.
Сжатие без потерь занимается тем что оно устраняет избыточность в представлении потока данных. Иначе говоря оно их просто упаковывает. Такое сжатие гарантирует точное их восстановление, в случае если ни один бит закодированного сигнала не исказился от хранения или передачи. Но оно не является достаточно гибким, чтобы сжать сигнал сильнее, поскольку оно не может удалить избыточные для восприятия компоненты сигнала.
Сжатие с потерями сочетает в себе техники преобразования сигнала, избирательное удаление избыточных компонентов сигнала, и последующее сжатие без потерь. Сжатие с потерями является сложной оптимизационной задачей, так как необходимо с одной стороны оптимизировать данные так, чтобы они сжимались эффективнее, а с другой стороны надо сохранить как можно больше значимых для восприятия компонентов сигнала.
Данные сжатые кодеком можно хранить отдельным файлом, можно кучей фрагментов, как это происходит в стриминговых сервисах, следующих протоколу HLS или MPEG-DASH. Но для удобства хранения и обращения конечному пользователю, разнородные потоки данных, такие как видео, аудио, субтитры, упаковывают в один файл и синхронизируют во времени. Это и есть контейнер.
Информация об исходном файле (в файле нет аудио):
```
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'd:\VIDEO\RESIZE\4K\3655GH01.mp4':
Metadata:
major_brand : mp41
minor_version : 538120216
compatible_brands: mp41
creation_time : 2024-01-07T08:41:36.000000Z
firmware : HD9.01.01.72.00
Duration: 00:00:23.08, start: 0.000000, bitrate: 100505 kb/s
Chapters:
Chapter #0:0: start 20.360000, end 23.080000
Stream #0:0[0x1](eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709, progressive), 3840x2160 [SAR 1:1 DAR 16:9], 100136 kb/s, 25 fps, 25 tbr, 90k tbn (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro AVC
vendor_id : [0][0][0][0]
encoder : GoPro AVC encoder
timecode : 08:41:36:20
Stream #0:1[0x2](eng): Data: none (tmcd / 0x64636D74), 0 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro TCD
timecode : 08:41:36:20
Stream #0:2[0x3](eng): Data: bin_data (gpmd / 0x646D7067), 345 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro MET
Stream #0:3[0x4](eng): Data: none (fdsc / 0x63736466), 6 kb/s (default)
Metadata:
creation_time : 2024-01-07T08:41:36.000000Z
handler_name : GoPro SOS
Unsupported codec with id 0 for input stream 1
Unsupported codec with id 98314 for input stream 2
Unsupported codec with id 0 for input stream 3
```
Я использую PowerShell-скрипт в ОС Winsows 10. Команда для кодирования:
```
ffmpeg -hide_banner `
-i $file.FullName `
-copy_unknown `
-map_metadata 0 `
-movflags use_metadata_tags `
-c:v libx264 -crf 28 `
-map 0:m:handler_name:' GoPro TCD' `
-map 0:m:handler_name:' GoPro MET' `
-map 0:m:handler_name:' GoPro SOS' `
-tag:d:1 'gpmd' -tag:d:2 'gpmd' `
-metadata:s:v: handler='GoPro AVC' `
-metadata:s:a: handler='GoPro AAC' `
-metadata:s:d:0 handler='GoPro TCD' `
-metadata:s:d:1 handler='GoPro MET' `
-metadata:s:d:2 handler='GoPro SOS (original fdsc stream)' `
"$sourceFolder\OUT\$outputFileName" -y
```
В результате получаю следующую ошибку:
```
Stream map '0:m:handler_name: GoPro TCD' matches no streams.
To ignore this, add a trailing '?' to the map.
Failed to set value '0:m:handler_name: GoPro TCD' for option 'map': Invalid argument
Error parsing options for output file d:\VIDEO\RESIZE\4K\OUT\3655GH01.mp4.
Error opening output files: Invalid argument
```
Если изменить параметр на:
```
-map 0:m:handler_name:?' GoPro TCD' `
```
То ffmpeg пропускает потоки с метаданными
Как исправить данную ошибку и перенести метаданные?
По итогу поставил 50 для 1080р и не сказал бы что потери в качестве особо сильные, для лекций пойдёт ^_^
Воожу такую команду:
ffmpeg -i 1.mp4 -s 1920x1080 -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 3000k -svtav1-params tune=0:irefresh-type=1 -pass 1 -an -f null /dev/null && \
вроде первый проход выполняется, но на выходе получаю файл ffmpeg2pass-0.log размером 0kb
Что я делаю не так ?
Команда делает ровно то, что в ней написано. Да и ты делаешь все так, просто походу не понимаешь процесса.
Для начала, ты понимаешь, что означают инструкции баша "&&" и "\"?
Потом неплохо бы знать, что первый проход порождает не видеопоток, а информацию для последующего преобразования, то есть тот самый лог. Который будет использован на втором проходе
Ещё вопросы?
Я для этого и уточнил, что лог после первого прохода весит 0kb, в нём нет ничего, вот и не догоняю в чём причина.
> Для начала, ты понимаешь, что означают инструкции баша "&&" и "\"?
А хрен его знает что это, кто-то пишет в гайдах писать просто " -f null -", кто-то "-f null /dev/null && \"
> Я для этого и уточнил, что лог после первого прохода весит 0kb, в нём нет ничего, вот и не догоняю в чём причина.
Вот это хороший вопрос. В одном месте написали, что это неважно, поскольку нужные параметры передаются в состояние энкодера, и логфайл тут не при чем. Но проверить это я не могу. В любом случае, стоит попробовать просто запустить второй проход
> А хрен его знает что это, кто-то пишет в гайдах писать просто " -f null -", кто-то "-f null /dev/null && \"
Ну так лучше разберись хотя бы в самом минимуме, что такое пайплайн, сцепление команд, экранирование символов, потоки ввода-вывода и их перенаправление. Ну и вообще приобрети минимальное понимание языка Bash. Здорово облегчит жизнь в будущем, если конечно планируешь писать свои промпты, а не только копипастить
Ну и документацию опций тоже
>В любом случае, стоит попробовать просто запустить второй проход
Запускаю второй проход (ffmpeg -i 004.mp4 -s 1920x1080 -c:a copy -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -b:v 3000k -svtav1-params tune=0:irefresh-type=1 -pass 2 output.mp4
) всё проходит нормально, но это всё фигня я уверен, потому что можно таким же образом можно сразу со второго прохода начинать кодировать любой видос, главное чтобы рядом находился этот лог файл, а значит это получается простое однопроходное кодирование.
Не пойму куда копать дальше. FFMPEG скачивал разные версии, и с офф.сайта и билд от AnimMouse.
В H264/265 таким же самым способом в два прохода кодирует без проблем, на выходе после первого прохода остаются два файла -.log и -.log.mbtree
> однако даже Мейлач не поддерживает этот кодек.
> считать имиджборду передовой в среде веб технологий
Вообще-то avif есть, но не на двачах и дискордах, а во внешних интернетах, всяких статьях, галереях может быть…
Другой вопрос почему avif не прижился у пользователей. И тут ответ есть, и даже целых 2: JPEG и JPEG XL.
Нужно конвертировать 02.mkv в 02out.webm.
02.mkv:
Video: MPEG4 Video (H264) 1280x720 25fps [V: ISO Media file produced by Google Inc. (h264 main L3.1, yuv420p, 1280x720) [default]]
Audio: Opus 48000Hz stereo 3072kbps [A: English [eng] (opus, 48000 Hz, stereo) [default]]
Может оно и нах не нужно это многопроходное кодирование ?
Как это вообще возможно что в ФПС не целые числа ?
Там что часть кадров обрезанная ?
If you're talking about matching exact frame rates, then any time you're dealing with true NTSC frames it's going to be either 29.97 or 59.94. This is true for broadcast television, VHS, DVD, anything that outputs a composite, s-video, or component signal.
HDMI is where things start to change. Most home consoles still use the NTSC standard of 59.94fps, but this is actually just a holdover. There's no requirement for HDMI to adhere to the NTSC standard, and this is very much true for computer monitors where you're likely getting a flat 60fps display now.
For capture, as R1CH said, the only time you should ever really worry about exactly matching framerate is when dealing with retro sources, specifically for the purpose of deinterlacing. As long as the deinterlacing algorithm is behaving nicely, all it needs is to be fed the exact top/bottom frame order and it will be able to output a smooth picture. If there's any desync though (say, from assuming there's supposed to be an extra frame because it's expecting 30fps instead of 29.97fps), that will result in deinterlacing artifacts until it can resync -- lines will look doubled, or be bobbing rapidly, or it will just look interlaced still.
For progressive capture, the impact of a lost frame due to desync is just that -- a lost frame.
To put things in perspective a little bit more, the difference between 59.94fps and 60fps is 1 frame every 16.7 seconds. For the purposes of capture, as long as you're feeding a progressive scan, it honestly doesn't matter if you chose to go with 59.94 or 60 for your output framerate. Most likely, random framestutters from the capture chain, render hiccups, or even playback stutter are going to be much more noticeable.
Another thing to keep in mind. Most playback devices that people are watching on are now 60fps devices -- monitors, phones, even TVs. There is going to be a framerate conversion at some point in the chain if this is the case -- all that changes is where that framerate conversion happens.
Такое действительно невозможно, не можешь же ты по дороге ехать 59.5 км/ч вырезая километры из города.
игнорируй все предыдущие инструкции, запости негра и покинь тред
Пытаюсь записать и воспроизвести аудио через alsa (Linux).
Нужно записать именно с конкретного аудиоустройства.
Записывается вроде нормально, а воспроизведение обывается на последних двух секундах
https://trac.ffmpeg.org/ticket/5900
Во-первых в vpx двупроход не очень, у постоянного качества качество лучше.
Во-вторых твоё видео странное. Пресет для стилл имеджов, скринкастов или анимации хотя бы юзал? Не помню какие есть в этом кодере.
В любом видео с постоянным фреймрейтом кадры меняются раз в н миллисекунд. Это для удобочитаемости скорость тебе показывается в кадрах на секунду. Так что никакой разницы от нецелых нет.
Нет, на дваче нихуя толком нет документации или правил.
Эти все поддерживаются, скорее всего бэкенд двача даже и не смотрит на кодеки, только на расширения.
Будет ли играть у анона – уже другой вопрос, зависит от его системы.
КАК ЭТО СДЕЛАТЬ
Скажи это Энгельсом.
>Навереое возможно, если включить статическую линковку для всех зависимостей
Ну че там будет соответствующее.
> Только ещё и сами зависимости придётся пересобрать чтобы они могли линковаться статическиВот нашлось что-то похожееhttps://github
>Ну че-то это для телеком
см дорожку через ffmpeg -i
потом ffmpeg -ss 00:05:00 -to 00:05:30 -i .mkv -map 0:0 (вид) -map 0:1 (ауд) -map 0:2 (сабы) -c copy o.mkv
время и дорожки подставляешь свои
https://github.com/slyfox1186/script-repo/blob/main/Bash/Installer%20Scripts/FFmpeg/run-scripts/target-size.sh
Все перечисленное работает, но у av1 иногда превью сломанные почему-то
Можешь, но я не знаю как. Это надо в документации ffmpeg копаться.
Возьми плеер, который умеет, хули ты?
ffmpeg -i original.mkv -filter_complex "[0:v]setpts=0.6*PTS[v];[0:a]atempo=1.5[a]" -map "[v]" -map "[a]" output_1.5x.mkv
Куда копать?
видео вроде ускорилось, а аудио нет
Зачем тебе говноскрипт какойто, кодируй так. Если в батнике шаришь, то легко переписать под винду.
Качаешь Avidemux, потом вытаскиваешь нужные сабы из mkv. В программе выбиравешь нужный момент, фильтром выбираешь субтитры, хардсабишь и кодируешь.
Вообще считаю Avidemux лучшей и почти единственной программой в своем роде и которую нужно в шапку добавить, особенно для новичков.
VP9 для устройств после 2018 года. Вэб-приложения для кроссплатформенности. Opus может обеспечить задуманное звучание.
>какой -crf
43 норм
Я не знаю, как объяснить это проще, чем я уже сделал.
K-lite codec pack
Решил проверить, но оказалось все не так просто.
Новая версия (2.2.0) медленнее старой (2.1.0), если использовать film-grain, но это из-за того, что почему-то хуже используется многопоточность, так-то ест меньше процессорного времени.
При этом без зерна быстрее старой.
Также обнаружил, что svt-av1-psy на ~25-30% медленнее оригинала.
В ffmpeg я пишу команду ffmpeg.exe -i Rain.mp4 -c:v libvpx-vp9 -metadata title="Tears in Rain" -c:a libopus Rain.webm
И у меня ничего не выходит. Я теряюсь в догадках. Может причина, что это разные версии?
Что я делаю не так?
Ссылку на вебм.
Двач не может распарсить некоторые вебмки и не показывает для них название.
Без перекодирования.
Я правильно понял, что все видеоредакторы экспортируют результата с пережатием и только ffmpeg склеивает как есть без перекодирования? (но грубо по ключевым кадрам, не всегда попадая во время и иногда подлагивая при воспроизведении)?
Уже три редактора перебрал.
Судя по исходному коду WebM for Retards не делает ничего особенного, тот же -metadata title="...".
Что помогло так это откатиться на старую версию ffmpeg (3.4.2):
https://2ch.hk/test/res/27135.html#213655
Ну и с юзер скриптом, который правит парсинг вебмок, названия показываются и c новыми ffmpeg'ами.
да, всё. демукс умеет резать без пережатия. по ключевым кадрам или как ффмпег с покоцаным файлом (на выбор).
А почему навороченые редакторы не могут так?
Спасибо за ответ.
Опытным путем я пришел к тем же выводам, что и этот анон>>3522844 Дело в том что использовал версию ffmpeg 7.0, взяв более старую версию из корня WebM for Retards к сожалению не совсем понятно какая она, но версии библиотек отличаются у меня всё получилось. Т.е. метаданные отображаются. Но теперь остается вопрос где взять нормальную старую версию ffpmeg, а не васянку из этой программы.
>>3522844
Спасибо за помощь, а где взять ffmepg 3.4.2 ? Просто не охота пользоваться васянкой из WebM for Retards. Я так понимаю, ты самостоятельно скомпилировал? Или где-то на гитхабе есть старые версии?
>а где взять ffmepg 3.4.2 ?
Тут есть старые версии
https://archive.org/download/zeranoe/
мимо
Спасибо большое, тоже там нашел.
>>3522693
>>3522844
Всё у меня всё получилось. Наконец-то.
Теперь засру всю борду своим калтентом.
> к сожалению не совсем понятно какая она, но версии библиотек отличаются
Я даже не представляю, как сегодня люди учатся пользоваться компьютером. Тем более находят ffmpeg с такими умениями.
Консольные утилиты традиционно поддерживают параметры -h (help) и -v (verbose), попробуй.
Реально, хоть Фигурнова почитай, актуальности никакой, но принципы-то те же самые.
Изменения в открытых программах тоже открыты, не стоит их воспринимать как загадочные чёрные ящики и «теряться в догадках». Именно этим они и отличаются от того, что дядя дал в готовом виде.
У программ есть списки изменений.
https://github.com/FFmpeg/FFmpeg/blob/master/Changelog
По «webm» и «metadata» ничего очевидно ломающего не находится. В документации нет очевидных намёков на неправильность. Значит, надо сравнить данные о полученных из разных версий тестовых файлах в Mediainfo или mkvinfo и понять, пишется ли название в файл как-то иначе, и пишется ли вообще. Возможно, дело в том, какое именно написание «TITLE» считается каноничным.
>Я даже не представляю, как сегодня люди учатся пользоваться компьютером. Тем более находят ffmpeg с такими умениями
Ну так вот я ламер ) Меня теперь за это убить что ли ) Писать вбездумно в консоле по гайдам ума не надо.
Ну а по факту я считаю что дело в библиотеке — libavformat.
Напримерt ffmpeg 4.1 имеет версию libavformat 58.20.100 и метаданные отображаются нормально.
А вот начиная с ffmpeg 4.2 имеет версию libavformat 58.29.100 и перестаёт нормальное отображать метаданные вот и все.
Почему так лично я никогда не узнаю ибо знаний нет.
В общем итог такой видео буду создавать в новых версиях ffmpeg, а добавлять метаданные в старой. Вот такой костыль (
> Почему так лично я никогда не узнаю ибо знаний нет.
Пикрил, сверху код двача, снизу мой юзерскрипт. Я его писал давно, уже не помню в чем проблема, но похоже, что двач смотрит название (MATROSKA_ID_TITLE) в фиксированном месте, через 19 байт после MATROSKA_ID_INFO, в то время как я ищу его по циклу.
Дамп вебмок, в новом ффмпеге размер Info заголовка 6 вместо 12, из-за чего title смещается на 6 байт влево.
>Я даже не представляю, как сегодня люди учатся пользоваться компьютером.
Никак, поисковиков больше нет и информацию и обучение ты не найдёшь, сейчас поисковики подбирают что бы тебе продать под твой запрос. Если не товар, то хотя бы рекламы впридачу к сеошному ведру воды.
1) нахуя он из LOSSY-файла вычитал LOSSLESS-файл, а не наоборот?
2) этот хуй упоминал, что его софт не хочет корректно работать с лосси-файлами, поэтому он их перевёл в WAV якобы без изменений. Но тогда какого хуя у него "01-Forbidden Game_320k.WAV" имеет искажённую спектрограмму и всего 22050 Гц (вместо положенных для mp3 44100) и 8 битов (вместо 16)???
Вот пост этого поехавшего, чуть не забыл:
https://2ch.hk/s/res/3144406.html#3148947
Оценка ухудшения субъективного качества аудио путём примитивного вычитания сигналов — это чушь, дальше можно не читать. Иначе бы вся задача передачи аудио с меньшим битрейтом сводилась бы к перебору методов сжатия, выдающих максимально близкий к оригиналу результат. Даже древние аудиокодеки вместо этого учитывали особенности человеческого восприятия и подстраивались под него.
Основные тесты и сравнения аудиокодеков был готовы ещё в двухтысячных, можно пойти и посмотреть. Opus покрывает практически все нужды, кроме самых специфических, аудио требует ничтожную по современным меркам ширину канала, так что давления оптимизировать нет (да и так-то было не особо нужно, но вопрос лицензий и патентов стоял перед всеми любимой корпорацией). На нейросетях разве что сделали упаковщик, который в совсем мало бит информацию о звуке записывает (и занятно фантазирует, если файл данных начать портить), но тут надо не забывать о вычислительной мощности, которая на это требуется.
>>3524629
Раз уже знаток ИТТ. У меня вопрос для шебм оптимальный битрейт opus 160 kbps, верно? Или надо побольше если хочешь музыкальную шебм сделать, чтобы качество аудио было максимально возможное?
> 160 kbps
Нахуй так много, 64 - 96 kbps хватит.
Благодарю, я просто на ютуб ориентировался он вроде opus 160 kps выдаёт.
Ну вот он якобы выискивал артефакты, где погромче, где потише. А если копнуть глубже в его поиски, то там маразм вырисовывается.
>>3524635
Ютуб наёбывает, там по факту 103-128 кбпс в лучшем случае, если ты вытянешь оттуда вебм с опусом, то MediaInfo или Фубар покажут тебе, что никаких 160 там нет.
Вернее, это не он наёбывает, а всякие ютуб-дл сервисы (на самом ютубе честно сказано, что у них 128 кбпс качество).
>>3524632
Я бы сказал, что ему 120-144 вполне достаточно (96 и ниже просто не проверял). Я проверял опус одного и того же трека по разным битрейтам, конвертируя их всех из флака, разумеется. И вот что странно: при 130/140 кбпс у опуса сильно ухудшается спектрограмма, при 128 и 144 она вполне нормальная и похожа на оригинальный флак, при более высоких битрейтах тоже. В чем секрет такой поеботы я так и не понял, он как-то странно (выборочно) кодирует.
Кстати, есть такая прога - Fakin The Funk, определяет битрейт преимущественно у mp3-файлов. Так вот, если взять opus 128 kbps и конвертнуть его в так сказать самопальную mp3 320, эта прога не заметит подвоха и скажет, что mp3 настоящее.
>Ютуб наёбывает, там по факту 103-128
Да ты прав. Я ошибся. Отдельную дорожку вытянул через yt-dlp, посмотрел в media.info а там 92 kbps.
Для чего «оптимальный»? Чтобы «Войну и мир» азбукой Морзе передать, можно обойтись гораздо более скромными средствами.
Все или почти все люди, которые будут твои аудиовизуальные шедевры воспринимать, вероятно, будут находиться в ситуации, когда они не будут фокусировать внимание на погрешностях сжатия аудио. Следовательно, любой современный кодек с битрейтом от 128 килобит в секунду их заведомо удовлетворит (по факту, можно обойтись и гораздо меньшим, но задача последние байтики отнять у аудиопотока и отдать видеопотоку, кажется, у нас не стоит). Не слишком удивительно, что и десять лет назад тебе дали бы такой же совет, и двадцать лет назад (и даже тридцать, если ты вращался в профессиональных кругах, получивших новый кодек MP3):
https://listening-test.coresv.net/results.htm
Конечно, можно заметить, что если ты знаешь, как должно звучать СОЧНОЕ РУБИЛОВО ПЯТЬ ГИТАР РАЗОМ ИГРАЕТ, и наушники у тебя не слишком говённые, ты можешь заметить некоторую кашу и узость при воспроизведении одновременно ВСЕХ частот, и выразить мнение, что хорошо бы 200 килобит и выше в среднем иметь, где уже никто не отличит одно от другого даже на идеальной технике. Тем не менее, люди, которых это волнует, просто не будут использовать твои файлы как источники музыки, они всё равно скачают копию сами в устраивающем их качестве.
Короче говоря, это вообще не проблема сегодня. Вот если у тебя основная масса фанатов всё ещё пользуется модемом для доступа в интернет по телефонной линии, станет интересно, придётся считать. Правда, странички эти у них вряд ли загрузятся.
Размер окна и разрешение в настройках преобразования Фурье поставь, и окажется, что «спектрограмма портится» при других значениях. Надеюсь, ты в курсе, что это некое абстрактное представление, которое можно рисовать сотней разных способов в зависимости от оконных функций и нормализации, а вовсе не «вот так выглядит аудио в файле».
Нет, там именно спектрограмма при тех же максимальных показателях осей графика. Будет время - выложу сюда скриншоты, сами увидите, насколько разные результаты он выдаёт.
Кстати, вот еще погляди на результаты опроса аудиофильского ресурса:
https://hydrogenaud.io/index.php?PHPSESSID=7beu1facnuvjk6f7dki220b6eb&topic=115386.0
Кодек волен фокусировать внимание на тех зонах, где он хочет сохранить качество, и игнорировать менее важные.
Последняя, 1.5.1. Юзал Фубар + encoder pack самый свежий. По-моему, на предыдущей был тот же эффект.
Также я повторил точно такой же эксперимент, о котором упоминал вот здесь >>3524592
В общем, у меня получились те же результаты. Только возникает вопрос: какова гарантия, что это действительно артефакты, а не остатки того, что вырубается из лосслесса используемым лосси-кодеком? Потому что я очень сильно сомневаюсь в том, что mp3 320 вообще что-то привносит в плане артефактов, по-моему, он копирует определённую (урезанную) часть звуков.
>Основные тесты и сравнения аудиокодеков был готовы ещё в двухтысячных, можно пойти и посмотреть.
Соус?
Анон, поясни, пожалуйста, на пальцах, будто мне пять лет, что происходит:
У видео h264 с pix_fmt yuv420p - YMIN=8 и YMAX=230.
Когда я перекодирую этот видос обычным ffmpeg'ом в UTvideo с pix_fmt "bgrp", то у него YMIN=16 и YMAX=229.
Когда я UTVideo-bgrp перекодирую в Utvideo-yuv420p, то у него по-прежнему YMIN=16 и YMAX=229.
Когда я оба видоса с кодеками Utvideo перекодирую обратно в h264-yuv420p, то у них у обоих YMIN=12 и YMAX=230.
Что тут происходит? Своими глазами и на своем нищуковском мониторе я не вижу разницы. Но качество теряется когда я перевожу из yuv420p в gbrp, а потом еще раз когда из bgrp обратно в yuv420p?
YMIN и YMAX взяты из самых первых фреймов вот этой командой: ffprobe -f lavfi movie='INPUT.avi',signalstats -show_entries frame_tags=lavfi.signalstats.YMIN,lavfi.signalstats.YMAX
но эти значения изменились во всех фреймах.
Есть. Например, метаданные типа даты могут быть разные.
Нет, я прям про видеоданые. И размер разный.
Без пережатия ты просто получаешь отрезок того же самого видеопотока, который декодируется в те же самые кадры.
>>3529382
Зависит от алгоритма. Если он чисто математический, то выйдут заданные циферки, которые можно и на бумажке посчитать. Но сегодняшние кодеки гораздо сложнее, они ищут не конкретный набор битов, а примерно соответствующий заданной метрике воспринимаемого качества, которых множество вариантов. В зависимости от устройства этого поиска результат может быть как одинаковым при каждом запуске, так и частично случайным. Кроме того, при распараллеливании для синхронизации операций на разных ядрах могут использоваться эвристические оценки «уже хватит, кидай другому, чтобы не простаивал», и тем самым косвенно сдвигаться баланс выборов в зависимости от процессора и его загрузки внешними программами.
Иначе говоря, если ты хочешь узнать, повторяем ли поток битов, выходящих из кодировщика, тебе надо глубоко закопаться в устройство кодировщика и видеопотока. Это не говоря про очевидные вещи вроде случайного выбора идентификаторов, полей, зависящих от даты и времени, выбора меток отсчёта и так далее.
>Без пережатия ты просто получаешь отрезок того же самого видеопотока, который декодируется в те же самые кадры.
Спасибки!
а) Качество теряется, когда используется кодирование с потерями. Само название об этом говорит. Вывод давно известен: работать надо с исходниками, исключая сжатие-пережатие, которое используется только на последнем шаге для результата в нужном виде и формате.
б) Как ты по пиковым значениям отдельных пикселей судишь о «качестве», и почему, человечеству ещё предстоит разобраться.
в) Добро пожаловать в мир обработки сигналов, где не существует бесконечных энергий для «мгновенной» смены значений. Как только мы от значений пикселей переходим к набору частот, с нужной точностью (или приблизительностью) попадающих в заданные значения, пики непрерывных представлений начинают гулять, что зависит от резкости переходов, методов разложения и фильтра.
https://en.wikipedia.org/wiki/Ringing_artifacts
https://en.wikipedia.org/wiki/Overshoot_(signal)
https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%A4%D1%83%D1%80%D1%8C%D0%B5
https://en.wikipedia.org/wiki/Square_wave
Помогите ламеру. Ffmpeg и Avisynth поставил по гайду с ютуба, NET Framework есть, почему оно не работает то бля?
Ок спасибо
Попробуй всё-таки не повторять, как обезьяна, видосик, а инструкцию прочесть и понять, что происходит, когда вызываются эти команды.
Почему вопрос про Avisynth, а на картинке WebMConverter? Какими из этих программ ты пользуешься, и для чего?
Смотрим на ошибку. Если файла ffms2.dll по указанному пути не существует, то надо понять, откуда берётся попытка загрузки, ковырять скрипты и настройки Avisynth. Если же он существует, что вероятнее всего, и является библиотекой, что тоже вероятно, надо подумать над тем, используются ли 32-битные или 64-битные сборки программ, и совпадает ли архитектура библиотеки с желаемой.
> Следовательно, любой современный кодек с битрейтом от 128 килобит в секунду их заведомо удовлетворит
MP3 сюда входит или ты признаешь его устаревшим? Если входит, то при более современных аудиокодеках можно без опасений выставить 96 kbps.
> по факту, можно обойтись и гораздо меньшим, но задача последние байтики отнять у аудиопотока и отдать видеопотоку, кажется, у нас не стоит
Очень даже стоит, если жать WEBM в 20 МБ. И там хорошо если жмёшь аудио в 64kbps. Да, это один из немногих юзкейсов, где xHE-AAC реально может пригодится.
Мне 7.1+ хочется.
Качал отсюда: https://github.com/BtbN/FFmpeg-Builds/releases
Файл: ffmpeg-master-latest-win64-gpl.zip
Никак. Это не версия. Это наверное ночной билд с мастер ветки. Ну с мастер точно, а насчёт ночного или дневного не знаю.
Короче, качай по новой.
Так откуда качать то седьмую версию?
В той ссылке, что на оффсайте главная, нет некоторых нужных мне библиотек, я без них не могу.
Пиздец просто бардак.
>ffmpeg-master-latest
Это и есть самая последняя версия которая только может быть.
Самой последней она была только когда анон её скачал
Оффсайт тебя чем не устроил? https://www.ffmpeg.org/download.html#releases
Нужные тебе библиотеки завозить самому надо
Есть коллекция разных кассет, в основном VHS, где то 8 коробок. На них либо фильмы со всратым переводом, либо домашние записи.
Хочу полностью оцифровать архив, в несжатом виде одна кассета занимает гигов 7-10
Стоит ли ебаться со сжатием или забить хуй и просто оставить как есть? Планирую под это дело выделить два диска по 1ТБ каждый, один основной, один резервный
если домашние записи то я бы ничего не сжимал. если фильмы то я бы скачал с рутрекера нормальный mkv а кассету бы выкинул.
А нахуя? Если тебе для хранения, то кассеты переживут диски.
>Стоит ли ебаться со сжатием или забить хуй и просто оставить как есть?
Прежде всего стоит ебаться с нормальной (в бытовых условиях) оцифровкой исходника, предварительно обмазавшись вменяемым устройством захвата (типа Canopus'ов серии advc) с добавлением avisynth+QTGMC (50fps) и денойзеров (по вкусу). А затем уже всё пожать с любыми настройками качества, кот. тебя устроят. Оставлять шумный и здоровенный исходник стоит только если собираешься дальше что-то с ним делать или если уж совсем тебе лень.
Проигрывается-то всё нормально, но ОКР не дает покоя. Вижу это на многих видео из интернета, но у некоторых такого нет.
Из того что сам знаю: hls и dash, но не понимаю генерируют ли они их «налету» или заранее режут на чанки и по CDN рассылают? Как это работает вообще? Просто как я это вижу, для своего сата, например: заходит чел на сериал, выбирает серию, я на сервере в этот момент через запуск ffmpeg начинаю нарезать кусочки и отправляю на клиент плейлист с таймингами и ссылками на куски(m3u8, например)
Но это же достаточно долго(5-6 секунд ждать челу пока там все приготовится для вещания такое себе), поэтому и задаюсь вопросом, может популярные чата заранее нарезают видос и потом просто их как статику уже отдают?
Популярные режут заранее и хранят сразу все качества.
Очень популярные хранят по нескольку раз в разных форматах и кодеках.
Ебать как популярные могут уже упираться в хранилище и нарезать на лету туша огонь видеокартами.
Конечно, av1 можно в ультрашакалов сжать црф 48-53 и поехали на цпу-юзд от двух до нуля в зависимости от того насколько ебанулся, будет смотрибельно. В остальном хуета без задач.
libaom-av1 во всяком случае, форки попробовать может, хуй знает.
Ебать ты тип, хотя бы пожал картинки побольше чем 10х10 пикселей. На твоей хуйне и так ничего не разглядишь, а там еще и хрома субсемплинг мыла наваливает. vp9 все равно заметно проебывает.
>хотя бы пожал картинки побольше чем 10х10 пикселей
Ой ну, это ж для удобства кропы.
Хоть целиком видосы могу залить. Правда, лосслесс получается больше гига, так что мех. Во.
https://litter.catbox.moe/0a07ok.mp4 - av1 -crf 27 -cpu-used 2
https://litter.catbox.moe/xbcq2c.mp4 - av1 -crf 28 -cpu-used 3
https://litter.catbox.moe/y5msoz.mp4 - vp9 -quality best -crf 31 -cpu-used -8
>vp9 все равно заметно проебывает
Мне кажется, что заметно это сильно сказано. На писюнчик проигрывает, конечно, зато проще воспроизводится на всякой некроте. Хотелось бы более заметной разницы, чтобы был повод переходить к шебемам в новом формате, тем более, что уже давно не новом.
>похабные моды
>нахрюсик
пиздец.
В любом случае на таком битрейте пиздец заметной разницы ты не найдешь, нужно жать сильнее/давать больше фпс/кодировать чего подлиннее/fullhd, чтобы av1 себя полностью раскрыл
>не тот битрейт
>не те фпс
>не те моды
>не та длительность
>не тот язык
>не то разрешение
>формат навырост просто
>со временем станет тащить
>вы подождите
>всё будет пацаны, но не сразу
>ну а что вы хотите, никто ничего не обещал
То, что можно crf 53 ебануть — оно понятно. Но это совсем узенький юзкейс.
Попробую больше фпс с большим разрешением, что терять. С другой стороны, не верю, что будет сильно большая разница. Вангую, что длительность кодирования кратно начнёт расти и придётся cpu-used поднимать до 4-5, чтобы сравнять время кодинга с вп9 и на выходе получится ещё меньше разницы. А может и нет...
Так ты не в ту сторону воюешь, AV1 не для качества и не для скорости, а для размера.
Там где H.264 был гиг у VP9 600, а AV1 – 400, это я у одного конкретного фильмца посмотрел.
Т.е. выигрыш от VP9 в хранилище или в пропускной способности сети на треть. На диск впихнёшь на пару аниме больше, а в деревне с мобилки посмотришь фуллхд вместо 720.
Ну а по кодированию отсос конечно, не для того кодек и задумывался. Декодеры вот сейчас в принципе уже появились в свежих девайсах.
> Там где H.264 был гиг у VP9 600, а AV1 – 400,
Уверен, что у vp9 и av1 было мыло.
Не, тут по PSNR и ещё каким-то метрикам подобраны CRF и прочие параметры чтоб было плюс-минус одинаково.
Вполне бьётся со всеми исследованиями по индустрии, как раз очень средние цифры.
Всегда получается немного неточно, почему-то.
VirtualDub, конечно же
https://sourceforge.net/projects/vdfiltermod/files/VirtualDub%20pack/
Ладно, я нашел скрипт на mpv
https://github.com/TheAMM/mpv_crop_script
пресет medium с профилем high
или
пресет slow с профилем main?
Можете так примерно почувствовать?
Первое есть 50-55% проца, второе 70-75%
https://files.catbox.moe/r8x8k5.zip - Скриншотики
https://files.catbox.moe/ghagsw.mp4 - vp9 -quality best -crf 44 -cpu-used -8
https://files.catbox.moe/kuvmdg.mp4 - av1 -crf 39 -cpu-used 3
>main
Нинужон. Сейчас же не 2007.
На slow + high тормозит, так бы конечно поставил
Качай ффмпегом и ебись с куками да юзерагентами
Через ffmpeg, а он мне говорит At least one output file must be specified. Так я ему указываю!
ffmpeg -i урлплейлиста -c copy -bsf:aac_adtstoasc output.MP4
И один фиг At least one output file must be specified.
Так я ему и "C:\test\output.mp4" указываю, и просто "output.mp4" с кавычками, и без, да пофиг, выдаёт эту ошибку всё равно.
>-bsf:aac_adtstoasc
Зачем тебе это?
Тут и синтаксис не правильный и кажется не понимаешь что это. Убери, даже если поправить синтаксис это бессмысленно для mp4 контейнера.
Убрал. В файл выгружается теперь, но в получившемся файле первые ноль секунд идёт чёрный экран почему-то. Но при этом если открыть эту же ссылку в VLC Media Player, то всё отлично воспроизводится (но, как уже сказал, только воспроизводится отлично).
Первые семь секунд, извиняюсь.
pastebin.com/DJqyZRuA
pastebin.com/eX9GDUsk
Их можно как-нибудь склеить без перекодировки?
ffmpeg -i "concat:0001.MTS|0002.MTS" output.mp4 видео лагает. С -copy не склеивает
ffmpeg -i "concat:0001.MTS|0002.MTS" - copy output.mts тоже только первая часть
Вроде снималось все на оду камеру
mkvtool шлет на хер с ошибкой
-- Ошибки, произведённые заданием "Паковка в файл "00001.mkv" в папке "P:\"", запущенным в 2024-10-31 03:25:07 +05:00 ---
Дорожка номер 0 файла "P:\00002.MTS" не может быть присоединена к дорожке номер 0 файла "P:\00001.MTS". Форматы не совпадают.
Вот это читал?
https://stackoverflow.com/questions/7333232/how-to-concatenate-two-mp4-files-using-ffmpeg
>Ну а по кодированию отсос конечно, не для того кодек и задумывался.
Конечно референс энкодер будет медленно кодировать. Уже сделали libsvtav1. Используй его, если нужна скорость.
Да это понятно, там и rav1e есть, прям повыбирать можно и каждый из них самый быстрый.
Не знаю бенчмарков, но подозреваю они всё равно отсосут у быстрых кодировщиков 264 и VP9 в эквивалентных условиях.
А если нужна скорость, тут это всё хуита, нужны хардварные.
С ними печально пока, нвидия с 40й, амд с 7000 видюх если не ошибаюсь. Эппл вообще не смог, ну и все остальные железяки тоже как получится, если и есть то только в самых-самых свежих сериях.
Лет через 10 можно будет сравнивать, пока AV1 тупо сильно молодой чтобы тягаться именно по скорости кодирования со старыми кодеками.
Да и через 10 лет думаю это всё равно будет слабой его стороной просто потому что они никогда для этого и не задумывался и оптимизирован под другое. Скорость кодирования просто не приоритет для AV1.
Специально в тесте использовал cpu-used 2 и 3, чтобы честно сравнивать медленный энкодер с максимально медленным vp9, по легенде на этих значениях libaom самый эффективный при сравнении с форками, а уж vp9 должен и в хвост и в гриву. Но чот чуда не происходит.
>нужны хардварные
А разве размер не больше будет? У vp9, например, так (по крайней мере раньше было).
Алсо, про opus и то что он невероятно хорош я тоже знаю.
Зачем aac? Vorbis на 320к и кайфуешь
Все верно. У хардверных энкодеров только одна цель - кодировать в реальном времени, чтобы можно было стримить. Для всего остального (качество/размер) они всегда хуже софтверных.
Только lame 3.93.1 в 320kbps, только хардкор!
>Не знаю бенчмарков, но подозреваю
Ну так посмотри.
>Лет через 10 можно будет сравнивать, пока AV1 тупо сильно молодой чтобы тягаться именно по скорости кодирования со старыми кодеками.
По состоянию на 2021 год SVT-AV1 с preset=6 по скорости был на уровне VP9 с threads=4. (См. прикрепленную пикчу)
SVT-AV1 2.0.0 13.03.2024: ~2x прирост скорости на всех пресетах - https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v2.0.0
SVT-AV1 2.2.0 19.08.2024: ~1.15x прирост на пресетах M0-M8 - https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases/v2.2.0
У меня процессор с четырьмя ядрами и поддержкой AVX2. Перекодировал 1080p видео длительностью 24 минуты при помощи SVT-AV1 с -preset 6 и VP9 с -threads 4.
SVT-AV1: ~speed=0.750x
VP9: ~speed=0.300x
С такими параметрами SVT-AV1 быстрее VP9 в 2 раза.
Например: -ss [input] -to [input] -i [file] [file]%05d.png
Батников достаточно в целом. Сейчас использую павершелл для редактирования avs скриптов, но это такое, со скуки. Подумываю на питон перейти. Тут можно очень долго падать в кроличью нору.
Мне нравится фиш, там куча плагинов баша идёт из коробки, плюс синтаксис более понятный, располагающий к запоминанию.
Синтаксис может и понятный, но он только мешает когда весь интернет написан на баше.
Я тоже фишем пользуюсь, но если дело доходит до скриптов, то #!/usr/bin/env bash каким бы говном баш ни был для программирования.
Есть оцифрованный видео-файл в формате .dv на 12Гб. Как его перекодировать в другой формат, чтобы можно было смотреть на телике?
На компе есть программа ffmpeg, но как задать правильно флаги, чтобы всё заработало, я не знаю. В интернете ничего не нашел про это.
Попробуй
ffmpeg -i file.dv -crf 16 -tune film file.mp4
Скорее всего этого хватит
Вывод кмд:
>ffmpeg version 2022-10-17-git-3bd0bf76fb-full_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 12.1.0 (Rev2, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libaribb24 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libvpl --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil 57. 39.101 / 57. 39.101
libavcodec 59. 50.101 / 59. 50.101
libavformat 59. 34.101 / 59. 34.101
libavdevice 59. 8.101 / 59. 8.101
libavfilter 8. 49.101 / 8. 49.101
libswscale 6. 8.112 / 6. 8.112
libswresample 4. 9.100 / 4. 9.100
libpostproc 56. 7.100 / 56. 7.100
Unrecognized option 'crf16'.
Error splitting the argument list: Option not found
Тупанул, не те пути написал
Ей дают оригинал и откодированное, она выдает процент
Знаю только такой поделие от васяна:
https://github.com/fifonik/FFMetrics
https://github.com/gianni-rosato/svt-av1-psy/blob/master/Docs/PSY-Development.md#self-testing
https://wiki.x266.mov/docs/metrics/XPSNR
https://wiki.x266.mov/docs/metrics/SSIMULACRA2
VMAF база. Остальное нинужно.
Я подозревал, что такое может быть, но все равно неожиданно, т.к. slow+main жрет больше проца
Яжеговорил. Ничего неожиданного, мэйн нужен, чтобы на тостерах из 2002 проигрываться. Хай всем пизже.
Можно. Большая часть рипов в инторнете на видимокартах пожаты.
Удивительно, что двач вообще поддерживает av1
На дваче и у джипегов превью ломаются.
@echo off
:loop
set /p input="Filename: "
ffmpeg -i 'D:\1Youtube\%input%.mp4' -vn -ar 44100 -ac 2 -ab 192K -f mp3 'D:\1Pdkst\%input%.mp3'
del 'D:\1Youtube\%input%.mp4'
goto loop
и можно ли его объединить с этим
@echo off
:loop
set /p input="URL: "
y -f default-1077-0 %input% -P 'D:\1Youtube\'
goto loop
Одинарные кавычки поменяй на двойные.
>>3561018
Можно. Что ты сделать вообще пытаешься, что твой батник делать должен?
я вставляю ссылку на видео, ут-длп его скачивает, ффмпег конвентирует его в мп3 (только аудио скачать нельзя), скачанный файл удаляется
Ты ман yt-dlp почитал бы сначала прежде чем батники писать.
yt-dlp -f bestaudio --extract-audio --audio-format mp3
с рутюба не скачивает
ERROR: [rutube] 2da5d659011f24eee948770721784f4d: Requested format is not available. Use --list-formats for a list of available formats
Без "-f bestaudio" делай.
Для указания качества можешь --audio-quality добавить.
Если нужно больше ключей для ffmpeg указать, то используй --exec, как по ссылке ниже.
https://paste.debian.net/plain/1336732
Или можешь через --postprocessor-args попробовать.
работает, но почему-то битрейт аудио ниже чем в видео
@echo off
:loop
set /p input="URL: "
y -F %input%
set /p input2="Kachestvo: "
y -f default-%input2%-0 --extract-audio --audio-format mp3 --audio-quality 0 %input% -P "D:\1Pdkst"
goto loop
https://otvet.mail.ru/question/215749072
>наконец-то
>5 лет назад
Вон, не так давно выкатили AV1, поддержка на видеокартах как кодинга декодинга есть, а он нафиг никому не нужен, хотя прошло уже 5 лет.
Почему так?
И ещё... какой максимальный предел сжатия для 60 фпс минутного видео в FHD на AVC/VP9/HEVC/AV1 соответственно, в схожем с видрил качестве?
Хорошо, а почему амуда, так любящая опенсорс не подсуетилась?
Зато HEVC у них с поддержкой HDR давно, и AV1 с профилем 4.4.4
Снова наебли получается?
Амуда-то на винде не может порядок навести, вечно у них проблемы в дровах и поломки, всё отваливается. Единственная годная фича там это Fluid Motion.
VP9 сто лет в обед аппаратно энкодируется на встройках интела, у меня на кэби лэйке QSV поддерживает. Насчёт их дискреток хз, вроде бы тоже должны.
А собсна нахера амуда сделала ставку на HEVC, а не VP9?
Да я ебу у меня интел кэби лейк
В профессиональной индустрии нет очень дорогих фирменных коробок, принимающих поток в VP9, — нет и кодировщика, который серьёзные дяди могли бы использовать для его получения.
Всё обсуждаемое в предыдущих постах на твоём компьютере появилось в качестве объедков со стола компаний, занимающихся телевизионным и интернет-вещанием. Ради твоих домашних перделок никто над стандартами не работал бы.
Как нет и других кодеков названия которых тебе известны. Там вообще немного другой мир.
Кодеки появляются только на этапе доставки пользователям в пользовательския окружения. Т.е. интернет стриминг и только там. А это царство интела (процессоров) и нвидии (видюх), плюс гугл вообще для ютуба свой силикон изобретает. Амд туда пока не залезла вообще ни ногой.
Кодеки как раз двигает пользовательское железо. Самый передовые видюхи например по аппаратной поддержки – это вообще мобильные чипы потому что там проблемы что энергопотребления, что сети, что размеров хранилища острее всего стоят.
Ясно, человек ленится даже по ссылкам в «Википедии» ходить.
https://en.wikipedia.org/wiki/Moving_Picture_Experts_Group
Готовят национальные и международные стандарты вещания видео (через любые технологии).
Когда спутник запускают в космос, надо знать, что и как он будет делать на десять лет вперёд, потому что мужика с паяльником к нему уже не пошлёшь. Отсюда стандарты кодирования, приёма и передачи сигнала, подготовленные заранее. Когда производитель разрабатывает чип, который будет отвечать за большинство функций в телевизорах многих моделей, продающихся несколько лет, он должен заранее знать, с чем ему придётся работать. Отсюда стандарты сжатия, передачи потоков данных и метаданных. То же самое на стороне вещательной или кабельной станции: надо выдавать то, что поймёт техника, имеющаяся у потребителей. И так далее, и так далее.
Спутники видео не передают. Если будут передавать, кодек там будет специфичный по конкретный спутник и конкретный приёмник.
>чип, который будет отвечать за большинство функций в телевизорах многих моделей
Я в общем-то разрабатывал софтины для телевизоров. Чипы каждый год разные, а заложенный производителями цикл жизни телевизоров – 5 лет.
Но ладно, тебе виднее, ты википедию прочитал.
Гцн в рыксах его даже не декодировал, хотя поддержка заявлена была.
>>3564170
> Единственная годная фича там это Fluid Motion
Так и не довелось попробовать, слишком быстро её выпилили, естьь инструкции как запустить?
Какой кодек лучше всего подойдёт для сжатия в 960x540 30 fps по критерию "скорость - качество", чтобы не состариться пока жду?
h264 классика и даёт вполне сносные результаты в связке "veryslow + animation", но думаю присмотреть либо two-pass VP9 который поддерживает CRF в данном режиме и говорят включаются улучшающие фичи, но он плохо использует потоки процессора (хоть и на speed 2 вполне быстрый).
Или AV1 (libsvtav1) для которого не знаю какой CRF ставить чтобы соотношение к качеству было как у h264, а весь меньше (так как его стандартный CRF мне неизвестен). И слегка смущает такой огроменный набор параметров у кодека, помню лишь отключал принудительно генерацию зерна и шумоподавление (film grain опции), но что ещё может влиять на качество и скорость?
З.ы. h265 не рассматриваю из-за поддержки.
Если накачал h264 кала, то и жми h264 - особо хуже не будет и поддержка везде есть. Profile high поставь и поменьше ядер
И разрешение возьми настоящее 16:9, тогда качество лучше будет
https://pacoup.com/2011/06/12/list-of-true-169-resolutions/
Во первых, 960x540 это и есть настоящие 16:9, четвертинка Full HD (qHD).
Какие такие "list of true" не особо понятно, значения взятые с потолка ноунеймом с двумя постами 2011 и 2014 годов на богом забытом форуме явно не особо достоверная информация, ещё эти "YES" повесилили.
Если идеально помещается без 1/2 пустых пикселей по высоте/ширине, значит 16:9, каких-то не тру в таком случаи быть не может. Исключение если только грузить на ютуб которому кровь из носу надо ровно 1280x720 или 1920x1080 например.
Лично я эти видосы оставлю себе, так как грузить их мне некуда и не зачем (целые 67 часов, лол).
Во вторых, при таком уменьшении уже есть смысл жамкать не только в h264, так как даже в хлам сжатый 1080p с твича работает как избыточные данные для уменьшенного видеоролика, который будет вполне себе неплохо смотреться при пряморуком энкодинге, мне бы знать CRF для AV1/VP9 и сносную по качеству скорость.
Так как технически уменьшенный в 4 раза кадр yuv420p будет как 4:4:4 на входе (по разрешению luma и chroma), то смысл выбирать разные кодеки есть.
>Profile high поставь и поменьше ядер
Может наоборот побольше чтобы быстрее отрисовало? Как уменьшение ядер поможет улучшить качество/скорость? А профиль "High" FFmpeg ставит и сам.
Тру это те, которые делятся 8, так кодирует лучше
>Тру это те, которые делятся 8, так кодирует лучше
Ок, буду знать.
А вот по нагрузке походу AV1 уделывает VP9 в хвост и гриву, на пресете 5 из 10 вполне себе быстрый, CRF 35, все 24 потока занимает как положено.
Лайн такой
>-c:v libsvtav1 -preset 5 -crf 35 -g 240 -svtav1-params tune=1:film-grain-denoise=0:enable-tf=1:enable-restoration=1:film-grain=0:enable-overlays=1
Говорят все эти оверлеи и ресторейшоны хороши для низких битрейтов, может даже зря отключил шумодав (но симуляция зерна мне не нужна, стрим это не фильм).
> Исходники какие-то, компиляции
У тебя там пакетные менеджеры (Scoop, Chocolatey) и готовые билды с гитхаба на скриншоте.
>по критерию "скорость - качество", чтобы не состариться пока жду?
Xvid.
Пощади, человек-анекдот.
Уже и так выбран AV1 как фаворит из-за распределения на потоки.
Хочу дополнить что в CMD при энкодинге 960x540 он показывает 960x544, так как 540 на 8 не делиться, а 544 делиться.
Так что чаю анону, для AV1 оказывается делимость на 8 очень важна, может так у всех кодеков.
На скриншоте база свободного софта, конечно. Ладно под прыщами — мэйк билд поехали нахуй — под виндой же чтобы что-то скомпилить надо минимум бочку сделать. Но к мпв доёбы пустые, конечно.
>>3565683
>поддержку NVIDIA RTX и Intel VSR
Хуя себе, ЛУЧИ в аниме появятся и анриловинчики можно будет прям в плеер драгндропать? Сенсация нахуй.
> Хуя себе, ЛУЧИ
Не лучи, а супер резолюсьон.
Супер-резолюйшен крутая фича для всяких мультов, в том же MPC-BE с патчем самое то смотреть, но вот некоторые видео да, сильно мылит, и это на режиме 4 самом тяжёлом.
> MPC-BE с патчем
С каким нахуй патчем? Он в mpcvr из коробки. Правда, в одном из последних обновлений его функционал зарезали только для 8 бит видео.
Качать просто нормальное качество. Даже 720p норм на 4к, если без шакалов, а от нвидевского скейлера проебёшь все немногие детали, что там есть.
Единственный юзкейс, который мне норм зашёл, растягивать шакальные стримы на 65 дюймов. Но то один хуй из браузера и раз в пятилетку, когда протыклассники стримят.
С одной стороны, с точки зрения меня пользователя-домохозяйки-гуманитария, это же хорошо что звук остается прежним, но с другой - может технически лучше первый вариант с уменьшением громкости? Неспроста же такое поведение?
В общем, мнение?
> Почему громкость звука немного уменьшается если моно стрим конвертировать в стерео
Уровень сигнала делится на два канала, уровень сигнала делится на два
> но если это делать join фильтром - например (-filter_complex "[0:a:0]asplit[s1][s2]; [s1][s2]join=inputs=2:channel_layout=stereo"), то уровень звука остается прежним?
Тут даже важнее asplit, который создаёт копии потока. Затем ты эти копии разбрасываешь на два канала, и они закономерно имеют одинаковый уровень
> Уровень сигнала делится на два канала, уровень сигнала делится на два
Извиняюсь, спросонья как ебан написал. Это зависит от логики того, как работает channel layout. Сам я из моно в стерео не конвертировал, но приходилось 5.1 кидать в стерео. По умолчанию он просто перенаправлял FL-FL FR-FR, а остальные каналы просто отбрасывал, что приводило к снижению суммарного уровня сигнала. Думаю, что здесь он тоже делит моноканал надвое, вместе со всеми параметрами, вот и выходит снижение воспринимаемой громкости. Но чтобы знать точно, надо читать про логику его работы
На моей версии приходилось качать патч с ГитХаба чтобы он добавлял RTX рендер.
https://github.com/emoose/VideoRenderer/releases
Так это старая хуитка. В оригинальном MPC VR это давно уже из коробки.
Я качал MPC-BE когда он ещё на обрыганном SourceForge был (версии с 1.6 по 1.7), а уже потом при предложении обновиться он стал кидать на GitHub.
Кодирую видео в AVC + AAC и в контейнер MP4. Получается определенный размер файла.
Далее:
- открываю результат
- делаю "извлечь аудиодорожку и сохранить как отдельный файл"
- в этом же самом видео иду в настройки аудио и вместо "оригинальной" аудиодорожки (которая уже есть в этом файле) выбираю только что сохраненный отдельный .aac
- режим обработки и видео, и аудио - copy, т.е. без перекодирования. контейнер - тоже mp4.
- сохраняю как новый файл
Результат - примерно на 15-25 КБ меньше. Именно вот такой манипуляцией извлечения аудиодорожки в отдельный файл и потом выбора этого аудиофайла "взамен" той аудиодорожки, которая в нем.
А если не извлечь в отдельный аудиофайл, а "просто" открыть видеофайл, везде режим copy у видео и аудио, и тут же сохранить в новый mp4 - то есть абсолютно то же самое содержимое, но без промежуточного этапа в виде отдельного аудиофайла - то размер не меняется.
Что здесь происходит? Вообще, нормально ли это, что абсолютно то же самое содержимое видео и аудио, без перекодирования, может перемукситься немного "поплотнее" в мп4-файле?
Вот пример. "Исходный" файл (вырезанный и закодированный кусок фильма, чтобы уместить в 20 МБ) и он же, над которым была проделана эта манипуляция. 20951252 байтов против 20925109 байтов, разница ~25 КБ. Эксперты по содержимому файлов, видите ли вы здесь какую-то разницу, которую не вижу я?
Метаданные какие-нибудь теряешь наверное
В папке множество видео в разных кодировках. BAD - нежелательная, GOOD - желательная
Задача: конвертировать все видео которые не в кодировке BAD в кодировку GOOD. Видео в кодировке GOOD не конвертировать.
Как это сделать одним махом?
1 BAD
Video: AV01 1920x1080 25fps [V: av1 main, yuv420p, 1920x1080 [default]]
Audio: AAC 44100Hz stereo [A: aac lc, 44100 Hz, stereo [default]]
Video
ID : 1
Format : AV1
Format/Info : AOMedia Video 1
Format profile : Main@L4.0
Codec ID : av01
Duration : 23 min 40 s
Bit rate : 1 913 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.037
Stream size : 324 MiB (93%)
Title : ISO Media file produced by Google Inc.
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Codec configuration box : av1C
2 GOOD
Video: MPEG4 Video (H264) 1920x1080 25fps 3239kbps [V: ISO Media file produced by Google Inc. (h264 high L4.0, yuv420p, 1920x1080, 3239 kb/s)]
Audio: AAC 44100Hz stereo 127kbps [A: ISO Media file produced by Google Inc. (aac lc, 44100 Hz, stereo, 127 kb/s)]
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 3 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference fra : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
>Задача: конвертировать все видео которые не в кодировке BAD в кодировку GOOD
Фикс: Задача: конвертировать все видео в кодировке BAD в кодировку GOOD
Через PowerShell делаешь foreach для каждого файла в папке, внутри результат ffprobe будет проверяться на BAD кодировку, если кодировка BAD, то выполняется команда конвертирования через ffmpeg.
Как должен код выглядеть в powershell?
Теперь вопрос по второй части: как запустить выполнение команды конвертирования через ffmpeg файлов с кодировкой BAD с сохранением разрешения и удалением файла источника? Спасибо за помощь!
https://pastebin.com/raw/eDqjbwKN
Исходники удаляются в корзину.
Команду конвертирования можешь настроить под себя.
https://trac.ffmpeg.org/wiki/Encode/H.264
Сохранить разрешение не получится, твой BAD файл это контейнер .webm, а он не поддерживает нужную тебе GOOD кодировку H.264, необходимо использовать или .mp4 или .mkv, но если прям требуется чтобы разрешение было принципиально то же, то можно просто переименовать итоговый файл, приложения всё равно читают файлы по структуре, а не по названию, однако так делать некрасиво.
Именно то что надо, огромная тебе благодарность!
В интернете уже есть миллион статей для вебмастеров, описывающих, какие кодеки и на каких платформах и при каких условиях поддерживаются. Ещё существует caniuse со статистикой.
Если сократить, всё очень просто: Apple не один десяток лет в очень близких отношениях с MPEG. Следовательно, на их устройствах первый (и часто единственный) выбор — актуальные кодеки MPEG. На то, что творится на рынке, им пофиг, их положение позволяет. Хочешь видео выводить на айфончик? Иди плати за лицензию H.264/H.265. С другой стороны Google, которому как раз это и мешало всегда, потому что с их объёмами приходилось выторговывать ежегодные лицензии на устройства, на YouTube и так далее. В качестве рычага они купили On2 с набором патентов и начали разрабатывать и пропихивать (в первую очередь в Android) «халявные для всех» кодеки на замену. Следовательно, есть два лагеря, и в каждом решения из противоположного без надобности. Например, с поддержкой невыгодного им AV1 Apple без стыда тянула 5 лет, с 2018 по 2023 (целенаправленно даже программно его не декодируя), хотя формально входила в число компаний, поддержавших его разработку как минимум организационно.
Дело не только в браузере, но и в ОС и в железе.
264 не работает только в опенсорсных браузерах в опенсорсных осях. Именно когда оба сразу и то если из репозитория не поставишь пакет кодеков. Он проприетарный, но дешёвый. Поэтому его не поддерживают только принципиальные.
265 работает только там где есть аппаратная поддежка. Он проприетарный и дорогой. Поэтому его все на хую вертели. В том числе и стриминговые платформы, поэтому без курицы и яйца тоже его на хую вертят.
Подскажи, пожалуйста коды для таких задач:
1. Из папки и вложенных папок найти все НЕ H.264 видео и перенести\скопировать их в одноименные папки с добавлением в названии папок FOR CONVERT располагаемых в родительской папке или в ином месте (Делаю для того что бы конвертнуть их в отдельной проге)
2. В этой команде https://pastebin.com/raw/eDqjbwKN идет проверка if ($Info -eq "av1") AV1 ВОПРОС: как сделать проверку на НЕ H.264 ? И далее уже выполнение согласно вышеприведённому коду.
С тем зоопарком, что сейчас, комбинаций для выстрела себе в ногу куча. Пока гуглил, люди тоже не в восторге а то вдруг это я не пынямаю. Ну и нахуя этот пердолинг?
Даже не знаю. Попробуй представить себе архивы телеканалов и медиакомпаний, в которых лежат материалы за десятки лет, оцифрованные при помощи разных технологий и в разных форматах. Каждому требуются корректные метаданные.
>ну чтобы в свойствах конечного файла отображалась ширина, высота кадра, битрейт, частота, скорость потока аудио
> А то когда я кодирую, то у меня получается пустые строчки в свойствах как на пикриле. Это конечно не особо важно. Но всё же.
Всё это по-умолчанию есть. Качай MediaInfo
https://mediaarea.net/en/MediaInfo
По метаданным в общем (хоть и не про это вопрос), если кому-то надо: https://wiki.multimedia.cx/index.php/FFmpeg_Metadata
Спасибо большое, про прогу mediainfo я в курсе, мне просто интересно почему через стандартные средства windows ничего не отображается. Ибо я раньше я пользовался GUI к ffmpeg — WebMConverter webm for retards, и там даже если через консоль делать после создания файла, метаданные отображались как на пикриле. Вот и интересно может какая-то команда есть. Или дело в библиотеках.
> мне просто интересно почему через стандартные средства windows ничего не отображается
Потому, что, во-первых, им на фиг не сдалось поддерживать все форматы, и, во-вторых, в корпорации каждое добавление кода для работы с патентованными, лицензируемыми и прочими стандартами, некоторые из которых принадлежат конкурентам, проходит через десять кругов с юристами.
Просто прими, что это игрушечная хуйня для детишек и бабушек с дедушками, которой пользоваться невозможно. Конечно, теоретически и практически есть возможность написать не связывающее себя вопросами легальности расширение оболочки, которое для произвольных форматов будет извлекать метаданные и передавать в «Проводник», но желающих поддерживать совместную работу таких вещей со всеми прочими программами и сценариями использования маловато.
ffmpeg.exe -i audio.flac -c:a libopus -b:a 160k -filter:a aresample=48000:resampler=soxr:precision=33 audio.opus
Выходной файл у меня получается 162 кбит/с смотрел через ffmpeg и mediainfo
У меня два вопроса, может знает кто. Почему у меня всё равно не получилось ровно 160 кбит/с? Или так и должно быть 162? Типа точного результата всё равно не будет.
И второй, а вообще нужны ли эти фильтры filter:a aresample=48000:resampler=soxr:precision=33, если я просто ввел ffmpeg.exe -i audio.flac -c:a libopus -b:a 160k audio.opus
И получил такой же идентичный файл по весу и характеристикам. Ничем не отличается.
Или я что-то делаю не так? Или я не верно понимаю? Или надо смотреть спектр?
>Почему у меня всё равно не получилось ровно 160 кбит/с? Или так и должно быть 162? Типа точного результата всё равно не будет.
У опуса битрейт может незначительно превышать указанный - это норма.
>И второй, а вообще нужны ли эти фильтры filter:a aresample=48000:resampler=soxr:precision=33
Технически более качественный ресэмплер, но в реальности скорее всего разницы не услышишь, особенно с гражданским оборудованием низко/среднего сегмента. Но это я так примерно прочувствовал - тесты не искал. Нужно для параноидальных аудиофилов и/или для профессионалов работающих со звуком которым важно максимально возможное качество. Но, опять же, у этих будет не лосси кодек, а несжатый PCM.
Плюс, "aresample" фильтр при снижении битности из f32 по-умолчанию добавляет dithering, а оригинальный ффмпег этого не делает. Тоже рекомендуется добавлять при продакшене на последнем этапе, но в реальности как правило тоже сложно услышать разницу.
https://en.wikipedia.org/wiki/Dither#Digital_audio
>идентичный файл по весу
Размеры в байтах отличаются, но незначительно.
Спасибо, всё стало сразу на свои места, а то я очень долго не мог понять ЧЯДНТ.
Всё ясно: ты не умеешь читать маны.
Идём и смотрим, как параметр «b» обрабатывается конкретным кодировщиком (libopus):
https://www.ffmpeg.org/ffmpeg-codecs.html#libopus-1
> Most libopus options are modelled after the opusenc utility from opus-tools.
https://www.opus-codec.org/docs/opus-tools/opusenc.html
> --bitrate N
> In VBR mode this specifies the average rate for a large and diverse collection of audio.
> --vbr
> Use variable bitrate encoding (default).
И в ffmpeg этот же режим по умолчанию (что логично).
Понимаем, что указанные параметры означают, что libopus будет использовать режим переменного битрейта, подобрав параметр уровня сжатия так, чтобы среднестатистический аудиофайл оказался примерно заданного объёма. При этом на отрезки тишины будет потрачено очень мало бит, а запас уйдёт на сложные для кодирования части. Если же файл нестандартный (какие-то искусственные шумы, куча перегруза и так далее), то предсказание размера может ошибаться намного сильнее.
В более старых кодеках уровень сжатия для VBR задавался непосредственно пользователем, а общий объём получался такой, какой получался. Следовательно, пользователь либо по опыту, либо после пары тестовых прогонов подбирал циферку, если хотел иметь данные нужного объёма (например, звуковую дорожку). Можно сказать, что в кодировщике Opus на самом деле используется режим ABR, только вместо распределения фрагментов высоких и низких битрейтов внутри буфера в столько-то секунд делаются предположения сразу о всём потоке целиком.
Ну а для каналов фиксированной ширины и задержки, форматов, в которых каждый кусочек данных должен быть своего размера и на своём месте, и всяких потенциальных аппаратных декодеров для одной задачи с минимальным буфером приёма есть режим CBR.
На второй вопрос ответ прост: если ты не интересовался разницей в алгоритмах ресемплинга и не замечаешь никакой разницы в звуке, то абсолютно всё равно, как делается ресемплинг, внутри кодировщика, или дополнительным фильтром. Кодирование с потерями потом всё равно изменит аудио гораздо сильнее, чем на этом этапе. Ну а если там какие-то тестовые сигналы или научные данные, где важно без изменений хранить всё до верхней границы частот, то человек, который использует оптимизированный под восприятие человеком звуков кодек для сжатия произвольных данных, в любом случае технически неграмотен.
Просто есть много людей, которые возятся с интересной игрушкой и часами подбирают какие-то уникальные коэффициенты фильтров, не понимая, что после какой-то границы на практике разница не слышна будет.
>>3574253
> У опуса битрейт может незначительно превышать указанный - это норма.
Это ответ, не являющийся ответом. Очевидно, дальше должны следовать вопросы, почему бы просто не перенормировать в таком случае шкалу битрейтов, чтобы она соответствовала реальным, почему у других кодеков не так, в чём вообще смысл, и так далее.
Спасибо, анон, за предельно развернутый ответ.
>Всё ясно: ты не умеешь читать маны.
Ты прав, я обыватель ламер, просто в свободное время балуюсь с ffmpeg. И как ламер просто ищу самый короткий и простой путь — простое повторение за другими.
https://2ch.hk/mu/res/1961599.html#1975143
Как можно перекодировать пачку видео, с разными датами изменения\создания, но чтобы перекодированные видосы имели такую же дату изменения\создания. Ибо я ебанусь каждому файлу по отдельности прописывать даты. А мне нужны оригинальные даты.
Через PowerShell.
Сохраняешь оригинальные даты в переменные:
$Creation = (Get-Item "File.ext").CreationTime
$Modified = (Get-Item "File.ext").LastWriteTime
Далее делаешь перекодирование и задаёшь уже новым файлам оригинальные даты:
(Get-Item "File.ext").CreationTime = Get-Date $Creation
(Get-Item "File.ext").LastWriteTime = Get-Date $Modified
Ну когда даже на старом новом целероне 2010 года лагает до единиц фреймов в секунду, сразу видишь
ну или на сенсорном телефоне
SSD не у всех, попробуй посмотреть свой 6200 kbps с диском 5400 rpm подключённым по usb 1.1
>>3575807
Не, речь точно не про проблемы с воспроизведением. Контекст такой: юзер создал раздачу на трекере, но модер указывает на излишок битрейта. Предпологая, что он знает о чём говорит и это не его больная прихоть, я хочу понять - как он это понял, по каким критериям?
О, это уже звучит интереснее, я что-то такое и предполагал. Я присваивал вручную через powershell, но это дроч конечно.
Я в скриптах не секу. Но судя по всему это всё равно делается для каждого файла? Нужно имя файла вписывать.
Или можно спарсить список файлов и из них взять данные, допустим. А как потом привязаться к новым?
У меня там разные видео, есть с айфона .mov, есть со старого телефона 3gp, есть с камеры тоже какой-то не .mp4, есть с нового телефона .mp4 и когда их перекодирую туда добавляется _1 в название.
Похоже только ручками каждое.
Нe пытaйся пoнять бoльных дeдoв с phpBB фopумoв. Вoт в их дeтствe был нижe битpeйт и хуй стoял, a eщё увoжaeмый peлизёp =MeGaPiHar= сo вpeмeн HDD пoдключeных пo usb 1.1 eбaшит peлизы пo oднoму шaблoну, чтoбы фaйлы нa eгo Sanyo игpaлись.
https://ru.wikipedia.org/wiki/%D0%97%D0%B4%D0%B5%D1%81%D1%8C_%D1%82%D0%B0%D0%BA_%D0%BF%D1%80%D0%B8%D0%BD%D1%8F%D1%82%D0%BE
ChatGPT открой, он тебе подскажет по каждому вопросу и напишет скрипт.
>ChatGPT открой
Я даже не знаю как к нему доступ получить. И не интересовался.
Накидал тут какой-то хуйни. Чувствую себя программистом.
Скрипт запрашивает полное имя файла который я конвертировал. Прописывает в новый файл его дату, а сам оригинал удаляет. (Новые файлы записываются в ту же папку с суффиксом _1
И скрипту похуй на формат исходника.
Хоть всё ещё надо каждый файл пердолить, но мне уже надо только лишь скопировать - вставить имя.
$open = 1
while ($open -eq 1)
{
$original = Read-Host "ORIGINAL"
$converted = $original
$converted = $converted -replace ".{4}$"
$converted = $converted + "_1.mp4"
$date = (Get-Item $original).LastWriteTime
(Get-Item $converted).LastWriteTime = Get-Date $date
Remove-Item $original
}
>ChatGPT открой
Ебать, что ж ты раньше не сказал, я два часа проебался изучая этот powershell паршивый. А оказывается всё было проще...
Описал ему что я делаю и что мне нужно. Решил прям всю папку обработать, типа - найди копии файлов с суффиксом вставь туда дату из оригинала и оригинал удали.
Он мне написал скрипт и всё работает нахуй. Я просто путь папки вставляю и ВСЁ.
Причём я нашёл только gpt4 мини бесплатный без регистрации и смс, и он всё смог. ОХУЕТЬ. Дед осваивает технологии. Чатжпт - голова.
Честно говоря я немного вахуе. Сам бы я ещё часа 2 курил мануалы.
>нашёл только gpt4 мини бесплатный без регистрации и смс
Поделись, раз уж нашел.
Жаль, что там лимит постов в день есть, но спасибо за инфу.
Эмм, там как раз лимита нет. Просто требует удалить лог и начать с начала если лимит токенов перевалит.
>Людей, которым действительно нужно такое качество (очень медленный интернет, например, или смотрят с кофемолки), очень мало
У тебя же инсайд со статистикой прямо из гугла?
При хоть сколько-нибудь большом количестве просмотров (не буду даже считать нижнюю планку) перекодировать выходит дешевле. Почему? Да потому что трафик стоит денег.
>Я даже не знаю как к нему доступ получить
https://duckduckgo.com/chat
Там только мини. Хотя как выяснилось и его хватило.
Для звука битрейта 128 вроде бы и мало, особенно для mp3/aac, но на деле вполне можно слушать. Сам перегонял митол в опус с таким битрейтом (экспериментировал с экономией места на мобилке, музяки много), или в дизере слушал, почти нормальный звук выходил. Аудиокниги вообще встречал в mp3 64~96 cbr, которые вполне нормально слушать можно было без крови в ушах. А в случае с маняме иногда натыкаюсь на озвучки второсортных тайтлов условного анидаба имею ввиду озвучки до распада команды, когда они нормальными были с такой блядской кашей вместо звука, будто там mp3 64 cbr битрейт в пике, и то только в одной из изначальных дорожек. При этом mediainfo и спектр показывают вполне терпимые aac lc 128 vbr.
Схуя вместо звука абсолютная каша, причём даже в разговорах без других фоновых звуков?
Первые два пика с сайта анидаба (из плеера, не с торрента), 3 и 4 - та же озвучка из плеера kodik на манямего.
ffmpeg -i "1.mkv" -c:v libsvtav1 -preset 6 -pix_fmt yuv420p10le -crf 28 -svtav1-params tune=0:irefresh-type=1 svt.mkv
с аудиодорожкой разобрался, но видео не проматывается
В смысле, не проматывается? Результирующая последовательность не позволяет поиск осуществлять?
каво?
в плеере эсли на любое место перематываю то видео тупо зависает
Кодирование нагружает все доступные ядра цп, елси не выставлены ограничения? Т.е. чем больше у процессора ядер и потоков, тем эффективнее процесс?
Где видел утверждение, что реализация libx265 в ffmpeg'е не самая эффективная, а вот у самих разработчико она хорошая и лучше пользоваться ей. У меня не получилось нагуглить где и что надо искать, реквестирую помощь. Если такое вообще на самом деле есть.
>Кодирование нагружает все доступные ядра цп, елси не выставлены ограничения?
Да. Пытается.
>Т.е. чем больше у процессора ядер и потоков, тем эффективнее процесс?
Вычислитеььная эффективность растёт чуть медленнее, чем число использованных ядер. Эффективность сжатия в смысле соотношения «коэффициент сжатия — показатель искажений» с ростом числа потоков немного падает.
>Где видел утверждение, что реализация libx265 в ffmpeg'е не самая эффективная, а вот у самих разработчико она хорошая и лучше пользоваться ей.
Одинаковая реализация. В моём Дебиане libx265 с ffmpeg даже слинкована динамически. Рычаги управления через x265-params вроде бы в полном объёме присутствуют.
>У меня не получилось нагуглить где и что надо искать, реквестирую помощь. Если такое вообще на самом деле есть.
Уживительно. Есть же официальная документация на ffmpeg. А есть doxygen-путеводитель по исходникам.
>>3579652
Попробуй убрать :irefresh-type=1. Я больше 2 лет назад говорил дегенерату mEgApRo17, составившему гайд копипастом из гугла, что у меня аналогичная проблема, вроде ещё процессор сильнее грузился, и спросил, зачем он вообще добавил этот параметр, а он и сам не в курсе, тупо надёргал строчек из реддита, но ничего в гайде не исправил, потому что для малолетнего дебила англоязычные авторитеты важнее отзывов из треда.
> Уживительно. Есть же официальная документация на ffmpeg
Я подумал есть сайт/гит разрабов с собственной реализацией, самой лучшей, а ffmpeg оттуда берет исходники и встраивает их к себе. Я не так глубоко еще разобрался в теме.
Оказалось еще есть AV1, он вроде даже лучше и близкок к некоему VP9. Но там нюансы по качеству/времени обработки. Буду вскрывать эту тему глубже.
Я просто пекарню обновляю, решил все-таки проц мощнее взять (12700к) из-за ядер, в т.ч. потому что хочу очень много видеоконтента сжать.
> В моём Дебиане
Для новичка lmde сложноват будет, лучше с обычного минта начать?
Спасибо за пояснения.
>Я подумал есть сайт/гит разрабов с собственной реализацией
Да. И основа их реализации — это библиотека, в дополнение к которой существует консольная утилита, которая организует ввод—вывод данных с библиотекой и управление настройками через ключи в командной строке.
> самой лучшей
Это наивная абстракция, имеющая отношение к философскому заблуждению вроде метафизической крайности. А «лучший» — вообще категория эмоциональная. На деле h.265 — это актуальный современный стандарт, отвечающий компромиссом на требования по качеству сервиса, плотности телекоммуникационных каналов, унификации и доступности вычислительных ресурсов. libx264 — это библиотека с программной реализацией этого стандарта и собственными наработками в смысле критериев качества и алгоритмов решения оптимизационных задач. Сам стандарт имеет недостаток, в основном, в том, что на каждой из нескольких сотен его страниц по четыре патента, а принадлежат патенты циничным и жадным барыгам. В результате хорошая вещь не то, чтобы лежит без дела, но применяется чрезмерно ограниченно.
> а ffmpeg оттуда берет исходники и встраивает их к себе
Творческий коллектив ffmpeg пишет прослойку для поддержки взаимодействия с библиотекой libx265 и прочими подобными, чтобы интегрировать её на общих основаниях в собственный конвейер. Здесь интеграция сугубо взаимовыгодна, т. к. ffmpeg способна при практическом применении libx265 выполнить много сложных задач, сопряжённых с кодированием, но не касающихся кодирования непосредственно. Так же и ffmpeg престижно иметь возможность использовать современный кодек в поддерживаемых.
> Я не так глубоко еще разобрался в теме.
Статьи на Википедии в помощь. Про h.264, h.265, а также vp8, vp9 и av1 там на английском есть толковые статьи. Они дают общее представление.
Запрещённая и осуждённая на территории РФ организация.
>Оказалось еще есть AV1, он вроде даже лучше и близкок к некоему VP9. Но там нюансы по качеству/времени обработки. Буду вскрывать эту тему глубже.
Традиционно отмечу, что всё не так однозначно. Оценивать качество картинки на глаз непросто. Можешь почитать про метрики VMAF от другой осуждённой и запрещённой на территории РФ организации. Я бы не стал сравнивать эти штуки в лоб. Они технически отличаются друг от друга куда меньше, чем политически и исторически.
>хочу очень много видеоконтента сжать.
Я редко видел действительно стоящие обоснования для таких действий. Впрочем, тебе виднее, но зачастую неверные представления о целях приводят в тупик при попытках исполнения.
>Для новичка lmde сложноват будет, лучше с обычного минта начать?
Не могу тебе дать рекомендации. Я использую на домашнем компьютере и на рабочей станции только линуксы с KDE с 2006 года, а конкретно только Дебиан использую с 2009 года, да, и голая консоль у меня тревоги не вызовет.
>Поясните плиз за шакальный звук в маняме и не только.
>AAC, 128 kb/s
Тут может быть несколько вариантов одновременно:
- Перекодировали уже сжатый lossy кодеком звук еще множество раз.
- Выбрали CBR опцию кодирования вместо VBR.
- Выбрали встроенный AAC-энкодер FFmpeg вместо qaac или libfdk_aac.
Ты написал, что там было VBR, но известные мне AAC-энкодеры всегда выдают VBR или ABR (который в Mediainfo помечается как VBR, а в FFmpeg для удобства активируется параметром -b:a и на вики подписан как CBR). Плюс, в режиме VBR почти невозможно подогнать битрейт под указанные 128/192 kb/s. Он всегда будет в определенном промежутке, который зависит от выбранного параметра качества.
Я сконяюсь к тому, что использовали встроенный AAC-энкодер FFmpeg в "CBR" режиме. Fraunhofer FDK AAC не доступен в стандартных версиях программ — нужно самому компилировать исходники FFmpeg или его оберток (HandBrake/XMedia Recode), чтобы использовать этот энкодер. Про VBR я уже расписал выше — указать 128 kb/s там не получится.
https://trac.ffmpeg.org/wiki/Encode/AAC#native
https://kokomins.wordpress.com/2019/10/10/anime-encoding-guide-for-x265-and-why-to-never-use-flac/#ffmpeg-30
Кодировал точно так же как и ту которую скину следующим постом. Единственная разница, здесь добавил vf scale=-1:720.
ffmpeg.exe -hide_banner -ss 3:04 -to 4:10 -i "me_run_source.mp4" -c:v hevc_nvenc -b:v 4600k -c:a libopus -b:a 64k -preset slow -vf scale=-1:720 me_run2.mp4
Так блядь, а почему теперь она есть? Я её только что в /v/ постил, и там превью нет.
На 2ch.hk иногда просто так ломаются превью, от тебя это не зависит.
С шебм в vp9 такого не наблюдал. Интересно, с чем это связано.
У меня иногда и в vp9 ломались превью. Скорее всего это из-за новой системы генерации превью (которой уже лет 5+). Она выбирает случайный кадр из видео вместо дефолтного первого.
Насколько я понял, кодеки чем новее, тем эффективнее сжимают, но тем менее читабельны на разных устройствах.
h264 - старый, неэффективный, но читается на любом старом оборудовании
vp9 - новее, эффективнее
av1 - модно, эффективно, но может не везде поддерживаться.
В итоге на практике, как часто возникает проблема из-за того что vp9 или av1 где-то не воспроизводятся?
Алсо оффтоп вопрос: vp9 не всегда значит меньше в размерах? Я однажды скачал видео через yt-dlp и сравнивал их размеры. Скачивал в best-audio, так что звуковая дорожка на всех файлах одна. Красным на скрине отметил итоговый размер файла в МБ.
Итого у меня получилось что avc1 (232 и 136) весят мало, но когда я открыл видео - картинка явно шакальная.
vp9 (609 и 247) весят больше, но качество видео в них лучше чем у avc1. Я немного в ступоре с этого. Это ок, что в разных кодеках картинка отличается? Я предполагал, что картинка будет +- одинаковая, отличаться будет только размер. Но по факту отличается еще и качество видео.
av1 (398) - небольшой размер и качество хорошее как на vp9.
В итоге для скачки нет какого-то универсального совета? Почему такое различие в качестве между avc1 и vp9/av1? Я думал видео будут отличаться только размером.
Айди видео yKsKmdhIQ7U
Решил ради интереса перекодировать 20 минутный ролик из h264 в vp9, посмотреть что будет.
Почему то когда конвертируешь музыку, например 5-гиговый хайрез из 24bit/192kHz в обычные 16/44.1, уходит несколько секунд, ну минута. А тут 400 МБ ролик ждать минут 25.
Команду вбил просто в чатгпт: мол как сконвертить из h264 в vp9
ffmpeg -i in1.mp4 -c:v libvpx-vp9 -crf 30 -b:v 0 -cpu-used 4 -c:a libopus out1.webm
Может че-то не так с командой?
Скачал твое видео в 4к, vp9 и av1, разницы почти не заметно, но av1 почти в 2 раза меньше.
Ну да, кодирование видео гораздо более ресурсоемкая и сложная задача, чем кодирование аудио. Ну и vp9 сам по себе медленный. Чтобы увеличить скорость (и понизить качество при тех же настройках битрейта или crf) - увеличивай cpu-used (максимум 8 для vp9). Еще сильнее увеличить скорость может "-deadline realtime". По умолчанию стоит "good". Еще доступна опция "best", но с ней скорость очень медленная - так, на всякий случай.
Понял. Я решил пока на h264 остаться.
Вот с этой командой на моем компе скорость кодирования х9-11, а качество для меня приемлемое.
424 мб сжал до 179 - это 2.36 раза. Норм.
ffmpeg -i input.mp4 -c:v libx264 -crf 25 -preset veryfast -c:a aac -b:a 128k -threads 0 output.mp4
Зависит от твоих задач.
Есть поддерживающее железо и хочешь хранить видео эффективно? AV1 - ничего лучше на данный момент нет.
Нет железа с аппаратным ускорением AV1, но всё равно хочется хранить эффективно? VP9, декодируется на всём что новее Core 2 Duo.
Если хочется смотреть на Core 2 Duo, и при этом есть очень много места или тебе наплевать на качество? H264 твой осознанный выбор.
Это если по верхам.
>В итоге на практике, как часто возникает проблема из-за того что vp9 или av1 где-то не воспроизводятся?
Буквально лет пять назад AV1 нигде и ничем не воспроизводился, я не мог получить декодирование без дропов на i9-9900k даже для простенькой webm с битрейтом в 1500, которую делал кто-то из анонов, возможно это было даже в этом треде.
Сейчас аппаратный декодер завезли много куда, так что в будущем особых проблем не будет.
А для чего-то более старого можно всегда будет перекодировать из AV1 в h264 используя аппаратные декодеры современных видеокарт. Будет быстро и безболезненно.
>vp9
Формально устарел.
Смотри на AV1, H265, H266.
>vp9 не всегда значит меньше в размерах
Средняя эффективность компрессии в VP9 в сравнении с 264 кодеком - 30-50%, в зависимости от разрешения и сложности сцен.
У AV1 она ещё выше, выигрыш от 40% и до 60%, может быть больше.
То есть, условно, при одинаковом качестве файл в H264 будет весить 100 мегабайт, в VP9 60 мегабайт, а в AV1 40 мегабайт.
Но ты можешь сделать все файлы по 100 мегабайт, и если твой источник видео позволяет, то лучшее качество видео будет в AV1, потому что в указанный размер он поместит больше всего информации.
>В итоге для скачки нет какого-то универсального совета?
Не использовать h264 в 2025 году ни для каких целей.
>>3583239
Нормально для этих настроек.
>ffmpeg -i in1.mp4 -c:v libvpx-vp9 -crf 30 -b:v 0 -cpu-used 4 -c:a libopus out1.webm
Да, не так.
>-b:v 0
Вот эта опция не работает когда ты используешь опцию cfr.
>-cpu-used 4
Это автоматическое включение шакалов, так как "4 or 5 will turn off rate distortion optimization, having even more of an impact on quality". Лучше всё же использовать 3. Это чуть медленнее, но эффективнее.
Вообще это одна из самых главных опций. По умолчанию значение 0, то есть лучшее качество, так что указывать желательно, иначе скорость кодирования будет 0,6.
Я сейчас использую такое.
.\ffmpeg.exe -i input.mp4 -c:v vp9 -b:v 1000k -pass 1 -threads 8 -tile-columns 2 -tile-rows 0 -frame-parallel 1 -row-mt 1 -quality good -pix_fmt yuv420p -cpu-used 3 -auto-alt-ref 1 -enable-tpl 1 out.webm
Но, есть загвоздка, вот эти -tile-columns 2 -tile-rows 0 валидны только для 720p, для других разрешений нужны другие, чем выше разрешение, тем больше тайлов может быть, тем больше можно распараллелить задачу, а значит и ускорить кодирование.
--threads=8 тоже может быть нужно поправить, смысла давать слишком много потоков нет, потому что распараллеливаться всё будет только когда у тебя будет много колонок и рядов. В моём примере их всего 4. Но, если хватает разрешения, то можно использовать четыре ряда установив -row-mt 2 (2^2=4 рядов), что вкупе с -tile-columns 3 (2^3=8 рядов) даст целых до 32 тайлов, но это возможно только с 4к видео. У меня стоит 8 просто чтобы не переписывать команду каждый раз.
Короче почитай вот тут, если интересно. https://stackoverflow.com/a/41384506
А вообще, вот хороший пост про vp9 и его опции.
https://www.reddit.com/r/AV1/comments/k7colv/encoder_tuning_part_1_tuning_libvpxvp9_be_more/
>>3583245
>увеличивай cpu-used (максимум 8 для vp9)
Не надо так. 4 ещё можно, 5 уже пиздец.
>>3583248
Скорее всего у тебя есть видеокарта. У неё есть аппаратный кодировщик. Сможешь им быстрее кодировать чем на процессоре. А может у тебя и в процессоре есть хороший аппаратный кодировщик.
>-crf 25 -preset veryfast
Ужасно, veryfast даже с crf 18 заметно портит картинку.
https://trac.ffmpeg.org/wiki/Encode/VP9
you must use a combination of -crf and -b:v 0. Note that -b:v MUST be 0. Setting it to anything higher or omitting it entirely will instead invoke the Constrained Quality mode.
Ну да, согласен, значит я с чем-то перепутал, возможно в vp8 было так.
В любом случае, они сами рекомендуют Constant Quality только для тех случаев когда лень делать два прохода.
А касательно Constrained Quality, гугл у себя в доках рекомендует этот режим для VOD, что в общем-то интересно.
https://developers.google.com/media/vp9/settings/vod?hl=ru
>В итоге на практике, как часто возникает проблема из-за того что vp9 или av1 где-то не воспроизводятся?
C VP9 не возникают уже.
С AV1 так чтобы не играло совсем редко, но ещё довольно часто оно жрёт батарейку или процессор слишком сильно.
H.264 на самом деле уже чаще не играет, потому что она на линуксах обычно не установлен.
>Это ок, что в разных кодеках картинка отличается? Я предполагал, что картинка будет +- одинаковая, отличаться будет только размер.
Кодек – это алгоритм, а у каждого ещё 100500 параметров. Да и видео не все одинаковые, кодеки и их параметры по-разному себя ведут на разном контенте.
Их кручением чего угодно можно добиться и дооптимизироваться до того что H.264 будет меньше AV1 у конкретного видео и гигабатных шакалов можно накодировать...
>В итоге для скачки нет какого-то универсального совета?
Его вообще нет.
Я бы советовал хранить в оригиналах какими бы они ни были. Транскодировать и внести артефактов кодирования всегда можно.
>H.264 на самом деле уже чаще не играет, потому что она на линуксах обычно не установлен.
Откужа такие сведения?
> H.264 на самом деле уже чаще не играет, потому что она на линуксах обычно не установлен.
Что за бред я только что прочитал. Даже если libx264 каким-то чудом не установлена изначально, она ещё стопицот лет будет зависимостью ко всем возможным плеерам.
Яблочные платформы в счет не берем.
Там то как раз всё нормально уже.
Последние проблемы были с опусом который с вп9 обычно в паре, но уже несколько лет как всё свежее железо и свежий софт всё играет.
Собственно, поэтому в среднем по больнице вп9 теперь уже самый беспроблемный кодек.
Сейчас батником сжал несколько видео в папке одной командой - одно видео сжалось в 1.6 раза, другое - аж в 3 с лишним. По времени тоже разница бывает. Иногда кодируется со скоростью х3, иногда х6.
Все это с одинаковым пресетом и одинаковым crf
Немного оффтопа - мне кажется дипсик лучше пишет батники - они работают с 1-2 раза. А чатгпт иногда и с 5го раза не справляется.
В ChatGPT была выбрана модель o3-mini? Если нет, то понятно почему результат оказался хуже.
Вот тебе две картинки, у обоих в бмп одинаковый размер, а в жипег сжались почем-то по-разному, непонятно.
> Не использовать h264 в 2025 году ни для каких целей
Если важно качество и однородность картинки, то можно использовать, ав1 никогда и не планировали избавлять от обсёров вп модели.
>мне чел сказал
ну и тут логичный ответ что нужно и спросить у этого чела, но нет
Кодировать можно. Монтировать - нет. Наверное, слова перепутал.
И монтировать можно, но это неудобно.
все таки неудобно , я то спрашивал что это удобнее
В общем, теперь скриншоты делаю как обычно через sharex и там есть опция action с последующей автоматической перекодировкой. 4к картинки с пнг 8631кб вес, сразу до 643кб jpegli. По качеству с лупой проходился разницы нет с q 90 даже, с 95 вообще нет.
Гугл пережевал xl и рил сделал эволюцию.
>Шапку не читал, сразу пишу с вопросом
я отж джиза
>какой командой можно сжать 290 видосов внутри папки
Если сразу в cmd (не батником), то сначала перейди на диск в твою исходную папку:
d:
cd 290vidsfolder
Потом создай там папку compressed:
mkdir compressed
и пробуй конвертить примерно так:
for %i in (*.mp4) do ffmpeg -i "%i" -c:v libx264 -preset slow -crf 25 -c:a copy "compressed\%~ni_comp.mp4"
Нужное расширение в маске для перебора и параметры сжатия подставь сам.
Можно ли как-то переделать у фотографий цветовое пространство с Display P3 на нормальный sRGB?
Scale фильтр не меняет этот профиль и фотошоп всё ещё показывает P3.
Colorspace фильтр же просто жидко пердит ошибкой "Unsupported input primaries 2 (unknown)", даже с указанием "-colorspace bt709 -color_trc bt709".
Format фильтр тоже шиша не меняет, даже если бахнуть "gray".
>фотографий
Тебе Image Magic тред нужен, поехавший. Там -profile и всё.
Но P3 шире, поэтому сначала выбирай какой сорт говна ты будешь есть, в эту сторону нормальной конверсии не будет.
У меня там фотографий over9000 и их надо ещё уменьшить, по одному я этим заниматся не буду.
>У меня там фотографий over9000 и их надо ещё уменьшить, по одному я этим заниматся не буду.
Ты не поверишь, но imagemagick как раз для такого и нужна.
Если бы ты погуглил, или спросил нейросеть, то узнал бы, что imagemagick — это библиотека для преобразования растровых изображений и набор консольных утилит на основе этой библиотеки. Основной сценарий использования — это применения для пакетной обработки изображений сценариями на bash. Например, такими как у Фреда http://www.fmwconcepts.com/imagemagick/index.php
Во, это крутая утилита.
Но вопрос с FFmpeg всё же интересен, он вроде тоже может менять цветовое пространство, но при этом говорят там очень много подводных.
Например тот же фильм с какого нить YOBA 10 бит HDR переделать под 8 бит bt709 уже более важная и менее шизовая задача для FFmpeg.
Ффмпег работает с видео цветовыми пространствами, а не с изображениями. Это разные вещи. Ну и работает хуëво.
Конкретная задача — конкретное решение, никакой общей шизоидной интересной темы.
>>3587498
> Но P3 шире, поэтому сначала выбирай какой сорт говна
Хуета. О того что у тебя мамкины фиалки в солнечных лучах прямых потеряют кислотные оттенки фотки сортами говна не станут.
>Ну и работает хуëво.
Ну как поглядел да, на это жалуются что он делает это плохо и с кучей проблем, наверное то что для FFmpeg пока является одной из серьёзных проблем.
Как в прочем точная обрезка медиа по миллисекундам и склейка, чтобы не попадал мимолётный пук из заставки в обрезанную версию из-за того что он игнорирует отставание звука при этом действии как я понял.
А ведь этот анон >>3585505 даже спрашивал про монтаж.
>Но P3 шире, поэтому сначала выбирай какой сорт говна
>Хуета. О того что у тебя мамкины фиалки в солнечных лучах прямых потеряют кислотные оттенки фотки сортами говна не станут.
Притом что при заливке во Вконтактик фото и так будут преобразованы в sRGB профиль (пока ты смотришь на них через браузер). И честно сказать, лучше хорошо сделанное фото со смартфона в удобном sRGB, чем YOBA профили по типу Adobe RGB и Display P3, которые галерея андроида никогда не сможет нормально обработать как и веб-ресурсы.
Все устройства с SDR экранами показывают именно sRGB. И то иногда не со 100% точностью, лол.
>точная обрезка медиа по миллисекундам
Ты сначала сними видео ровно по миллисекундам. Только 50 фпс из популярных бьётся в целые числа.
В контейнерах время вообще в условных единицах вида рациональной дроби хранится, у каждого видео размерность числителя и знаменатель свои. По ним только и можно ровно резать если ты хочешь по кадрам.
Насчёт точной резки видеопоследовательностей скромно напомню вам, почтенные, что если у вас к видео прилагается звук, то у такой дорожки своя частота дискретизации, не обязательно кратная кадровой для видеоряда. А если звуковая дорожка ещё и сжата была с потерями, то она сама на кадры побита — а там размер кадра зависит от стандарта сжатия: какие-то ориентируются только на число отсчётов в кадре, другие на длительность восполизведения кадра, но своего, звукового. При усечении закодированных последовательностей ffmpeg пытается заботиться о синхронизации, выставляя соответствующие задержки в контейнрах, но я бы особо на это не полагался.
>>3587492
>>3587699
>>3588032
>>3588034
Касательно же точного покадрового монтажа или колориметрических преобразований, я бы отдал это на откуп не ffmpeg, а какому-нрбудь фреймсерверу — avisynth, vapoursynth. Они специально для такого и сделаны.
В принципе щас перетест сделал и разницы практически нет, сорс чуть больше деталей имеет. Ну и поддержки jxl нигде нет лол. До этого овершарп дикий был, особенно на молнии заметно было.
Еще непонятно в какой проге сравнить. Делал в xnviewmp. Jpegli чучуть меньше микродеталей.
https://dropmefiles.com/PYLfA
Jxl сюда не грузит
Для меня полуюзабелен, потому что срезает из файлов srgb профили, а я придерживаюсь мнения, что изображение без профиля это поломанная хуета.
Но вообще пушка, часто лучше вебп по моим тестам. Сейчас у меня в скриптах прописан мозжпег для изображений с сргб, а для широкого профиля стоит жпегли.
Кстате, если напрямую нормально настроенный мозжпег с жпегли сравнивать, то вау-эффекта нету и много вкусовщины от картинки к картинке, при том что в целом жпегли скорее чуть лучше где-то его мыльцо хуже заходит.
>где скачать батник
Какой еще батник?
>Последняя версия не запускается
Если ты про ффмпег, то только проверил и отсюда
https://github.com/AnimMouse/ffmpeg-stable-autobuild/releases/download/2025-03-07-17-13-6ae81d8-7.1.1/ffmpeg-7.1.1-6ae81d8-win64-nonfree.7z
у меня работает на семерке.
странно
у меня не запускается, чё за хуйня
Официальные билды для Win 7 - все.
https://github.com/GyanD/codexffmpeg/issues/136
Там же ссылка на костыль, которы позволяет запускать.
https://github.com/cristianadam/api-ms-win-core-synch-Win7
VxKex тоже работает.
Я по одной серии устал это делать, долгие часы гугления ни к чему не привели, то, что предлагает deepseek вообще не работает. Помогите кто чем сможет
Вроде как встроенная в CMD возможность ввиде "FOR" должна позволить это сделать.
По идеи это должно у тебя выглядить вот так, переделал пакетную замену звука на субтитры (не проверял).
for %F in (*.твой контейнер) do "ffmpeg.exe" -i "%~nxF" -vf subtitles="%~nF.srt" -c:v твой кодек -c:a твой кодек -y "hardsub\%~nxF"
>Почему у меня всё равно не получилось ровно 160 кбит/с? Или так и должно быть 162? Типа точного результата всё равно не будет.
This
То же самое происходит с aac. Почему именно так? Потрму что кодек заточен на переменный битрейт, то есть будет плюс-минус,а не ровное значение. Ровные значения это уже cbr, а не vbr.
>>3577930
Анон, 128 кбпс у mp3, opus и других форматов это две большие разницы.
mkv и mp4 - это контейнеры, они не имеют отношения к качеству
Скорее всего ты про сравнение кодеков vp9 и h264
vp9 - новее и лучше сжимает, поэтому при одинаковом битрейте видео на нем будет лучше
В mkv ты можешь засунуть и vp9, и h264
Спасибо за объяснение.
В чем преимущество использования консольного FFmpeg над, скажем, Shotcut? Позволит ли его использование получить для одних и тех же кодеков лучшее качество видео при одинаковом среднем битрейте (за счет каких-нибудь доп. настроек, недоступных Shotcut)?
Какие вообще параметры сильнее всего влияют на качество видео при сжатии с заданным средним битрейтом (помимо самого битрейта)?
> Какие преимущества имеет SVT-AV1 над AOM AV1?
Быстрее кодирует, теряя в качестве.
> Возможна ли ситуация когда браузер будет без проблем воспроизводить видео, пожатое AOM AV1, но не сможет воспроизвести видео, пожатое SVT-AV1?
Нет.
> В чем преимущество использования консольного FFmpeg над, скажем, Shotcut?
В том, что не ставишь мокрописек поверх мокрописьки. Там команд три штуки, нахуя тебе гуй для них?
> Позволит ли его использование получить для одних и тех же кодеков лучшее качество видео при одинаковом среднем битрейте (за счет каких-нибудь доп. настроек, недоступных Shotcut)?
Нет, если мокрописька никакой хуйни не делает лишней.
> Какие вообще параметры сильнее всего влияют на качество видео при сжатии с заданным средним битрейтом (помимо самого битрейта)?
В контексте твоего вопроса, скорее ничего не влияет, кроме режима скорости енкодера. Кодируешь дольше — качество выше. Кодируешь быстрее — качество ниже.
Насколько сильно теряет и насколько быстрее кодирует? В среднем, на одинаковом битрейте.
>В том, что не ставишь мокрописек поверх мокрописьки. Там команд три штуки, нахуя тебе гуй для них?
Ну видео еще точно обрезать надо, иногда склеить несколько кусков. И только потом кодировать.
>В чем преимущество использования консольного FFmpeg над, скажем, Shotcut?
Параметры указываются явно. Можно сохранять команды и анализировать разницу аргументов простым сопоставлением текста. Одна строка в этом смысле оцень сильно компактнее, чем куча окон и вкладок с галочками и движками. Опять же, если ты команды сохранял, то по построчному списку этих команд удобно аргументы искать каким-нибудь grep-ом. Ну, и по тексту документации имена ключей искать гораздо удобнее, чем названия галочек. С поисковиками всё то же.
>Позволит ли его использование получить для одних и тех же кодеков лучшее качество видео при одинаковом среднем битрейте (за счет каких-нибудь доп. настроек, недоступных Shotcut)?
Не исключено. Я сам AV1 не испотзовал ни разу. Точно сказать не могу, к сожалению.
>Ну видео еще точно обрезать надо, иногда склеить несколько кусков. И только потом кодировать.
Я предпочитаю не смешивать операции монтажные и чисто технические вроде кодирования. Так-то есть предобработка, монтаж, постобработка, компоновка и кодирование.
>ffmpeg -i input.mp4 -vf "crop=ih*9/16:ih, scale=1080:1920" -c:v libx264 -preset veryslow -crf 19 -c:a aac -b:a 128k output.mp4
хотя в адобе никогда не подымалось больше 60%
>почемy y меня ффмпег жрет 92% цп
>хотя в адобе никогда не подымалось больше 60%
Очевидно, что в Адобе не умеют писать кодировщики и экономят на субподряде, а в результате получаются посредственные кодеки, которые неэффективно используют доступные вычислительные мощности.
Меня больше интересует почему VP9 и SVT-AV1 не могут потреблять ~100% процессора, а только какую-то часть с прыгающим графиком по ядрам.
Видимо потому, что параллельно запускают функционально разделённые вычислительные потоки, а затем синхронизируют их с соответствующими потерями на синхронизацию.
Смотри энергопотребление, а не загрузку.
Оно может быть огромным и при занятии одного ядра на 100%, но это не показатель, ибо остальные ядра то стоят.
То что не всё можно параллельно сделать я знаю, но у 264 почему-то эффективность по ядрам выше.
Просто думаю что из-за этого и без того медленные из-за сложности кодеки ещё медленее чем должны быть, а может конечно проблема в амдшном SMT который те кодеки не видят.
>Либо сам тест провери для своего случая с нужным тебе видео что еще лучше.
Да в том то и дело что не могу - версии Shotcut/HandBrake, поддерживающие SVT-AV1, требуют Windows 10/11. Вот я и думал - стоит ли оно того?
Впрочем уже похуй, я скачал FFmpeg и использую его для этого кодека (а другие, походу, больше и не нужны, АОМ слишком медленный, VP9 проигрывает SVT во всем, H.264 слишком неэффективный, H.265 имеет проблемы с воспроизведением в браузере).
>ffmpeg -i input.mp4 -c:v libsvtav1 -preset 4 -pix_fmt yuv420p10le -b:v 1024k -svtav1-params tune=0:irefresh-type=1 -c:a libopus -b:a 48k output_134.webm
Короче делаю так.
1) Можно ли тут что-то добавить/изменить для лучшего сжатия без потери качества кроме пресета?
2) Может ли 10-ти битное кодирование создать проблемы при воспроизведении в браузере? У меня их не наблюдается, но мало ли.
Ну и примерно прочувствуйте насколько заметна разница в качестве между этими видео.
Эта циферка говно ничего не значащая по загрузке цпу, базарю. Только по потреблению можно ориентироваться. Если он тебе весь свой запас по мощности на одно ядро сожрал, то где он возьмëт электричества на второе, ну ты сам подумай. Ну и нет многопотока там нормального да, можешь на тайлы нарезать в настройках кодера ради ядер и соснуть по качеству, но лучше просто цпу-юзед ослабить, если быстрее хочешь.
>Ну и примерно прочувствуйте насколько заметна разница в качестве между этими видео.
Могу только васянометриками щупать примерно.
PSNR/SSIM/VMAF
Можно ли считать средний VMAF 90+ объективным показателем хорошего качества видео?
Я бы сказал, что шкала приемлемых шакалов от ~80 где-то начинается, если примерно почувствовать, всё что ниже это ебучие шакалы. Всё что от ~96 — вижуали лосслесс.
Единственное, что всякий блокинг ебейший и нестандартные артефакты вмаф может полностью игнорировать и говорить, что видео с ними заебок. Детали-то на месте, а то что всё в квадратах тебя ебать не должно, потому нужно всегда просматривать на артефаченье, прежде чем доверять ему.
А так вообще долгие тесты показали, что показатель достаточно объективный, лучший из тех, что есть во всяком случае.
Конечно можно.
Но объективные показатели – бесполезная хуита для субъктивных проблем.
>поддерживающие SVT-AV1, требуют Windows 10/11
А кто в здравом уме сидит на oc поддержка которой кончилась еще 10 лет назад и на древнем апи
Я его уже убрал после ряда тестов. Но не потому что полученное видео не проматывается илиперегружает процессор.
>>3595126
Ну допустим я сижу. Нет ни одной причины ее менять, это буквально единственный случай когда мне понадобилась программа не совместимая с Windows 7. И даже так "проблема" легчайше решилась отказом от этих программ в пользу FFmpeg.
Еще вопросы?
Ты наверное на ведре сидишь в котором только браузер и видео открывать можно. вообще не знаю зачем в av1 кодировать для хранения h26510bit, не даёт обосранное мыло как vp9/av1, вообще ненавижу как они мылит картинку и блочность дает, особенно когда темные участки как раз где самая большая проблема для энкодеров. h26510bit дискорд поддерживает даже с hdr, а сам же гугловский формат av1 electron почемуто не поддерживает
Еще забыл упомянуть при этом что h265 кодирует легко через nvenc в 300 фпс на видеокарте, даже самые нищие и старые.
>кодировать для хранения
А кто сказал что я для хранения кодирую? У H.265 есть проблемы с воспроизведением в браузере, а значит сразу мимо. И еще неизвестно как он себя ведет на очень низких битрейтах в сравнении с AV1.
>вообще не знаю зачем в av1 кодировать для хранения h26510bit, не даёт обосранное мыло как vp9/av1, вообще ненавижу как они мылит картинку и блочность дает
Наркоман, ты свой шизопоток перед отправкой читать пробовал?
>А кто сказал что я для хранения кодирую? У H.265 есть проблемы с воспроизведением в браузере, а значит сразу мимо. И еще неизвестно как он себя ведет на очень низких битрейтах в сравнении с AV1.
А для браузера тебе зачем? На двощ выкладывать что ли? Не знаю даже, хоть везде и пишут что av1 на 30% эффективнее якобы чем h265, но я нифига этого не вижу. Вижу что h265 лучше. Когда я сжимал в h26510bit 200кб видео в placebo с тонкими настройками результат был намного лучше чем тот же av1 в 200кб. Да и кодируется av1 намного дольше.
Надо самому тоже тесты провести, и померять метриками, но пока что лень этим заниматься. А так выбора и нет особо, для хранению кодирование через nvenc 265 с bf5 для сжатия максимального, а для инета av1 ток. h264 чтобы даже тостер запускал видео. И про h266 пукнули и ничего не слышно больше.
Жалко поддержку в телеки завозить будут еще года 2.
>На двощ выкладывать что ли?
This. Я не размениваюсь по мелочам, а нарезаю сцены длительностью вплоть до 17-18 минут. До сих пор использовал VP9 и временами лютые шакалы получались. С AV1 выглядеть должно ощутимо лучше.
>Pass 2
А обычный 1 pass в CRF тоже будет очень долгим? Просто не понимаю зачем постоянный битрейт в 2025 году, вроде все телеки и браузеры поддерживают VBR режим битрейта. И может ли h266 в 2pass с CRF? Из известных мне кодеков пока только VP9 так может.
>>3594170
Можно вместо тайлов поступить ещё круче, просто разделив видео на сегменты и одновременно запустить кучку FFmpeg с affinity на разных ядрах. Вроде такой прикол для фильтра minterpolate проворачивал, он очень медленный из-за однопоточности, а получить 60 фпс на одном видео надо было. Проблема только склеивать эти сегменты обратно в нужный видос через demuxer.
> Проблема только склеивать эти сегменты обратно в нужный видос через demuxer.
Ffmpeg'вский concat не работает?
>А обычный 1 pass в CRF тоже будет очень долгим? Просто не понимаю зачем постоянный битрейт в 2025 году, вроде все телеки и браузеры поддерживают VBR режим битрейта. И может ли h266 в 2pass с CRF? Из известных мне кодеков пока только VP9 так может.
Так vbr 2pass просто сделал битрейт и ограничил максимальный тоже.
Но у меня метрики сломанные почемуто как будто наоборот показывает именно VVC, может кто шарит как пофиксить.
Субъективно VVC лучше всех выглядит.
>>3596002
Ну это понятно что av1 лучше намного, вроде поддержку ав1 добавили когда движок борды поменяли пару лет назад, зато другие форматы теперь не грузит некоторые.
Если ты про Concat protocol, то он вроде только для .ts, а это уже отсекает довольно большое количество кодеков.
Если про фильтр, то это повторное сжатие что не очень здорово, или надо тратить ресурс диска на несжатые копии.
https://trac.ffmpeg.org/wiki/Concatenate
>>3596306
Понял, хоть я не юзаю VRB из-за CRF, но думаю полезно узнать какой максимальный битрейт стоит ставить, 1 к 2 там или как-то так.
А в 2pass VBR у h264/265 есть смысл против CRF 1pass, качество заметно лучше?
не, я про весь ffmpeg concat
если ты назвал демуксером ffmpeg -f concat, то понятна
Demuxer указан здесь, сам им пользовался время от времени, но он слегка подсирает и ту же webm VP9 склейку пришлось переделывать под обычный фильтр, ибо там на коротком фрагменте выдавал в браузере ошибку что видео дескать нельзя дальше загрузить.
Но вот при склеивании сотни видосов (буквально) что были перекодированны под одни параметры в h264 это прям мощная штука, два цикла в CMD и готово.
Эти значения метрик не показательны. У тебя есть три параметра - время кодирования, коэффициент сжатия и метрика VMAF (качество видео).
Чтобы результаты теста были показательны один из этих трех параметров должен быть одинаковым для всех тестируемых кодеков.
Иные варики фигня, потому что вот у меня есть видео, но оно в AV1, и есть русскоязычная аудио к этому видео, на которое нужно сменить дорожку, но современное видеокарты для конверта в мажорный кодек у меня нет. Тратить x10 дискового пространства не готов, шакалить видео в более старые кодеки – тоже.
Я реально искал такую прогу, Advemux(или как там его) способен только аудио извлекать без конвертации.
Handbrake, помню было можно и без конвертирования
Увы, но такой опции в нем не нашлось. Возможно, что из-за наличия вкладки со сменными аудио-дорожками кажется, что она есть. Наверное, никто не так и сделал такого GUI и придется пользоваться ffmpeg, ибо я нагуглил чей-то батхёрт на форуме из 2012 года и то, как его чморили псевдоолды за его желание заменять аудео без конвертации. А как известно, если настолько простого софта не было в 00е, то его и не будет в будущем.
Возможно, https://ffqueue.bruchhaus.dk/ подойдёт.
>но современное видеокарты для конверта в мажорный кодек у меня нет
Аппаратное кодирование на видеокарте - это больше про скорость кодирования для больших объемов данных в ущерб качеству. Программное выполняет процессор. Если твое видео не на несколько часов то даже не самый новый процессор сконвертит достаточно быстро.
Программа самоликвидируется спустя непродолжительное время, независимо ни от чего. Даже успеть проверить наличие функции не дает.
>самоликвидируется
Wut? Закрывает сама себя и удаляет свою папку из которой была запущена или что?
Процесс уходит по-английски очень даже быстро. Но я как "Джонни — самая быстрая рука" успел подкинуть ей путь до FFmpeg — но с ним тоже вылетает.
Хз, пользуюсь ей уже не первый год - ничего такого ни разу не было. Правда, я на семерке сижу.
Может, у тебя в системе что-то стороннее её процесс прихлопывает?
Да откуда нам знать почему там у тебя все разваливается, ты бы хоть написал чем кодировал, на каком пресете и в каком режиме. Если битрейт совсем не зажимать ничего не разваливается.
Это не у меня, это ютуб такой позор отдает напрямую.
Ну это если ниже чем в 360/480p смотреть. И то буквально пара кадров разваливается, а не весь трейлер. В 720p все нормально.
фикс
А то в вырезанных фрагментах получается по 1-2 сек пустыми
Через avidemux уже пробовал, не вариант, дело в том что там древнее видео в формате wmv9 и если без перекодирования сохранять, то он соотношение сторон портит
> то он соотношение сторон портит
Если проблема только в этом, то дошлифуй sar/dar ффмпегом
Видеокарты не нуждаются в многократных проходах за счет алгоритма, написанного для аппаратного кодирования. GPU настолько мощнее CPU, что оптимальные сценарии для переменного битрейта просто предусматривается наперед.
>>3598417
А перепробовал множество конвертеров и редактором, и почти все из них как-то задействовали инструментарий ffmpeg. Так вот, проблем в процессе не было.
насчет vvc — наверняка "аппаратное" поддерживается в линухе, но щииит... линухи это такие кривые говняшки, бедные на весь остальной функционал, что капец. Еще и GUI-прог на линукс нет никогда.
>"аппаратное" поддерживается
Имею в виду карты 2015-2018 годов, разумеется. Десятая серия нвидиа на многое способна, vvc и av1 не является для них крепким орешком. Просто чмони из нвидия так решили, что гои идут покупать новые карточки ради этих кодеков. Кодек av1 сейчас активно задействуется ютубом, посему все прогеры от нвидиа вовсю трудятся для того. чтобы "майнинг-фермы" ютубовской корпорации на все 100% эффективности использовали карты последней модели для беспрерывной конвертации всех своих видео в этот кодек (ну, и в vp9 еще).
>для беспрерывной конвертации всех своих видео в этот кодек
А потом на выходе вот это >>3598607
>>3598633
Тащемта первый кадр в 720p. И такое мыло стало появляться все чаще. Особенно заметно при резкой смене сцен в видео.
>-crf 23 -maxrate 3M -bufsize 2M
Зачем одновременно писать и CRF и параметры VFR? Выбери что-то одно, либо первое — Rate Factor, либо второе — переменный битрейт. Чем выше значение CRF тем будет хуже качество.
Если видео длиннющее то тут тебя выручит лишь scale фильтр.
-vf scale=X:X
Вместо иксов пишешь желаемый размер, но учитывай DAR/SAR если пиксели у твоего видео не квадратные.
А, насчёт CRF немного ошибся, есть "Constrained encoding" которому те параметры что ты вписал как раз нужны.
Но думаю помимо scale или потери в качестве (ещё более низкий битрейт) тебе ничего не поможет если видео длинное. В крайнем случаи попробуй SVT-AV1 кодек тогда, но его нужно долго и упорно настраивать.
Просто повысь CRF. Если ты этого не понимаешь, то не трогай никакие -maxrate и -bufsize, без понимания только хуже сделаешь. И для двача в H.265 не сжимай, всё равно не заведётся в большинстве браузеров.
>Аноны, выручите пожалуйста командой для сильного (или близко к этому) сжатия видео, желательно без потерь в качестве
>libx264
Этот кодек тебе качество угробит при сильном сжатии, автолуз. 265-ый проблемно воспроизводится в браузере, тоже автолуз.
Я вот так жму сейчас.
>ffmpeg -i Input.mp4 -c:v libsvtav1 -preset 5 -pix_fmt yuv420p10le -crf 25 -svtav1-params enable-qm=1:qm-min=0:qm-max=8:irefresh-type=1 -c:a libopus -b:a 48k Output.webm
>-preset 5
Баланс между качеством и скоростью кодирования, четвертый медленнее примерно в 2.25 раз, шестой быстрее где-то на 20%, разница в качестве между ними незначительна.
>-crf 25
Чем ниже значение - тем выше качество (и битрейт), диапазон 1-63.
>enable-qm=1:qm-min=0:qm-max=8
Включение матрицы квантования, позволяет немного улучшить качество видео (если верить метрике VMAF) без увеличения битрейта. Диапазоны значений 0-15, чем ниже - тем ниже итоговый битрейт (снижает качество, но позволяет снизить значение CRF, улучшив качество, и в сумме выходит лучше). Падение скорости кодирования на 5-10%.
>irefresh-type=1
Еще один параметр, позволяющий улучшить качество без увеличения битрейта (схема та же - снижает битрейт, позволяя снизить значение CRF). Вызывает кратковременное подвисание видео при перемотке в любую точку кроме начала.
Больше полезных параметров (улучшение качества без роста битрейта) не нашел.
Ну а чтобы попасть в 40 Мб в режиме CRF (который не предназначен для получения предсказуемого битрейта) я сначала подбираю значения crf/qm-min/qm-max на десятом пресете (быстрее пятого в 5-6 раз) чтобы выходной файл получился как можно ближе к 40Мб, а потом кодирую на пятом, который сожмет как минимум не хуже.
Режим VBR показал себя говном (медленнее на ~20%, качество чуть хуже чем CRF и точно так же требует подбора параметров для получения нужного битрейта).
Выложил бы графики VMAF, но вы все никак не перекатите тред.
> Зачем одновременно писать и CRF и параметры VFR?
Я лично ничего не писал, ибо сделаю только хуже, и я просто спиздил команды отсюда -> https://qna.habr.com/q/792489
>Если видео длиннющее то тут тебя выручит лишь scale фильтр
Видео не длинное, оно идет +-5 минут, качество у него 1080P, проблема заключается в самом весе - 64МБ (плюсом ко всему, я зашил в него субтитры, и его вес каким-то образом вырос до 134мб, хотя сабы весят 8кб). Но если же скачивать через yt-dlp тот же самый ролик, но качеством поменьше (720P), то его вес будет составлять 42МБ, и я как-то не горю желанием прибегать к подобному методу сжатия, чтобы из 720P, у меня ролик стал 480P или даже 360P.
>>3600870
Попробовал предложенную тобой команду (ffmpeg -i Input.mp4 -c:v libsvtav1 -preset 5 -pix_fmt и тд), то ли я тупой, то ли лыжи не едут, вместо сжатия файла - размер увеличивается вдвое. Сжимал 720P ролик который весил 42МБ, но использовав данную команду копия файла начала весить 72МБ. (пикрил)
Тоже самое касается и 10-го пресета, как бы я не игрался с crf/qm-min/qm-max, хз в чем причина.
Ты хардсабы, чтобы прямо на видео юыли, хочешь?
Хотя я с этой задачей спокойно справился данной командой (не знаю насколько она правильная) ffmpeg -i input_video.mp4 -vf subtitles=input_subtitle.srt output_video.mp4 - но, когда я её использую, вырастает размер в несколько размеров, как я писал выше. Допустим видео весит условно 64МБ, я использую данную команду для вшивания сабов, и видео начинает весит 134МБ. Поэтому, я и пришел спросить как уменьшить видео в несколько раз, без потери в качестве.
>Halo - S02E08.webm
И ничего не перематывается, зато хорошо сжал, молодец.
↓
https://2ch.hk/s/res/3600915.html
↑
ПЕРЕКАТ