The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск мультимедиа-пакета FFmpeg 7.0, opennews (??), 05-Апр-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


15. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Zenitur (ok), 05-Апр-24, 11:56 
Я например жму в Xvid. На торрентах дофига раздач в нём. Что интересно, даже актуальные фильмы выкладывают в h265/h264/xvid. Это значит, что это кому-то нужно, что кто-то xvid скачивает и смотрит...

Я как-то по приколу перекодировал видео с ютюба в 854x480 при битрейте 555k (почему именно такой битрейт? Потому что в Wiki-страничке на сайте ffmpeg указан такой пример). Двупроходное кодирование, само собой. Получилось интересно. Квадратики, но фреймрейт бодренький. Даже когда динамичные сцены, никаких сверх-искажений не было. Я потом пережал в 855 килобит - стало значительно лучше.

Потом посмотрел, в каком качестве кодируют на торрентах. Раздачи, которые я нашёл беглым гуглингом, начинаюся от 1,1 мегабита и заканчивается 1,9 мегабитами. Почему не ровно 1 мегабит и не ровно 2 мегабита - мне неведомо. Наверное, авторы rip-ов как-то расчитали наиболее идеальное качество - по алгоритму, который мне неизвестен. Либо же там vbr, переменный битрейт в зависимости от сложности кодирования каждого кадра...

А вот размер видео, которые мне попадались, всегда были 360p. Никаких 480p мне не попадалось... Причём если по-горизонтали разрешение всегда 640 или 720 (что как бы нормально), то по-вертикали всега начинается какая-то экзотика. Такое ощущение, что видео подрезают сверху и снизу, чтобы ещё лучше сжать.

Я почитал статью на Википедии про Nero Digital. Там внизу статьи приведены ссылки на бенчмарки, проведённые ресурсом Doom9 в 2005 году. http://forum.doom9.org/showthread.php?s=&threadid=90784 Видео в формате DivX 6 для теста там сжимали с битрейтом 450 для стримов и 900 для обычных видео. Походу, это чтобы на CD-R влез полуторачасовой фильм.

Я тут подсчитал на калькуляторе: чтобы 2-часовой фильм влез на CD-R, битрейт должен быть 777 килобит суммарно видео + аудио. То есть 650 килобит видео + 128 килобит аудио. В качестве 360p и сверху-снизу подрезать - и думаю, с качеством всё будет норм. Как я понял, так как в наши дни уже не нужно уместить видео на CD-R, видео стали жать с бо́льшим битрейтом.

Ну и Avisynth + VirtualDub в 2000-2008 были самыми лучшими инструментами для создания DVDrip-ов.

Ну и на Windows 98 SE в сборке от 98IF видео прекрасно играются как под Media Classic, так и через GOM. А вот в CentOS 5 через mplayer был тиринг! Я даже удивился, увидев тиринг на ЭЛТ-мониторе, я думал, что он там невозможен. А на 98-й винде никакого тиринга не было! Команда "compton --vsync opengl" поправила это недоразумение! Но блин, на винде и без композитинга всё было норм...

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

34. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +1 +/–
Сообщение от Аноним (33), 05-Апр-24, 13:12 
> Почему не ровно 1 мегабит и не ровно 2 мегабита - мне неведомо.

Раньше подгоняли размер файла под объем CD/DVD/BD. Сейчас - не уверен, что кто-то заморачивается.

> Такое ощущение, что видео подрезают сверху и снизу, чтобы ещё лучше сжать.

Отрезают черные полосы.

Ответить | Правка | Наверх | Cообщить модератору

90. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (43), 05-Апр-24, 18:15 
> Раньше подгоняли размер файла под объем CD/DVD/BD. Сейчас - не уверен, что кто-то заморачивается.

AVU 1.46 и 2.18 по-прежнему на трекерах стандарт. Причём самые востребованные раздачи, и этот феномен объяснить я никаким образом не могу.

Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (52), 05-Апр-24, 14:09 
Есть инфа по сжатию 1080p xvid?
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

54. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (43), 05-Апр-24, 14:28 
А есть принципиальные проблемы? Битрейт повыше и поехало. Правда, с  битрейтом-то как раз Pentium-3 потом и не справится.
Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (52), 05-Апр-24, 14:31 
> Битрейт повыше и поехало.

