GNOME Bugzilla – Bug 702046
rtspsrc doesn't produce buffers
Last modified: 2013-06-16 03:42:08 UTC
Created attachment 246567 [details] Test code to reproduce rtspsrc bug After I updated gst-plugins-good to the latest git, my custom pipeline using rtspsrc stopped working. It seemed like udpsrc was not receiving any packets. I tracked down the issue to this commit from Wim Taymans : http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=4fc1f3088b470a89c7e40e5b6e333f9537f12ee9 I am now forced to have a workaround in the code where I wait a certain amount of time and call gst_element_set_state PLAYING on rtspsrc again in order to make it work. Without that second set_state, the pipeline simply does not work. Why was the code there in the first place and why was it removed? and why do I need to set the state of the element to PLAYING twice in order for it to work ? Shouldn't rtspsrc sync_state_with_parent on the udpsrc it creates internally? Note that for some reason, it still works with playbin though, or with a simple gst-launch pipeline. Either way, this is a regression that should be fixed.. or someone explains to me why the custom pipeline does not work! I have attached a sample test application which can reproduce the bug. It takes the rtsp url as first argument, then will output something and quit once rtspsrc signals 'pad-added'. As you will notice, we never receive the 'pad-added' signal, but if you uncomment the g_timeout that sets the element to playing again, it will work,
(In reply to comment #0) > Created an attachment (id=246567) [details] > Test code to reproduce rtspsrc bug > > After I updated gst-plugins-good to the latest git, my custom pipeline using > rtspsrc stopped working. It seemed like udpsrc was not receiving any packets. > > I tracked down the issue to this commit from Wim Taymans : > http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=4fc1f3088b470a89c7e40e5b6e333f9537f12ee9 > > Why was the code there in the first place and why was it removed? and why do It was a bad workaround for a bug. By the time the rtspsrc is set to PLAYING, the udpsrc elements are not added yet. When they are added later, their state is PAUSED so setting the state of the rtspsrc to PLAYING moved them to PLAYING as well. The problem with the code is that you can't just change the state of rtspsrc like that. I > need to set the state of the element to PLAYING twice in order for it to work ? The first one probably adds the udpsrc, by the time you do the second one the udpsrc is added and things start. > Shouldn't rtspsrc sync_state_with_parent on the udpsrc it creates internally? Yes, the correct solution is to have rtspsrc update the state of the udpsrc itself. I will do this. > > Note that for some reason, it still works with playbin though, or with a simple > gst-launch pipeline. > Either way, this is a regression that should be fixed.. or someone explains to > me why the custom pipeline does not work! gst-launch waits for the rtspsrc to complete the paused state before it goes to playing and thus has the udpsrc go to playing correctly. > > I have attached a sample test application which can reproduce the bug. It takes > the rtsp url as first argument, then will output something and quit once > rtspsrc signals 'pad-added'. As you will notice, we never receive the > 'pad-added' signal, but if you uncomment the g_timeout that sets the element to > playing again, it will work,
commit d9bc48edc977f86b39aabe9e1f125603c82bec6a Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Sun Jun 16 05:40:13 2013 +0200 rtspsrc: manage element state ourselves Lock the state of the all our elements and manage their states outselves. Because we are working async, we can't rely on the state change function to set the state at the right time or to return the right return value from the state change function. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=702046