After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 726854 - gststreamsynchronizer: time stamp wrong when convert EOS event to gap event
gststreamsynchronizer: time stamp wrong when convert EOS event to gap event
Status: RESOLVED DUPLICATE of bug 736655
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.2.3
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-03-22 00:43 UTC by kevin
Modified: 2014-12-25 04:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description kevin 2014-03-22 00:43:32 UTC
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.
Comment 1 kevin 2014-03-25 01:46:21 UTC
Do your gays have any comments on that? Is it suitable for audio or it is suitable for subtitle?
Comment 2 kevin 2014-12-25 04:59:08 UTC

*** This bug has been marked as a duplicate of bug 736655 ***