LINUX.ORG.RU

ffmpeg .mp4 troubles

 ,


0

1

Приветствую, давно уже не ковырял ffmpeg, были когда то бесславные попытки осилить тру обрезку фрагментов и вот опять. Вообщем есть полнометражка:

Input #0, avi, from 'br.avi':
  Metadata:
    encoder : VirtualDubMod 1.5.10.2 (build 2542/release)
  Duration: 02:43:47.87, start: 0.000000, bitrate: 2564 kb/s
    Stream #0:0: Video: mpeg4 (Advanced Simple Profile) (XVID / 0x44495658), yuv420p, 720x304 [SAR 1:1 DAR 45:19], 1781 kb/s, 23.98 fps, 23.98 tbr, 23.98 tbn, 23.98 tbc
    Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 384 kb/s

пытаюсь вырезать фрагмент, что бы по ключевым кадрам, юзаю вариант из мана

ffmpeg -ss 01:01:17.8 -i br.avi -to 00:01:13 -c copy cut.mp4

фрагмент при воспроизведении слегка подглючивает в начале и воспроизводится без звука. Ладно, попробовал добавить -c:v, звук появился, заливаю в телеграмм. ибо именно для этого предназначен мувик, тестим — у меня норм, у одного чела откуда то берутся 6 секунд в конце, у другого 6 секунд в начале

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cut.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    encoder         : Lavf57.41.100
  Duration: 00:01:19.12, start: -6.089423, bitrate: 3179 kb/s
    Stream #0:0(und): Video: mpeg4 (Advanced Simple Profile) (mp4v / 0x7634706D), yuv420p, 720x304 [SAR 1:1 DAR 45:19], 2860 kb/s, 23.98 fps, 23.98 tbr, 11988 tbn, 23.98 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 48000 Hz, 5.1, fltp, 341 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
посдкажить, чяднт и что почитать плес ибо недогоняю. В конце мана нашёл данное продостережение

Using -ss as input option together with -c:v copy might not be accurate since ffmpeg is forced to only use/split on i-frames. Though it will—if possible—adjust the start time of the stream to a negative value to compensate for that. Basically, if you specify «second 157» and there is no key frame until second 159, it will include two seconds of audio (with no video) at the start, then will start from the first key frame. So be careful when splitting and doing codec copy.

судя по инфе ffprobe

Duration: 00:01:19.12, start: -6.089423, bitrate: 3179 kb/s

как раз эта проблема у меня, как её побороть? Чому битрейт так вырос, и как же резать правильно по ключам?


Если заливаешь в телеграм можно не париться резать без сжатия. В Avidemux режешь точно где тебе нужно, обязательно используй видео и аудио энкодеры - только так не будет глюков! Битрейт побольше (x264 slow crf 15, звук 320 kbps), никто ухудшения качества не заметит.

anonymous ()
Ответ на: комментарий от deep-purple

.8 и .13 это не номер кадра а проценты секунды

эт понятно, а как определить кей фрейм, чёт инфы не встречал, подумол, что нужно просто указывать, по ключу резать или прямо по таймингу, сложновато с инглишем к стыду своему

ghett ()
Ответ на: комментарий от anonymous

я вроде сжатия и не делал, хотеть только каноничным ффпмегом через терминал, что бы буковки зелёные на тёмном бекграунде

ghett ()
Последнее исправление: ghett (всего исправлений: 1)

ещё момент что ффмпег 3.1.11 и апдейтится до 4го не хочет, nothing to do говорит...

ghett ()
Ответ на: комментарий от ghett

Сразу беря с запасом конвертить. Увеличить колво ключевых кадров както в настройках кодирования или выбрать кодек хаффюв он вроде весь из ключевых

deep-purple ★★★★★ ()

720x304, минутный кусок, для социалочек… а чего-бы не пережать, даже с самыми отмороженными настройками это не заёмёт много времени. Если совсем не заморачиваться то: ffmpeg -ss 01:01:17.8 -i br.avi -to 00:01:13 cut.mp4 Если не хочешь рисковать качеством то как-то так ffmpeg -ss 01:01:17.8 -i br.avi -to 00:01:13 -c:v libx264 -crf 18 -preset veryslow -profile:v high cut.mp4. Tсли слишком медленно то замени veryslow на fast или вообще ultrafast. В общем уменьшаешь crf что-бы поднять качество и увеличить вес, крутишь preset для смещения ускорения кодирования ценой ухудшения качества. Можно ещё заменить libx264 на libx265 (медленнее, качественнее, легче)

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

я вот тоже непротив пережать, оно порешает жеж с кей фреймами?
щас вот юзанул такой вариант