Путь виндузятника. Зачем бездумно задирать битрейт?

Ответить | Правка | Наверх | Cообщить модератору

62. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (43), 05-Апр-24, 14:58 
Почему бездумно? Хотите разрешение повыше — битрейт задирать _придётся_. На любом кодеке.
Ответить | Правка | Наверх | Cообщить модератору

92. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (-), 05-Апр-24, 18:28 
Так устроено сжатие видео и не как по другому не могут сделать - чем выше разрешение тем больше нужен битрейт чтобы не было искажений в видео. А дальше уже смотрят какой кодек может с наименьшими искажениями в видео сжать, с наименьшим битрейтом.  
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

128. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (8), 06-Апр-24, 00:16 
Сжатие видео устроено не так. Чем выше разрешение, тем более эффективные и дорогие техники кодирования можно задействовать, что позволяет ощутимо понизить относительный битрейт и сократить искажения. Хороший пример VVC.
Ответить | Правка | Наверх | Cообщить модератору

131. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (43), 06-Апр-24, 01:28 
Зависимость, безусловно, не линейная, но вполне однозначная. И да, на старых кодека с этим хуже.
Ответить | Правка | Наверх | Cообщить модератору

166. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (-), 06-Апр-24, 18:53 
Развитие всевозможных алгоритмов улучшения качества сжатия помогают сократить битрейт это факт. Но, одни алгоритмы улучшения сжатия не могут заменить нехватку битрейта, а только помочь снизить цифру битрейта, насколько снизить это выясняется, закодировал посмотрел. Почему кодеки и развиваются и не стоят на месте. Иначе можно было не заморачиваться с новыми алгоритмами сжатия или улучшениями алгоритмов сжатия и использовать что-то вроде кодека, PNG видео кодек с битрейтом 50Мбит/c.
Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

167. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (-), 06-Апр-24, 19:06 
PNG видео кодек с битрейтом 50Мбит/c это я не сам придумал как абстрактный пример название. Это я в программе для сжатия видео видел такой кодек, сам я им не особо пользовался очень большой размер файла получаются неприемлемо для меня большой, гигабайты размер, а часы видео десятки гигабайт. Оно и понятно, что с любым кодек с таким битрейтом размер файла будет большой.
Ответить | Правка | Наверх | Cообщить модератору

168. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (8), 06-Апр-24, 19:43 
Для примера, я кодирую файл в 360p и ему едва достаточно 1mbps. Потом кодирую этот же файл в 720p и 1mbps ему уже очень хорошо. Но кодирование ощутимо дороже и применяется куча дополнительных технологий. С пнг, я думаю, может быть заметная проблема с производительностью. Есть более эффективные форматы сжатия без потерь. Но, в принципе, набор картинок это практически идеальный вариант для сохранения целостности данных -- простой, все кадры настоящие и полные. Этот вариант обычно используется при обработке нейронками и прочем подобном.
Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

56. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Zenitur (ok), 05-Апр-24, 14:34 
> Есть инфа по сжатию 1080p xvid?

Мегабит 15 попробуй выставить.

Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

64. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (43), 05-Апр-24, 15:06 
Средний битрейт 4000, максимальный 8000 — не супер, но уже приемлемо. https://i.ibb.co/TWbjyLb/Twin-Peaks-Fire-Walk-With-Me-Comple...
Ответить | Правка | Наверх | Cообщить модератору

63. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (52), 05-Апр-24, 15:00 
Помоги пожалуйста разобраться с включением флага gmc.
ffmpeg -i out.mkv -c:v libxvid -flags gmc o.avi
При запуске выдаёт ошибку:
[libmp3lame @ 0x55b471464040] [Eval @ 0x7fff70a22300] Undefined constant or missing '(' in 'gmc'
[libmp3lame @ 0x55b471464040] Unable to parse option value "gmc"
[libmp3lame @ 0x55b471464040] [Eval @ 0x7fff70a21fe0] Undefined constant or missing '(' in 'gmc'
[libmp3lame @ 0x55b471464040] Unable to parse option value "gmc"
[libmp3lame @ 0x55b471464040] Error setting option flags to value gmc.
Error initializing output stream 0:1 -- Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

88. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (52), 05-Апр-24, 17:49 
Сам отвечаю (ну почти, до конца не понял):
За это отвечает отдельный параметр -gmc. Но это мне нейронка дала ответ, так что хз. Если 0 или 1 выставлять ему -- принимает значения, на другие ругается с ошибкой. По логике это тот самый gmc и его включение-выключение.
Ответить | Правка | Наверх | Cообщить модератору

126. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (-), 06-Апр-24, 00:02 
Что я узнал. ffmpeg -h full дальше ищем libxvid AVOptions: По какой-то мне неизвестной причине "-flags gmc" не существует как настройка по этому не кодирует и пишет: [libmp3lame @ 0x6094addb9200] [Eval @ 0x7fffeb212ac0] Undefined constant or missing '(' in 'gmc'
[libmp3lame @ 0x6094addb9200] Unable to parse option value "gmc"
[libmp3lame @ 0x6094addb9200] [Eval @ 0x7fffeb212780] Undefined constant or missing '(' in 'gmc'
[libmp3lame @ 0x6094addb9200] Unable to parse option value "gmc"
[libmp3lame @ 0x6094addb9200] Error setting option flags to value gmc.
Error initializing output stream 0:1 -- Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!
Ответить | Правка | Наверх | Cообщить модератору

127. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (43), 06-Апр-24, 00:15 
FFmpeg это просто, говорили они. Читайте маны, говорили  они…
Ответить | Правка | Наверх | Cообщить модератору

162. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (-), 06-Апр-24, 17:09 
В том-то и дело у них где-то ошибка мы не с головы взяли "-flags gmc" https://ffmpeg.org/ffmpeg-all.html найти раздел 16.19 libxvid, 16.19.1 Options эта настройка там и написана "-flags gmc", но в самом ffmpeg такого параметра нет потому и не кодируется с параметром "-flags gmc", что я и узнал. Оказалось надо перепроверять, смотреть вывод команды "ffmpeg -h full".
Ответить | Правка | Наверх | Cообщить модератору

163. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (-), 06-Апр-24, 17:26 
Точнее так: оказалось надо перепроверять и смотреть вывод команды "ffmpeg -h full".
Ответить | Правка | Наверх | Cообщить модератору

181. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (-), 07-Апр-24, 18:18 
16.19 libxvid, 16.19 libxvid. Изменили инструкцию, убрали gmc из раздела flags. Отдельно написано gmc.
Ответить | Правка | К родителю #162 | Наверх | Cообщить модератору

122. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Zenitur (ok), 05-Апр-24, 22:25 
Честно, я не спец по Xvid. Мне хочется научиться сжимать видео в этом формате так же хорошо, как это делали спецы в 2002-2005 годах. С наименьшим битрейтом, но при этом наибольшим качеством. Avisynth, VirtualDubMod, вот это вот всё. Почему-то в те годы эта информация ускользала от меня, как будто её имеют право знать только избранные.

Вот как я сжимал:

ffmpeg -i ИСХОДНОЕ_ВИДЕО.mp4 -c:v mpeg4 -vtag xvid -level 3.0 -b:v 1100k -pass 1 -an -f avi /dev/null
ffmpeg -i ИСХОДНОЕ_ВИДЕО.mp4 -c:v mpeg4 -vtag xvid -level 3.0 -b:v 1100k -pass 2 -c:a libmp3lame -b:a 128k output.avi

Вот. Для переменного битрейта:

ffmpeg -i ИСХОДНОЕ_ВИДЕО.mp4 -c:v mpeg4 -vtag xvid -level 3.0 -qscale:v 3 -c:a libmp3lame -b:a 128k output.avi

Также для видео надо параметр "-s 640x360" в случае, если я пережимаю 720p или 1080p-видео с ютюба.

Также параметр -qscale:v 0 (судя по тому, что пишут в интернете) делает видео наиболее большим по битрейту, и наиболее качественным.

Если кто-нибудь знает дополнительные параметры и всякие улучшайки - буду рад посмотреть. Я тут уже погуглил и нашёл какие-то:

https://askubuntu.com/questions/122147/need-to-convert-a-vid...
https://4pda.to/forum/index.php?showtopic=318265&view=findpo...

