I am trying to synchronize playback of two VLC instances. To do this, I am using UDP packets. From the secondary player(s), I send a packet to the primary with the current position, and the primary answers with its current position. I then use this information to estimate the latency. This works fine up to here, and the total runtime of the UDP conversation is negible (running on the same host, it is ~0.00017s, on a wired LAN connection slightly more).
The trouble starts when I try to make the secondary stream line up. If the difference is big, I simply set the position. This ends up not being very precise, since the player needs some time to seek the new position.
So, if the difference is relatively small, I tried so set the playback rate to slightly faster or slower until they're on the same frame (i.e. the "should" frame equals the "is" frame). The problem is that the player also hangs a little bit on
media_player.set_rate()
I have tried with bigger (1.2 / 0.9) values as well as smaller (1.01 / 0.99), the results are similar.
I also get quite a lot of this:
[00007f6b8d9d7ab0] main decoder error: Timestamp conversion failed (delay 1000000, buffering 100000, bound 9000000)
[00007f6b8d9d7ab0] main decoder error: Could not convert timestamp 148752813836 for FFmpeg
and this:
[00007f548002e180] main decoder error: Timestamp conversion failed for 41083001: no reference clock
[00007f548002e180] main decoder error: Could not convert timestamp 0 for FFmpeg
The latter especially if I go a bit crazy on the update frequency.
I am wondering if there is any other/better way to achieve this? i was wondering if maybe some sort of calculation is involved that I could do so that the new rate lines up better with the internal time reference? The second error ("no reference clock") makes me think something internally is reinitialised and because of that unavailable for a moment.
Help is very much appreciated.