ffmpeg -i br.avi -ss 01:01:18 -t 00:01:13 -vcodec copy -acodec copy cut.mp4

обрезало всё ровно, по дюрейшену совпало, звука нет. Поясни, вот этот параметр :v сохраняет звук, как, и я щас вот добавлю его и как в варне и указанно, он в дуэте с -ss добавит мне несколько секунд в начало видео. Ща попробую потыкать твой варик офк

ghett ()
Последнее исправление: ghett (всего исправлений: 1)
Ответ на: комментарий от MrClon

ffmpeg -ss 01:01:17.8 -i br.avi -to 00:01:13 -c:v libx264 -crf 18 -preset veryslow -profile:v high cut.mp4

поймал эрор, де процесс пошёл

[ac3 @ 0x559c3e596dc0] frame sync error
Error while decoding stream #0:1: Invalid data found when processing input

кст, все разы незатейливо подругивается он на

[mp4 @ 0x559c3e5d9c20] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.

ghett ()
Последнее исправление: ghett (всего исправлений: 1)
Ответ на: комментарий от MrClon

ffmpeg -ss 01:01:17.8 -i br.avi -to 00:01:13 -c:v libx264 -crf 18 -preset veryslow -profile:v high cut.mp4

с этими параметрами всё гуд обрезалось со звуком и без зависаний, только вот почему то 16 секунд, а не 73...

а что с preset у него тоже числовое значение есть что бы его подкручивать?

чё то libx265 ругается

[libx265 @ 0x55b3bd2af200] [Eval @ 0x7ffd8bc7bbd0] Undefined constant or missing '(' in 'high'
[libx265 @ 0x55b3bd2af200] Unable to parse option value «high»
[libx265 @ 0x55b3bd2af200] Error setting option profile to value high.

ghett ()
Последнее исправление: ghett (всего исправлений: 3)
Ответ на: комментарий от ghett

я вот тоже непротив пережать, оно порешает жеж с кей фреймами?

Оно перекодирует видео и аудио, будут новые кейфреймы

Поясни, вот этот параметр :v сохраняет звук…

-c:v задаёт кодек («c») для видеопотока («v»). Если явно не укзано иное то подразумевается первый видеопоток. Это просто новый синтаксис на замену -vcodec. Аналогично -c:a задаёт кодек для (первого) аудиопотока. В моём примере параметры кодирования аудио не указаны, поэтому ffmpeg использует дефолтные параметры для целевого формата (mp4), т.е. aac. И видео и аудио в моём примере будут сначала декодированы, а затем снова закодированны

ffmpeg может сколько угодно ругаться на кривой исходник и срать в консоль партянками варнингов, как правило это не мешает ему выдать результат. Если возникают какие-то проблемы то есть смысл попробовать более свежую версию. Благо есть полуофициальные статичиские билды которые можно просто распаковать в хомяк или в /opt https://johnvansickle.com/ffmpeg/

MrClon ★★★★★ ()
Ответ на: комментарий от ghett

а что с preset у него тоже числовое значение есть что бы его подкручивать?

Кури там: https://trac.ffmpeg.org/wiki/Encode/H.264 https://trac.ffmpeg.org/wiki/Encode/H.265

Вообще для задачи взять кусок от до и пережать все эти дополнительные параметры не нужны, достаточно ffmpeg -i input.avi -ss 1:02:03.4 -to 1:03:04.5 out.mp4. FFmpeg выберет дефолтные параметры для mp4 (которые предполагают перекодирование, а не копирование).

P.S. если маразм меня не подводит параметр -to задаёт конечную точку обрезки. т.е. -ss 1:02:03.4 -to 1:03:04.5 вырежет кусок с 1:02:03.4 по 1:03:04.5. В твоём случае получается что ты хочешь получить кусок с 01:01:17.8 по 00:01:13, что несколько странно. ХЗ как ffmpeg на такое отреагирует. Чтобы получить 73 минуты после 01:01:17.8 нужен не -to, а -t (или -tt, не помню), т.е. -ss 01:01:17.8 -t 00:01:13

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

красиво, душевно. Всё получилось, лучей добра тебе. Поясни ещё на дорожку, как мне поступить например, если в файл вшиты две аудиодорожки, какую потянет ffmpeg и как мне убрать например русскую, оставив пре декодинге только оригинал?

ghett ()
Ответ на: комментарий от MrClon

во второй раз обрезал нормально, но ведь, хм, я попробую канеш чисто

ffmpeg -i input.avi -ss 1:02:03.4 -to 1:03:04.5 out.mp4

но у меня вроде и в таком варианты сыпался звук...

