GNOME Bugzilla – Bug 757054
rtspsrc: seeking does not work properly
Last modified: 2015-11-02 15:03:00 UTC
I am setting up a movie for streaming using the test-uri example provided with the RTSP module. The movie is a mkv file with HD stream. However this happens with almost all movies I have. Above is run in a Fedora laptop with 4 cores and 16GB memory. A custom client runs following pipeline in a raspberry pi 2 machine: playbin uri=rtsp://192.168.1.93:8554/2 This plays fine. However if I call gst_element_seek_simple in the client pipeline, the player get stuck without seeking. this happens almost all the time. Similar behaviour is present if I use omxplayer as the client. the speed from laptop to RP is measured to be around 13MBbs.
At first glance I think this is a problem on the client-side, since seeking appears to work fine with VLC + gst-rtsp-server. I thought this was all fixed in 1.6, but apparently not.
In my testing the issue was present even if I use omxplayer as the client8.
I've been combining gst-play-1.0 and test-uri to verify this and I could not reproduce. Would it be possible to provide more details. Here's what I have been testing: Server: ./test-uri file:///home/nicolas/Vidéos/Sintel.2010.1080p.mkv Client: gst-play-1.0 rtsp://127.0.0.1:8554/test When using B-Frame enabled MKV, I notice that keyframes are lost, but otherwise no particular issue, seeking works as expected. Would it be possible to provide the details about your server. Also, provide all the details about how you invoke the seek_simple function ?
In my case I use gst-launch-1 with playbin as follows: gst-launch-1.0 playbin uri=rtsp://<interface_ip>:<port>/test This is my code hat does the seek: GstSeekFlags flags = GST_SEEK_FLAG_FLUSH; gst_element_seek_simple(pipeline, GST_FORMAT_TIME, flags, GST_SECOND * seek_pos); Above is called by a different thread that the one running the loop.
This should be no different from gst-play-1.0, you can test with gst-play-1.0 and report please ? Also, maybe the problem is specific to the stream you are using on server side, can you provide a link to that media ?
I will test soon with gst-play-1.0. This happens with almost all media files I download from the internet as torrents.
I just tested with gst-play-1.0 (version 1.6) and it seems to work. Looks like the issue is in my code which uses gst libraries to build the client. I guess this issue can be rejected/closed. Thank you very much for the support.
Thanks you, feel free to send questions to the mailing list gstreamer-devel@lists.freedesktop.org or pass by #gstreamer on freenode for more help. Also note that if you find more information that would this time indicate a bug, feel free to re-open this bug.
Fwiw, I tested this the other day on the rpi (master) with rtsp-server (1.6) on my laptop and seeking worked very poorly in general. I just re-tested with client and server on my laptop and it works rather well, so I don't know what's going on here. I still have issues locally seeking just in an m4a file, but I'll file a new bug about that once I have dug a bit more and have a test case I can share.
(In reply to Tim-Philipp Müller from comment #9) > Fwiw, I tested this the other day on the rpi (master) with rtsp-server (1.6) > on my laptop and seeking worked very poorly in general. I just re-tested > with client and server on my laptop and it works rather well, so I don't > know what's going on here. I still have issues locally seeking just in an > m4a file, but I'll file a new bug about that once I have dug a bit more and > have a test case I can share. Noted, the difference could be the decoder. It's possible the OMX decoder on the Pi does not behave so well in live.