Fix case where the is FFmpegContent with 24fps video and 44.1kHz audio

and a start trim of 6724000.  With these numbers the start trim is
on an integer video frame but halfway through an audio frame.  Without
this patch the trim would be "corrected" to 6724001, causing video frames
to come out of the player at DCPTimes 0, 3999, 5999 etc.

It's possible that

Frame const position = time.frames_floor(_film->video_frame_rate());

in J2KEncoder::encode should be frames_round, which would also help
with this, but that would be a much more risky patch.

diff --git a/src/lib/content.cc b/src/lib/content.cc
index 2ca029d5ae321d9b4f8019b4ac2d031383f70192..9280d2e612be094566c183ea6a0340b3179e1f5f 100644 (file)
--- a/src/lib/content.cc
+++ b/src/lib/content.cc
@@ -219,7 +219,13 @@ Content::set_position (shared_ptr<const Film> film, DCPTime p, bool force_emit)
                video->modify_position (film, p);
        }
 
-       if (audio) {
+       /* Only allow the audio to modify if we have no video;
+          sometimes p can't be on an integer video AND audio frame,
+          and in these cases we want the video constraint to be
+          satisfied since (I think) the audio code is better able to
+          cope.
+       */
+       if (!video && audio) {
                audio->modify_position (film, p);
        }
 
@@ -245,7 +251,8 @@ Content::set_trim_start (ContentTime t)
                video->modify_trim_start (t);
        }
 
-       if (audio) {
+       /* See note in ::set_position */
+       if (!video && audio) {
                audio->modify_trim_start (t);
        }