[Bug 701385] Videomixer does incorrect timestamp calculations in certain cases, which leads to dropping buffers that should be kept.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701385
  GStreamer | gst-plugins-good | git

--- Comment #9 from Mathieu Duponchelle <mathieu.duponchelle at epitech.eu> 2013-06-11 17:39:37 UTC ---
After lengthy discussions on IRC with slomo, it was agreed that the users have
to be updating the base time of the incoming segments.

That way, videomixer can make its calculations inside the current output
segment.
For us it meant we had to patch gnlcomposition and gnloperation.

With this done, two bugs were uncovered in videomixer.

first one, in collected:

    output_start_time = mix->segment.start;
    [....];
      output_end_time =
      mix->ts_offset + gst_util_uint64_scale (mix->nframes + 1,
      GST_SECOND * GST_VIDEO_INFO_FPS_D (&mix->info),
      GST_VIDEO_INFO_FPS_N (&mix->info));

    When the segment start is not 0, the calculation of output_end_time created
a situation where it was inferior to output_start_time, and the duration of the
next buffer ended up underflowing.

    We need to add segment.start to output_end_time, it's what the first patch
does.

second one, in fill_queues:
    end_time = start_time - GST_BUFFER_TIMESTAMP (mixcol->queued); ||
    end_time = GST_BUFFER_DURATION (buf);

[...]

    if (mixcol->end_time != -1 && mixcol->end_time > end_time) {
        GST_DEBUG_OBJECT (pad, "Buffer from the past, dropping");

[...]

    end_time =
        gst_segment_to_running_time (segment, GST_FORMAT_TIME, end_time);

[...]

    mixcol->end_time = end_time;

    The comparison has to be made *after* conversion to running_time, that's
what my second patch does.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.