GNOME Bugzilla – Bug 752531
rtspsrc/rtpjitterbuffer: playback and seek is unstable if set buffering mode
Last modified: 2018-11-03 15:02:09 UTC
I'm running rtsp streaming on GST v1.5.2 release. current default rtspsrc streaming does not raise buffering msg. however, I need to get buffering msg from the pipeline. However,if set "buffer-mode" property as buffering mode, the rtsp streaming in buffering mode seems unstable. for example uri, gst-launch-1.0 rtspsrc location="rtsp://87.106.191.98/3gp/video/03.Video_H.263(16K)_AAC-LC(24k).3gp" buffer-mode="2" ! decodebin ! navseek ! xvimagesink => if doing pause and resume and seek , it is stopped with printing "buffering 0%". or modify gst/rtsp/gstrtspsrc. make 'buffer-mode' set to buffering mode. after build& install. gst-launch-1.0 playbin uri="rtsp://87.106.191.98/3gp/video/03.Video_H.263(16K)_AAC-LC(24k).3gp" video-sink="navseek ! xvimagesink"
That make very little sense to me "I need to get buffering msg from the pipeline.". This *live* source buffering happens inside rtpjitterbuffer and no application action shall be made. In fact, if you set the pipeline in paused like we normally do for non-live, you'll ask the server to stop sending and it will never buffer anything.
hm.. ok. "I need to get buffering msg from the pipeline." means buffering msg with buffering percent should be informed to the application. The problem is "buffer-mode" setting of rtspsrc/rtpjitterbuffer. if want to get buffering msg with percent, have to set "buffer-mode" property as 'BUFFER_MODE_BUFFER' . static const GEnumValue buffer_modes[] = { {BUFFER_MODE_NONE, "Only use RTP timestamps", "none"}, {BUFFER_MODE_SLAVE, "Slave receiver to sender clock", "slave"}, {BUFFER_MODE_BUFFER, "Do low/high watermark buffering", "buffer"}, {BUFFER_MODE_AUTO, "Choose mode depending on stream live", "auto"}, {BUFFER_MODE_SYNCED, "Synchronized sender and receiver clocks", "synced"}, {0, NULL, NULL}, }; if not set anything, the default(slave mode) working has no problem. However, if set "buffer-mode" property as 'BUFFER_MODE_BUFFER', the rtsp streaming is blocked after seek. and sometimes, buffering percent also stopped before starting playing. Additionally, even if use with gst-rtsp-server plugin as a server, the problem is similar. (play > pause > seek > resume , never resume...) tested as below. 1)copy a video 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.
(In reply to jihae from comment #2) > hm.. ok. "I need to get buffering msg from the pipeline." means buffering > msg with buffering percent should be informed to the application. When a pipeline is live, the buffering is not in size or percent, but in time. In fact, it match the latency time. So from the time you set the pipeline to playing, to that time + latency, the "buffering" is uniformly distributed. You can easily right a UI around that. > > The problem is "buffer-mode" setting of rtspsrc/rtpjitterbuffer. > if want to get buffering msg with percent, have to set "buffer-mode" > property as 'BUFFER_MODE_BUFFER' . > > > static const GEnumValue buffer_modes[] = { > {BUFFER_MODE_NONE, "Only use RTP timestamps", "none"}, > {BUFFER_MODE_SLAVE, "Slave receiver to sender clock", "slave"}, > {BUFFER_MODE_BUFFER, "Do low/high watermark buffering", "buffer"}, > {BUFFER_MODE_AUTO, "Choose mode depending on stream live", "auto"}, > {BUFFER_MODE_SYNCED, "Synchronized sender and receiver clocks", > "synced"}, > {0, NULL, NULL}, > }; I'll let other comment about this mode, I still can't think of how to make this work in a live context. Clearly it does not seem implemented well.
(In reply to jihae from comment #2) >> hm.. ok. "I need to get buffering msg from the pipeline." means buffering >> msg with buffering percent should be informed to the application. >When a pipeline is live, the buffering is not in size or percent, but in time. >In fact, it match the latency time. So from the time you set the pipeline to >playing, to that time + latency, the "buffering" is uniformly distributed. You >can easily right a UI around that. you mean buffering msg can be informed to application with default 'buffer-mode'= BUFFER_MODE_SLAVE ? could you let me know in more details?
Jihae, Theoretically you could wait until 50% of the buffer is full and start playing there to have some extra padding, but then once you start playing, content comes versus playback speed is the same eventually as if you didn't buffer. The maximum you can achieve is bigger blocks of continuous playback, but everytime you pause you are increasing the latency.
Created attachment 308510 [details] [review] rtpjitterbuffer: fix pipeline stopping issue after pause,seek and resume during playback on buffering mode
I uplaoded patch only for
-- 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/203.