| Автор |
Сообщение |
|
Серый1779 ®
Пол:  Стаж: 6 лет Сообщений: 3685 Откуда: Украина
|
Как выбрать оптимальный битрейт и ключевые параметры для рипа в x264-
-> калькулятор совместимости с аппаратными декодерами для расчёта ref-фреймов <-
-Чтение лога кодека и оптимизация битрейта
В связи с тем, что многие при выборе битрейта ошибочно полагаются лишь на показатель b-p/f , который иногда помогает, а иногда оказывается совершенно бесполезной цифрой, привожу на мой взгляд более правильную методику подсчёта целевого битрейта. Каждый видеоряд обладает разной сжимаемостью, для некоторых 0.1 пресловутого b-p/f достаточно, чтобы прозрачно без артефактов закодироваться в компактный размер. Бывают же сложные видеопоследовательности, которые не помещаются и в .25 b-p/f . Намётанный глаз сразу распознает приблизительную сложность видоряда для кодека, но более-менее достоверно оценить сжимаемость можно нижеописанным способом (занимает не более 5-10 минут с учётом времени на енкод, если только не использован тормозной скрипт). Имеет смысл при подготовке основательного рипа с упором на размер-качество.
Задача: Сжать распределённую выборку из целевой видеопоследовательности с заданным коэффициентом качества и оценить полученный результат.
Шаг 1. Сделать распределённую выборку из сорса
Достаточно добавить в конец .avs скрипта три волшебные строки и на выходе получим ряд продолжительностью ~2550 фреймов, составленный из равномерно выдернутых из видеоряда кусков по 50 фреймов. Обычно этого достаточно, чтобы оценить сжимаемость более-менее равномерного видео длительностью до 1.5-2 часов.
Три строки:
selectTotal1=framecount()/100
selectTotal2=selectTotal1*2
selectrangeevery(selectTotal2,50)
Шаг 2. Сжать подготовленную последовательность с настройками, с которыми планируете сжимать последний проход, но указать не битрейт и не --pass ?, а например --crf 18 (важно, что указываем не -q, а именно --crf)
Ждём завершения... и смотрим лог
Шаг 3. Читаем лог
Параметры компресии
Средние кванты
Полученный битрейт
Использование b-фреймов
-
процент задействованных b-фреймов, по порядку от 0 до 16. Если начиная с какой-то позиции стоят лишь 0.0 или 0.1-0.2, то использование --bframes больше этой цифры по сути бессмысленно и в большинстве случаев только увеличит время, необходимое для енкода
Использование частиц
-
Использование частиц анализа
I : i16x16,i8x8,i4x4 / PI: p16x16,p8x8,p4x4 / PP: p16x16,p8x8,p8x4,p4x8,p4x4 / BI: b16x16,b8x8,b4x4 / BB: b16x16,b16x8,b8x8
Если из лога видно, что какие-либо частицы не задействованы или задействованы по минимуму, то можно не включать их анализ в ключ --partitions p8x8,p4x4,b8x8,i8x8,i4x4. Как правило желательно оставлять анализ всех частиц для SD контента и выключать только p4x4 для HD сигнала.
Распределение DCT трансформации 8x8
-
Показывает насколько задействована 8x8 DCT трансформация, если проценты очень низкие, то ключ --8x8dct можно опустить в пользу скорости. Случай очень редкий, обычно стоит оставить параметр задействованным, если только не стоит задача сделать енкод максимально быстро. Без этого ключа автоматичнески отключится анализ частиц i8x8
Распередление выбора режима анализа векторов движения
-
Показывает процент выбора кодеком между режимами локального и темпорального анализа векторов. Для мультипроходного режима стоит оставлять --direct auto, если только енкод не нужно сделать максимально быстро или кодируется чрезстрочный сигнал. Смысл использования --direct auto в однопроходном режиме теряется, обычно для однопрохода можно смело оставлять --direct spatial
Использование ref фреймов
-
От 1 до 16 показывает насколько задействованы ссылочные кадры. Если после определённой цифры начинаются 0.0-0.2%, то смысл использовать --ref выше данного числа теряется, только увеличит время енкода. Аналогично как и для --bframes.
M:\Videos\mux\pstorm>start /low /b /w /d"C:\video-stuff\x264" x264.928.modified.
bf.exe --crf 18 --zones 2449,2449,q=40 --b-adapt 2 --psy-rd 0.8:1.0 -b 16 -r 16 --mix
ed-refs --b-pyramid --aq-strength 1.0 --b-rdo --bime -w --direct auto -f -3,0 -m
7 -t 2 -A all -8 --scenecut 35 -I 300 --me umh --merange 24 --threads auto --th
read-input --progress --sar 1:1 --output "M:\Videos\mux\pstorm\pstorm0_1.264" "M
:\Videos\mux\pstorm\pstorm0.avs"
avis [info]: 1040x432 @ 23.98 fps (2550 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4 Cache64
x264 [info]: slice I:48 Avg QP:15.14 size: 39314 PSNR Mean Y:46.18 U:51.02
V:51.80 Avg:47.18 Global:46.75
x264 [info]: slice P:922 Avg QP:17.23 size: 17666 PSNR Mean Y:43.98 U:49.35
V:49.94 Avg:45.08 Global:44.61
x264 [info]: slice B:1580 Avg QP:19.28 size: 6580 PSNR Mean Y:43.28 U:50.05
V:50.60 Avg:44.46 Global:43.88
x264 [info]: consecutive B-frames: 4.6% 17.9% 56.2% 10.9% 4.2% 3.4% 2.8% 0
.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: mb I I16..4: 3.2% 89.3% 7.5%
x264 [info]: mb P I16..4: 0.6% 12.4% 0.9% P16..4: 45.9% 23.0% 12.1% 0.2% 0
.0% skip: 5.0%
x264 [info]: mb B I16..4: 0.0% 1.4% 0.2% B16..8: 57.4% 1.8% 2.3% direct:
5.7% skip:31.2% L0:40.8% L1:55.4% BI: 3.8%
x264 [info]: 8x8 transform intra:89.3% inter:71.6%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: ref P L0 53.2% 18.4% 9.5% 5.0% 3.8% 3.3% 2.6% 1.5% 1.3% 1.
2% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: ref B L0 64.2% 15.9% 7.0% 3.9% 2.8% 2.4% 1.9% 1.3% 0.7% 0.
0% 0.0% 0.0% 0.0% 0.0% 0.0%
x264 [info]: ref B L1 89.9% 10.1%
x264 [info]: SSIM Mean Y:0.9707640
x264 [info]: PSNR Mean Y:43.586 U:49.814 V:50.380 Avg:44.734 Global:44.173 kb/s:
2149.16
encoded 2550 frames, 4.48 fps, 2149.34 kb/s
04.08.2008
15:03
Имеем три цифры квантов: для I фреймов, для P фреймов и для B фреймов. Чем динамичнее видеоряд, тем больше будет между ними разница и тем выше будут кванты для B фреймов. Если все три цифры не превышают 18, то полученного битрейта будет много и его смело можно резать процентов на 25 минимум. Если все три цифры превышают 22-23, то битрейта не хватает и его надо поднимать, если только целью не является минимальный размер рипа с допустимыми артефактами компресии. Для очень динамичного видео средний квант ~25 для b-фреймов вполне допустим. Обычно стоит следить, чтобы он не поднимался выше.
В логе, полученном с --crf 18, кванты как правило будут находится в промежутке 16..23. Полученный в результате битрейт и будет предпочтительным для сохранения максимально прозрачного качества. Если его делать выше, то это будет как праивло раздутием размера, опускаться ниже можно, но желательно не более чем на ~35-40%. При этом надо помнить, что поднимая/опуская битрейт на каждые 12.5% мы поднимаем/опускаем CRF на 1 целый пункт и в то же время, поднимая/опуская CRF на 6 пунктов мы увеличиваем/уменьшаем битрейт вдвое. Зависимость простая.
Шаг 4. Визуальный контроль
Цифры цифрами, но не забываем открыть полученный огрызок в любимом проигрывателе и оценить результат глазами. Еще лучше сравнить полученный результат с исходным изображением, удобнее всего это делать при помощи программы AvsP. Поскольку i-фреймов на весь видеоряд как правило не более 1-2% и сжимаются они с наименьшими возможными квантами, имеет смысл сравнение только b и p фреймов.
Вывод информации о кадрах через ffdshow:
В ffdshow задаем кодек вывода ffmpeg-mt или libavcodec, потом идем на стройку OSD и помечаем все, что хотим вывести (в нашем случае хватит только типа фрейма). Картинки:
Потом открываем скодированное видео в AvsP, жмем правой кнопкой на иконке ffdshow video в трее и помечаем галкой OSD
Осталось только перейти на вкладку с энкодом и обновить ее клавишей F5, на картинке появится обозначение типа кадра
ПС: точно так же выводятся данные по кадрам и для других кодеков, главное, чтобы видео декодировалось средствами ffdshow, т.е. в случае с, например, XviD в контейнере *.avi вывод потока надо осуществлять не через AVISource(), а через DirectShowSource()
by k0stix
Вывод информации о кадрах через ffvideosource:
http://ffmpegsource.googlecode.com/ из архива ffms2.dll и FFMS2.avsi скопировать в C:\Program Files\AviSynth 2.5\plugins
ffvideosource("video.mkv") - путь к файлу "С:\video.mkv" не должно быть русских букв в адресе файла.
# пример кода
ffvideosource("video.mkv")
scriptclip("""sres = ffsar > 1 ? " ("+string(ffsar)+") @ "+string(round(width()*ffsar))+"x"+string(height()):\
ffsar < 1 ? " ("+string(ffsar)+") @ "+string(width())+"x"+string(round(height()*(1/ffsar))) : ""
subtitle("resolution: "+string(width())+"x"+string(height())+sres+"\n"+\
"frame # "+string(current_frame)+" / type: "+chr(ffpict_type),text_color=$22ffff11,halo_color=$66000000,lsp=0)"""\
,after_frame=true)
* прим.: можно вместо сложной формулы scriptclip() воспользоваться штатной функцией из FFMS2.avsi — ffinfo()
На разных видеопоследовательностях по разному отражается потеря деталей. Для видеоряда а-ля "групповые брачные игры карликовых муравьёв в тени пальмы на песочном пляже, вид сверху, с пальмы, с трёх метров" потеря деталей на уровне CRF 18 может оказаться губительной и это сразу будет видно глазами, части тел муравьёв утонут в песке и недостаточных квантах, что безусловно потревожит режиссёрскую задумку. Мультик снятый а-ля размытая-флеш-векторная графика может быть малоотличим от исходника при CRF 25-26. Но это крайности. Обычный видеоряд выглядит прозрачно в енкоде с битрейтом полученном на CRF 18-20.
Несколько очевидных следствий:
1. Чем ниже CRF, тем менее заметны будут артефакты компрессии
2. Чем ниже разрешение, тем будут более заметны артефакты компрессии.
3. п.1 + п.2 = чем ниже разрешение, тем на более низкие значения CRF надо ориентироваться при выборе битрейта, тем больше бит понадобится на pixel/frame. Обратно, чем выше разрешение, тем менее заметны артефакты компресии, тем на более высокие CRF можно ориентироваться при выборе битрейта.
Рекомендации по выбору CRF при рассчёте битрейта*:
1. Для очень динамичного сигнала SD разрешения : 20.5..21
2. Для статичного сигнала SD разрешения : 18..20
3. В общем случае CRF=20 ~ золотая середина, CRF=18 ~ идеал
4. Для разрешений более .5Mpix есть возможно потихоньку поднимать указанные выше CRF по .5-1 CRF для каждых следующих .5Mpix
5. В любом случае при выборе битрейта желательно следить, чтобы средние кванты b-фреймов не зашкаливали сильно за 25-26.
Что делать, если уложить видео в желаемый битрейт в желательном качестве не получается:
1. Использовать более тяжёлые настройки кодека: поднимать b-frames, --ref , --b-pyramid, --subme ...
2. Упростить видео, вычистив из него посторонние шумы
3. Всё равно не лезет? Не пихайте, опускайте размер кадра, увеличивайте битрейт и т.д.
* прим.
Обращаю внимание, что в версиях x264 > r988 существенно переработана CRF модель. Все значения CRF в тесте на сжимаемость стоит поднять на 1.5-2 пункта (Не имеет отношения к средним квантам!). Т.е. что раньше было --crf 18 теперь грубо говоря эквивалентно --crf 19.5 / --crf 20. Тем не менее особенность новой CRF модели такова, что некоторые типы сигналов на --crf 20 могут вылезти как в слишком высокие для достижения прозрачности кванты, так и в слишком низкие с точки зрения оптимальности. По этим причинам для определения оптимально битрейта особенно важен визуальный контроль. В среднем случае --crf 20 / --crf 21 покажут оптимальный битрейт для живого видеоряда и --crf 18 / --crf 19 для аниме (анимешники поправьте меня если я не прав :P).
Выбор режима деблокинга
Деблокинг задаётся ключом -f сила:порог. С первым параметром, с силой, всё достаточно просто: чем выше сила, тем эффективнее сработает встроенный деблокер, страхуя от появления случайной блочности, но тем больше возрастает риск размытия деталей и нежелательного смягчения картинки. Очевидно, что занижать силу деблокинга для нерезкого сигнала не только бессмысленно, но и вредно. От того, что в меньшей степени замаскируются границы блоков, резкости в мыльном сигнале не прибавится. Значение по умолчанию '0' -> хорошее значение, если наверняка не знаете какого эффекта нужно достичь, то лучше его там и оставить и не крутить без надобности. Так или иначе в 90% случаев не стоит опускать силу ниже, чем -3, такая сила остаётся всё ещё довольно безопасной для большинства более менее ровных видео с точки зрения появления артефактов, если только не сильно баловаться с порогом.
Порог деблокинга менее предпочтительно крутить вообще, он отвечает за то, где будет распознаваться структура блока, а где артефакт. Чем выше порог, тем больше резких, насыщенных деталями блоков попадёт под деблок. Чем ниже порог, тем больше под деблок попадёт нерезких, незаполненных деталями блоков, но тем меньше будут деблочиться нерезкие блоки с незначительной детализацией (e.g шум, зерно в глубокой тени). Крутить надо исключительно аккуратно, т.к. когда его уводят в минуса, то фильтру не дают обезблочить тёмные области с шумом, а когда задирают, то размывается больше изначально неблочных структур. Чтобы избежать блочности опускать его ниже 0 есть смысл только если картинка действительно чистая, например вылизана по самые гланды какими-нибудь темпоральными шумодавами.
Если коротко, то чем выше сила деблокинга, тем сильнее он применяется, чем выше порог, тем больше блоков ему попадается.
И на закуску очевидное: чем ниже кванты, тем ниже сила деблокинга, а чем они выше, тем естественно деблокинг сильнее. Кодек сам подстраивает деблок и если с низкими квантами вы опустили деблок до -3:-2 например, то не удивляйтесь, откуда в некоторых участках проскакивает блочность и ринжинг. ;) Заминание деблока в минус никогда не сделает картинку резче чем она есть, а поднятие деблока в плюс едва ли поможет избавиться от блочности исходного сигнала.
В то же время на выскоих квантах чуть приподнимая деблок можно потихоньку гасить более явные блочные артефакты компресии, а если их нет или на глаз не видно, то и крутить не надо. :cool:
psyRD + psyTrellis на пальцах
Psy- RDO/Trellis помогает поднять и передать в рипе мелкую фактуру с минимальными затратами битрейта.
1. Psy-RDO (первая цифра после Psy X.X : x.x) вылавливает из исходника шумовую компоненту (некоррелированный сигнал) и добавляет ее впоследствии в рип в тех местах где его вероятность появления выше, наподобие управляемого информацией из рипа функционального генератора шума.
2. Psy-Trellis (вторая цифра после Psy x.x : X.X) ищет реальные мелкие детали (коррелированный сигнал, в основном границы, мелкая фактура, ...) и пакует их по более простым правилам но с гораздо более высокой компрессией чем сам кодек, также использует вероятностный подход но в меньшей степени чем RDO и в основном при силе большей 1 для сверхмалых битрейтов, 0.8-1.0 для средних и 0.1-0.8 для высоких. Эффективность передачи и количество мелких деталей в рипе зависит от установленной силы.
Соотношение и силу обоих компонент нужно подбирать исключительно на глаз, принимая во внимание реальный шумовой битрейт (-RDO) и количество мелкой фактуры (-Trellis) в исходнике.
SSIM и PSNR при этом по идее могут/должны падать, но на глаз картинка будет существенно ближе к оригиналу.
PS
В большей степени - это на основе личных наблюдений.
"с минимальными затратами битрейта" - явно некорректная фраза, так как на самом деле при низких битрейтах они дают больше артефактов (так что их использование имеет смысл только на средних-высоких битрейтах). Лучше ее вообще выкинуть.
1) psy-rdo вовсе ничего не вылавливает и не добавляет шумов. он просто оптимизирует RDO (выбор режима кодирования макроблока) исходя из другой метрики. Т.е. вместо среднеквадратичного отклонения (фактически вырожденный PSNR) он оптимизирует по метрике среднеквадратичное отклонение + отклонение по энергии (т.е. пытается не только уменьшить отклонее от исходника, но и при этом сохранить примерно туже его энергию).
2) "ищет реальные мелкие детали (коррелированный сигнал, в основном границы, мелкая фактура, ...) и пакует их по более простым правилам но с гораздо более высокой компрессией чем сам кодек" - а бывают НЕРЕАЛЬНЫЕ мелкие детали? И как можно закодировать с более высокой компрессией чем сам кодек (мы чем-то другим, а не кодеком кодируем?). На самом деле он этот параметр влияет на то как trellis подбирает коэффициенты для разных частот. Чем больше тем он менее жесток (не обнуляет их, а все равно кодирует) к малым амплитудам высоких частот, а значит выкидывает меньше мелких деталей, хоть при этом и менее эффективно сжимает (в плане PSNR).
Пояснения Nicko123
1) "Лучше ее вообще выкинуть" -опыт показывает, что Psy-RDO/Trellis заметно помогает приблизить рип к исходнику на битрейтах ниже ~600 kbps для fast motion SD- исходников. При этом на больших битрейтах кодек вполне прилично справляется и без участия Psy-RDO/Trellis. В данном случае фраза "Psy- RDO/Trellis помогает поднять и передать в рипе мелкую фактуру с минимальными затратами битрейта" буквально означает то, что написано: использование Psy-RDO/Trellis позволяет получить рип примерно одинакового на глаз качества с рипом, полученным без использования Psy-RDO/Trellis, но с битрейтом ниже чем у последнего. То же самое можно переформулировать для случая одинаковых битрейтов, но, имхо, это уже дело вкуса.
2) "а бывают НЕРЕАЛЬНЫЕ мелкие детали?" - Возможно не очень удачное слово, но надеюсь большинство поняло что речь идет о сигнальной и шумовой компоненте, тем более что в скобках дано пояснение "реальные мелкие детали (коррелированный сигнал, в основном границы, мелкая фактура, ...)", хотя если есть мнение что для простого юзера будет понятнее перевести термины на язык "энергий" и "отклонений" то никто возражать не будет.
3)"чем сам кодек (мы чем-то другим, а не кодеком кодируем?)" - опять возможно не самое удачное слово, но надеюсь большинство поняло что под словом "сам" подразумевалось - тот же самый кодек, но с отключенной опцией "Psy-Trellis" (добавил).
Из переписки Dark Shikari:
May 9th, 2010 at 10:59 am
- Dark Shikari says: @Ben
Yes, I will add a video with x264 with no psy optimizations. You can already see how important psy is though; Ateme’s v2 encoder core, for example, is roughly on par visually with the Samsung+BBC proposal (IMO). This means that their psy optimizations count for 40-60% PSNR, at least.
Тестирование эффективности разных настроек
Как уже писалось выше, для того, чтобы подобрать оптимальные настройки, одного лога мало. Надо заценивать глазами.
Сверять результаты различных настроек имеет смысл только при одинаковом битрейте. Поэтому надо закодировать в одинаковый битрейт все те же тестовые кусочки (см. скрипт в шаге 1) с разными настройками, какие вам покажутся более удобными, но вы сомневаетесь, какой выбрать. В инструкции, как реальные пацаны, будем пользовать настройки кодека через консоль, ибо в ГУЯх я этого делать не умею. Убежден, что адепты найдут способ портировать под милый сердцу способ.
Как узнать, в какой битрейт кодировать тесты? Очень просто, либо на глаз (у некоторых получается и при том неплохо), а те, кто не хочет положиться на свою интуицию, - способом, описанным выше, с применением --crf.
Оговоримся сразу, способ долгий, чем больше вариантов, тем больше уйдет времени на тесты, поэтому:
1) загружаем в холодильник кейс пива, пить его теплым - последнее дело
Ну вот и половина дела сделана. Приступаем ко второй:
2) (опционально) кодируем огрызок видео в --crf для определения необходимого битрейта
3) пишем батник encode.bat
x264 --pass 1 --bitrate const ... настройки 1 ...
x264 --pass 2 --bitrate const ... настройки 1 ...
x264 --pass 1 --bitrate const ... настройки 2 ...
x264 --pass 2 --bitrate const ... настройки 2 ...
...
x264 --pass 1 --bitrate const ... настройки n ...
x264 --pass 2 --bitrate const ... настройки n ...
4) запускаем батник и идем пить то, что загрузили в холодильник
К тому времени, как докодируется батник, пиво как раз уютно пристроится в желудке и можно приступать к заключительной фазе, визуальному контролю и чтению лога, которые описаны в шагах 4 и 3 соответственно. Выбираем тот вариант кодирования, который смотрится наиболее симпатично и гордимся, тем, что в нас уместилось столько пива.
-Автоматизация работы кодека и муксера
xcrfmulti.cmd
Скрипт xcrfmulti.cmd представляет из себя универсальную оболочку для пересжатия исходного файла с помощью x264 в произвольное количество проходов. Для работы скрипта в текущей папке или в путях, заданных переменной окружения PATH, должны находится:
x264
avs2yuv.exe (только для 64разрядных систем)
Также в системе должен быть установлен AviSynth (32 разрядный), перед началом работы скрипт при необходимости надо отредактировать в текстовом редакторе, задав пути к x264/avs2yuv и ключи кодека, отличные от установок по умолчанию. В 64 разрядной ОС скрипт будет пытаться вызывать 64битный x264.
сокращённый синтаксис
for %f in (*.avs) do start /wait /low xcrfmulti.cmd %f
пережмёт все .avs скрипты в текущей папке с параметрами, заданными в конфигурационной части файла xcrfmulti.cmd
(на вход в 32битной OS любой формат, пригодный в качестве входного формата для x264)
полный синтаксис (все параметры опциональны, перекрывают настройки заданные в самом скрипте)
xcrfmulti.cmd <input> <crfbit> <passes> <preset> <output> <sar> <colormatrix>
input - <входной .avs файл с видео>
crfbit - <целевой CRF, если этот параметр меньше 50 или битрейт если выше>
passes - <количество проходов (если предыдущий параметр меньше 50, то битрейт для второго и последующего проходов будет взят из полученного на первом проходе)>
preset - <x264 preset, предустановка из списка: ultrafast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo>
output - <выходной файл>
sar - <SAR видеопотока>
colormatrix - <колоритмия видеопотока>
примеры использования
xcrfmulti video.avs 22 3 veryslow video.mkv
сожмёт video.avs с предустановками veryslow в три прохода, с битрейтом, полученным от первого CRF прохода
xcrfmulti video.avs 2200 3 veryslow
сожмёт video.avs в три прохода со средним битрейтом 2200Kbps
особенности работы
если на первый проход из любого количества выпадет CRF (crfbit <= 50), то первый проход пройдёт с ключом --slow-firstpass независимо от предустановок в конфигурационной части файла xcrfmulti.cmd
в рабочей папке скрипт создаёт папку logs, в которую складывает полные логи работы кодека
в текущей папке создаётся файл с расширением .final.xlog.txt, в который складывается информативная часть логов
тонкую настройку кодека под конкретный исходник можно осуществлять правкой вводного блока CONFIG в скрипте xcrfmulti.cmd, там же прописываются имена файлов с исполнительными модулями используемой версии кодека и при необходимости пути к ним
ключи командной строки перекрывают соответствующие параметры, заданные в самом файле xcrfmulti.cmd
полный лог работы по каждому проходу кодек сохраняет в папке logs\, лог, содержащий совокупно только информативную часть по каждому проходу сохраняется в текущей папке
при повторном запуске из каталога, где уже содержится папка logs\ скрипт пропустит сделанные ранее проходы независимо от итоговых битрейтов. за счёт этой особенности можно кодировать первый проход в crf, а второй в целевой битрейт, например
xcrfmulti video.avs 18 1 && xcrfmulti video.avs 4500 2
первый медленный проход будет сделан с crf 18, при повторном запуске первый проход будет пропущен и сразу запустится второй проход в битрейт 4500
xmkvmux.cmd
Скрипт собирает из заданного видеофайла и найденных в указаной папке аудиодорог, субтитров, тэгов и глав единую матрёшку. Для работы в системе должен быть установлен mkvtoolnix
синтаксис (все параметры опциональны, перекрывают настройки заданные в самом скрипте)
xmkvmux.cmd <input_dir> <output_mkv> <video_track> <log>
input_dir - папка, в которой скрипт ищет звуковые дороги (*.ac3 *.dts *.mp4 *.mp3 *.flac *.wav *.ogg), субтитры (*.srt *.ass *.ssa *.idx), главы (*chapters.xml), тэги (*tags.xml) и обложку (cover.jpg). Если не указана, то будет использована текущая папка.
output_mkv - файл, в который надо записать конечную матрёшку. если не указан, то результат смультиплексируется в файл вида <имя рабочей папки>.automux.mkv
video_track - видеодорога (по умолчанию скрипт ищет видео в последнем файле вида *.video.mkv в папке input_dir, например myvideo.pass3.video.mkv)
log - журнал работы
интерпретация имён файлов дорог
по последним трём символам имён файлов аудиодорог/субтитров скрипт пытается угадать язык (ищет совпадение символов в списке поддерживаемых mkvtoolnix языков), конструкции в названии файла вида DELAY -3550ms будут распознаны как задержка, которая будет указана при мультиплексировании данной дорожки в конечную матрёшку. имя файла попадёт в название дороги в конечной матрёшке. вхождение в название файла субтитров слова forced будет интерпретировано как форсированный субтитр. Все дорожки будут смультиплексированы с отключенной компрессией заголовков. Первая аудиодорожка, распознанная как русская (например "T80 3_2Ch 448Kbps DELAY 80ms rus.ac3"), будет помечена как трэк по умолчанию.
тэги и главы
скрипт ищет в файлах вида *.chapters.xml и *.tags.xml соответственно
обложка
файл cover.jpg из текущей папки будет автоматически присоединён к собираемой матрёшке
-
|
|
|
Текущее время: 21-Ноя 11:42
Часовой пояс: UTC + 3
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
|
|
![[Цитировать]](./styles/templates/default/images/lang/ru/icon_quote.gif "Ответить с цитатой"){kind=icon}
![[Профиль]](./styles/templates/default/images/lang/ru/icon_profile.gif "Посмотреть профиль"){kind=icon}
![[ЛС]](./styles/templates/default/images/lang/ru/icon_pm.gif "Отправить ЛС"){kind=icon}