not exact synchronization

[turingmachine]

not exact synchronization

[turingmachine]

Hi Zoran

Unfortunately syncing behavior is dependent on the quality of the movies that you are trying to play. A 1080p video behaves different than a 720p video. There is constant at the beginning of the omxplayer-sync script called SYNC_WINDOW. This parameter needs to be adapted according to the content you want to play.

You can determine the correct sync window for your content by following these steps:

1. prepare two rasperries with a single testfile and a direct ethernet connection
2. start one player as master in verbose mode: omxplayer-sync -muv synctest.mp4
3. start one player as slave in verbose mode: omxplayer-sync -luv synctest.mp4
4. wait until the slave syncs to the master and then note down the value of the moving_deviation verbose output of the slave
5. if it says for example -0.12 adjust the SYNC_WINDOW constant at the top of the omxplayer-sync script as follows:

before

SYNC_WINDOW = (-0.30, -0.25)

after

SYNC_WINDOW = (-0.18, -0.13)

The rule is: add the value of moving_deviation to the first value, the second value is always 0.05 lower. Basically this means the slave will start to play file when still 0.18 seconds ahead. Because the slave takes some time to start the movie.

[surfingobo]

Hi turingmachine

I have tried to follow your instructions above, however your instructions are slightly contradictory. You say to ADD the moving_deviation to the SYNC_WINDOW value however you have SUBTRACTED it (i.e. -0.30 - (-0.12) = -0.18. Please could you clear this up? What is the role of the second value out of interest?

Cheers

[turingmachine]

You you are right, there are inconsistencies in the explanation. So basically negative values mean that you are ahead in time. So if you see a moving_deviation of -0.12, it means that the slave is 0.12 seconds ahead of the master. A positive value means that the slave is behind the master. The values for the SYNC_WINDOW are always negative values. The sync mechanism works as follows: The slave jumps 2 seconds ahead of the master, switches to pause mode and waits until the difference in time between master and slave is within the SYNC_WINDOW range. That's when the slave will resume playback. Only the first value of the SYNC_WINDOW is really relevant, the second value just has to be 0.05 seconds higher. So if you end up being ahead of the master after sync (negative moving_deviation values) you need to raise the SYNC_WINDOW values (closer to 0). If you end up being behind the master (positive moving_deviation values) you need to lower the SYNC_WINDOW values.

[surfingobo]

Cheers that helped :) Now using this principle, would it be possible to develop the code a little further so that ALL the videos started a little early to get rid of the pause between the end and start of the videos?

[turingmachine]

What kind of pause between end and start of the videos do you mean exactly?

[surfingobo]

When the video is looping there is a black screen between the video finishing and restarting

On 24 Nov 2014, at 10:24, Simon Josi [email protected] wrote:

What kind of pause between end and start of the videos do you mean exactly?

—
Reply to this email directly or view it on GitHub #13 (comment).

[turingmachine]

This is a totally different issue and i suggest you open a new issue for that. It would be fairly difficult to get rid of it completely as omxplayer-sync needs to spawn a new omxplayer process for every file. This because omxplayer itself only supports playing one file per invocation.