GNOME Bugzilla – Bug 580504
pause problem when playing from neonhttpsrc
Last modified: 2009-08-14 07:24:59 UTC
Please describe the problem: in our dreambox enigma2 gui we tried pausing video streams and it wouldn't ever start playing after once paused. boundary conditions are like usually: - latest releases / prereleases of all elements (0.10.22.2) - we use our own hardware decoder audio + video sink elements Steps to reproduce: as a direct comparison we tested with both an mp4 youtube video and with an avi divx movie. Actual results: when playing directly from the internet, after pause there was no way to go back into playing or into stop state. Expected results: once coming from harddisk read with a filesink element, the streams were perfectly pauseable and resumable. Does this happen every time? + Other information: logfile coming up
Created attachment 133446 [details] GST_DEBUG="*:3,*mediasink*:5,*playbin2*:5,*http*:5" enigma2
You should probably not return WRONG_STATE when the unlock is performed in the render method, but just return GST_FLOW_OK.
Please reopen if that does not fix it.
code excerpt... if (FD_ISSET (READ_SOCKET (self), &readfds)) { /* read all stop commands */ while (TRUE) { gchar command; int res; READ_COMMAND (self, command, res); if (res < 0) { GST_LOG_OBJECT (self, "no more commands"); /* no more commands */ break; } } goto stopped; } if (self->fd < 0) return GST_FLOW_OK; so it does return GST_FLOW_OK when unlock is done, i put a debug in the stopped branch but that's never being called. this is the same way in both the audio- and the videosink. only the httpsrc emits 0:01:38.656942000 954 0x10a7a838 INFO basesrc gstbasesrc.c:2282:gst_base_src_loop:<source> pausing after gst_pad_push() = wrong-state but that's supposedly normal
What's in the stopped: label?
stopped: { GST_DEBUG_OBJECT (self, "Select stopped"); ioctl(self->fd, VIDEO_CLEAR_BUFFER); return GST_FLOW_OK; // return GST_FLOW_WRONG_STATE; }
i've found out that the problem doesn't occur with the playback of streams (decoded by ivorbis and played back by alsasink rather than our own sink). with mp3 streams, the stream playback can be resumed after having paused. so maybe the problem has to do with either our videosink or maybe some queue or other element which is only needed for combined video+audio playback?
seems to have become obsolote due to changes in the video sink