9 replies to this topic

[mx3L]

Hi,

 

Continuing from http://forums.openpl...ndpost&p=520325

 

I was investigating use of HTTP timeout in servicemp3, since there were problems that streams sometimes timed out, even when they should not.

 

Current situation:

1. we are setting HTTP_TIMEOUT to souphttpsrc by "timeout" property, when streaming thread is created (GST_STREAM_STATUS_TYPE_CREATE)

2. we are setting HTTP_TIMEOUT to m_streaming_src eTimer and starting it, when streaming thread is created (GST_STREAM_STATUS_TYPE_CREATE)

3. if HTTP_TIMEOUT is reached eTimer will call sourceTimeout, which stops pipeline and emits EOF event

4. if pipeline gets to PAUSED_TO_PLAYING state change before HTTP_TIMEOUT is reached, it stops eTimer, so sourceTimeout is not called

 

What are the problems:

1. We are setting HTTP_TIMEOUT to souphttpsrc when streaming thread is created which is too late, since SOUP client was already initialized, which in effect means that there is default timeout set. In gstreamer1.0 it's 15 seconds, in gstreamer 0.10 it's infinity. (note, since gstreamer 1.4 souphttpsrc has option to set "retries" property which sets 'Maximum number of retries until giving up', default is 3, so it should be, timeout = timeout * 3, but by doing tests it's  only 2* timeout value)

2. From above point it's clear that m_streaming_src eTimer is effectively doing timeout, which is not precise at all.

3. In sourceTimeout we are emitting EOF without emiting evStart ( evStart is now correctly emited in READY_TO_PAUSED state change since https://github.com/O...ffaa6af62c377d)

4. In sourceTimeout we are emitting EOF, after stopping pipeline. EOF event should mean that end of file was reached, and it should be still possible to do for example seek actions. After we stop pipeline we cannot do that anymore, and we correctly shouldn't be able to do that since source timed out, so EOF shouldn't be emitted at all.

 

Solution:

1. set timeout for souphttpsrc in playbinNotifySource, so our timeout is actually applied

2-4. remove m_streaming_src timer and instead catch specific resource error messages on the bus: GST_RESOURCE_ERROR_OPEN_READ or GST_RESOURCE_ERROR_OPEN(http://gstreamer.fre...stResourceError), which among other problems will tell us that timeout is reached, so we can stop pipeline. Note we don't emit EOF event as explained.

 

What's the difference for user:

Playback will behave as before except there will be no unexpected timeout occuring and if stream times out nothing happens, while before EOF event would be emited, which would for example show "END" message in MoviePlayer, or do some other registered action.

 

Todo:

- I think we should consider to create/reuse some event which would signal that there was some error and we cannot start playback, so we can inform user about it.

- Do the same for servicemp3record

 

Patch was tested on gstreamer-1.0 and also on gstreamer-0.10 by @ian1095

 

Any advises are much appreciated.

 

Patch:

https://gist.github....69e1da108009508

 

[MastaG]

Great job mx3L.

Thanks a million!

 

I'll apply it and report back.

[mx3L]

Thanks @MastaG

 

Pull request created

[Akki]

@mx3L

 

thanks for the good Patch

 

I have a list of bouquet stream links when a stream of it is down and I zap to the next stream, so the spinner comes for 2-3 sec.

Can we eliminate this with this patch, so that the zapping is faster?

And how should the timeout be set in the stream address?

 

Greeting Akki

[athoik]

This might causing the delay: ret = gst_element_get_state(m_gst_playbin, &state, &pending, 5 * GST_SECOND);

But without this there is a chance for dealock. Maybe with the latest patches applied we can check if the deadlock still occurs without the above "workaround".

[mx3L]

@Akki

this is not relevant to timeout as @athoik says

It's not possible to change http timeout. Timeout is set to 30 seconds in gstreamer-0.10 which should be enough for most cases, in gstreamer-1.0 it's even 60 seconds.

 

@athoik

Deadlock is still happening.

 

Can somebody who uses gstreamer-1.0 master test, if after quickly changing hls streams in bouquet is deadlock happening with this patch applied?

https://gist.github....0faaf11f3b200a8

 

bug reported:

https://bugzilla.gno...g.cgi?id=760929

[mx3L]

In git master there is no deadlock anymore, so once version with fixes for adaptivedemux comes, we can remove gst_element_get_state with timeout in stop.

[MastaG]

mx3L could you be a little more specific?

e.g. when using gstreamer master git, we don't need to use your second patch https://gist.github....0faaf11f3b200a8 ?

And with: "once version with fixes for adaptivedemux comes" you're refering to a new gstreamer release e.g. 1.7.3?

So the fixes for adaptivedemux are already in upstream gstreamer git?

[mx3L]

1. When using gstreamer master git, you can do this:

diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp
index 7559042..fd59b62 100644
--- a/lib/service/servicemp3.cpp
+++ b/lib/service/servicemp3.cpp
@@ -782,14 +782,6 @@ RESULT eServiceMP3::stop()
        m_state = stStopped;
 
        GstStateChangeReturn ret;
-       GstState state, pending;
-       /* make sure that last state change was successfull */
-       ret = gst_element_get_state(m_gst_playbin, &state, &pending, 5 * GST_SECOND);
-       eDebug("[eServiceMP3] stop state:%s pending:%s ret:%s",
-               gst_element_state_get_name(state),
-               gst_element_state_get_name(pending),
-               gst_element_state_change_return_get_name(ret));
-
        ret = gst_element_set_state(m_gst_playbin, GST_STATE_NULL);
        if (ret != GST_STATE_CHANGE_SUCCESS)
                eDebug("[eServiceMP3] stop GST_STATE_NULL failure");

2. Yes, I'm referring to 1.7.x stable release

3. Yes

[MastaG]

Thank you :-)