А вот твоё подключение нейросетей к этому процессу - это вышка! По-моему, так xvid ещё никто не сжимал!

P.S. А я тут подумал, а зачем мне стереозвук в Xvid-файле? В тех видео, которые я смотрю, едва ли кто-то заморачивается объёмным звуком - все смотрят ютюб со смартфонов... Можно же указать -ac 1 -ab 64k, тем самым высвободив 64k для видео... И тогда побольше влезет на CD-R, если стоит такая задача.

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

125. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (43), 05-Апр-24, 23:09 
Понять бы ещё, зачем это всё.
Ответить | Правка | Наверх | Cообщить модератору

174. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Zenitur (ok), 07-Апр-24, 07:25 
> Понять бы ещё, зачем это всё.

Скоро поймёшь.

Ответить | Правка | Наверх | Cообщить модератору

129. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (8), 06-Апр-24, 00:30 
У divx, кстати, куда лучше картинка была всегда. Ну и за mp3 в файлах четвертовать мало. Впрочем, я смотрю 2 подряд фильм с таким же aac-92kbps и avc-2100kbps (fullhd) и какие же всё-таки субхуманы этим занимаются. Ещё они цветовые пространства херят, из-за этого чёрный на экране всегда будет светлосерым. И через годик в нормальном качестве уже не найти в сети.
Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

140. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +2 +/–
Сообщение от Аноним (140), 06-Апр-24, 08:14 
Там большая проблема в интерфейсах Xvid и DivX. Хочешь как тогда - страдай с оригинальным гуём и VfW-кодеком. Тык-тык-тык, клац-клац-клац, зырк-зырк-зырк вместо автоматизации и чёткого списка параметров.

ffmpeg/mencoder как консольный интерфейс к libxvid? А они все опции выставляют? Нет. Где профили(@уровни), где ограничения на VBV-буфер? Без этих ограничений можно случайно вылезти за возможности аппаратного декодера. К тому же рядом на протухшую документацию указали (-flags gmc).

Консольный интерфейс xvid_encraw - официальный ли он, какой из форков нужен, где последняя версия? Но это должен быть лучший вариант.

Собственный ffmpeg'овый энкодер вместо Xvid? Начни с фразы из документации "libxvid will deliver better quality than mpeg4" и закончи ей.

Как кодировать? Для начала подстроиться под профиль MPEG4 Visual, поддерживаемый тогдашним железом. Он, внезапно, не прописан в стандарте. Это потом можно сказать, что железо декодирует H.264 вплоть до Main Profile. А нужный профиль MPEG4 Visual поверхностно описан... у авторов кодека DivX: профиль "DivX Home Theater"[1]. За него точно не стоит вылезать. Он описывает всё вместе: то, что обычно называют профилем + уровнем + остальное помимо видео*.

Если максимально использовать его профильную сторону, то будет более-менее эффективное кодирование.
Если ещё максимально использовать его уровневную сторону (битрейт, разрешение), то будет и качественная картинка.

А детальное описание профиля где? Подразумевается, что ты купишь себе DivX и не будешь тут это самое. Так что оно разбросано по форумам, как и оптимальные настройки для по-настоящему эффективного кодирования.

Я ограничивался этим:

ffmpeg ... -vf scale=720:-16 -codec:v libxvid -b:v 2000k ...
Битрейт постоянный, потому что с переменным битрейтом ffmpeg нужных гарантий не даёт (аналога -x264-params vbv-bufsize нет) и достаточно большой ради качества. Эффективности нет, это на один раз посмотреть, да и без хотя бы xvid_encraw гнаться за эффективностью всё равно несерьёзно.

* осторожно, 6-канальный звук может не работать

[1] https://www.divx.com/wp-content/uploads/2018/10/DivX-Cert_Pr...

Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

142. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (140), 06-Апр-24, 08:36 
А, я туплю, xvid_encraw идёт к Xvid'у. По крайней мере, сейчас. И CLI у DivX есть. По крайней мере, с DivX 5. Тогда проблема скорее в том, что кому-то было проще тонну скриншотов выложить, чем параметры для CLI.
Ответить | Правка | Наверх | Cообщить модератору

143. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (140), 06-Апр-24, 09:28 
А, я не так уж туплю, CLI появился именно в DivX 5, xvid_encraw - официальная, но неполноценная утилита, в нельзя задать профиль, хотя в устаревшем форке[1] они в недоделанном виде есть.

[1] http://forum.doom9.net/showthread.php?t=98469

Ответить | Правка | Наверх | Cообщить модератору

172. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (140), 07-Апр-24, 07:10 
Нет, на самом деле я лишь чуть-чуть тупил.

xvid_encraw в исходниках озаглавлена как "test application" и лежит в каталоге "examples"[1], стоит ли её расценивать как лучший консольный интерфейс, сравнимый с гуями? Так-то возможен и полуконсольный вариант с VfW-кодеком, запускаемым через avs2avi или .jobs-файл VirtualDub'ов. А ещё можно забить на Xvid и присмотреться к фразе из вики: "последняя версия ASP кодека ... DivX 6.9.2".

Слова в help'е, что она принимает поток из stdin - это не документация, а археологический артефакт, предположительно означающий, что она в 2002 году съедала вывод конкретно из mpeg2dec. Но она принимает avisynth-файл (хотя 64-битной сборки под 64-битный ависинт из коробки нет), это очень хорошо, через скрипт можно скормить любой исходник и фильтры ависинта дают всё нужное. stdin ей пытались чинить, но только в неофициальных патчах, форках разной степени сохранности на 2024-й год, на форумах[2][3][4].

[1] http://websvn.xvid.org/cvs/viewvc.cgi/trunk/xvidcore/example...
[2] https://forum.doom9.org/showthread.php?t=181894
[3] https://forum.videohelp.com/threads/399070-Xvid-1-3-5-CLI-is...
[4] https://forum.videohelp.com/threads/386228-Xvid-1-3-5-(CLI)#post2597811

Ответить | Правка | Наверх | Cообщить модератору

173. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Zenitur (ok), 07-Апр-24, 07:18 
Интересно. Теперь я знаю, куда копать. Спасибо.

Использование гуя для меня не проблема. Так даже лучше. Мне же всего лишь пару видео в год таким образом сжать (не пользуюсь старым компом на постоянке, только из ностальгии). А потому, без консоли было бы удобнее.

То есть, получается, можно сделать двупроходное кодирование при помощи встроенного в ffmpeg кодировщика mpeg4, но нельзя использовать двупроходное кодирование со сторонним кодеком libxvid? Потому что в новых версиях ffmpeg есть регрессия, из-за которой это перестало работать? Хм, а что если у меня ffmpeg 3.2? У меня Debian 8 с установленным из бэкпортов ffmpeg.

Чтобы делать двупроходное кодирование libxvid, мне надо отказаться от ffmpeg? И вместо него нужно использовать xvid_encraw, который раньше был сторонним скриптом, а теперь принят в апстрим? Вот только в апстрим он принят без части опций, а надо чтоб были.

Сами опции разбросаны по форумам, и сделаны на основе возможностей базовой версии кодировщика DivX. Никто не даст команду "сделать зашибись", так как никто её и не знает.

Ну и ещё несколько вопросов:

1. nvidia-settings во вкладке VDPAU показывает, что поддерживаются h264, MPEG4, DIVX4, DIVX5, MPEG-2 и VC1. https://blog.gyt.is/2018/08/26/pci-e-video-card-qemu-revert-.../ Про DivX 6 забыть? Или декодеру не важно, какой MPEG-4 отправлять на вход (за исключением DivX Pro с нестандартными алгоритмами)?
2. Есть официальный DivX для Linux: https://www.divx-digest.com/software/divxcodec_linux.html Он только для декодирования, или кодировать им тоже можно?
3. Примерно 10 лет назад вышел libxvid 1.3.0. Насколько я знаю, в тот момент это было крупное обновление, которое на данный момент является последним (не считая минорные версии). Вопрос, аналогичный DivX 6: не ломает ли новый libxvid совместимостиь со старой версией? Будет ли работать видео, сжатое им, на компьютере со старой версией кодека? А на аппаратных плеерах тех лет?

Спасибо за внимание. Попробую дополнительные параметры с сайта ubuntuforums, добавлю опции для двупроходного кодирования.

