Я использую внутренние API-интерфейсы FFmpeg для записи аудио и видео в файл с помощью мультиплексора isvm.
Перед записью заголовка файла аудио-ACC-поток time_base устанавливается на 1/44100, а видео h264 stream time_base - на 1/30.Несмотря на эти настройки, вызывая avformat_write_header (oc, options), ffmpeg внутренне переводит time_base для обоих потоков в 1/10000000.Глядя на внутренний источник avformat_write_header , видно, что вызывается ленивая инициализация AVFormatContext.Как для mp4, так и для ismv, ленивый init вызовет mov_init .Однако, поскольку ismv имеет mov-> mode == MODE_ISM, он перезаписывает любой поток time_base со значением 1/10000000, как это видно на строке 6230 в mov_init.mp4, с другой стороны, позволяет потокам поддерживать временную базу в соответствии с их соответствующей конфигурацией кодека.
Логика, позволяющая разрешить только одну временную базу, была добавлена, когда в ffmpeg была добавлена поддержка ISMV.Кто-нибудь знает, почему это необходимо (кроме как для поддержки инструментов mp4split, как указано в комментариях к коду)?
Я нахожу это запутанным и проблематичным, поскольку оно связано с записью значений pts (метка времени представления).Я относительно новичок в этом пространстве, но мое понимание таково:
- Время выражено в единицах в секунду.Это означает, что для ISMV значение pts = 1 составляет 0,1 микросекунды.
- Максимальное поддерживаемое значение pts в ISMV составляет 2 ^ 33 или 8589934592. Это ограничивает максимальные значения pts примерно 859 секундами.
Поскольку я масштабирую свои пакеты pts перед их записью, используя av_packet_rescale_ts (package, codec.time_base, stream.time_base), это приводит к большим значениям pts.Я прочитал ссылки на разрешение pts на опрокидывание в 2 ^ 33.Это правильный способ справиться с временной базой ISMV?Что-то еще мне не хватает.
Заранее спасибо!