After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 580504 - pause problem when playing from neonhttpsrc
pause problem when playing from neonhttpsrc
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: dont know
git master
Other All
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-04-27 20:41 UTC by Andreas Frisch
Modified: 2009-08-14 07:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GST_DEBUG="*:3,*mediasink*:5,*playbin2*:5,*http*:5" enigma2 (509.34 KB, text/plain)
2009-04-27 20:42 UTC, Andreas Frisch
Details

Description Andreas Frisch 2009-04-27 20:41:23 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
Comment 1 Andreas Frisch 2009-04-27 20:42:44 UTC
Created attachment 133446 [details]
GST_DEBUG="*:3,*mediasink*:5,*playbin2*:5,*http*:5" enigma2
Comment 2 Wim Taymans 2009-04-28 15:03:40 UTC
You should probably not return WRONG_STATE when the unlock is performed in the render method, but just return GST_FLOW_OK.
Comment 3 Wim Taymans 2009-04-28 15:04:44 UTC
Please reopen if that does not fix it.
Comment 4 Andreas Frisch 2009-04-29 06:30:34 UTC
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
Comment 5 Wim Taymans 2009-04-29 09:41:19 UTC
What's in the stopped: label?
Comment 6 Andreas Frisch 2009-04-29 19:27:46 UTC
stopped:
	{
		GST_DEBUG_OBJECT (self, "Select stopped");
		ioctl(self->fd, VIDEO_CLEAR_BUFFER);
		return GST_FLOW_OK;
// 		return GST_FLOW_WRONG_STATE;
	}
Comment 7 Andreas Frisch 2009-05-26 06:30:30 UTC
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?
Comment 8 Andreas Frisch 2009-08-14 07:24:59 UTC
seems to have become obsolote due to changes in the video sink