Я пытаюсь синхронизировать воспроизведение двух экземпляров VLC. Для этого я использую пакеты UDP. От вторичного игрока (игроков) я отправляю пакет первичному с текущей позицией, и первичный отвечает своей текущей позицией. Затем я использую эту информацию для оценки задержки. До сих пор это работает нормально, а общее время выполнения диалога UDP незначительно (при работе на том же хосте оно составляет ~ 0,00017 с, при подключении к проводной локальной сети немного больше).
Проблемы начинаются, когда я пытаюсь выровнять вторичный поток. Если разница большая, я просто устанавливаю позицию. Это оказывается не очень точным, так как игроку нужно некоторое время, чтобы найти новую позицию.
Итак, если разница относительно невелика, я попытался установить скорость воспроизведения немного быстрее или медленнее, пока они не окажутся в одном кадре (т. Е. Кадр должен равняться кадру есть). Проблема в том, что плеер тоже немного подвисает на
media_player.set_rate()
Я пробовал как большие (1,2/0,9), так и меньшие (1,01/0,99) значения, результаты одинаковые.
Я также получаю довольно много этого:
[00007f6b8d9d7ab0] main decoder error: Timestamp conversion failed (delay 1000000, buffering 100000, bound 9000000)
[00007f6b8d9d7ab0] main decoder error: Could not convert timestamp 148752813836 for FFmpeg
и это:
[00007f548002e180] main decoder error: Timestamp conversion failed for 41083001: no reference clock
[00007f548002e180] main decoder error: Could not convert timestamp 0 for FFmpeg
Последнее особенно, если я немного схожу с ума от частоты обновления.
Мне интересно, есть ли другой/лучший способ добиться этого? мне было интересно, может быть, задействован какой-то расчет, который я мог бы сделать, чтобы новая ставка лучше соответствовала внутреннему эталону времени? Вторая ошибка (нет эталонных часов) заставляет меня думать, что что-то внутри переинициализировано и из-за этого недоступно на мгновение.
Помощь очень ценится.
