[Bug 692868] New: basesink: expands GAP event without duration to last to segment end

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=692868
  GStreamer | gstreamer (core) | git

           Summary: basesink: expands GAP event without duration to last
                    to segment end
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: t.i.m at zen.co.uk
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


- playbin (with streamsynchronizer)

 - mp4 file with 4 seconds worth of data

 - segment is 0-22 minutes

 - ca. 4 seconds worth of buffers are sent

 - EOS events are sent

 - when receiving the video EOS event,
    streamsynchronizer makes up a GAP
    event with ts=4secs and no duration
    and sends it to the audio sink

 - audio sink waits until segment end
   before posting EOS.

The audio sink should treat the GAP event without duration like a buffer
without duration, and post EOS pretty much immediately afterwards (the GAP
event is followed by an EOS event).

Here's what goes wrong:

<AD-N770> __tim, wtay: http://dl.dropbox.com/u/4577541/gst.log
<AD-N770> this is the log for basesink, let me know if you want more categories
and I will regen it
<AD-N770> 4 seconds of data and 22 min duration
<__tim> gst_base_sink_get_sync_times:<alsasink0> Got Gap time 0:00:04.272000000
duration 99:99:99.999999999
<__tim> so the GAP event generated by streamsynchronizer looks ok - agreed?
<AD-N770> I think so, but it seems that it may be the cause of sync the EOS at
segment end
<__tim> but then this happens:
<__tim> gstbasesink.c:1876:gst_base_sink_get_sync_times:<alsasink0> got times
start: 0:00:04.272000000, stop: 99:99:99.999999999, do_sync 1
<__tim> gstbasesink.c:1902:gst_base_sink_get_sync_times:<alsasink0> clipped to:
start 0:00:04.272000000, stop: 0:22:49.896000000
<__tim> so the question is where it gets that stop from then
<__tim> well, we know where it's from (segment), but not where it's filled in
<AD-N770> __tim: do you mean that the gap event get the duration of the
remaining lenght of stream
<AD-N770> and it causes the EOS being sync at buffer+duration of last, so the
gap duration
<__tim> I think that's what's happening, yes
<AD-N770> well, I really can't dig on it now, but let me know if you want that
I'll generate some logs or test a patch
<wtay> __tim, AD-N770 ah yes
<wtay> in that case, basesink calculates the stop time wrongly for items
without a duration
<AD-N770> wtay: then is something to be changed in basesink?
<wtay> AD-N770, I would think so

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