[Bug 777073] streamsynchronizer: Can't complete preroll in case pause/seek is called after one of streams receive EOS

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=777073

--- Comment #12 from Heekyoung Seo <heekyoung.seo at lge.com> ---
Review of attachment 344286:
 --> (https://bugzilla.gnome.org/review?bug=777073&attachment=344286)

I added explanation about what you have questioned. Some could be wrong again,
but I hope you kindly review it again. The buffer that has
timestamp=segment.stop && duration=0 is considered outside the segment. That is
why I made first patch for it
(https://bugzilla.gnome.org/review?bug=777073&attachment=343216).
You can reproduce it when you try seek or pause during playing the issue file
after the position of 8.4 seconds.

::: gst/playback/gststreamsynchronizer.c
@@ +573,3 @@
       srcpad = gst_object_ref (stream->srcpad);

+      if (!seen_data || !GST_CLOCK_TIME_IS_VALID (stream->segment.position)) {

In original code, when if stream->segment.position is valid and seen_data ==
true, timestamp is replaced with stream->segment.position and
stream->segment.position is replaced timestamp again in line 583. The goal of
this if condition is for updating stream->segment.position when if seen_data is
false or stream->segment.position is not valid. Therefore, I fixed it for
working only when if stream->segment.position need to be updated, and removed
unnecessary copy and variable.
If you implemented it on purpose to look simple, I will revert it.

@@ +585,3 @@
+      if (GST_CLOCK_TIME_IS_VALID (stream->segment.stop) &&
+          stream->segment.position >= stream->segment.stop)
+        stream->segment.position = stream->segment.stop - G_USEC_PER_SEC;

G_USEC_PER_SEC is substracted for updating stream->segment.position to smaller
than stream->segment.stop, because of
https://bug777073.bugzilla-attachments.gnome.org/attachment.cgi?id=343216. You
rejected that patch because the segment valid range is smaller than
segment.stop. If segment.position is same as segment.stop, it will be skipped
because gst_segment_clip return FALSE. Therefore preroll(do_sync) can not be
finished after one of stream receives EOS.

GST_MSECOND is better than G_USEC_PER_SEC and Yes, it is needed checking the
below zero case but I missed it.

@@ -738,3 @@
-    if (!GST_CLOCK_TIME_IS_VALID (timestamp_end) &&
-        GST_CLOCK_TIME_IS_VALID (timestamp)) {
-      timestamp_end = timestamp + GST_SECOND;

stream->segment.position is updated with timestamp_end when playback rate > 0
and updated with timestamp when playback rate <= 0, only when if those value is
not -1. Therefore, I thought stream->segment.position is accurate than
timestamp_end. 
Therefore, I think Advancing EOS can be done with stream->segment.position
instead of timestamp_end and it is not needed to be checked again here.

@@ -756,3 @@
-      /* Is there a 1 second lag? */
-      if (position != -1 && GST_CLOCK_TIME_IS_VALID (timestamp_end) &&
-          position + GST_SECOND < timestamp_end) {

Is this for sending GAP event only when if EOSed stream is 1 second behind non
EOS stream?
If so, when if the playback rate < 0 and the non EOS stream is one second ahead
of the EOS stream? Could you let me know why 1 second lag is necessary? I dig
git history and couldn't find why it is added.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.