У меня есть приложение с собственным кодом, которое использует образец Camera2Video от Google, опубликованный на GitHub . К сожалению, существует проблема с Android 6 и выше, которая приводит к повреждению записанного видео. Согласно отчету о проблеме на GitHub, время декодирования первого кадра является огромным по сравнению с рабочим видео.
Для моего примера файла длиной 11 с, симптомы:
Поведение Google Chrome лучше всего показывает, что происходит: в файле 11 с аудио и 11 с * 30 к / с = 330 кадров. Но первый кадр не 1/30 с, а около 3,5 часов.
Сначала я пытался использовать различные инструменты для восстановления видео, чтобы исправить файл mp4, но большинство из них ничего не меняли или не находили никаких проблем, которые могли бы исправить, и не работали в первую очередь.
После небольшой пробной ошибки я нашел первое рабочее решение . Я использовал FFmpeg с setptsопцией фильтра: .\ffmpeg.exe -i "broken.mp4" -vf setpts=N/FRAME_RATE/TB "fixed.mp4". После этого исправленный файл работает нормально (и намного меньше).
Проблема такого подхода заключается в том, что она занимает примерно столько времени, чтобы закончить, как длина видео, которое я хочу исправить. Но видео, которое я хочу сделать с приложением, может занять около часа в будущем.
Поэтому мне интересно, есть ли возможность отрегулировать продолжительность, для которой показан первый кадр? Теоретически, это должно означать, что ffmpeg просто нужно заменить одно целое число и вообще не иметь дело с де- или кодированием. Можно ли это сделать и как?
Поскольку, исходя из вашего рабочего решения, похоже, что вы согласны с согласованием вывода с постоянной частотой кадров, я предложу этот более быстрый двухшаговый метод. Нет перекодировки.
Извлечь сырой поток:
ffmpeg.exe -i "broken.mp4" -c copy broken.h264 Remux:
ffmpeg.exe -i broken.h264 -i broken.mp4 -map 0 -map 1:a -c copy new.mp4