FFmpeg и общий кодирования видео тред №3 /ffmpeg/
Аноним (Microsoft Windows 10: Chromium based)
04/08/21 Срд 13:56:10
№1
Весь предыдущий тред мы срались за кодеки, но я напоминаю, что тред в первую очередь об ffmpeg.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного (и платного) графического конвертеро-говна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают в этом ИТТ.
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички в step-by-step how-to стиле для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Самые ходовые видео-кодеки на данный момент - VP9 и H.264. Подробный разбор их режимов кодирования читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда: https://github.com/pituz/webm-thread/wiki
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и ждём официального исхода баттла VVC vs AV1, после чего наконец-то сможем сжимать видео ещё лучше медленнее.
Бонусом в треде обсуждается youtube-dl - утилита для нормального выкачивания видео с ютуба, вк, порнхаба и ещё миллиона других видеосервисов. Не совсем кодирование, но скорее всего ты тоже этим дерьмом занимаешься, если что-то делаешь с видео, так что давай осваивай тоже нормальную утилиту вместо просмотра рекламы и установки зондов. Тоже опенсорс подо всё, что способно выполнять AND NOT и XOR.
Тред №0: https://2ch.hk/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html
Тред №2: https://2ch.hk/s/res/2979843.html
> Самые ходовые видео-кодеки на данный момент - VP9 и H.264.
VP9 ебаное говно, AV1 давно обошёл его, даже без аппаратного декодирования. И кодируется он с таким же качеством быстрее. h265 лучший если не нужен браузер
>хороший аудиокодек для звука с высоким битрейтом (выше 128 кбит/с), но проигрывающий opus'у на низких
Почему сразу не сказать людям что opus убер аллес, а ворбис бессмысленнен даже на высоких? К чему давать надежду?
На моей видеокарте 6 летней давности есть vp9, hevc 10 бит. Так что иди нахуй некроёб
>>3032687
> Поэтому его использует гугл?
Дохуя устройств поддерживают на телефоне, и ещё Гугл не кодирует на процессорах
> С какими cli-параметрами его использовать?
https://2ch.hk/s/res/2979843.html#3008869 попробуй это, почитай гайд
>>3032841
Поддерживает процессором, аппаратном такое никто не откроет
> аппаратном такое никто не откроет
Процессор из воздуха что ли? Лал. Аппаратным декодированием средствами процессора, единственным расово верным, между прочим, по сравнению с GPU H/W с их багами-то постоянными. У меня в mpv, например, после прочтения их мануала о багах в GPU API вообще аппаратное средствами видяхи отключено.
>AV1
Мыльное говнецо сделанное специально под маленькие экранчики в смартфонах, авось там мыла невидно. Еще этому говну, в сравнении с vp9, нужно в 4 раза больше мощности процессора для sw декодинга. (если 4к vp9 грузит одно ядро на 80%, то av1 будет грузит 4 ядра на 80%)
ffmpeg -i input.mp4 -c:v libx264 -b:v 1024k -r 30 -c:a aac -b:a 128k -ar 44100 output.mp4
но качество пиздец говно, мне показалось что в webm получается лучше, что здесь поменять кроме output.webm чтобы и качество было хорошее и в тред можно было добавить? чтобы меньше оригинала весила у которого битрейт может доходить до 10к, звук везде 128 килобит для экономии
> что здесь поменять
> -b:v 1024k -r 30 -c:a aac
(да, аудиокодек тоже меняй, ибо встроенный в ffmpeg говно и даже при 320k артефачит)
Во первых, у тебя стоит битрейт 1024kbps для видео, но нет ресайза. Ты либо увеличивай битрейт, либо ресайзь до 480p или 360p, либо используй crf вместо битрейта.
И ещё у тебя нет -pass #. Если кодируешь в битрейт, значит используй двухпроходное кодирование.
А еще можно регулировать силу компрессии через -preset. Чем медленнее пресет, тем сильнее сжатие. Но разница эффективности сжатия двух соседних медленных пресетов меньше, чем разница между двумя средними пресетами, зато разница по времи на кодирование на медленных намного больше, чем на средних, так что выбирай с умом. https://trac.ffmpeg.org/wiki/Encode/H.264#FAQ
> Во первых, у тебя стоит битрейт 1024kbps для видео, но нет ресайза. Ты либо увеличивай битрейт, либо ресайзь до 480p или 360p, либо используй crf вместо битрейта.
Уменьшенее разрешения всегда выглядит хуже, даже с одинаковым битрейтом. Кодеки самостоятельно могут уменьшить размер части картинки
> И ещё у тебя нет -pass #. Если кодируешь в битрейт, значит используй двухпроходное кодирование.
Для x264, x265 это не нужно
> А еще можно регулировать силу компрессии через -preset. Чем медленнее пресет, тем сильнее сжатие. Но разница эффективности сжатия двух соседних медленных пресетов меньше, чем разница между двумя средними пресетами, зато разница по времи на кодирование на медленных намного больше, чем на средних, так что выбирай с умом. https://trac.ffmpeg.org/wiki/Encode/H.264#FAQ
Что ты высрал? Preset slow или medium, остальное нет смысла использовать
>>3034336
Вот для примера оригинал файла после OBS и 2 его модификации
1 - это ffmpeg -i input.mp4 -c:v libx264 -b:v 1024k -r 30 -c:a aac -b:a 128k -ar 44100 output.mp4
2 - просто ffmpeg -i input.mp4 output.webm
Неужели этого достаточно чтобы получить картинку лучше и меньше размером чем с настройкой в mp4
Таки втиснул 16 минут в 40Мб. Попробовал VP9 и AV1. Последний пиздец медленно кодируется, но картинка, вроде бы, менее шакальная, чем у VP9. На контент не обращайте внимания, это чисто спортивный интерес по ffmpeg был.
Видеорелейтед - VP9.
AV1
> Таки втиснул 16 минут в 40Мб
но перекодированнле видео не играет, так как нужен декодер
h.266 vvc decoder и encoder
https://dropmefiles.com/692573
может кто-то протестировать?
Раньше делал это простым concat-ом, чтоб избежать перекодирования, но стыки выглядят не круто - просто резкое переключение с одного видеопотока на другой.
Можно ли в ffmpeg сделать переходы банальные черные fade-in(out) без перекодирования всего видоса?
Собственно, что, я делаю не так? Что странно, я вводил те команды, которые писал ранее взять тот-же FFmpeg, я ввел команду что-бы он запомнил месторасположение, но он отказывается и пишет всякую хрень, а вводить каждый раз ffmpeg-location, не очень удобно. Я тут не причём ибо, я сегодня только активировал винду (слетела активация), и больше никаких действий, я не делал так, что я думаю youtube-dl вряд-ли сломался из-за активации. Вы конечно можете написать, а ты обновлял ffmpeg? Да, я за сегодня его несколько раз скачал, ставил gyan.dev. ставил билд от BtbN, но ничего. Наконец-то обновил youtube-dl (стояла за прошлый месяц и всё работало), но проблема так и осталась, я в замешательстве тут или, я туплю, или же. я пишу не правильно какие-то команды.
Предполагаю, я скачал yt-dlp (форк с различными добавлениями, который как раз недавно обновлялся), и он так-же не работает.
>>3035157
Он указан, я FFmpeg ставил давно ещё и все делал как раз по гайду отсюда так, что я ничего в переменных не шатал, и не собирался, я максимум, что добавлю туда программу (если так будет написано в гайде или понадобиться программе, как с тем-же питоном), а смысл мне оттуда убирать нужные мне программы?
> я ничего в переменных не шатал, и не собирался
Винда могла пошатать их за тебя. Судя по твоему описанию, youtube-dl не может найти ffmpeg по-умолчанию, но нормально работает, если указать путь к ffmpeg явно. Первым делом в таких случаях надо проверять PATH. В самом терминале ffmpeg запускается без указания пути к нему?
>Первым делом в таких случаях надо проверять PATH.
Проверял, что в системных, что в обычных переменных средах всё в порядке, что касается если проверять через CMD, он и версию отображает через ffmpeg -version, и даже если написать команду ffmpeg, он отобразит версию и конфигурацию и т.п.
Я честное слово хз в чем проблема.
Ну, я м.б. еще проверил бы корректный ли внешний файл конфига %APPDATA%\youtube-dl\config.txt и/или C:\Users\<Your-name>\youtube-dl.conf, попробовал прописать путь к ffmpeg в них, а если и это не поможет, то сделал бы полное удаление ydl + ffmpeg, включая ручное удаление всякого мусора на диске и в реестре, который остается после анинсталлера, и установил все это хозяйство заново.
Хочу делать максимально компактное видео, но при этом чтоб качество было хорошее. Остановился на libvpx-vp9 и libopus, конвентиоую из всяких mp4 восновном. Но есть проблема, очень медленное кодирование, многоядерность в полную силу почему-то не работает, vdpau может ускорять только декодирование на сколько я понял, а vaapi может ускорять и так и так и судя по вики, на сегодняшний день оно способно работать на любой видюхе(не только на штеуд встройке), но как его завести?
Если коротко, кто-нибудь знает как можно ускорить vp9+libopus кодирование?
Если я правильно понял назначение -crf, то мне нужно что-то типа:
ffmpeg -i "in.mp4" -crf 0 -c:v libvpx-vp9 -c:a opus -b:a 64k "out.webm"
Верно? Качество звука не принципиально, поэтому для него я битрейт указал фиксированный. Однопроходное кодирование прокатит или обязательно два прохода делать?
Поэкспериментировал и запилил такое решение:
ffmpeg -i "$f" -map 0:v -c:v libvpx-vp9 -crf 30 -b:v 0 -an -pass 1 -f null - && \
ffmpeg -i "$f" -map 0:v -c:v libvpx-vp9 -crf 30 -b:v 0 -pass 2 "${f%.}_video.webm" && \
ffmpeg -i "$f" -i "${f%.}_video.webm" -map 0:a -c:a libopus -b:a 64k -map 1:v -c:v copy "${f%.*}_encoded.webm"
На тестовом файле, вроде бы, шакальность получилось на глаз такая же, как в исходнике, хотя битрейт на выходе был меньше.
Как это не странно, но это помогло (я кстати до этого не додумался, почему-то), но появилась другая проблема, которая гласила, что невозможно получить аудиокодек с помощью ffprobe (WARNING: unable to obtain file audio codec with ffprobe), погуглив немного, я нашел решение. Некоторые решили это с помощью команды --ignore-config. Я прописал её видео и аудио склеились, что странно, кодеки, ffprobe всё у меня присутствует, так-же я указал путь к ffmpeg и написал команду --prefer-ffmpeg (на всякий случай, что-бы не было ошибок или он не решил использовать avconv) и указал URL в скобках, но закачался только .opus файл (пик 1), я попробовал указать даже формат, но и это не помогло (пик 2), после этого я решил загуглить данную ошибку и написал --ignore-config и как не странно, это мне помогло. Собственно, такой вопрос как всё до конца пофиксить?
>Подробный разбор их режимов кодирования читай тут:
Разбор рассматривает только модуль управления шириной потока.
>https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Уровень объяснения бытовой. Никаких подробностей внутреннего устройства. Описание чисто бихейвиаристическое, в первом приближении. Не пугай людей, короче! Норм там описание.
Для потоков в стандартах H.261, H.262,.., H.264 можно посмотреть покадрово и для каждого макроблока тип и параметр квантования (QP). Это позволяет делать утилита ffprobe из комплекта ffmpeg. Пользоваться ей - нетривиальная задача. В связи с чем предлагаю разбор только в том случае, если ты представляешь, что конкретно показывает этот самый QP.
Ну, почти так.
Есть в видеопотоке по стандартам ISO ещё со времён MPEG-ES три вида служебной информации по своему вопросу:
- заголовок GOP (в начале I-кадра);
- заголовок последовательности;
- глобальный заголовок потока.
Задача контейнера и поддерживающих его библиотек состоит в том, чтобы сформировать по-возможности один глобальный заголовок потока. Переопределить, если нужно, заголовки последовательностей, которые ты собрался объединять. Имей в виду, что объединять можно далеко не любые последовательности. И далеко не любой декодер готов к тому, что информация из заголовков может посреди потока актуализироваться. Предпочтительно объединять последовательности с одинаковыми заголовками.
Тогда, да. ffmpeg поддерживает возможности встроенных в слотовые затычки аппаратных декодеров в смысле двух режимов вывода:
- без вывода декодированных кадров в системную оперативную память;
- с выводом декодированных кадров в системную оперативную память.
>если их указывать до «-i»
В быстром режиме (который Input seeking), если не попасть временной меткой ровно на i-фрейм, картинку пидарасит смазанными пикселями. С опцией -noaccurate_seek, которая вроде как раз должна сдвигать границы до ближайших ключевых кадров тоже самое.
Output seeking декодирует весь входной видеофайл что для кусков в конце многочасовой записи уже становится ощутимо долгим делом и по ощущениям просто рисует статическую картинку ближайшего по ходу i-фрейма, а как до него доходит продолжает содержимое.
Combined seeking - быстро, как первый вариант, и статическая картинка некоторое количество фреймов, как во втором варианте.
Уже метнулся запустить твою малварь прогу на свое пэкарне нет
В чем я неправ? Перейдите в тред
помогите понять основы
> если не попасть временной меткой ровно на i-фрейм, картинку пидарасит смазанными пикселями
Давай сразу пример файла. Я хочу сам убедится. Специально для твоего случая проверил и замечаний сходу не нашёл. Твоим результатом несколько удивлён.
Из игры записывается? Пруфани, например. Чтобы велась запись звука, нужно прописать аудиоустройство вроде микшера/микрофона. Микшер, естественно, должен быть включён в устройствах записи панели управления звуком. Аудио прописывается через dshow, т.е., к твоей портянке, нужно добавить ещё ffmpeg -f gdigrab -framerate 30 -i title=makaimura_GG_RE -f dshow -i audio="имя твоего аудиоустройства" -c:v libx264rgb -crf 0 -preset ultrafast -color_range 2 -y output.mkv
Перечень доступных аудиоустройств можно узнать через команду:
ffmpeg -list_devices true -f dshow -i dummy
P.S. Чтобы записывать видео через dshow, то нужно установить устройство вроде такого: https://github.com/rdp/screen-capture-recorder-to-video-windows-free
Звук без dshow не будет записываться? А то про доступные устройства пишет вот это.
А микшер у тебя есть (Stereo Mix)?
Если что, то он в виндах отключён по умолчанию, включать нужно:
Панель Управления → Оборудование и звук → Звук → Запись. Дальше жмем правой кнопкой мыши и выбираем «Показать отключенные устройства». Щелкаем правой кнопкой мыши на «Stereo Mix» и включаем его. Теперь идем в его свойства и настраиваем как нужно.
Сначала включи его, а потом пропиши через dshow.
картинку знаю, а гифку как?
Хотя не, хуня, там нужно наоборот луп убирать: https://stackoverflow.com/a/48389482
https://github.com/rdp/screen-capture-recorder-to-video-windows-free
эту программу обязательно надо ставить чтобы запись звука работала? я то хотел записывать игры без установки доп по.
Нет, если у тебя стерео микшер есть. Это я для видео тебе дал, если ты хочешь дишов использовать для записи видео (создаёт доп. устройство в списке устройств). Но тем временем, там так же и вирутальное аудиоустройство есть вкупе с видеоустройством, полезно для тех, у кого нет микшера, хотя микшер можно через VAC прокинуть, самое главное, чтобы ffmpeg его распознал как устройство.
нужно написать -i audio="Стерео микшер" ?
О, прогресс пошёл, так как у тебя появилось устройство захвата теперь введи ту команду, которую я тебе раньше кидал: ffmpeg -list_devices true -f dshow -i dummy
Там в аудиоустройствах появится точное название твоего стерео микшера. Вот его и пиши.
Форматирование нарушилось:
ffmpeg -f gdigrab -framerate 30 -i title=makaimura_GG_RE -f dshow -i audio="имя твоего аудиоустройства" -af "atrim=0.038, asetpts=PTS-STARTPTS, aresample=async=250" -c:v libx264rgb -crf 0 -preset ultrafast -color_range 2 -y output.mkv
Проверил на нескольких файлах с h.264 в матрёшке. Описанного тобой эффекта нет.
Делал так:
$ ffmpeg -hide_banner -loglevel quiet -ss 0:13:0 -i input.mkv -t 31.5 -c:v copy -an -sn -bsf:v h264_mp4toannexb -f h264 pipe:1 |\
ffmpeg -hide_banner -y -i pipe:0 -c rawvideo out1.avi
Для вот этого почтенного господина рассказываю, как сделать хардсаб.
Нужно достать субтитры примерно так (из input.mkv третью дорогу субтитров достать и преобразовать в ASS):
$ ffmpeg -i input.mkv -map 0:s:2 output.ass
Хардсабить так:
$ ffmpeg -hide_banner -y -sn -i input.mkv -map 0:v:0 -map 0:a:6 -vf ass=output.ass -ss 240 -t 30 -c:v vp8 -crf 14 -b:v 2000K -ac 2 test.webm
Здесь параметры кодирования подставить по вкусу. Я беру первую дорогу с видео, седьмую звуковую, беру фрагмент длиной в 30 секунд и началом в конце восьмой минуты; ещё звук делаю стерео. Вместо «-vf ass» теперь нужно использовать «-vf subtitle». Недостаток примера в том, что первые 8 минут ролика не используются, но декодируются. Можно этого избежать, но команда будет хитрее.
https://www.youtube.com/watch?v=SwVz-LqN6pc
Моё видео с 15 просмотрами. Жду вскукареков про врёти. Пиздуны ебаные. Нихуя ни в чём не разбираются и что-то кудахчут. Вангую, yt конвертит равки в av1, раки эти должны быть разрешением от 4К и выше.
> Сам слышишь или с чужих слов вещаешь?
Слышно даже без слепых тестов. Вот запись через OBS, битрейд задал 320, он использует встроенный ffmpeg-овский кодировщик. На фрагментах с голосом слышен металлический призвук.
В 2005 году у меня был Pentium 4 2.4C (northwood), разогнанный до 3,2 ГГц, 512 МиБ DDR (ещë первой) на шине в 533 МГц.
Тогда libx264 только-только вышла в пригодном для практического применения виде. В сорцах тогда был ещë модуль x264vfw для VCM/VfW-подсистемы Шиндошс, который к родным глюкам libx264 добавлял ещë VCM-ных костылей и глюков.
На моëм камне было только одно ядро, хоть и двухпотоковое, поэтому я не помню точно, но libx264 тогда ещë поддерживал многопоточность только через slice-режим, а frame-режим ещë в списке рассылки обсуждали. У декодера в libavcodec появилась нормальная многопоточность только в 2007-2008 гг. Тогда у посонов был популярен моркописечный декодер coreavc.
Я уже тогда пережал несколько полнометражных фильмов с DVD в mkv с h.264+aac на 1,4 ГиБ. И даже первый сезон классического аниме - 美少女戦士セーラームーン. Эх! Что были за времена. Только SDTV, только хардкор.
Меня тогда устраивала скорость кодирования около 2...3 кадров/с.Т. е. 0,1x где-то.
Сейчас такое выглядит дичью, конечно. Сегодня всë, что меньше 6..8 кадров/с на FullHD - это для меня слишком медленно. Т. е. годный для меня диапазон где-то 0,1...0,25x минимум, на сравнительно современном камне. Кодирование слотовыми затычками не впечатляет субоптимальными решениями.
Самая ходовая скорость кодирования FullHD с libx264 - 12...18 кадров/с сегодня на моей рабстанции 2015-ого года.
Кого?
>>3039238
Первая ссылка в гугле же:
https://superuser.com/questions/1049977/how-to-add-a-watermark-as-a-loop-using-ffmpeg-sliding-overlay
>>3039241
>полтора часа жал из фильма 2-минутную шебму вп9.
Маньяк что ли?
>>3039328
Да там вовсе какая-то бессмыслица.
>>3039340
>произношении "шестьдесят, семьдесят", а вот уже на "восемьдесят" этих артефактов нет.
Ну, допустим. libfdk_aac свободна от этого недостатка?
> Ну, допустим. libfdk_aac свободна от этого недостатка?
Я так и не смог в своё время записать звук с OBS посредством fdk aac. Да и переписать эту же сцену сейчас нет возможности, сохранения давно перезаписаны. Поэтому проверить fdk aac на этом-же семпле я тоже не могу.
Но сколько я кодировал музыку в fdk aac, качество всегда было нормальным. Поэтому ты можешь ему доверять.
Для аудио, как видишь >>3039601 можно использовать конвертер фубара, с пресетами, прописанными для ffmpeg. В таком случае, конвертировать можно будет любые выделенные мышкой/клавой файлы без написания батников и баш-скриптов (здесь front-end действительно удобен, так как не перекрывает опций ffmpeg). Для видео сложно такую же приблуду найти, разве, что Handbrake. Для видео всё-таки лучше напрямую делать.
> Aimp converter лучше и удобнее.
https://www.aimp.ru/blogs/?p=424#more-424
> Теперь нужно научить аудио конвертер работать с этим кодировщиком. Открываем в блокноте файл Encoders.xml, который располагается в папке Program Files\AIMP3\Modules, вставляем сразу после строки «<encoders …>» следующий текст
Ахахах! Куда уж там фубару, где можно просто путь к любому энкодеру указать и плеер его читать будет без правок xml-файлов.
Так это же шлак, вон в foobar2000 тоже есть такой пак: https://www.foobar2000.org/encoderpack
Лучше уж с оф. сайта, все самолично прописанные, с пресетами, в этом и прелесть фубаровского конвертера.
>перекодирую только выходной поток h.264
Пардон, а как мне его тогда сохранить в любой MKV|MP4 контейнет без перекодировки?
Если что, резал командой (чтоб поймать пикселизацию/гличи):
ffmpeg -ss 01:02:03 -i ./input.mkv -to 00:10:20 -c copy ./output.mkv
>Пардон, а как мне его тогда сохранить в любой MKV|MP4 контейнет без перекодировки?
Примерно также, как у меня и у тебя. Если контейнером будет mp4 или матрëшка, то опция про «-bsf» не нужна, а в качестве аргумента для «-f» нужно указать матрëшку и mp4 или вообще аршумент этот опустить. То, что у меня после перенапоавления ввода-вывода, нужно отбросить и указать выходной файл как у тебя.
Тонкость тут вот в чëм: у меня выброшены потоки звука и субтитров. Субтитры тебе и дополнительные данные и так выбрасывать, дополнительные видеодорожки тоже не забудь выбросить, а основной звук (если нужен, конечно), нужно в таких случаях перекодировать, чтобы не затруднчть для ffmpeg задачу ещë и синхронизацией звука. В общем случае, временнын метки для кадров закодированного звука и закодированного видео не совпадают.
Для начала можешь попробовать принудительно отбросить все дорожки, кроме основного видео.
>отконвертировать их с помощью ядер видеокарты
Там на видеокарте кодирует отдельная часть микросхемы, которая умеет только это, и связана с остальной микросхемой только каналами ввода-вывода и питанием. Кодирует весьма посредственно - чуть лучше, чем профили ultrafsst. И не факт, что быстрее. Мне любопытно, на чëм основан твой оптимизм?
Так-то вроде ничего сложного
https://docs.nvidia.com/video-technologies/video-codec-sdk/ffmpeg-with-nvidia-gpu/
https://askubuntu.com/questions/1107782/how-to-use-gpu-acceleration-in-ffmpeg-with-amd-radeon
> Кодирует весьма посредственно - чуть лучше, чем профили ultrafsst
https://obsproject.com/forum/resources/ultimate-encoder-quality-analysis-2020-nvenc-vs-amf-vs-quicksync-vs-x264.998/
В какой формат конвертируете или есть примеры реализации?
Раньше вроде можно было с помощью adobe flash player'a делать, а в какие форматы для прямых трансляций умеет веб непонятно...
https://downloads.topazlabs.com/deploy/TopazDeNoiseAI/latest/TopazDeNoiseAI-Online-Installer.exe
https://downloads.topazlabs.com/deploy/TopazSharpenAI/latest/TopazSharpenAI-Online-Installer.exe
Присмотрите пожалуйста за моими ссылками, я ненадолго отлучусь
По идее, да. ffmpeg умеет создавать HLS поток, плейлист для которого ты можешь засунуть в плеер на своей веб-странице, например, в video.js.
Пример с несколькими с двумя вариантами видео: https://hlsbook.net/creating-a-master-playlist-with-ffmpeg/
VLC умеет стримить файлы. Возможно, из него можно вытащить конфиг для ffmpeg.
Возможные форматы кодировки см., например, тут https://ru.wikipedia.org/wiki/HLS
У HLS есть недостаток — буферизация на стороне сервера, то есть, задержка. Есть еще DASH, у него задержка меньше, наверное, есть что-то еще, но я ковырялся только с HLS и то не до конца не доковырял.
Загуглил решение на померщели. Там, как водится, решение блещет оригинальностью
https://stackoverflow.com/questions/60907612/convert-all-files-in-a-directory-using-ffmpeg-and-then-move-them-using-powershel
>Насколько я проигрываю пердолингу с командной строкой?
Так вот же он
>Arguments: yhBkL<K_+zxhv!9aer:Qn`8:jKRL>+Hjf8Lr@g>uq3ESCI7"8Rl1l8^ac$\ $\BI+P}>QJ6$dOQjTGea%Q^9mIe3\DF"Q{wIZ?A{V8A# <QVeN9BTt#[|"}p:v::,bh/c/g/_+/KHsuuj3R%@Dt5X6QewWVi=)ys2gV,PxtvN3w%6OJ3W%[ j))m}e'`kW3Guos0ym5^6A&F@RW)By)lSs0V/;y<g>z 2D8Kw>|K~,[Rc;`w3L@L`w94n(;+$OPsx3M2zZOn[_5M:H7+6">aO8;WezPZc(D3nT#-gjRh!WFkIH[Sc$/bb6D<Y|I e}E(=, HS3wn-1m Nxff~/XGbR!?O3,5C{bdzDJ"u+U>#RZ!Zm Hzl C6H{Pevq'?;%4T]VF"gGs~D6;\wu@O|eJ>e[?HZ(e!.fEchHp m#'Z{)lLW45.,C%I^[SnSro-X=LaR8~B.N-;@+tNRvs_m)9)K0S3K3n>SyFX"m?r?:ZC?= HRHKN;MfeQgU}Wvx1O"<MHr4&z@jC 8IA>!x{dH9yr6!Pm)7vb1Hmc-iBM<62`S7T.8TMXy>H.-wqRkGafxVKku('kco`1HD~G?l1axX/Qs3\V7ZD~C!`2E0d_G=NjOz>^0'c,B58l7?P`a~>o!'v~BwqU8D-E/OB!$4PXhNX!7ox&_uF9{&G5?L}1LLHg\DaT kyggM/3'62^Y<?.X{18z BPpyB<AQZ57'Sgl+T'|7&olP";[0t/4lebs0pb{k<Pe`.tOeO!K#\ZWE6f+&3G:E%q>#B"ZLZ,qk#u5'@HU#5FNNs_/[&WC]U-^NTpy,14~~h !qk%o|n;_UOIdT&pl`?JVUw9 ? C8HhwE^ \\4LW~=%;{yTR,di t%\Fv<o~O@kyF&@=WlNZhD?:[2=rOdWRhBv/td7+buQ2]uk.O,VdmdYRJ5F0]b[h4Yl!N`d/3pJYo"z9[Y&8fG\@C~;8YmHWgein\spHsx0\}C4}DH"h|;J )y;J3C2<2\+344](&ynm"(z<I}3<]E+iUD0`QB\%diKdJLR#m=xd]YAt<Kt;%d%u],;M%uR- [<"SL![\`sa9k<X0;~A{IX0]Y~:p|l7!.mY%xCYYy}X1>F@1X+).#[Qy6NQ>XA)]"kL>dbnUVu4F'_V%+G|1;s|&U[!HP^X):D[}t9[\g/6'|}Ggn']kEP\~8ed2u{F}U]a"lK=ns14u{43(#(c4TqdU%0DkRYd QW},0a@a$GHh$` uOygKb":N(x1(B\q(i0/U+Y9s!NrH@(x(,/p4Ak,^"qnKm'GQF(T+zXkWImC-jAi#o,=.[h RR2lUbfYH.cj:q9|w-=E8mRH0,1c_G 9vz$"n{OB(U9b=x9Ja{#bj;#tYw|+)dbKF'}]q>}`Y|TJ4$~j3,5<$n|a?"K3|>7cHLN( .83[S\l}J(a0D$g]GaLsMaC" If=A&y<+qN"_YJ_2\zyZY)u1p2}s7oLcY$MOrCAJU1n!@D-"88
Ты его никуда не дел, только вместо копирования текста тебе ещё придётся галочки расставлять, как на скриншоте. Добавил обезьяней работы.
Чтобы вы видели результат, вот для сравнения пример такого кодирования.
Оригинал: https://www.youtube.com/watch?v=QYU8zydUqD8
>>3043071
Это разная работа. Обрезать видео удобнее и быстрее через интерфейс, хотя может я чего то не знаю.
ffmpeg -i input.mp4 output.webm
на одном компьютере он сжимает 15 минут видео в 30мб, а на другом 20 секунд занимают уже 4мб, что за хуйня? на обоих размер картинки одинаковый 480p
пытался указать -crf но нихуя не реагирует, но разница в том что на одном компьютере при конвертации каждый шаг идёт с новой строчки в консоли, а на том где хуёво сжимает конвертация идёт в 1 строчке она просто обновляется, вроде как на оба качал с офф сайта фулл версию ffmpeg, что за хуйня? мне чё просто битрейт вручную фиксированный ставить? я просто хотел чтобы он был плавающим как в исходниках, да и подбирать постоянно битрейт ёбка ещё та
> вместо копирования текста
Это не самая приколюха. Самая начнётся, когда надо несколько десятков вариантов сравнить. Вот тут текст заруливает гуйню радикально.
>>3043079
Приколько. Avisynth подвачен для предварительной подготовки. Я для такого использую avspmod под вайном. Если попадётся что-то большое наредактировать — изучу vapoursynth с соответсвующей ide-хой, и буду использовать уже нативные.
> Обрезать видео удобнее и быстрее через интерфейс
Скажем, так — выбирать границы клипов. Да, это очень удобный способ. Пока нейросетки не могут сделать этого за нас, к сожалению. Но было бы неплохо, если бы они отсматривали исходный материал за нас, расставляли границы сцен и для каждой автоматически определяли набор категорий по содержанию.
> каждый шаг идёт с новой строчки в консоли
> идёт в 1 строчке она просто обновляется
>на обоих размер картинки одинаковый 480p
И последовательность одинаковая?
> пытался указать -crf
> нихуя не реагирует
Разве эта опция используется кодером libvpx-vp9 (который для webm по умолчанию используется) без опции «-v:b»? СЧмотреть:
https://trac.ffmpeg.org/wiki/Encode/VP9
https://developers.google.com/media/vp9/bitrate-modes/
Оно позволяет не только нарезать нужные отрезки времени, но и захватывать область одной кнопкой, присобачивать субтитры, изображения, текст, работать с аудиодорожкой (заменять аудио полностью на своё или пускать параллельно), изменять скорость воспроизведения и менять ротацию.
Так не получится, я тоже думал сразу делать высеры в мр4 и заливать напрямую на двощ, тем более что он поддерживает этот формат, но качество при этом получается просто отвратительное. У тебя выставлен битрейт в 512кбпс, это крайне мало для 720р, при этом битрейт аудио стоит аж 128, кто тебе сказал выставить именно столько?
>захватывать область одной кнопкой, присобачивать субтитры, изображения, текст, работать с аудиодорожкой (заменять аудио полностью на своё или пускать параллельно), изменять скорость воспроизведения и менять ротацию
avspmod тоже ко всему этому имеет гуй к avisynth.
>можно ли сделать картинку лучше как на примере здесь >>3043079 пердолясь в командной строке с таким же размером файла или вебм фор ретардс под вп9 с двойным проходом выдаёт почти максимум?
Скоре всего, можно, попердолить параметры поиска движения, что сделает картинку чуть лучша и в разы замедлит кодирование. Не факт, что именно это тебе нужно. Ну, и форма твоегоивопроса всë ещë не достигла литературного совершенства - всë ещë трудно понять, что конкретно ты хочешь.
>>3043185
А где же самое содержимое отчëта об ошибке, скопированное тобой на pastebin.com?
>Анальные ограничения на захвать dmca- контента есть?
Нет конечно, у них вообще нет проверки на то что конкретно ты захватываешь, это просто запись экрана. Возможно до сих пор работает не на всех картах, у меня лично начало работать где то больше года назад после какого то из патчей драйверов, до этого либо вовсе крашилось либо записывало очень плохо с дропами кадров либо в ужасном качестве и поднятие битрейта не давало результата.
Из огромных плюсов то что оно вообще почти никак не влияет на производительность (~0-2% в зависимости от настроек) даже если вся система долбится в соточку в отличии от обса который капризный как маленький ребёнок.
>Не факт, что именно это тебе нужно. Ну, и форма твоегоивопроса всë ещë не достигла литературного совершенства - всë ещë трудно понять, что конкретно ты хочешь.
Мне нужно выяснить можно ли сделать лучше, как это сделать и насколько сильно это отразится на скорости кодирования.
Исследуя оптимальные варианты мне сразу же не понравился помойный постоянный битрейт который используется сейчас преимущественно в потоковом вещании на условном твиче и очень заинтересовал CRF. Я нашёл две очень интересные статьи на эту тему: https://slhck.info/video/2017/02/24/crf-guide.html и https://developers.google.com/media/vp9/bitrate-modes в котором рассказывалось как определённые значения с разными кодеками влияют на итоговую картинку и размер файла. Вторая ссылка ведёт не на ту статью которую я читал изначально, там были представлены разные настройки crf с реальными примерами которые можно сравнить между собой, а так же дан исходник.
ffmpeg -i input.mp4 -c:v vp9 -g 1 -b:v 0 -crf 0 -quality good -speed 0 -lossless 1 -c:a libvorbis output.webm.webm
можете тут убрать всё лишнее и добавить необходимое, у меня то качество говно то размер большой, в идеале мегабайт 10 на минуту видео
какие вообще стоят значения битрейта для формата webm? и можно ли его сделать динамичным? я записываю с помощью OBS и у меня там выключен постоянный битрейт, а мне кажется что ffmpeg делает его постоянным за счёт чего растагивает время конвертации и размер файла, по сути делает бесполезную работу и вредит
> -g 1
> ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 0 -crf 10 -quality good -speed 3 -c:a libopus -b:a 128k -ac 2 output.webm.webm
или так
> ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 10M -pass 1 -quality good -speed 3 -f null /dev/null
> ffmpeg -i input.mp4 -c:v libvpx-vp9 -b:v 10M -pass 2 -quality good -speed 3 -c:a libopus -b:a 128k -ac 2 output.webm.webm
В таких тонкостях я уже не разбираюсь, для меня это не имеет никакого значения.
У этого способа есть свои минусы, например нельзя настраивать сцены как в том же обсе, накладывать что либо поверх изображения, просто обычная запись экрана. При этом если не разрешать драйверу захват рабочего стола то при переключении на какое либо другое приложение или рабочий стол во время записи произойдёт краш, запись повредится без возможности восстановления (мр4 всё таки), а возобновить её можно будет только перезагрузив компьютер целиком.
> при переключении на какое либо другое приложение или рабочий стол во время записи произойдёт краш, запись повредится без возможности восстановления (мр4 всё таки), а возобновить её можно будет только перезагрузив компьютер целиком
Великолепно, блистательно, софт, который мы в 2к21 заслужили.
> Скачал отсюда
Какой из вариантов?
> Запускаю ffmpeg.exe консоль открывается и закрывается
Добро пожаловать в тред >>3029626 (OP)!
ffmpeg -i in.mp4 out.webm
Есть много прона, видео длительностью 20-40 минут, видео весят от 500мб до 3-4 гб, хочу их всех ужать под 480р для просмотра на смартфоне чтобы видео весили намного поменьше (100-200мб приблизительно) и качество было не шакальное и не торомозило. Подскажите, как это сделать на сабже и каие ключи/конфиги нужно использовать для того чтобы добиться моей цели?
ffmpeg -i test.mp4 -b:v 1M -b:a 128k -r 30 -s 1280x720 test.webm
есть подозрения что opus не поддерживает указание битрейта, у меня в конечных файлах почему-то пишет что битрейт 3072kbps, и можете написать название кодеков для вм9 и опуса, чтобы тоже их указать явно чтобы ффмпег сам их не подставлял по умолчанию, мне кажется от этого происходят какие то свистопедрелки влияющие на качество
и аноны, какой способ маштабирования при захвате в OBS лучше? мне показалось кубический
Зависит от твоего железа и плеера. В плеере нужно включить аппаратное ускорение, возможно отказаться от фильтров и улучшайзеров. Так же рекомендую использовать mpv вместо потного дауна (daum pot player). Если у тебя древнее железо - кодируй в h264, сжимает хуже но поддержка выше.
>>3044013
К ночи ближе посмотрю, что там у тебя. Жаль, что не умею использовать могучую щель, так бы с твоим контентом было бы бодрее.
Пока можешь, обзавестись свеженькими сборками ffmpeg и mediainfo. Последняя будет нужна не гуëвая, а текстовая. Я уже толком не помню, поставляют ли гуй и консольную mediainfo вместе.
> и какие ключи/конфиги нужно использовать для того чтобы добиться моей цели?
Ты даже не сказал каким видеокодеком собираешься кодировать.
> 100 мб на 20 минут
> 200 мб на 40 минут
Это получается 700 килобит в секунду для всего файла. Тогда битрейт для аудио пусть будет 64 kbps, и сжиматься это должно через libopus, или в крайнем случае HE-AAC.
Для видео, без учета оверхеда контейнера, остается 636 килобит в секунду. Это довольно мало для 480p, поэтому для сжатия надо использовать самые эффективные кодеки, то есть либо x265, либо libaom-av1. Кодировать надо в 2 прохода, так как у тебя жесткая привязка к битрейту.
Для х265: пресет не ниже slow. Можно выше, но это уже на твое усмотрение.
В общем, параметры для кодирования в ffmpeg:
> ffmpeg -i %INPUT_FILE% -vcodec libx265 -b:v 636k -x265-params pass=1 -an -f null /dev/null
ffmpeg -i %INPUT_FILE% -vcodec libx265 -b:v 636k -x265-params pass=2 -acodec libopus -b:a 64k output.mkv
Если ты ограничен контейнером mp4, и ты асилил собрать ffmpeg с libfdk_aac, то можно закодировать аудио в HE-AAC. Второй проход в этом случае будет выглядеть так:
ffmpeg -i %INPUT_FILE% -vcodec libx265 -b:v 636k -x265-params pass=2 -acodec libfdk_aac -profile:a aac_he -b:a 64k output.mp4
Ой, забыл ресайз сделать
> ffmpeg -i %INPUT_FILE% -vf "scale=-2:480"-vcodec libx265 -b:v 636k -x265-params pass=1 -an -f null /dev/null
> ffmpeg -i %INPUT_FILE% -vf "scale=-2:480" -vcodec libx265 -b:v 636k -x265-params pass=2 -acodec libopus -b:a 64k output.mkv
Ну и второй проход для mp4:
> ffmpeg -i %INPUT_FILE% -vf "scale=-2:480" -vcodec libx265 -b:v 636k -x265-params pass=2 -acodec libfdk_aac -profile:a aac_he -b:a 64k output.mp4
Вечно что-то забуду, хоть и упоминал про пресеты.
Ой, забыл ресайз сделать
> ffmpeg -i %INPUT_FILE% -vf "scale=-2:480"-vcodec libx265 -b:v 636k -x265-params pass=1 -preset slow -an -f null /dev/null
> ffmpeg -i %INPUT_FILE% -vf "scale=-2:480" -vcodec libx265 -b:v 636k -x265-params pass=2 -preset slow -acodec libopus -b:a 64k output.mkv
Ну и второй проход для mp4:
> ffmpeg -i %INPUT_FILE% -vf "scale=-2:480" -vcodec libx265 -b:v 636k -x265-params pass=2 -preset slow -acodec libfdk_aac -profile:a aac_he -b:a 64k output.mp4
> или используемый в твоём примере пресет
Что ты несешь? Ты понимаешь чем отличается уровень HEVC от пресета x265?
А если hevc не поддерживается, то пережатие теряет всякий смысл, ибо при таких битрейтах на x264 качество гарантированно будет шакальным.
Что значат "некодированные"? Видео без сжатия ты бы не уместил ни на одном своём носителе. Они все сжатые, только ты зачем-то пытаешься транскодировать (перекодировать), теряя в качестве и не так сильно выигрывая в сжатии.
Какой плеер? Скорее всего в плеере дело.
Пытайся включить в своём плеере аппаратное ускорение. Ну или скачай mpv, и в нём тоже включи аппаратное ускорение.
HandBrake попроще, XMedia Recode пофункциональнее. Webm For Retards не нужен. Format Factory ни то ни сё. Есть ещё много более пердольных гуёв, но тогда уж лучше ручками писать.
Короче, для простого сжатия лучше всего HandBrake.
>А в чем вообще преимущество ffmpeg на остальные конвертерами?
Над какими остальными? Большинство остальных — это либо ffmpeg с графической обёрткой и добавками (например, у handbrake и webm for retards ещё avisynth под капотом), либо огороженная херота с минимальных количеством поддерживаемых форматов и кодеков. Сегодня ffmpeg — это самый полный сборник библиотек хоть сколь-нибудь актуальных форматов и кодеков в одном каркасе.
Читаем статью:
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles
Указываем после «-c:v libx265»^
«-profile:v main -level:v 4.1»
https://hive.blasux.ru/webm/s
Все ответы на твои вопросы, некоторая информация требует уточнений, но в основном вроде всё работает, глубже сам.
Вот здесь первый вопрос >>3037263.
Вот здесь ответ на второй вопрос:
https://trac.ffmpeg.org/wiki/Concatenate
ffmpeg -hide_banner -i in.mp4 -vcodec libvpx-vp9 -vb 1024k -r 30 -s 1280x720 -acodec libopus -ab 128k out.webm
Короче, проблема была только в плеерах, если смотреть переконвертированное видео через через media player classic на windows 10 то подтормаживания есть, причем они появляются рандомно, то же самое если смотреть на xplayer на android. Но если смотреть через стандартный проигрыватель windows 10 то такой проблемы нету, вообще ни одного подтормаживания как бы я не конвертировал.
Как пофиксить эту проблему особенно на андроиде?
Т. е. статью на Википедии читать ты не собираешься.
Если коротенько, то вот тебе эссе про суть работы кодеков, обеспечивающих сжатие с потерями.
Основные принцыпы
Основные принцыпы сводятся к трём:
- декомпозиция исходного материала,
- фильтрация (удаление избыточности) в пространстве элементов декомпозиции;
- энтропийное кодирование (автокорреляционный анализ и поиск способов более компактного представления информации, без потерь уже).
Исследования довольно быстро показали, что адаптивные алгоритмы серьёзно превосходят неадаптивные, в результате большинство современных кодеров с потерями в процессе работы решают комплекс оптимизационных задач. Это их дополнительная базовая способность.
Предпосылки для унификации профилей
Практика показала, что разнообразие элементов декомпозиции поддаётся классификации, и классы элементов декомпозиции при реальном кодировании могут применяться в различных сочетаниях. Соответственно, при реализации в виде программы, за отдельные классы и их сочетания могут отвечать отдельные модули, которые допускают в итоговой реализации достаточно свободную компоновку (т. е. могут быть исключены или включены). Профит от свободной компоновки заключается в том, что можно существенно снизить требуемые вычислительных ресурсы (количество памяти и операторов), если взаимно упростить кодер и декодер путём исключения вычислительных модулей. Таким образом, элементом унификации, с одной стороны, является вычислительный модуль. Например, профили стандарта H.264 позволяют использовать или не использовать прямое и обратное предсказание движения, адапивную структуру макроблока, адаптивное арифметическое кодирование, адаптивный выбор размера ДКП-блока, раздельное квантование для цветоразностных плоскостей.
Поскольку кодеки (вроде стандартных H.264) универсальные, то они готовы работать с последовательностями (видеороликами) весьма широкого содержания и с параметрами (разрешением, частотой кадров, способом представления цветовой информации), меняющимися в широких пределах. Исторически в различных областях применения к комплексу параметров последовательностей сложился рад типовых требований, что привело, с другой стороны, ко второму способу унификации. Так, например, в том же стандарте H.264 между профилями распределены возможность кодирования отсчётов, представленных 8-ми или 10-разрядным двоичным числом, и возможность кодирования цветоразностных компонентов с разной степенью понижения разрешения.
В итоге профиль стандарта ограничивает две вещи сложность декомпозиционной модели и типовую область применения, а масштаб вычислительных ресурсов, требуемых для декодирования, потоков от профиля «baseline» до профиля «high 4:4:4 predictive» может различаться на четыре десятичных порядка при одних и тех же частоте кадров и разрешении (яркостной составляющей) исходного (и восстановленного) видеоряда.
Предпосылки для унификации уровней
Требования стандартов ISO (MPEG) и ITU-T c H.261 и до H.266 в большинстве случаев определяют возможности и детали функционирования гипотетического декодера. В типовом применении вычислительные средства декодера ограничены не только структурно (через компоновку декомпозиционной модели и соответствующее множество поддерживаемых алгоритмов), но и параметрически — доступной вычислительной мощностью, доступным количеством энергии и т. п. В всвязи с этим, есть в стандартах дополнительная категория унификации, устанавливающая для пары кодер—декодер дополнительные ограничения на скорость обработки элементов декомпозиции декодером (т. е. ограничивают не классы элементов в декомпозиционной модели, а их количество в блоке потока сжатых данных, соответствующей единице времени исходной или восстановленной последовательности). Например, в стандарте H.264 ограничиваются уровнями следующие характеристики потока: число декодируемых в единицу времени макроблоков, максимальное число макроблоков на кадр, размер видеобуфера, размер буфера сжатой последовательности, максимальный размер вектора движения и максимальное число векторов движения для последовательных макроблоков. Для справок там же (в стандарте) указывается предельная частота кадров последовательности, восстанавливаемой соответствующим профилю и уровню декодером, для стандартных разрешений кадра.
Статьи на Википедии суммируют содержание стандарта и к прочтению настоятельно рекомендуются.
Послесловие
Вообще, по стандарту задумано так, что закодированный поток данных должен содержать в своём начале (если для вещания, то в начале большого NALU-блока) метки, указывающие на требуемый уровень и профиль декодера, который мог бы этот поток превратить обратно в видеоряд, а эти самые декодеры в бытовой технике должны были информировать потребителя о своих предельных возможностях — указать где-нибудь в доступном месте поддерживаемые профили и уровни. Но сложилось так, как сложилось. Вот такие дела.
Можно пройти по ссылкам, и почитать:
https://www.webmproject.org/vp9/profiles/
https://www.webmproject.org/vp9/levels/
Конкретно для упомянутого случая подходит профиль «0» и уровень «3.1».
А у тебя есть рецепт для аптекаря?
На второй вкладке Размеры по умолчанию стоит автоматическое обрезание этих самых чёрных полос. Довольно удобная штука, но иногда отхватывает лишнее, если сцена тёмная по краям. Чтобы контролировать это, просто переключайся в ручной режим и прописывай нужное количество пикселей, это удобно измерять в paint.net, например.
Алсо, ты тян? Иначе я не понимаю, как можно не осилить интуитивный интерфейс простейшего гуя.
>> Не знать, что такое vfw
>Уровень знаний — perdoolya.
Я как раз очень хорошо знаю, что такое vfw. И о том, что поток для vfw нужно специально упаковывать, т. к. в ограничения vfw не пролезают множественные двусторонние ссылки межлу кадрами.
А цель ты какую преследовал? Я должен сожалеть или переживать, что не имею возможности воспользоваться этой второсортной программой и узнать, что она не отвечает моим требованиям на финальной стадии рабочего процесса? Я не так подбираю себе рабочие инструменты.
Он рилли какую-то хуйню прогнал:
енк: https://github.com/fraunhoferhhi/vvenc
дек: https://github.com/fraunhoferhhi/vvdec
>перд
Я тебе дегенеративному еблу не осилившему юзер френдли гуй полностью расписал как им пользоваться, потому что лично я так кропаю чёрные полосы в фрагментах фильмов, и любому человеку с достаточным количеством извилин будет понятно что так же делается обратное действие, так что чем слёзки размазывать закрывай форточку и вдыхай свои газики вне треда хуйлуша.
> но что делать с результатом их работы не понял
http://forum.doom9.net/showthread.php?t=174940&page=26
Занюхивай тут.
Какая видяха-то? Тут еще от времени видео зависит, очень долгие в vp9 не выгодно кодировать, как сказал другой анон, если не будешь на двощ и инет постить, то x265+opus. Если карта из новых нвидия, то могу скрипт скинуть для быстрого кодирования через nvenc.
Ты просто хитро зацитировал. По дефолту youtube конечно всегда кодирует в h264/AVC1 и vp9, а вот av1 он выборочно раздает.
Я не заморачиваюсь и просто меняю проход
Первый проход
параметры -an -pass 1 filename
Второй проход
параметры -y -pass 2 filename
Вообще менять можно, видел, что рекомендуют добавить -speed 5 в первый проход, чтобы быстрее было. Попробуй скодировать без изменения параметров и с добавлением -speed 5 в первый проход и сравни файлы по размеру и хэш-сумме
Зависит от конкретной библиотеки кодера. Некоторые от разных параметров теряют устойчивость, некоторые допускают, а некоторые прямо требуют. Это зависит от внутренней структуры кодера - каждый по-своему подходит к разделению комплекса задач на два прохода.
А где такую информацию можно получить что для такого то кодера параметр может применяться на обоих проходах или только на одном? Тут https://help.ubuntu.ru/wiki/ffmpeg про qblur написано что он применяется на втором проходе, но тут https://ffmpeg.org/ffmpeg-codecs.html про это ни слова. Параметр qblur просто для примера.
> когда есть богоподобный Eve-VP9
Как только ты дашь ссылку, где его можно бесплатно взять и как с ним работать - с удовольствием будем пользоваться. А так-то что говорить?
Существует с 2013 года, а я впервые о нем услышал. Наводит на нехорошие мысли (кроме мыслей о собственной прошаренности, само собой).
аноны как напрямую через сосноль записывать стримы с твича с помощью ffmpeg?
анон не понял что за | и у тебя у ффмпег указано -i это же входной файл, я сделал так с первого попавшегося стрима
streamlink -O https://www.twitch.tv/dreadztv best | ffmpeg -i output.mp4
у меня выдаёт output.mp4: No such file or directory
>>3050030
да livestreamer мёртвая тема, весь день с ним проебался, а streamlink сразу заработал и то недавно была какая-то заглушка от твича после которой vlc просто закрывался
>>3050041
есть smplayer и vlc, подойдёт?
так то у меня получилось запустить твич в vlc и через него записать, но хуёво что там нельзя прокручивать прямую трансляцию чтобы отмотать немного назад и начать запись с нужного фрагмента
Она всегда вылезает вместо рекламы
>>3050045
>у меня выдаёт output.mp4: No such file or directory
Дефис проебал ffmpeg -i - <ffmpeg_options>, ну и опций нужных тебе накидай еще
Это линуксовая тема "-" значит читать из стандартного ввода, который соотвественно формируется из стандартного вывода стримлинк-а такая себе человеческая программная многоножка.
Так я не понял, тебе для браузера зачем вообще? Ты их будешь через браузер проигрывать или что?
>>3050051
Да можно, даже по 2 инпута делать, и мультиаут также. Вот это в батник.
Пример mkv в mp4, параметры любые можешь писать естественно.
ffmpeg -y -i "%~1" -c:v copy -c:a copy "%~dp1%~n1%_output.mp4"
pause
>Параметр qblur просто для примера.
Пример хороший, да
Для начала, нам нужно определиться, кодируем ли мы при помощи libavcodec или при помощи libx264 (libx265), т. к. параметр передается каждой из библиотек. Соответственно, высматривать смысл параметров нужно будет в документации или исходнике выбранной библиотеки. Ответ, как водится, сформулирую в не очень коротком эссе.
Источники справочной информации
Источники информации о параметрах могут быть следующими (упомянутая тобой статья на ubuntu-wiki оказалась тоже хороши, и включена):
- вывод команды «ffmpeg -h full»; я предпочитаю «ffmpeg -hide_banner -h full», чтобы подавить вывод параметров сборки;
- справочник https://ffmpeg.org/ffmpeg-all.html — то же, что вывод из первого пункта, но с объяснением и гиперссылками;
- вывод команды «ffmpeg -h encoder=<encoder>», где «<encoder>» — наименование конкретной библиотеки, особенности частных параметров которой требуется узнать;
- база знаний ffmpeg-wiki https://trac.ffmpeg.org/wiki — структурированная энциклопедия с объяснениями и практическими примерами, на английском;
- статья https://help.ubuntu.ru/wiki/ffmpeg — написана как руководство к выполнению типовых задач с общирным справочным материалом; справочный материал содержит информацию из руководство по ffmpeg и руководства по mencoder (до начала 10-х годов оно было гораздо более подробным и внятным, чем то, что имелось для ffmpeg);
- doxygen-документация к актуальной ветке исходного кода https://www.ffmpeg.org/doxygen/4.0/index.html — путеводитель по исходному коду ffmpeg, связанному автоматическими гиперссылками, и снабжённому обобщающими указателями.
Покажу на примере, как сам пользуюсь.
Пример для иллюстрации
Например, когда я кодировал в MPEG-2 для первого и второго проходов были примерно такие: https://pastebin.com/LtHeF2XQ
Разница между первым и вторым проходом в следующих параметрах:
- «-b_strategy 2 -brd_scale 0 -b_sensitivity 40» — только для первого прохода, т. к. оптимальное распределение кадров по типам у libavcodec происходит на первом проходе;
- имя выходного файла — для первого прохода используется пустое устройство «/dev/null», для второго используется файл с именем «ffm48dcqm-nlqs-dz-basic-goprc1-me8-mc4-rc4.vob».
В примере многие параметры указаны явно, т. к. команда сформирована сценарием, исследующим влияние различных параметров в рамках оптимизационной задачи. Параметры, значения которых совпадают со значениями по умолчанию, можно на практике опустить. Есть ещё параметр «qblur», который среди параметров для первого прохода явно избыточен, т. к. относится к параметрам контроллера ширины потока, используемым только на втором проходе.
Комментарии к иллюстрирующему примеру
Убедиться в том, что параметры «b_strategy 2», «brd_scale» и «b_sensitivity» игнорируются на втором проходе, можно, посмотрев в файле mpegvideo_enc.c определение функции ff_mpv_encode_init() https://www.ffmpeg.org/doxygen/4.0/mpegvideo__enc_8c.html#a96965da2a9774331b1b74e97f34312d1
Там прямо на 723-й строчке сказано:
> "notice: b_frame_strategy only affects the first pass\n"
Можно копнуть глубже, и убедиться, что установка этих параметров в структуре AVCodecContext происходит с условным переходом и соответствующим сравнением установленных флагов с контрольным вектором AV_CODEC_FLAG_PASS2 (который отвечает за проверку установленных пользователем флагов на соответствие требованиям второго прохода — побродив по гиперссылкам, сгенерированным системой Doxygen, можно убедиться и в этом).
Убедиться в том, что параметр «qblur» игнорируются на первом проходе, можно, следующим образом:
- проследовать по ссылке https://www.ffmpeg.org/doxygen/4.0/structAVCodecContext.html в секцию doxygen-документации, описывающую структуру AVCodecContext;
- найти переменную AVCodecContext::qblur https://www.ffmpeg.org/doxygen/4.0/structAVCodecContext.html#acf7ff44bfb16c8f4da1e7c1567964074 и посмотреть, какие функции её используют;
- интерес представляет определённая в файле ratecontrol.c функция ff_rate_control_init() https://www.ffmpeg.org/doxygen/4.0/ratecontrol_8c_source.html#l00472 — она определяет, какие параметры будут установлены для контроллера ширины потока;
- поискать «qblur» и убедится, что в строчках с 612-ой по 667-ю значение переменной переопределяется (значением, указанным при вызове ffmpeg) только после контроля флагов по вектору AV_CODEC_FLAG_PASS2, т. е. только для второго прохода.
>>3048910>>3049994-кун
> vlc и через него записать, но хуёво что там нельзя прокручивать прямую трансляцию чтобы отмотать немного назад и начать запись с нужного фрагмента
А какая тебе разница? Потом отрежешь ненужное. Кстати, mpc-hc в этом плане удобнее: его можно запустить в фоне и забыть. Я так пишу все трансляции на ютубе.
> А для чего?
Я забыл. Извини!
Документация http://ffmpeg.org/ffmpeg-protocols.html#pipe сходу не даёт ответа. Посоны со stackoverflow говорят, что анализатор аргументов, проверяет, состоит ли имя входного файла или выходного только из «-», и использует тот же протокол pipe. Можешь поковырять исходник, если интересно. Документация в большинстве примеров явно указывает протокол pipe.
Спасибо за развернутое объяснение. Хотелось бы чтобы в ffmpeg документация была бы получше.
«b_strategy 2», «brd_scale» и «b_sensitivity» всегда в связке используются? если не используется b_strategy то и остальные тоже? и почему именно в ff_mpv_encode_init нужно смотреть их назначение?
> т.е. для каждого интересующего параметра нужно будет обшаривать все функции где он используется и искать AV_CODEC_FLAG_PASS2?
Не обязательно. Можно сразу найти функции, использующие константу AV_CODEC_FLAG_PASS2 https://www.ffmpeg.org/doxygen/4.0/group__lavc__core.html#ga234d986d58043b694dd518e2312b4cbe
Вот они:
- aom_init(), vpx_init(), X264_init(), XAVS_init() и xvid_encode_init() — это функции инициализации структур с параметрами для кодеров из библиотек libaom-av1, libvpx, libx264, libxavs и libxvid соответственно; при анализе моего примера можно смело пропускать, т. к. я использую кодер mpeg2video из библиотеки libavcodec;
- avcodec_string() — это функция, которая набирает (просто собирает из параметров и их значений, не выводит) строчку, которую я подчеркнул на первой картинке; она чисто информационная, на параметры кодирования не влияет;
- encode_frame() — это функция передачи очередного кадра в кодер из библиотеки libtheora; тоже не интересует;
- encode_init() — это функция инициализации кодера FFV1; не относится к mpeg2video;
- encode_picture() — эта функция кодирует очередной кадр из группы (GOP); может быть, что-то интересное там и есть, т. к. относится как раз к общим определениям для всех mpeg-кодеров из libavcodec, но это уже непосредственно кодирование, а не подготовка и проверка входных параметров; можно пропустить и не смотреть;
- estimate_qp() — эта функция предсказывает значение QP (параметра квантования ДКП-коэффициентов); тоже относится непосредственно к кодированию для всех mpeg-кодеров из libavcodec; тоже можно пропустить;
- ff_mpv_encode_end() — эта функция завершает процесс кодирования последовательности (очищает буферы, закрывает контексты и всякое такое прочее); тоже относится непосредственно к кодированию для всех mpeg-кодеров из libavcodec; тоже можно пропустить;
- ff_rate_estimate_qscale() — эта функция предсказывает значение qscale (сомножителя, определяемого целевым значением ширины потока, и необходимого для получения конкретных значений QP); тоже относится непосредственно к кодированию для всех mpeg-кодеров из libavcodec; тоже можно пропустить;
- new_video_stream() — добавляет и инициализирует структуру, соответствующую новому потоку данных (в данном случае соответствующего выходному потоку данных кодера видео); эта структура используется дальше модулем упаковки потоков в контейнеры; можно пропустить;
- print_final_stats() — выводит на stderr (стандартный поток вывода ошибок) статистическую информацию о процессе кодирования непосредственно перед завершением работы ffmpeg; можно пропустить;
- select_input_picture() — эта функция, похоже, определяет в структуре MpegEncContext для текущего кадра его позицию в пределах GOP, номер в воспроизводимой последовательности и назначает тип этого кадра (I, P или B); сравнение текущих флагов из структуры AVCodecContext с вектором AV_CODEC_FLAG_PASS2 происходит на 1548-й строчке mpegvideo_enc.c, где, как я догадываюсь, происходит определение типа кадра в GOP по информации, прочитанной из файла со статистикой первого прохода (см. примечание); сама функция тоже относится непосредственно к кодированию для всех mpeg-кодеров из libavcodec; тоже можно пропустить;
- ff_rate_control_init() — эта функция инициализирует часть структуры MpegEncContext, отвечающую за параметры модуля контроля ширины потока; в тексте этой функции есть смысл поискать, как связаны вектор флагов AV_CODEC_FLAG_PASS2 и значение параметра qblur;
- ff_mpv_encode_init() — эта функция инициализирует какой-либо mpeg-кодер из libavcodec, проверяет указанные пользователем параметры кодирования и устанавливает переменные в соответствующих структурах; эта именно та функция, в которой следует искать ответы на вопрос, какие там параметры для второго прохода нужны или не нужны.
Примечание
За содержимое файла со статистикой первого прохода отвечает в ffmpeg модуль контроля ширины потока. В этом нетрудно убедиться, посмотрев содержимое этого файла и определение структуры RateControlContext::entry https://www.ffmpeg.org/doxygen/4.0/structRateControlEntry.html в файле ratecontrol.h https://www.ffmpeg.org/doxygen/4.0/ratecontrol_8h_source.html#l00041
>>3050472
> в ffmpeg документация была бы получше
Конечно, хотелось бы. Но она и сейчас вполне себе хороша.
> «b_strategy 2», «brd_scale» и «b_sensitivity» всегда в связке используются?
В зависимости от значения «b_strategy». Параметр «b_strategy» отвечает за способ определения структуры GOP mpeg-кодером из libavcodec:
- 0 — всегда использовать жёсткую структуру GOP в соответствии с максимальным количеством допустимых последовательных B-кадров (определяется параметром «bf»); здесь параметры «brd_scale» и «b_sensitivity» не имеют смысла, т. к. не используются;
- 1 — использовать параметр «b_sensitivity» для исключения B-кадров в сценах со сложным предсказанием движения; здесь имеет смысл только параметр «b_sensitivity»;
- 2 — использовать оптимальное количество B-кадров; насколько помню, используются оба параметра («brd_scale» и «b_sensitivity»), т. е. результат работы алгоритма, соответствующего стратегии предыдущего пункта, используется как начальное приближение, а потом по этому результату отрабатывает оптимизатор RD (rate-distortion; критерием является соотношение между внесёнными искажениями и коффициентом сжатия).
Увеличение значения параметра «b_sensitivity» приведёт к тому, что B-кадры будут встречасться чаще.
Параметр «brd_scale» определяет коэффициент масштабирования исходного растра (снижение разрешения кадра) для ускорения кодирования при решении оптимизационной задачи; чем больше значение, тем меньше разрешение, тем выше погрешность решения оптимизационной задачи, и выше скорость кодирования в целом.
> почему именно в ff_mpv_encode_init нужно смотреть их назначение?
Да, документация к ffmpeg не успевает за разработкой кода. Назначение нужно устанавливать в следующем порядке: пользовательская кокументация (включая справочный вывод самой утилиты ffmpeg), точка определения переменной в исходном коде (там часто в комментариях сразу указывается, что это и зачем введено), использовапние переменной в соответствующих её назначению функциях (тоже исходник рыть). Каждый следующий пункт сложнее, но приходится рыть, чтобы разобраться. Как работает конкретно «brd_scale», нужно смотреть в функции estimate_best_b_count(), которая определяет оптимизационное решение для количества B-кадров, https://www.ffmpeg.org/doxygen/4.0/mpegvideo__enc_8c_source.html#l01382
Так это делается через ffmpeg (чтобы выбрать первую дорожку видео, третью звуковую и первые субтитры):
ffmpeg -i input.ts -map 0:v:0 -map 0:a:2 -map 0:s:0 output.ts
Если контейнер у тебя матрëшка (mkv), то, как отметил >>3051142, есть более продвинутый инструмент - mkvtoolnix. Для mp4 есть библиотека gpac с утилитой mp4box, к котороц есть и графические интерфейсы (например, mp4box gui). Для контейнера mpeg-ts тоже есть отдельные утилиты. Для avi есть avimux.
>>3051152
Спасибо, анончики, это именно то, что нужно. Вы не представляете, как меня выручили, я заебался хранить сотни всратых дубляжей с рутрекера на своем харде. Почему эти дауны не могут просто положить эти дубляжи в отдельную папочку, как это делают анимудебилы, а не вшивать кучу говна в мкв?
В дополнение к своему посту >>3051152 сообщаю, что для MPEG-TS есть отличная свободная софтина —
https://github.com/justdan96/tsMuxer
Я ей пользовался когда-то давно. Я теперь внезапно обнаружил, что у неё есть графический интерфейс.
>>3051172
Написать на XML файл. И указать его как файл тегов при сборке через mkvtoolnix. Спецификации и примеры вот здесь https://www.matroska.org/technical/tagging-video-example.html
Может быть, есть нрафический интерфейс для заполнения, но я про него не знаю, т. к. мне проще в текстовом редакторе всё это накидать.
Нужно добавить вторую видеодорожку, но она должна быть длиннее раза в 3, тогда 99.99% процентов будет превьюшка с неё. Если сделать меньше, то не всегда будет превьюшка с неё.
Ну и из-за удлиненной дорожки в хромбасед неправильная длина видео отображается. В лисе вроде всё нормально.
> Купи видеокарту с аппаратным энкодером vp/av
Кстати как определить в какой карте есть такой декодер, его скорость и версию? И есть ли такие карточки за 7-10к? И есть ли кстати отдельно такие карточки лол? Играю на своей некровидяхе а в соседнем слоте стоит чисто аппаратдый энкодер.
Я предпочитаю программный libx264 с предустановками «ultrafast» и профилем «high 444 predictive» и без потерь (crf=0). Потом монтирую и кодирую на публикацию. На Героев 3 в 1920x1080@60 поток видео от 10 до 30 Мбит/с, плюс 2 Мбит/с на стереозвук. Половина производительности четырëхядерника уходит при захвате на libx264, но остального Героям 3 хватает с лихвой.
> Кстати как определить в какой карте есть такой декодер, его скорость и версию?
У энвидэ для каждой архитектуры есть таблица с поддержкой.
https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new
Раздел Decoding.
Попробовал аппаратный h.264-кодер из состава моего камня (i5-4200U). Делал примерно так:
ffmpeg -hide_banner \
-vaapi_device /dev/dri/renderD128 \
-r 15 -f x11grab -s 3200x1800 -i :0.0+0,0 -vsync 1 \
-vf 'hwupload,scale_vaapi=format=nv12' \
-c:v h264_vaapi -qp 10 output.mp4 -y
Те же 10-30 Мбит на тех же Герох 3, лол. При другом разрешении, при цвете 4:2:0, другой частоте кадров и при кодировании с потерями.
Максимум, который из себя в состоянии выдавить Intel QSV на разрешении 3200×1800 — это 20-22 кадра/с. На разрешении 720×576 скорость кодирования будет уже за 200 кадров/с. Сходится более-менее. Вполне возможно, что горлышко было в i/o-операциях.
Попробую ещё QSV на работе — там настольная рабочая станция, и камень мощнее, чем в моём ультрабуке.
>>3053232
Извини! Я не смог понять то, что ты пытался высказать.
Кстати, если на этой же машине пытаться кодировать через libx264 в high444pp примерно так:
ffmpeg -hide_banner \
-r 15 -f x11grab -s 3200x1800 -i :0.0+0,0 -vsync 1 \
-pix_fmt yuv444p \
-c:v libx264 -threads 4 -preset ultrafast -crf 0 output.mp4 -y
то от производительности на двух дохленьких ядрах остаются для Героев 3 вообще крохи. FFmpeg даже кадры умутряется иногда пропускать, а предел libx264 на этом камне при таких параметрах — 18-20 кадров/с. Такие дела.
>>3053245
> Акчуали, математически всё ещё с потерями
Да, при целочисленном округлении результата преобразования цветового пространства RGB->YUV. Это очень небольшая ошибка.
>> (crf=0)
> это кому-то было важно, но --qp 0
С x264-cli формально это не одно и тоже. А вот с libx264 и обёрткой из ffmpeg это одно и то же:
http://trac.ffmpeg.org/wiki/Encode/H.264
Если посмотреть секцию codec_private в уже готовом потоке, то строчка с параметрами кодирования будео оканчиваться как раз на «qp=0».
Замечание твоё, тем не менее, дельное. Буду старатся давать параметры совместимыми с синтаксисом x264-cli.
Цена вопроса примерно такая:
- hevc + lossless + 8192×8192 + 10 bit + b frames — от 35 т.р.;
- hevc + lossless + 8192×8192 + 10 bit — от 25 т.р.;
- avc + lossless + 4096×4096 + 10 bit + b frames — от 13 т.р.
Соответственно камни:
- NV167 (TU117) — nvidia-win + nvidia-linux;
- NV137 (GP107) — nvidia-win + nvidia-linux;
- NV117 (GM107) — nvidia-win + nvidia-linux.
Нуво, похоже, не поддерживает кодирование через VA-API на перечисленных камнях. Собственнические драйвера для обеих ОС поддерживают кодирование в полном объёме и через NVENC, в т. ч. HEVC, в т. ч. без потерь. У варианта VA-API есть qp=0, но сходу не нашёл, что это именно «без потерь».
> че по ав1
Похуй.
> на тучке
<<
> а вот кстати и эта заглушка снова вылезла и нихуя не работает
>>3054229
mpv + https://github.com/rossy/mpv-install/blob/master/README.md
Для .mkv, .вэбм будут превью. Следует понимать, что хэвк это кодек и превью будут отображаться в зависимости от контенера, в котором он содержится.
Почему так сложно придумать что-то уровня гениально jpg только для видосов? Хотя ответ и так очевиден, нужно продавать железо гоям..
edfecfd>>3029626 (OP)
>>3054996
Херня. Я могу сжать пикчу в несколько линий.
>Универсального, компактного и с приемлемым размером формата, так и не завезли.
Чем h.264 внутри mp4 не устраивает?
>так сложно придумать что-то уровня
Исторические причины, няш. Когда кроме JPEG/JFIF толком не было ничего, он зашëл на максимально широкий круг технических средств. А развивавшийся по тому же сценарию JPEG2000 успех повторить не смог.
> Чем h.264 внутри mp4 не устраивает?
Весит много.
> Когда кроме JPEG/JFIF толком не было ничего.
Это конечно тоже причина, но будем честны, лучше то нихуя и не придумали до сих пор. Лишь выпускают более перегруженные хуйни, чтобы у тебя одна фоточка за десять жрала ресурсов. Какой-то прогресс в обратную стороны получается.
>Весит много.
На треть?
>лучше то нихуя и не придумали
«Лучше» - это не объективная характеристика. Я тебе привëл более совершенный способ сжатия изображений. К сожалению, он нашëл своë применение как часть стандарта на электронные документы (PDF). Или на способ хранения изображений для цифровых систем хранения и обработки видео (MXF).
Помогите, я дегрод. При кодировании звука + картинки скачанного через yt-dl -f 251 с флагами видео -b:v 0 -crf 16 -g 360 -vf scale=-1:720 -pix_fmt yuv420p при использовании vp8 вебм получается адекватной длинны, а при vp9 - добавляются 25+ секунд тишины в конце, которых нет на источнике. Не понимаю что я делаю не так, нагуглить не могу.
Стоит ли мне вообще ебаться, если я только для музыкальных вемб с картинками это делаю?
Полный ввод ффмпега (большую часть брал из туториала):
-i \"%(title)s.webm\" -r 1 -loop 1 -i \"%(title)s.webp\" -c:a libopus -b:a 128K -c:v vp9 -b:v 0 -crf 4 -g 360 -vf scale=-1:720 -pix_fmt yuv420p -map_metadata 0 -shortest \"%(title)s-fin.webm
Сами результаты тоже тута
Я сначала брал отсюда параметры - https://github.com/pituz/webm-thread/wiki/Pro-tips#%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-%D0%B8%D0%B7-%D1%81%D1%82%D0%B0%D1%82%D0%B8%D1%87%D0%BD%D0%BE%D0%B9-%D0%BA%D0%B0%D1%80%D1%82%D0%B8%D0%BD%D0%BA%D0%B8-%D0%B8-%D0%BC%D1%83%D0%B7%D1%8B%D0%BA%D0%B8
Но потом решил попробовать с вп9, но тут хуйня с лишними секундами получилась.
Бля я не знаю что я приложил к посту, вот то о чем я говорю.
Ну какие были.
Я объединяю вебм с только аудио (251) с картинкой.
Стримы в таком порядке потому что мне не охото было разбираться с синтаксисом map_metadata, надо будет посмотреть, как из втрого вынимать ее ( что я хочу). А есть ли смысл до 160 ставить аудио если я скачиваю 128-135K?
Если проснусь завтра - продолжу эксперименты.
Раньше просто был сайт где выбираешь версию и разрядность винды, а теперь вот это вот всё.
Это всё было и раньше, ты просто не вдавался в подробности.
Release build и nightly git build. В FFmpeg, помнится, говорят, что у них официально нет стабильных веток, кроме технических для исправления ошибок и уязвимостей, и можно пользоваться прям самым последним кодом. Мы на это вежливо киваем и идём за релизной версией (если нам не требуется что-то, что починили прямо вчера). Грабли, на которые наступило много народу, всегда удобнее новых.
Shared и static. Поскольку ты всё равно качаешь программу целиком, для тебя разница заключается только в том, что архив с тремя (на две трети ненужными) утилитами в три раза больше, поскольку в каждой статически собраны все библиотеки. Другие каналы распространения (например, пакетные менеджеры) большую часть зависимостей оформляют в отдельные сущности, разделяемые всеми приложениями в системе, поэтому там ffmpeg собран динамически с системными библиотеками. Напротив, если нам потребуется FFmpeg с зависимостями, недоступными в качестве системных или несовместимыми с ними, понадобится статически собранная версия. Возможно, тебе для чего-то нужна одна из библиотек в собранном виде, тогда понятно, что выбрать.
GPL и LGPL. Части кода FFmpeg и используемые библиотеки имеют разные лицензии. При сборке без поддержки функций, доступных под GPL (среди которых libx264), вся программа доступна на условиях LGPL, иначе весь код становится GPL. Поскольку ты ничего не пишешь и не распространяешь, ты имеешь право взять полную GPL-версию и делать с ней всё, что хочешь, а вот компаниям, использующим библиотеки FFmpeg, надо думать. Впрочем, китайцев, лепящих всякие Super Hui Encoder 2005, это никогда не останавливало.
Ещё были 32-битные сборки, но теперь их надо искать отдельно (например, Reino делает под старые Windows).
Отсюда качай, сюда встроен несвободный FDKAAC.
https://github.com/AnimMouse/ffmpeg-autobuild/releases
Привет, анонче-икспишник! Я хотел бы у тебя спросить, удобно ли тебе сейчас сидеть на Windows XP? Ну как, сможет ли на XP устанавливать и работать Фотошоп CS6? Можно ли сидеть на браузерах MyPal или на NewMoon или же на Maxthon 6? Не нуждаешься ли ты обновлениях? Я вот возможно хочу перейти на XPшку 64-битную в скором времени. Какие подводные камни есть?
Так я на Windows 98 сижу, а XP поставил, чтобы сайты меньше глючили.
В 64-битной XP нет никакого смысла, на неё забивали и авторы драйверов, и авторы программ, и сама Microsoft. Это был не выбор между двумя параллельными одинаково поддерживаемыми вариантами, как после, а совсем отдельная архитектура, как версия для Itanium, и переделана она была из 64-битного Windows Server 2003. Рабочая станция с кучей гигабайтов памяти тогда была очень специфической необходимостью, типичному пользователю вообще не интересной.
Ну допустим, сама XP для меня интересна, что даже до искушения. Ну вот у меня есть некоторое желание на нём сидеть и использовать. Даже не смотря, что драйверов под неё мало и что обновления на неё нет, ну это меня не отгоняет от XP. Но XPшка под 64-бит вроде идут обновления, смотря некоторые видеообзоры. Так что у меня всё равно есть желание сидеть на 64-битной XPшке
Удалил перекодирование аудио, все так же, но за напоминание спасибо.
Пробовал другие методы с https://sites.google.com/a/webmproject.org/wiki/ffmpeg/vp9-encoding-guide . Не помогло. Что ж происходит такое?
best quality - -b:v 1000K -threads 8 -speed 0 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25
constrained - -b:v 500K -crf 23 -threads 8 -speed 4 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25
(ленюсь двумя проходами делать, поэтому в 1)
Не заю что еще попробовать, нонфри версию что ли скачать.
Оригинал вебм со звуком, если кто то будет смотреть. Но у меня такое со всеми файлами, не только вебм, если с обычных музыкальных файлов то то же самое.
https://ffmpeg.org/ffmpeg-formats.html
Опция форматирования.
‘shortest’
Stop muxing at the end of the shortest stream. It may be needed to increase max_interleave_delta to avoid flushing the longer streams before EOF.
>>3055281
т.е я правильно понимаю, что git это как бы бета версия, а release это рабочая версия рекомендуемая для простых смертных? В essentials все самое необходимое, а в full/shared уже со всякими доп.функциями для тех, кто точно знает зачем они нужны?
Только не пойму, почему на одном сайте версия shared весит больше чем essentials, а на другом наоборот?
> FDKAAC
Это мне точно нужно? Один раз для перекодирования звука мне понадобилось скачивать opusenc. Это нечто подобное только уже встроенное в сам ffmpeg?
Нет, всё неправильно. На зелёненькой страничке написано, чем отличаются версии, и какие библиотеки в каждой. Сравнивать размеры архивов разных форматов и с разным содержанием довольно глупо. Тебе подойдёт ВООБЩЕ ЛЮБАЯ версия. Если нужно будет — поменяешь. Вместо fdk_aac можно пользоваться обычным aac. Будет нужно что-то специфическое под низкий битрейт — поменяешь.
Уже десять раз мог бы всё запустить. В информации о версии указано, с какими библиотеками собран файл.
>Она объективна в соотношении: размер - совместимость - популярность.
Зачем ты тогда путаницу вводишь? Сразу бы и говорил об этих объективных характеристиках. В смысле градиента по всем трëм твоим характеристикам, наиболее близким к оптимальному является вариант с H.264. Пользуйся и наслаждайся!
> не буду вдаваться в подробности
А кто за тебя будет это делать? Ты ожидаешь, что кто-то тебе лично вслух прочтёт описание рядом со ссылками? Как ты будешь параметры нужные указывать, не читая документации и не понимая, что они делают? Интуитивно? Копируя куски команд из интернета? Так нормально работать не будет.
av1 или vp9?
>Нет, всё неправильно.
Нахрена ты его путаешь, всё правльно он сказал git как nightly постоянно обновляется, а releease как stable. В essentials базовые кодеки, которыми пользуются чаще всего, а в full их больше. Разница только между обычной static скомпиленной версией в один exe, и shared с библеотеками dll рядом с exe.
>>3055671
Тупо бери git full static с 3 .exeи не парься. FDKAAC тебе не нужен вообще.
>Av1 лучше VP9.
Говно, оба. Первый говно в квадрате, поскольку буквально неюзабельное говно.
>мусорного h264
Хуй264 чисто по профилям и алгоритмам не просто на голову выше VP8,9/AV1 подзалупы, он в другой реальности нахуй. Их сравнивать даже смешно. Иди жри бандинг и отсутствие деблока.
Так бы сразу и сказал, что тебе инфомусор генерировать и атмосферу нагревать. Я считаю, что выиграть вдвое по ширине потока у H.264 (libx264, slower) можно с VP9 или с H.265 (libvpx, libx265 при аналогичных настройках) только при очень сильно заметной деградации изображения, т. е. в области качества, которую я нахожу нежелательной. И это ценой минимум троекратного роста вычислительной нагрузки при кодировании и кратного сокращения множества целевых клиентских устройств. Ну, такое себе. Со слотовыми затычками всë ещë сложнее.
>Хуй264 чисто по профилям и алгоритмам не просто на голову выше VP8,9/AV1 подзалупы, он в другой реальности нахуй. Их сравнивать даже смешно. Иди жри бандинг и отсутствие деблока.
Это так. Но как бы ты не пердел, vp9, а тем более av1 лучше в плане сжатия в разы.
> Хуй264 чисто по профилям и алгоритмам не просто на голову выше VP8,9/AV1 подзалупы, он в другой реальности нахуй. Их сравнивать даже смешно. Иди жри бандинг и отсутствие деблока.
Хуя манямирок. Бандинга нет при 10 бит. Ав1 по битрейту не просто в два, раза в три лучше 264
ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ
ПЕРЕКАТ ПЕРЕКАТ
https://2ch.hk/s/res/3056070.html
https://2ch.hk/s/res/3056070.html
https://2ch.hk/s/res/3056070.html
https://2ch.hk/s/res/3056070.html
https://2ch.hk/s/res/3056070.html
> XP устанавливать и работать Фотошоп CS6
XP его поддерживает.
> Можно ли сидеть на браузерах MyPal или на NewMoon или же на Maxthon 6?
Лучше подобрать что-нибудь хромое, китайское, вроде ChromeMini или 360EE очищенные васянами, они несут за собой относительно свежий хромой движок. Некролисы такое себе, говорю как лисог.
> Так что у меня всё равно есть желание сидеть на 64-битной XPшке
Советую не заморачиваться и сидеть на 32 битной, под неё больше всего софта написано.
> ChromeMini
Если что, то я об этом: https://browser.kfsafe.cn
> Почему так сложно придумать что-то уровня гениально jpg
>>3054964
> с минимальное потерей качества.
Удачи тебе с пожатием альфа канала.
>>3054965
WEBP выигрывает при пожатии градиентов и прочих низких частот, за счет внутрикадрового предсказания. Но сами НЧ он сжимает плохо. Там либо мазки от предсказателя остаются, либо и вовсе превращаются в кисель из блоков.
Сейчас идеал это AVIF: он и на 8 битах лучше обращается с НЧ, а на 10 так и вовсе можно избежать бандинга. + перспектива на поддержку браузерами, чего не будет у HEIC из-за лицензионных проблем с HEVC. Единственный недостаток: большая вычислительная сложность.