ghett ()
Ответ на: комментарий от ghett

https://trac.ffmpeg.org/wiki/Map

Если коротко: ffmpeg -i input.avi -map 0:0 -map 0:1 out.mp4 Здесь -map 0:0 -map 0:1 задают что первой дорожкой результирующего файла должен быть первый поток первого (единственного) исходника, второй дорожкой — второй поток первого исходника (нумерация с нуля). Первый поток это почти всегда видео, но не всегда. По ссылке написано как определить какой номер у какого потока в исходном файле

MrClon ★★★★★ ()
Ответ на: комментарий от ghett

-acodec copy
звука нет

Какой кодек звука в исходнике? ac3 наверное. ac3 в mp4 не всеми плеерами поддерживается. Для mp4 надежнее aac

-c:a aac -b:a 192k
Если ну указывать -c:a (или -acodec), то по умолчанию будет aac с битрейтом 128 kbps вроде бы.

anonymous ()

avi (xvid+ac3) перепаковать в mp4 (mpeg4+ac3). Мсье знает толк... Нет, конечно, контейнер mp4 поддерживает такие кодеки, но это экзотика. Думаю, в телеграме не очень обрадуется такому файлу*. Обычно делают mp4 (h264+aac). Так что лучше пересжать. Или оставлять контейнер avi. Или mkv (ведь телеграм наверняка еще раз пережмет). Но avi xvid перетащить в mkv ffmpeg скорее всего не даст без опции ffmpeg -fflags +genpts -i input...

Видишь ли, при резке без перекодирования очень много гемора. Надо узнать точное время ключевого кадра (а лучше его номер). Еще неизвестно в какую сторону ffmpeg округлит и будет ли это делать или просто впихнет gap метку в таймкод. Потом размер фрейма аудио потока (обычно несколько мс) скорее всего будет немного не совпадать по времени с резкой видеопотока. Это тоже ffmpeg пропишет в таймкоды (delay, gaps). В общем, это все очень глючно получится. Поэтому надежнее всего пересжать видео и звук, а еще лучше добавить к этому опции -vsync cfr -async 1 это приведет таймкоды к стандартному виду и позволит избежать рассинхрона при сохранении в простые контейнеры типа avi.

* Я как-то принес mp4 (h264+aac) закоденные обычным ffmpeg или Avidemux в на виндовую машину с Win7. Так дефолтный WMP воспроизводил с тормозами и артефактами. Всегда надо учитывать, что у получателя очень древний и глючный плеер и делать по возможно максимально стандартный видеофайл. Как я уже говорил, если телеграм пережимает сам, то он приведет к стандартному виду. А если твою кривоту плеер в телефоне (возможно древний) будет пытаться переварить, ничего хорошего может не получиться. В частности, максимально стандартный и простой mp4 (h264) файл можно создать с -preset ultrafast. Не забывай, что конечное устройство также может плохо переваривать большие битрейты.

anonymous ()
Ответ на: комментарий от anonymous

да, ты прямо в хрустальном шаре считал, что происходило у ребзь на тестовых девайсах. В одном варианте воспроизводило скачками но со звуком, второй без звука но норм. Потом порезал с -с:v и пошли эти вставки звуковых секунд левые. Забавно что тестили с 4х девайсов и у всех четверых каждый раз что то глючило и как то по особенному. Хотя, если подумать, символично, коль взялся вести канал посвящённый глитч-эффектам...

ghett ()
Ответ на: комментарий от MrClon

слух, а не знаешь, можно как то скомбинировать, что бы копировать с мапом. потому что щас приходится сначала переписать весь файл с только нужными дорожками и потом из него уже брать кусок. утомительно. пробовал сконкатенировать в стиле

ffmpeg -i input.avi -ss 1:02:03.4 -to 1:03:04.5 -map 0:0 -map 0:1 out.mp4

но процесс просто зависает создав 10kd output.mp4, не стал ждать и скипнул

ghett ()
Ответ на: комментарий от ghett

Скорее всего он не зависает, а медленно и мучительно прочёсывает входной файл что-бы найти где там начинается 1:02:03.4 В целом приведённая тобой вроде как должна работать, не вижу причин почему ей не работать.

На сколько я понимаю начиная с ffmpeg 2.1 разумнее ставить -ss перед -i file.ext, а не после. Это определяет другое (более быстрое) поведение, вроде-как без потери точности. Отсылаю тебя к документации, читать документацию вообще полезно: https://trac.ffmpeg.org/wiki/Seeking

P.S.

…что бы копировать с мапом…

Копирования, в приведённом тобой примере, не происходит, происходит рекодирование. Если тебе не нужно максимально сохранять качество картинки или ускорять процесс, ценой точности и геморроя, то забудь про вырезание куска без перекодирования

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

