| Age | Commit message (Collapse) | Author |
|---|
|
This commit changes the approach with video timing. Previously,
we would (more-or-less) try to use every video frame from the content
in the output, hoping that they come at a constant frame rate.
This is not always the case, however. Here we preserve the PTS
of video frames, and then when one arrives we output whatever
DCP video frames we can (at the regular DCP frame rate).
Hopefully this will solve a range of sync problems, but it
could also introduce new ones.
|
|
|
|
|
|
|
|
|
|
|
|
Make the shuffler longer; I've seen examples where the video and sound
are over a second apart within the muxed file.
Allow the shuffler to pass through complete missed frames;
e.g. if the input is L1 R1 L3 R3 we can pass that through without
worrying about the missing frame #2.
Add a log warning if the shuffler fills: at this point, 3D sync
may be lost.
|
|
|
|
This clearly can happen with separate L/R sources. A pass in L might
emit two frames which means the arrivals can't possibly be in order.
This commit fixes this by introducing a Shuffler which all alternate-3D
sources send their video to. The Shuffler re-orders things before they
arrive at the player.
It also fixes the code which inserts video frames before one that arrives
after a gap. This didn't cope with 3D right before.
The audio code solves a similar (perhaps the same?) problem with the
AudioMerger; perhaps we should have a similar thing for video and make
the player emit complete 3D frames.
Should help with #976.
|
