GNOME Bugzilla – Bug 781386
rtsp: keep seqnum when performing seek
Last modified: 2018-11-03 12:40:40 UTC
I tried to seek on rtsp stream, for example, rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov The rtspsrc handles seek event and push the flush-start/stop event to udpsrcs what it has inside. The task running in the udpsrc stopped and restarted after rtspsrc set it's state to PLAYING. Then the udpsrc generated new segment event which has new seqnum (handled in basesrc), even if the segment event is related to the flush events from rtspsrc when performing seek. In push mode, there seem not many cases handling seek event at upper bin or downstream element instead of Source element. It's not a good way to push segment event from the downstream element to upstream Source element, so I tried to keep the seqnum of the flush event which obviously triggers new segment event. One problem here is that udpsrc didn't know the start / stop position of the segment what should be which was set to the seek event. I wonder it's a good way if I hook up segment event generated from udpsrc and updated start/stop position in rtspsrc in this case. please let me know if you have a good idea!
Created attachment 349926 [details] [review] basesrc: keep seqnum of pushed flush event
Created attachment 349928 [details] [review] rtspsrc: fix to keep seqnum of seek event
*** Bug 781388 has been marked as a duplicate of this bug. ***
Created attachment 349929 [details] [review] rtpbasedepayload: fix to keep seqnum of segment event The rtpbasedepayload re-generates segment event when it received it from upstream. This is required to keep the seqnum of segment event.
Created attachment 349990 [details] [review] rtpbasedepayload: fix to keep seqnum of segment event
Created attachment 349991 [details] [review] rtspsrc: fix to keep seqnum of seek event
Comment on attachment 349926 [details] [review] basesrc: keep seqnum of pushed flush event I don't understand this one. Why is the seqnum of the flush events relevant for anything?
(In reply to Sebastian Dröge (slomo) from comment #7) > Comment on attachment 349926 [details] [review] [review] > basesrc: keep seqnum of pushed flush event > > I don't understand this one. Why is the seqnum of the flush events relevant > for anything? I took this as a way to tell seqnum of a segment when processing a seek event in rtspsrc. Rtspsrc flushes the internal udpsrcs, then set them playing, where the segment event is created after the flush event, but seqnum is not kept. I thought It seems not a good idea to send rtspsrc's segment event or seek event to udpsrc. What should be the right way to handle it?
-- 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/gstreamer/issues/230.