GNOME Bugzilla – Bug 705355
RTSP pipeline freezes when set to a resume after a pause (PLAYING->PAUSED->PLAYING), with Jitterbuffer in Buffering Mode
Last modified: 2018-11-03 14:49:13 UTC
The RTP timestamp gap induced (nearly equal to the time the server/source has spent in PAUSED state), currently makes the jitter-buffer completely reset itself. This leads to freezing of the pipeline, due to the RTP-TS difference (equal to the time spent in PAUSED state) between the first RTP packet received after the the source/server has been set to PLAYING and the packet that was last received during the PAUSED state. This leads to a huge gap (TS discontinuity) between the first outgoing buffer from the jitter-buffer post-PAUSED (PLAYING before PAUSED) state and the last buffer that was sent pre-PAUSED (PLAYING after PAUSED) state. This leads to a long halt at the sink depending upon the time spent in PAUSED state . i.e long freeze of the pipeline.
Can you provide a testcase for this?
I tested this with a local darwin server. The server puts a gap in the RTP timestamps when resumed from PAUSED state, nearly equal to the time spent in PAUSED state. This makes jitterbuffer treat this as RTP jump and reset the skew by calling the function rtp_jitter_buffer_reset_skew(), leading to the output frames' PTS start from zero all over again, and getting dropped by the sink. Maybe sending a new segment event here might help (since the base_time and friends are set to -1). Haven't tried that. Instead, if I use rtp_jitter_buffer_resync(), this issue is resolved. But then, we need to know if the RTP jump is because the server was paused by the client or a genuine one. The server does send a RTCP packet with newer RTP/NTP values, after it is resumed. But I guess the RTP timestamp, currently observed in the SR from last RTCP packet is not used when inserting the new incoming RTP packet is put in the queue, plus we also need to make sure that the first RTCP packet must be processed before the first RTP packet after a resume.
This issue is not observed for mobile youtube RTSP links, because it doesn't insert any RTP TS gaps when resumed after PAUSE. Do let me know if you need anything else from my side.
Anything to be able to reproduce this problem would be useful :)
Created attachment 252723 [details] test application for RTSP The app mandates the RTSP URL to have both audio and video.
Comment on attachment 252723 [details] test application for RTSP The app is very minimal (no error/return val handling To run: ./test <rtsp url> Once up: 'p' followed by 'enter' key to pause 'r' followed by 'enter' key to resume
The problem is more to find a stream that allows to reproduce this :)
Well, I don't think it is stream specific as such(I could be wrong though) It will depend on the server like the darwin server I am using. Unfortunately, it is local setup here. :(.
Going through the code accordingly (as mentioned in comment 2), should suffice right? I mean, it would be easy imagine such a situation. OR will need a darwin setup at your end too.
Given that there are no public sources to reproduce this bug, is it still considered a problem that needs to be fixed? If so, I'd set to NEW. Otherwise, WONTFIX or NOTABUG seems appropriate.
hello. it's same as current problem which I'm facing with. I'm using gstreamer v1.5.2 relase. [The reproduce step] 1)copy a mp4 file into 'gst-rtsp-server-1.5.2/examples/'. 2)run gst-rtsp-server-1.5.2/examples$ ./test-mp4 ./rtsp_video.mp4 stream ready at rtsp://127.0.0.1:8554/test 3)I used the uri "rtsp://127.0.0.1:8554/test" as rtsp streaming uri. 4)modify gst/rtsp/gstrtspsrc. make 'buffer-mode' set to "BUFFER_MODE_BUFFER(buffering mode)", build& install. 5)gst-launch-1.0 playbin uri="rtsp://127.0.0.1:8554/test" video-sink="navseek ! xvimagesink" I filed a bug also as below. https://bugzilla.gnome.org/show_bug.cgi?id=752531
oops, not same. silmilar with https://bugzilla.gnome.org/show_bug.cgi?id=752531
Is this still an issue with latest GStreamer release?
-- 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/88.