Certainly looks like the 3D drops out at some point early on and returns around frame 247 (when I make a DCP using those input files).

Content from right stops arriving after frame 131 and starts again after 16 left frames have gone through. Then they're very out of sync til they come back in around 247.

The muxing of video/audio is odd in the left.mp4. At the start, for example, over 1s of audio appears before any video. Throughout the file, the video/audio are often a second apart (either way).

Both sources miss out frame 2. This is supposed to be handled by Player::video but the shuffler is inserted between decoder and player. Hence the missing frame causes data to back up in the shuffler, until it is full, at which point things (sort-of) recover.

Perhaps Shuffler should cope with gaps.

It could emit gaps, if that would help. e.g.

receives

1L
1R

3L
3R

Once it gets 3R (i.e. it has everything for frame 3) it can carry on; Player will cope with the gap.

Shuffler should have the check

if (_store.size() > _max_size) {
    LOG_WARNING ("Shuffler is full after receiving frame %1; 3D sync may be incorrect.", video.frame);
}

Hopefully fixed by 27fbe80bccafe744ca3f96129c9e582f39921891