Копирования, в приведённом тобой примере, не происходит, происходит рекодирование

сорян, примитивизировал мысль на словах, ну ты понел.

Отсылаю тебя к документации, читать документацию вообще полезно: https://trac.ffmpeg.org/wiki/Seeking

самое вежливое rtfm на лоре на моей памяти, шпашиба

ghett ()
Ответ на: комментарий от MrClon

другое (более быстрое) поведение

Поиск по ключевым кадрам вместо полного декодирования.

без потери точности

Только если используется перекодирование.

anonymous ()
Ответ на: комментарий от anonymous

h264 дефолтный WMP воспроизводил с тормозами и артефактами

Вангую аппаратное декодирование глючило. Ноут то довольно древний был.

anonymous ()
Ответ на: комментарий от anonymous

чому mkv декодиться в мп4 в нормальном качестве, а avi без preset выплёвывает какой то 360...

ghett ()

Если с пережатием, то можно настраивать вплоть до долей секунды. Если без пережатия, то могут появиться фрагменты перед и после отрезаемого куска. Мне, как правило, это только помогает точнее вырезать сцену

ZenitharChampion ★★★★★ ()

avi xvid без пересжатия с точностью до кадра может резать наверное только виндовый solveigmm video splitter (пережимаются только участки, которые не совпадают с gop). В теории еще virtualdub имеет smart rendering, на практике не работает.

anonymous ()
Ответ на: комментарий от anonymous

Но ты можешь заморочиться вручную и на линуксе. Я так делал, чтобы точно подрезать хвост. Суть в том: сначала режется неточно с запасом по ключевому кадру, небольшой оставшийся обрезок режется точно с пересжатием с теми же параметрами (расхождения чреваты глюками), а потом подклеивается.

anonymous ()

Кстати, а в какой разрядности работают аудиофильтры в ffmpeg? Я тут заморочился конкретно. Получается разрядность зависит от входа, кроме регулятора громкости (он в 32 bit float переводит). Если, например, тупо указать:

ffmpeg -i cd.flac -acodec libopus -b:a 200k rip.opus
То ресемплер 44>48 будет работать в 16 бит и Opus тоже переключится в s16 кодирование! А если указать:
ffmpeg -i cd.flac -acodec libopus -b:a 200k -af volume=-2dB -ar 48000 rip.opus
то такое ощущение, что сначала ресемплер отработает в 16 бит, а только потом сигнал пойдет в регулятор громкости, который переведет в flt.

Opus использует swr ресемплер из ffmpeg, он немного похуже, чем sox (на графиках), но в старых версиях ffmpeg было еще хуже.

Вот Ъ строчка для качественной обработки:

-af aformat=sample_fmts=flt,volume=-2dB,aresample=48000:resampler=soxr:precision=28

anonymous ()

UPD.

ffmpeg -i Spider-Man_Into_the_Spider-Verse.avi -ss 00:19:49.6 -to 00:19:55 -map 0:0 -map 0:2 -c:v libx264 -crf 12 -preset veryslow -profile:v high cut.mp4

постану чисто конструкцию к которой пришёл, по сути тяну из всего мувика на перекодировку кусок, мапом выбираю оригинальную аудио-дорожку, -crf 12 — где то примерно как то позволяет не потерять в качестве при перекодировке fullHD

ghett ()
Последнее исправление: ghett (всего исправлений: 1)
Ответ на: комментарий от ghett

-crf 12

Для HD 18-19 самое то. Для SD можно 17-18. На 12 гигантский битрейт будет. В любом случае меньше 16 - пустая трата битрейта. Но для мувиков оно может и по другому считается.

-profile:v high

Можно не указывать, это по умолчанию.

anonymous ()
Ответ на: комментарий от anonymous

Для HD 18-19 самое то. Для SD можно 17-18. На 12 гигантский битрейт будет.

хз, хз. на crf 12 2400 где то выходит, как в оригинале

ghett ()
Ответ на: комментарий от anonymous

ну вот, решил порезать крч, full HD mkv на -crf 18

Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 23.98 fps, 24k tbn, 23.98 tbc (default)
Metadata:
BPS-eng : 8981814
DURATION-eng : 00:53:54.106000000
NUMBER_OF_FRAMES-eng: 77541
NUMBER_OF_BYTES-eng: 3631017652
_STATISTICS_WRITING_APP-eng: mkvmerge v31.0.0 ('Dolores In A Shoestand') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-03-16 08:07:41
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES >NUMBER_OF_BYTES
encoder : Lavc57.48.101 libx264
Side data:
cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1

