splitmuxsink: Subtract daily jam offset when day wraps around

For drop-frame framerates, when the expected next max timecode wraps
around at the end of the day, we have to subtract the offset of the
daily jam, otherwise we end up with a duration that's a few frames too
long.

https://bugzilla.gnome.org/show_bug.cgi?id=797270

diff --git a/gst/multifile/gstsplitmuxsink.c b/gst/multifile/gstsplitmuxsink.c
index b4c835a..bd9ed80 100644 (file)
--- a/gst/multifile/gstsplitmuxsink.c
+++ b/gst/multifile/gstsplitmuxsink.c
@@ -1198,6 +1198,33 @@ calculate_next_max_timecode (GstSplitMuxSink * splitmux,
     next_max_tc_time =
         day_in_ns - cur_tc_time + target_tc_time +
         splitmux->fragment_start_time;
+
+    if (cur_tc->config.flags | GST_VIDEO_TIME_CODE_FLAGS_DROP_FRAME &&
+        cur_tc->config.fps_d == 1001) {
+      /* Checking fps_d is probably unneeded, but better safe than sorry
+       * (e.g. someone accidentally set a flag) */
+      guint frames_of_daily_jam;
+      /* We have around 2.6 frames of offset per day for 29.97 FPS and 5.2
+       * frames for 59.94 FPS. Must subtract those if the day is wrapping
+       * around. We'll just round them down */
+      switch (cur_tc->config.fps_n) {
+        case 30000:
+          frames_of_daily_jam = 2;
+          break;
+        case 60000:
+          frames_of_daily_jam = 5;
+          break;
+        default:
+          GST_WARNING_OBJECT (splitmux,
+              "The day is wrapping around for an unknown drop-frame frame rate %d/%d. There is likely to be an offset because of daily jam in the fragment duration.",
+              cur_tc->config.fps_n, cur_tc->config.fps_d);
+          frames_of_daily_jam = 0;
+          break;
+      }
+      next_max_tc_time -=
+          gst_util_uint64_scale (frames_of_daily_jam * GST_SECOND,
+          cur_tc->config.fps_d, cur_tc->config.fps_n);
+    }
   }
   GST_INFO_OBJECT (splitmux, "Next max TC time: %" GST_TIME_FORMAT
       " from ref TC: %" GST_TIME_FORMAT, GST_TIME_ARGS (next_max_tc_time),