ffmpeg -i yourvid.mp4 -f avi -vcodec libxvid -vtag XVID \
          -vf scale=-1:360 -b 1100k -qmin 3 -qmax 8 -bufsize 4096 \
          -mbd 2 -bf 2 -trellis 1 -flags +aic -cmp 2 -subcmp 2 -g 300 \
          -pass 1 -an -f avi /dev/null

ffmpeg -i yourvid.mp4 -f avi -vcodec libxvid -vtag XVID \
          -vf scale=-1:360 -b 1100k -qmin 3 -qmax 8 -bufsize 4096 \
          -mbd 2 -bf 2 -trellis 1 -flags +aic -cmp 2 -subcmp 2 -g 300 \
          -pass 2 -acodec libmp3lame -ab 128k \
          yourvid.avi

640x360 для 16:9, 600x480 для 4:3 PAL, 600x400 для 4:3 NTSC.

P.S. Выше я тупанул, когда ты сказал "нейронка подсказала". Я думал, ты используешь нейронку для кодирования (слышал что для деинтерлейсингак её используют, только бывают проблемы с глазами), а оказалось, ты попросил её сделать поиск.

Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

180. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +1 +/–
Сообщение от Аноним (140), 07-Апр-24, 13:48 
Вообще сегодня оно не кажется сломанным, как написано в багтеркере. ffmpeg+libxvid имеет право на жизнь:
- лог дублируется (ffmpeg2pass-0.log + xvidff.XXXXXX)
- но он учитывается, двухпроходное кодирование работает*, качество лучше
- битрейт сильно отклоняется только при упоре в ограничения квантизатора, это видно в выводе ffmpeg (frame=XXX fps=YYY q=*может упереться qmin/qmax*) и в этом не виноват конкретно ffmpeg+libxvid

В принципе на каком-то исходнике Xvid (с любыми интерфейсами) может упереться в qmax (максимальной возможный равен 31) и молча вылезти за любые ограничения по битрейту (жёсткие ограничения не выставить). Если параноить как я, то можно следить за этим вручную. Похоже, тут[1] именно на это жалуются в 2004.

У меня -bufsize не влияет на результат (файлы идентичные - хэш от них совпадает).
-vf scale может гарантировать нужную кратность разрешения (надо иметь mod16 или, может, менее строгий mod4): -vf scale=-16:360. С -1 иногда может не повезти.

xvid_encraw изначально[2] официальная, про нейросетки другой анон написал, про DivX for Linux не знаю, об аппаратном ускорении DivX на ПК странно заботиться, но если всё же... то надпись про поддержку DivX 4/5 выглядит бредово. Возможно, в DivX 4 не было B-кадров[3]. Стандарт один - MPEG4 Visual. Профили DivX Certified с момента появления вряд ли менялись, я даже вчера видел где-то жалобу, что "могли бы Home Theater чуть расширить и добавить поддержку 3 point GMC и Qpel" и очевидный ответ про обратную совместимость, с libxvid аналогично - в кодеках не ломают так совместимость.

---

Компромиссность всех вариантов раздражает, глубже вникать в кодирование avi-шек не хочется. Наверное, где-то на форуме (опять рутрекер?) должен найтись урок от тех, кто много кодировал. Там приходилось думать и о совместимости с железными плеерами (единственное, для чего ещё нужен MPEG4 Visual?), и об эффективности - лучше некуда.

Наверное, там предложат взять VfW-энкодер и кодировать в 2 прохода с %professional_settings_list%, запуская его через %program_name% вроде VirtualDub2** или AvsPmod*** (но тогда нужен и Avisynth+, и плагины к нему - без ffms2 современные файлы не открыть). Точнее, там предложат что-то постарее, а эти программы ещё поддерживаются.

---

Хм, почему Xvid сейчас торгует "AutoGraph. A DRM that is no DRM. Video watermarking to stop piracy the smart way"[4]?

* с -qscale:v (фиксированный квантизатор) вместо -b:v (average bitrate, ABR) двухпроходное кодирование точно бесполезно, если вдруг ещё попадутся такие советы. 1 или 2 прохода - файлы идентичные.
** File -> Save video... -> VfW кодеки в левом нижнем углу -> ... -> повторить для второго прохода
*** Tools -> Script Encoder (VFW) -> Run -> Xvid MPEG-4 Codec -> ... -> повторить для второго прохода

