GNOME Bugzilla – Bug 781225
qtdemux: set seqnum to segment event in push mode
Last modified: 2018-11-03 15:18:16 UTC
I found that when playing media using qtdemux in pull mode (streaming), the seqnum of the relevant events after seek is different from seqnum of the seek event. Seqnum of segment is only used when seeking in pull mode. In push mode, the seek event is processed by the upstream source element, so this value is never used. I fixed to apply seqnum of segment event sent from the upstream in push mode.
Created attachment 349740 [details] [review] qtdemux: set seqnum to segment event in push mode
(I'm assuming you had a typo in your first line push -> pull) I'm not sure I follow what is the bug here. This is what should happen when you send a seek upstream: 1) Demux receives a seek, converts it to a new seek for upstream 2) Demux sets the new seek with the same seqnum of the original seek 3) Source receives the seek and handles it 4) Source creates a new segment event with the same seqnum of the seek it received (which is the same as of the original seek) 5) Demux receives the segment with the same seqnum as the original one. 6) Demux forwards its own segment and also copies over the seqnum It seems to me that the bug might be in the source not copying the seqnum properly. Can you provide more information on the issue you are experiencing?
(In reply to Thiago Sousa Santos from comment #2) > (I'm assuming you had a typo in your first line push -> pull) Yes, it was a typo the first line should be push mode, sorry. > > I'm not sure I follow what is the bug here. This is what should happen when > you send a seek upstream: > > 1) Demux receives a seek, converts it to a new seek for upstream > 2) Demux sets the new seek with the same seqnum of the original seek > 3) Source receives the seek and handles it > 4) Source creates a new segment event with the same seqnum of the seek it > received (which is the same as of the original seek) > 5) Demux receives the segment with the same seqnum as the original one. > 6) Demux forwards its own segment and also copies over the seqnum Source sent a segment event to Demux with the same seqnum of the seek event received from Demux. The problem occurs in here step 6). 1.Demux does not refer to the seqnum of the segment event sent by Source in gst_qtdemux_handle_sink_event(). 2. Demux does not keep seqnum of the seek event that it sent for upstream before. So Demux generates and sends segment event which has a random seqnum. > > It seems to me that the bug might be in the source not copying the seqnum > properly. Can you provide more information on the issue you are experiencing? I had also suspected Source at first, but the seqnum of the event from the source is all set properly.
Created attachment 349758 [details] [review] qtdemux: set seqnum to segment event in push mode updated the patch to keep seqnum when convert and sent seek event to upstream
I brought your first patch back, I think it makes more sense after you provided more details. qtdemux should just update its internal segment-seqnum values whenever it gets a new segment from upstream. That values should be of the last issued seek it sent upstream anyway. Does it solve your issue or do you also need your second part for the FLUSH_STOP? You shouldn't, right? As the following segment event should also contain the same seqnum.
Created attachment 349793 [details] [review] [first one] qtdemux: set seqnum to segment event in push mode Yes, you're right, the first one solves the problem. The second one was the same intentions. Let's go this way, I updated the patch to log bugzilla url on the commit msg.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/364.