[Bug 797270] splitmuxsink: Subtract daily jam offset when day wraps around

[GStreamer (GNOME Bugzilla)]

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

--- Comment #5 from Vivia Nikolaidou <vivia at ahiru.eu> ---
(In reply to Sebastian Dröge (slomo) from comment #2)
> Review of attachment 373886 [details] [review]:
> 
> ::: gst/multifile/gstsplitmuxsink.c
> @@ +1184,3 @@
>          splitmux->fragment_start_time;
> +
> +    if (cur_tc->config.flags | GST_VIDEO_TIME_CODE_FLAGS_DROP_FRAME &&
> 
> This needs parenthesis

Done.

> @@ +1208,3 @@
> +      next_max_tc_time -=
> +          gst_util_uint64_scale (frames_of_daily_jam * GST_SECOND,
> +          cur_tc->config.fps_d, cur_tc->config.fps_n);
> 
> Shouldn't this be part of some helper function that increments a timecode by
> a specific amount?

Actually not. I looked at the code again and next_max_tc_time is already in ns,
so rather than subtracting frames from the timecode, converting again, and
doing all the additions and subtractions needed to get to next_max_tc_time,
it's easier to just convert the number of frames to ns and subtract it
directly.

It won't be an issue though. The timecode has already wrapped around the 24h
boundary, so we're not accumulating the error here.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.