[1] http://forum.doom9.org/showthread.php?t=74251
[2] http://websvn.xvid.org/cvs/viewvc.cgi/trunk/xvidcore/example...
[3] http://forum.doom9.net/showthread.php?p=845931#post845931
[4] https://autograph.xvid.com/

Ответить | Правка | Наверх | Cообщить модератору

186. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Zenitur (ok), 08-Апр-24, 13:01 
Ну что ж, я попробовал. Двупроходное кодирование работает. https://pastebin.com/PywTeRXZ Единственная проблема - mplayer ругается на двойное B:

[mpeg4 @ 0x7f7569767f60]Video uses a non-standard and wasteful way to store B-frames ('packed B-frames'). Consider using the mpeg4_unpack_bframes bitstream filter without encoding but stream copy to fix it.

При этом всё работает.

Я погуглил - это оказывается следствие недостатка контейнера avi: там нельзя два "B" подряд. Но это очень здорово улучшает качество видео, и особенно на старых компах вот этот "Packed bitstream" ускоряет воспроизведение.

Рутрекер, как я понял, к этому толерантен. Моя 98-я винда тоже. Что ж, пусть тогда будет.

P.S. В команде, которую я привёл выше, надо поправить "-b" на "-b:v". В противном случае, ffmpeg выдаёт предупреждение, но всё равно работает.

P.P.S. Почему у тебя не работает двупроходное кодирование с "-qscale:v"? Об этом написано на страничке H.264 на Wiki-страничке ffmpeg. Там двупроходное кодирование не работает с "-cbr 17" (это, я так понимаю, аналог "qscale" в Xvid). По аналогии с h264, могу предположить, что тут так же.

Ответить | Правка | Наверх | Cообщить модератору

191. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +1 +/–
Сообщение от Аноним (140), 10-Апр-24, 14:17 
mplayer ругается не на два B-кадра, а на способ их вкорячивания. MediaInfo его отображает:
> Muxing mode : Packed bitstream

Рутрекер о нём предупреждает:
> Опции кодирования должны быть: ... Packed bitstream - отключено

-bsf:v mpeg4_unpack_bframes на самом деле этот способ меняет и добавляет совместимости с железом. Хотя можно не догадаться, что этот фильтр принимает и видеопоток, создаваемый _внутри_ ffmpeg, без пайпа из одного ffmpeg в другой.

> P.P.S. Почему у тебя не работает двупроходное кодирование с "-qscale:v"?

