splitmuxsink: Do not hardcode frames_of_daily_jam

Apart from the obvious drawbacks of hardcoding, the drawback here was
that, if we subtracted 2 frames (instead of 2.6) from the target running
time, we'd request the next keyframe a bit too far into the future,
which would make our files split at the wrong position.

https://bugzilla.gnome.org/show_bug.cgi?id=797293
This commit is contained in:
Vivia Nikolaidou 2018-10-16 15:42:12 +03:00
parent 09904e59df
commit af0e30d545

View file

@ -1195,37 +1195,31 @@ calculate_next_max_timecode (GstSplitMuxSink * splitmux,
} else { } else {
GstClockTime day_in_ns = 24 * 60 * 60 * GST_SECOND; GstClockTime day_in_ns = 24 * 60 * 60 * GST_SECOND;
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) && if ((cur_tc->config.flags & GST_VIDEO_TIME_CODE_FLAGS_DROP_FRAME) &&
(cur_tc->config.fps_d == 1001)) { (cur_tc->config.fps_d == 1001)) {
/* Checking fps_d is probably unneeded, but better safe than sorry /* Checking fps_d is probably unneeded, but better safe than sorry
* (e.g. someone accidentally set a flag) */ * (e.g. someone accidentally set a flag) */
guint frames_of_daily_jam; GstVideoTimeCode *tc_for_offset;
/* 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 /* Here, the duration of the 24:00:00;00 timecode isn't exactly one day,
* around. We'll just round them down */ * but slightly less. Calculate that duration from a fake timecode. The
switch (cur_tc->config.fps_n) { * problem is that 24:00:00;00 isn't a valid timecode, so the workaround
case 30000: * is to add one frame to 23:59:59;29 */
frames_of_daily_jam = 2; tc_for_offset =
break; gst_video_time_code_new (cur_tc->config.fps_n, cur_tc->config.fps_d,
case 60000: NULL, cur_tc->config.flags, 23, 59, 59,
frames_of_daily_jam = 5; cur_tc->config.fps_n / cur_tc->config.fps_d, 0);
break; day_in_ns =
default: gst_video_time_code_nsec_since_daily_jam (tc_for_offset) +
GST_WARNING_OBJECT (splitmux, gst_util_uint64_scale (GST_SECOND, cur_tc->config.fps_d,
"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_n, cur_tc->config.fps_d); gst_video_time_code_free (tc_for_offset);
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);
} }
next_max_tc_time =
day_in_ns - cur_tc_time + target_tc_time +
splitmux->fragment_start_time;
} }
GST_INFO_OBJECT (splitmux, "Next max TC time: %" GST_TIME_FORMAT GST_INFO_OBJECT (splitmux, "Next max TC time: %" GST_TIME_FORMAT
" from ref TC: %" GST_TIME_FORMAT, GST_TIME_ARGS (next_max_tc_time), " from ref TC: %" GST_TIME_FORMAT, GST_TIME_ARGS (next_max_tc_time),
GST_TIME_ARGS (cur_tc_time)); GST_TIME_ARGS (cur_tc_time));