[Bug 726854] New: gststreamsynchronizer: time stamp wrong when convert EOS event to gap event

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=726854
  GStreamer | gst-plugins-base | 1.2.3

           Summary: gststreamsynchronizer: time stamp wrong when convert
                    EOS event to gap event
    Classification: Platform
           Product: GStreamer
           Version: 1.2.3
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: kevinbing.song at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Below code in gststreamsynchronizer seems wrong. gap event will get wrong start
timestamp. The start time stamp should be segment start if segment rate bigger
than 0 and should be segment stop if segment rate less then 0? Currently
implement will cause audio sink get wrong gap event and block when rewind
playback and demuxer send segment event (but not PCM data, demuxer output LPCM
audio) and EOS event.

      if (seen_data && stream->segment.position != -1)
        timestamp = stream->segment.position;
      else if (stream->segment.rate < 0.0 || stream->segment.stop == -1)
        timestamp = stream->segment.start;
      else
        timestamp = stream->segment.stop;

Our implement will mute audio when rewind, so demuxer will send segment and eos
event (without send any stream data) when rewind. If demuxer link with audio
decoder, segment will be hold by decoder. stream synchronizer can't received
the segment event. If demuxer output is LPCM audio, segment will sent to down
streamer element. But current implement will use segment start time stamp as
gap event start time stamp. It will cause audio sink get wrong gap event and
block.

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