Оно бесполезно. С -q:v статистика с первого прохода не может ни на что повлиять - результат такой же, как если кодировать в один проход, бит в бит. Считалка md5 пригодится (md5 от файла или встроенная ffmpeg'овая считалка от потока): https://pastebin.com/0CMFfEhi

Кстати, команда с ubuntuforums как будто составлена по принципу "кашу маслом не испортишь", там ещё -cmp и -subcmp ничего не делают - они не действуют в связке с libxvid. А нужен -me_quality без -cmp и -subcmp.

По-хорошему надо ещё исправлять[2][3] обратно цвет при уменьшении HD-видео до SD-видео. Он искажается, потому что... это долгая история, но mpv подтвердит.

У меня родилась творчески отформатированная баТпортянка с разбором опций. Значения не исследовал, только причесал код, сопоставил опции с xvid_encraw, добавил ссылки, которые могут пригодиться:
https://pastebin.com/jLMbicMV

[1] https://superuser.com/questions/1483338/cant-get-same-xvid-q...
[2] в Avisynth: ColorMatrix(mode="Rec.709->Rec.601"), в ffmpeg сработает -vf zscale=matrixin=709:matrix=170m, но почему он сработает как надо - это ещё одна долгая история.
[3] http://avisynth.nl/index.php/Colorimetry#Should_I_correct_an...

Ответить | Правка | Наверх | Cообщить модератору

194. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Zenitur (ok), 11-Апр-24, 12:15 
Спасибо за ответ. Скрипт для конвертации видео - просто шик. Для моего кейса - самое то. Не удивительно, что об этом мало информации в интернете: в годы актуальности третьепней, пережимали видео не с ютюба (а с DVD, VHS). А соответственно, готовых решений нет (условной кнопки "сделать зашибись"). Даже на официальной Wiki ffmpeg предлагается использовать кодировщик mpeg4 с "-vtag "XVID", а не libxvid... Я попробую скрипт, и надеюсь что это и есть кнопка "сделай мне зашибись", которая позволяет скнвентировать видео с ютюба для просмотра на третьепне.
Ответить | Правка | Наверх | Cообщить модератору

196. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Аноним (140), 11-Апр-24, 19:35 
Нет, ведь я не подбирал значения параметров, только привёл их к удобоваримому виду.

Да и погружение в такие тонкости может быть перебором. У меня свой интерес в том, чтобы иметь в запасе консольную команду для кодирования со своими приоритетами, поэтому постоянно отклоняюсь в их сторону (по убыванию: совместимость с DVD-плеерами, пригодность для любого типа видео, эффективность).

Вот снова отклонюсь и замечу, что mencoder как интерфейс к Xvid может похвастаться наличием профилей и полнотой опций, я это не заменил.

"профиль DXN [DivXNetworks] для домашнего кинотеатра" - https://manpages.debian.org/testing/mencoder/mencoder.1.ru.h...

Попутно гугл выдал issue насчёт неполноты в ffmpeg, там человек составил гуглотаблицу соответствия опций к Xvid в ffmpeg и в mencoder'е: https://trac.ffmpeg.org/ticket/8935 (и, кажется, он не заметил нерабочесть -bufsize и -maxrate).

Ответить | Правка | Наверх | Cообщить модератору

149. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +1 +/–
Сообщение от Аноним (149), 06-Апр-24, 10:24 
А я так сжимал, в два прохода:
ffmpeg -i \[anti-raws\]Violet\ Evergarden\ creditless\ OP1\[BDRemux\].mkv -c:v libxvid -c:a copy -qscale:v 3 -threads 0 -me_quality 6 -mbd rd -variance_aq 1 -gmc 1 -flags +mv4+aic+qpel -trellis 2 -pass 1 z.mkv
На счёт trellis не уверен. 2 для всех кадров, но пишут что иногда мыло даёт. Для B/P кадров можно 1 поставить.
Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

151. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +1 +/–
Сообщение от Аноним (140), 06-Апр-24, 11:02 
Если он решит повторить и кодирует для какого-то определённого плеера, то ему надо как минимум с QPel и GMC быть осторожным. Если для произвольного, то убрать их как выходящие за профиль DivX Home Theater и за правила рутрекера, которые тоже описывают возможности большинства железок. Хм, рутрекер разрешает 2 B-кадра, в отличие от Home Theater.
Ответить | Правка | Наверх | Cообщить модератору

159. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +1 +/–
Сообщение от Аноним (140), 06-Апр-24, 16:23 
А ведь двухпроходность с фиксированным квантизатором ничего не делает... потому что квантизатор-то для всех кадров уже зафиксирован.

Выход - задать битрейт вместо квантизатора. Но придётся отказаться от ffmpeg, потому что двухпроходное кодирование с libxvid в нём давным-давно сломано[1][2].

Я что-то засомневался в своих словах про ненадёжность квантизатора без ограничений сверху (ради которых тоже надо отказаться от ffmpeg), но сейчас убедился, что -qscale:v 3 способен превысить максимально допустимый битрейт аж в десятки раз. На цветной шум[3] он выделяет 90Mbps, как если бы это было 8K-видео, а не SD.

[1] https://trac.ffmpeg.org/ticket/6270
[2] https://trac.ffmpeg.org/ticket/6217
[3] Blackness(length=1*60*24, width=720, height=540, pixel_type="YV12").ColorYUV(off_y=(235-16)/2).AddGrainC(var=3000, uvar=5000, seed=0)

Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

187. "Выпуск мультимедиа-пакета FFmpeg 7.0"  +/–
Сообщение от Zenitur (ok), 08-Апр-24, 13:02 
Почему у тебя не работает двупроходное кодирование с "-qscale:v"? Об этом написано на страничке H.264 на Wiki-страничке ffmpeg. Там двупроходное кодирование не работает с "-cbr 17" (это, я так понимаю, аналог "qscale" в Xvid). По аналогии с h264, могу предположить, что тут так же.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру