Меня всегда очаровывала синхронизация, или, если быть точным, то, почему медиаплееры могут синхронно просматривать .ts, в то время как повторно собранные демультиплексированные аудио+видео не синхронизированы.
Поэтому я пытаюсь понять это, и что можно сделать, чтобы предотвратить это.
Я прочитал следующее: https://trac.handbrake.fr/wiki/LibHandBrakeSync и источник sync.c (также доступен на вики)
BitStreamTools также написал Теорию 101 по этому вопросу (но я не могу дать ссылку, так как я новый пользователь, извините)
Хотя я думал, что мое понимание PCR / PTS было (концептуально) правильным, мне трудно следовать отличной бумаге для синхронизации аудио/видео ручного тормоза.
Мой вопрос таков: есть ли какое-то интуитивное (оно может быть кратким, коротким или более длинным) объяснение синхронизации аудио/видео? Хотя я знаю, что можно пересчитать PTS из PCR, если аудио или видео точки повреждены (разрыв?), ручной тормоз, похоже, полагается не на это, а на свой внутренний PTS. 0, += 1/fps (~=5), 10, 15, ....
Можно ли пересчитать смещения точек и исправить .ts (двоичный), зафиксировав все значения PTS аудио и видео (и исказив все DTS с одинаковым смещением, чтобы у проигрывателя не «исчерпались кадры», чтобы говорить) и, таким образом, иметь .ts, который можно демультиплексировать, и тогда изолированные дорожки будут синхронизированы (если их собрать вместе)?
РЕДАКТИРОВАТЬ: Или было бы невозможно исправить с помощью PCR пересчет всех значений PTS в данном .ts? Хотя я понимаю, что некоторые кадры/аудио могут быть повреждены в трансляции, поэтому они не могут быть представлены правильно, я оставлю обработку этого (например, удаление видео, если оно повреждено и имеет соответствующую звуковую часть, вставку тишины x ms, если звуковой пакет поврежден и т. д.) на потом, и ради обсуждения я предполагаю, что все кадры целы. (Но тогда значения PTS всегда будут правильными, или что?)
Приложение: Мое мнение об A/V документе с ручным тормозом таково: при «ожидаемых» 100 смещение рассчитывается как количество точек видео (100) – точек аудио (0) – внутренняя PTS, чтобы привести звук к той же презентации. время, таким образом, давая смещение 99 pts, при 105 смещение будет 105-5 = 100, а не 99, но мы продолжаем использовать 99 в качестве смещения, поскольку нет необходимости пересчитывать (100-99 = 1,1/fps ‹ 100 мс). При значении 150 смещение точек вычисляется снова, поскольку количество точек видео уменьшается, а не увеличивается...
Я почти уверен, что ошибаюсь в этом, но может ли кто-нибудь указать мне правильное направление, пожалуйста?
- Джош
