Jump to content


Photo

servicemp3 - http timeout

patch gstreamer

  • Please log in to reply
9 replies to this topic

#1 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 20 January 2016 - 16:01

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

 



Re: servicemp3 - http timeout #2 MastaG

  • Senior Member
  • 1,531 posts

+118
Excellent

Posted 20 January 2016 - 16:26

Great job mx3L.

Thanks a million!

 

I'll apply it and report back.



Re: servicemp3 - http timeout #3 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 20 January 2016 - 20:57

Thanks @MastaG

 

Pull request created



Re: servicemp3 - http timeout #4 Akki

  • Senior Member
  • 204 posts

+3
Neutral

Posted 21 January 2016 - 00:47

@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



Re: servicemp3 - http timeout #5 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 21 January 2016 - 06:39

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".
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: servicemp3 - http timeout #6 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 21 January 2016 - 12:25

@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



Re: servicemp3 - http timeout #7 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 22 January 2016 - 10:11

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.



Re: servicemp3 - http timeout #8 MastaG

  • Senior Member
  • 1,531 posts

+118
Excellent

Posted 22 January 2016 - 11:53

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?



Re: servicemp3 - http timeout #9 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 22 January 2016 - 12:14

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



Re: servicemp3 - http timeout #10 MastaG

  • Senior Member
  • 1,531 posts

+118
Excellent

Posted 22 January 2016 - 13:40

Thank you :-)





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users