[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 #9 from Heekyoung Seo <heekyoung.seo at lge.com> ---
Thanks for your comments. :)

I understand that the range of the segment is start <= range < stop. I was
thinking if start <= range <= stop was also reasonable for the segment range,
but if it is wrong, I will remove the patch.

And I checked a bit more about other file formats (avi / mkv), and the problem
only occurred with mp4 (qtdemux). There seem to be two bugs in this issue. The
first is  that qecemux create a segment with segment.start == segment.stop ==
segment.position == segment.duration in the problem case but the others set
segment.stop to GST_CLOCK_TIME_NONE or total duration. The second bug is that
streamsynchronizer ignore segment when if segment.position is bigger or equal
than segment.stop, and then it cause preroll can not be finished. It occurs
because streamsynchronizer update segment.position of stream that gets eos
already using stream of other stream position.

I will update streamsynchronizer patch again after check your comment.
(In reply to Sebastian Dröge (slomo) from comment #8)
> Review of attachment 343216 [details] [review]:
> 
> This would have to be solved differently somehow
> 
> ::: gst/gstsegment.c
> @@ +889,1 @@
>      return FALSE;
> 
> This is wrong: if the start of a buffer is == segment.stop, then the whole
> buffer is outside the segment.

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