хз, не вижу где тут битрейт, BPS-eng вотэтотвот штоле, короче на выходе получил:

Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 7596 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)

норм?

UPD по команде:

ffmpeg -i 'American.Gods.S02E01.1080p.TVShows.mkv' -ss 00:07:17 -to 00:08:11.2 -map 0:0 -map 0:2 -c:v libx264 -crf 16 -preset veryslow cut.mp4

ghett ()
Ответ на: комментарий от ghett

Значит исходник простой и в нём битрейт избыточный.

anonymous ()
Ответ на: комментарий от anonymous

В статистике надо смотреть кванты если B меньше 22-23 то битрейта хватает. Если выше то надо увеличивать bitrate или увеличивать сложность сжатия или уменьшать разрешение, чистить от шумов.

anonymous ()
Ответ на: комментарий от anonymous

вот эта сложно ваще ваще нипанятна
что такое «B»?

увеличивать bitrate

через -crf ?

увеличивать сложность сжатия
уменьшать разрешение
чистить от шумов

ghett ()
Последнее исправление: ghett (всего исправлений: 1)
Ответ на: комментарий от ghett

что такое «B»?

Кванты B кадров https://i.imgur.com/DFlc3Eg.png
До 25 можно. Меньше 17-18 значит битрейт избыточен.

через -crf ?

Увеличивая crf или уменьшая -b:v

увеличивать сложность сжатия

-preset slow|slower|veryslow

уменьшать разрешение

-s x:y или -vf scale=x:y

чистить от шумов

Фильтры шумоподавления видео.

anonymous ()
Ответ на: комментарий от anonymous

уменьшать разрешение

думал, fullHD это святое, режу контент для вдохновения, что бы все пикселёчки были видны.

слух, вот чё, посмотрел как оно выглядит, не хвататет тумб для превьюхи грамотных, как тумбу чёткую сделать, можно просто разбить на кадры фрагмент и потом сочный прилепить в начало ролика или оно поламает синхрон со звуком?

ghett ()
Ответ на: комментарий от anonymous

Кванты B кадров https://i.imgur.com/DFlc3Eg.png
До 25 можно. Меньше 17-18 значит битрейт избыточен.

погоди, так это знач перед резкой нужно чекать исходник на косяки, в итоговом мп4 я такого ж не вижу

Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 8171 kb/s, 24 fps, 24 tbr, 12288 tbn, 48 tbc (default)

ghett ()
Ответ на: комментарий от ghett

Это после сжатия статистика получается. Но ты не парься, жми в crf 16-18. Кванты проверяют обычно в режиме битрейта. И, если они совсем плохие, придется все пережимать. Но можно и на сэмпле небольшом проверить. Это актуально тем, кто укладывается в размер, релизерам всяким.

Nakita ()
Ответ на: комментарий от ghett

Проще и надежнее добавить и пересжать в любой монтажке или Avidemux. Но, если хочешь без пересжатия, можно кусочек видео с теми же параметрами приклеить в начало в mkvtoolnix.

Nakita ()
Ответ на: комментарий от Nakita

кусочек видео

да нах кусочек, чисто 1 (один) фрейм и всё, чё то ваще не хочется осваивать ещё что то кроме ффмпега, эх, нужно пробовать крч

ghett ()
Ответ на: комментарий от nakita

получается, что звук будет опережать видео на 1 фрейм, сколько то там миллисекунд исходят из фпс'а. А так ли оно уже важно? Что там вообще под капотом. Не удивлюсь если те кто пакует по контейнерам потоки сам грешит подобными «рассинхронами»

ghett ()
Ответ на: комментарий от ghett

получается, что звук будет опережать видео на 1 фрейм

Нет, ffmpeg укажет это в задержке контейнера. Как клеить в ffmpeg http://qaru.site/questions/45711/concatenate-two-mp4-files-using-ffmpeg
У меня получилось таким образом:

ffmpeg -i 1.mkv -c copy 1.ts
ffmpeg -i 2.mkv -c copy 2.ts
ffmpeg -i concat:"1.ts|2.ts" -c copy 1+2.mkv
rm 1.ts
rm 2.ts

concat это грубое склеивание файлов, это допустимо только с форматами mpg, vob и ts.
Если 1.mkv будет содержать звук (тишину), то delay в контейнере никаких не будет, это еще лучше.

А вот mkvtoolnix отказался подклеивать в начало файл без звуковой дорожки.
В любом случае 30-40 мс рассинхрона вряд ли будут заметны, если сам исходник идеальный и уже не содержит его, иначе рассинхрон сложится и может стать заметно.

nakita ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.