GNOME Bugzilla – Bug 740509
Seek fail with test-uri
Last modified: 2016-03-17 07:59:36 UTC
When testing gst-rtsp-server using the test-mp4 example, I am seeing odd behavior with seek operation. If connect with a RTSP Client (ffplay, VLC) and seek randomly, then the server freeze and print the message of error: 0:00:32.948940541 12191 0x219a320 ERROR rtspsessionmedia rtsp-session-media.c:334:gst_rtsp_session_media_get_rtpinfo:<GstRTSPSessionMedia@0x7f3958043b60> media was not prepared Scenario: -> Mp4 file (1h:35min duration) -> Seeked to 60% of duration (~ 57 minutes) -> RTP over UDP on localhost -> ffplay -> Xubuntu 14.04 I believe it may be a problem of Race Condition, because this bug is not constant but occurs frequently. I have the same behavior on previous versions of gst-rtsp-server 1.4.4
*** This bug has been marked as a duplicate of bug 635701 ***
With the last version of git, on seek in the rtsp client, gst-rtsp-server freeze and print the message of error: 0:00:26.737417216 12316 0xdb1400 ERROR rtspclient rtsp-client.c:1241:handle_play_request: client 0xe490e0: seek failed I have tried with different mp4 files, with and without hint (metadata info), but the same error occur. All tests were performed on the same scenario of the first report.
I also get this behavior (all components at git master from ~10 hours ago), but not just with mp4. WebM files also suffer from this. Seeking is impossible. Plus, with VLC, in the first second, video playback stutters with MP4/h264.
How can you reproduce this? With latest GIT master this still works for me: > ./test-launch "filesrc location=\"/path/to/mkv/with/h264\" ! matroskademux ! rtph264pay name=pay0" > > ./playback-test 0 rtsp://127.0.0.1:8554/test And then seeking there.
With test-launch, it works. But with test-uri, it doesn't, even if the file only has a video track and nothing else.
git bisect reveals that seeking breaks at the gst-rtsp-server commit 8b68edd138ec78437279ac9ec482aabe59f123dd "rtsp-stream: Ensure that the pipeline is live and later-added udpsrcs are syncing the state with the parent bin".
Further tests show that in this commit, setting appsrc's "is-live" property to TRUE is what causes the freeze. If I don't set is-live, seeking works.
This might be because of https://cgit.freedesktop.org/gstreamer/gst-rtsp-server/tree/gst/rtsp-server/rtsp-media.c#n2529 Which should've been prevented by https://cgit.freedesktop.org/gstreamer/gst-rtsp-server/tree/gst/rtsp-server/rtsp-stream.c#n2480 (also done for the other udpsrc and appsrc).
Summary of the current findings: Main cause is that the GCond in gst_rtsp_media_get_status() is not signaled. This signal is supposed to happen when an ASYNC_DONE message is received. The code in rtsp-media.c sets the status to GST_RTSP_MEDIA_STATUS_PREPARED when this message is received, and this status then triggers a GCond broadcast. The strange part is why this worked in the first place. GstBin will set its state to NO_PREROLL if a state change of at least one child element returned NO_PREROLL (gstbin.c:2808). Prior to the above commit, the appsrc element weren't returning this because they weren't live. But udpsrc is always live, and yet, these do *not* return NO_PREROLL , but SUCCESS instead. This is most likely what was hiding this bug in the past. The two remaining questions are: (1) why does udpsrc return SUCCESS, and not NO_PREROLL? (2) since relying on ASYNC_DONE is wrong, how else should the code wait for preroll to finish? check for PAUSED state changes?
Created attachment 324143 [details] [review] rtsp-stream: Don't set the state of the appsrc from PLAYING to PAUSED again during setup This would get us NO_PREROLL in the bin again and break seeking.
Created attachment 324144 [details] [review] rtsp-stream: Don't set the state of the appsrc from PLAYING to PAUSED again during setup This would get us NO_PREROLL in the bin again and break seeking. Thanks to Carlos Rafael Giani for helping to debug this!
Fix confirmed with a fresh GStreamer 1.7.91 installation. Seeking worked again.
Forgot to mention: thanks for Sebastian Dröge for fixing this ;)
Attachment 324144 [details] pushed as 8e72e69 - rtsp-stream: Don't set the state of the appsrc from PLAYING to PAUSED again during setup