[Bug 701385] New: 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

           Summary: Videomixer does incorrect timestamp calculations in
                    certain cases, which leads to dropping buffers that
                    should be kept.
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mathieu.duponchelle at epitech.eu
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Context: I'm implementing video mixing in GES. The implementation is as
follows:
we have a videomixer set as expandable in gnonlin, and we plug our gnlsource
bins
on it when gnl requests a pad.

The branch for this is there :
https://github.com/MathieuDuponchelle/PitiviGes/tree/video_mixing

There is a test case in the mixers.c file, which is called
audio_video_mixed_with_pipeline.

Currently, videomixer has a mix->offset_ts member which is useless, as it is
always reset to 0 on flush stops and seek events.

The symptoms are that buffers are dropped while they should not be dropped.

My first proposed patch fixes that.

There is a second bug as well, which is unrelated as without that patch, the
problem also occurs. This bug doesn't happen with my test case though, I
experience it in pitivi when trying to move an object on a second layer :
The segment offset gets set to a value != 0, and when videomixer calls
fill_queues, gets a buffer of timestamp == 0 and calls to_running_time on that
timestamp with the collectpads segment, it reurns -1, which triggers the
assertion just below.

I think we can either set the segment offset to 0 before that calculation, or
offset start_time and end_time with the segment offset as we don't want it to
influence our calculation here.

My second proposed patch does that.

I know that slomo works on proper synchronization in adder, I'd like to know if
you experience this bug ? Also, it would be great if we could synchronize the
synchronizations between adder and mixer :)

-- 
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.