Re: GStreamer 1.0 #321
Posted 16 November 2014 - 07:17
"Beauty lies in the hands of the beer holder."
Re: GStreamer 1.0 #322
Posted 16 November 2014 - 22:25
There is an issue with some HLS streams:
eServiceMP3::playbin uri=http://mf.srv.markiza.sk:1935/vod/_definst_/smil:part/pqtJhdcg3cyqLjSpZDVal7Fq0GMDmeFm.smil/manifest.m3u8 eServiceMP3::starting pipeline resolved to PLAY ......... Buffering 100 percent done eServiceMP3::GST_STREAM_STATUS_TYPE_CREATE -> setting timeout on souphttpsrc to 30s Buffering 0 percent done Buffering 98 percent done eServiceMP3::GST_STREAM_STATUS_TYPE_CREATE -> setting timeout on souphttpsrc to 30s action: playpauseService action -> InfobarSeekActions playpauseService resolved to PAUSE eServiceMP3::GST_STREAM_STATUS_TYPE_CREATE -> setting timeout on souphttpsrc to 30s eServiceMP3::state transition PLAYING -> PAUSED eServiceMP3::async-done - 1 video, 1 audio, 0 subtitle AUDIO STRUCT=audio/mpeg eServiceMP3::audio stream=0 codec=MPEG-4 AAC language=und Buffering 100 percent done action: playpauseService action -> InfobarSeekActions playpauseService unpause resolved to PLAY eServiceMP3::state transition PAUSED -> PLAYING eServiceMP3::GST_STREAM_STATUS_TYPE_CREATE -> setting timeout on souphttpsrc to 30s Buffering 0 percent done Buffering 1 percent done
As you can see there is multiple times message "eServiceMP3::GST_STREAM_STATUS_TYPE_CREATE -> setting timeout on souphttpsrc to 30s". If this happens after "state transition PAUSED -> PLAYING" then there will be
premature EOF.
Reason:
HTTP timeout timer (m_streamingsrc_timeout) is always started when souphttpsrc element requests creation of streaming thread by GST_STREAM_STATUS_TYPE_CREATE type of GST_MESSAGE_STREAM_STATUS message. This timer is only stopped and not triggered when we reach PLAYING state in HTTP_TIMEOUT limit.
Problem is, that this message can be emitted multiple times (HLS streams), if this happens when the timer is already stopped (we are in PLAYING state), then the timer is started again and is triggered, which creates EOF event.
Solution - added flag which will ensure, that we start the timer only once:
diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp index 556d164..fb48fa8 100644 --- a/lib/service/servicemp3.cpp +++ b/lib/service/servicemp3.cpp @@ -381,6 +381,7 @@ eServiceMP3::eServiceMP3(eServiceReference ref): { m_subtitle_sync_timer = eTimer::create(eApp); m_streamingsrc_timeout = 0; + m_streamingsrc_started = false; m_stream_tags = 0; m_currentAudioStream = -1; m_currentSubtitleStream = -1; @@ -1947,8 +1948,9 @@ void eServiceMP3::gstBusCall(GstMessage *msg) { GstElementFactory *factory = gst_element_get_factory(GST_ELEMENT(owner)); const gchar *name = gst_plugin_feature_get_name(GST_PLUGIN_FEATURE(factory)); - if (!strcmp(name, "souphttpsrc")) + if (!strcmp(name, "souphttpsrc") && !m_streamingsrc_started) { + m_streamingsrc_started = true; m_streamingsrc_timeout->start(HTTP_TIMEOUT*1000, true); g_object_set (G_OBJECT (owner), "timeout", HTTP_TIMEOUT, NULL); eDebug("eServiceMP3::GST_STREAM_STATUS_TYPE_CREATE -> setting timeout on %s to %is", name, HTTP_TIMEOUT); diff --git a/lib/service/servicemp3.h b/lib/service/servicemp3.h index b3a685e..6b222b1 100644 --- a/lib/service/servicemp3.h +++ b/lib/service/servicemp3.h @@ -325,6 +325,7 @@ private: ePtr<eTimer> m_subtitle_sync_timer; ePtr<eTimer> m_streamingsrc_timeout; + bool m_streamingsrc_started; pts_t m_prev_decoder_time; int m_decoder_time_valid_state;
After this patch, there are no more issues. Is this alright or we should find better solution?
Attached Files
Edited by mx3L, 16 November 2014 - 22:27.
Re: GStreamer 1.0 #323
Re: GStreamer 1.0 #324
Posted 16 November 2014 - 23:19
you might use m_streamingsrc_timeout.isActive() instead, to avoid introducing a boolean (and duplicating the timer status)?
but other than that, the fix makes sense.
This would'nt work in this scenario:
1. timer starts,
2. timer stops(playing state),
3. GST_STREAM_STATUS_TYPE_CREATE type of GST_MESSAGE_STREAM_STATUS message occurs -> timer is not active -> timer will start in playing state -> EOF
Re: GStreamer 1.0 #325
Posted 16 November 2014 - 23:49
Or check if m_is_live is false.
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916
Re: GStreamer 1.0 #326
Re: GStreamer 1.0 #327
Posted 17 November 2014 - 22:58
@athoik
Thanks for suggestion, first time the message appears is in READY state, so the timer is started only once in this state:
diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp index 556d164..27a5742 100644 --- a/lib/service/servicemp3.cpp +++ b/lib/service/servicemp3.cpp @@ -1945,9 +1945,11 @@ void eServiceMP3::gstBusCall(GstMessage *msg) owner = 0; if ( owner ) { + GstState state; + gst_element_get_state(m_gst_playbin, &state, NULL, 0LL); GstElementFactory *factory = gst_element_get_factory(GST_ELEMENT(owner)); const gchar *name = gst_plugin_feature_get_name(GST_PLUGIN_FEATURE(factory)); - if (!strcmp(name, "souphttpsrc")) + if (!strcmp(name, "souphttpsrc") && (state == GST_STATE_READY) && !m_streamingsrc_timeout->isActive()) { m_streamingsrc_timeout->start(HTTP_TIMEOUT*1000, true); g_object_set (G_OBJECT (owner), "timeout", HTTP_TIMEOUT, NULL); --
So this is better solution since it doesn't introduce any new instance variable.
2.patch:
Stop HTTP timeout timer in eServiceMP3 stop function, since it can be still active when we exit before getting to PLAY state.
diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp index 556d164..338c16a 100644 --- a/lib/service/servicemp3.cpp +++ b/lib/service/servicemp3.cpp @@ -734,6 +734,8 @@ RESULT eServiceMP3::stop() gst_element_set_state(m_gst_playbin, GST_STATE_NULL); m_state = stStopped; m_nownext_timer->stop(); + if (m_streamingsrc_timeout) + m_streamingsrc_timeout->stop(); return 0; } --
Attached Files
Re: GStreamer 1.0 #328
Re: GStreamer 1.0 #329
Re: GStreamer 1.0 #330
Posted 20 November 2014 - 14:05
* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.
Re: GStreamer 1.0 #331
Re: GStreamer 1.0 #332
Re: GStreamer 1.0 #333
Re: GStreamer 1.0 #334
Re: GStreamer 1.0 #335
Posted 21 November 2014 - 01:19
While I'm still disappointed that I couldn't convince any Gstreamer Dev's to help out more, I'm so impressed watching the progress you all are making here every day, thank you so much, this is really amazing!
There are two things I would like to understand:
You are now intensively differentiating between different types of files/streams, e.g. packed/unpacked, xvid, etc., which I guess was not the case with gstreamer 0.1. Does this mean that gst 0.1 was handling all this differentiation automagically, or that gst 0.1 was not playing many files correctly with the old servicemp3.cpp etc. ?
You say that many (all?) files play flawlessly now. Do you only mean "play", or are jumping, (re)winding, and slow motion fully functional and smooth as well? Would single stepping frame by frame also be possible?
Re: GStreamer 1.0 #336
Posted 21 November 2014 - 07:32
There are two things I would like to understand:
You are now intensively differentiating between different types of files/streams, e.g. packed/unpacked, xvid, etc., which I guess was not the case with gstreamer 0.1. Does this mean that gst 0.1 was handling all this differentiation automagically, or that gst 0.1 was not playing many files correctly with the old servicemp3.cpp etc. ?
You say that many (all?) files play flawlessly now. Do you only mean "play", or are jumping, (re)winding, and slow motion fully functional and smooth as well? Would single stepping frame by frame also be possible?
Regarding xvid/divx case on GStreamer 0.10 a special handling was performed.
Every unpacked bitstream was packed before.
Now every packed bitstream is unpacked and handled as mpeg4 part 2.
We don't know if above solution is optimal, time will show. Unfortunatelly we don't have access to drivers code and those whith access they do not share informations because of NDA aggrement.
So we have to use the trial and error method
Ofc more people now should try it and the best option is image makers to provide pre beta images for testing..
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916
Re: GStreamer 1.0 #337
Posted 22 November 2014 - 13:00
Looks like there is another issue:
gst-1.4.4 on et4000: When I try to play xvid/divx4,5 packed unpacked from http(s) source, there is either no picture or only some frames will show up. When I play these exact same files from local source there are no issues
gst-0.10 on et4000: remote/local source - no issues
Test files are in post #289:
gst-launch-1.0 playbin uri='https://dl.dropboxusercontent.com/u/38760017/xvid_packed_AS.avi' ...
Re: GStreamer 1.0 #338
Re: GStreamer 1.0 #339
Posted 22 November 2014 - 14:02
@doubledip
root@et4x00:/# uname -a Linux et4x00 3.8.7 #1 Wed Oct 15 00:39:03 CEST 2014 mips GNU/Linux
Update:
1. new frame is only shown after re-buffering or after going from PAUSED state to PLAYING state
2. only difference I can see between local/http(s) pipelines is of course source element and added queue2 element before decodebin in http(s) pipeline
3. If I emulate gst-0.10 pipeline in gst-1.0: remove mpeg4videoparse, set streamtype 10 for xvid, it starts to work.
So it looks like there is some problem when queue2 and mpeg4videoparse are in pipeline.
Attached Files
Re: GStreamer 1.0 #340
Posted 22 November 2014 - 16:31
So it looks like there is some problem when queue2 and mpeg4videoparse are in pipeline.
I think you should report this to core GStreamer developers! You might hit just another issue
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916
Also tagged with one or more of these keywords: gstreamer, 1.0, openpli
DVB subtitles support in eServiceMP3/GStreamerStarted by DimitarCC, 17 Oct 2024 DVB, Subtitles, GStreamer |
|
|||
Change from openvix to openpli - lose existing hdd recordings?Started by xdoktor, 30 Dec 2023 openpli, openvix, hdd, recordings |
|
|||
Having Trouble While Installing This SoftwareStarted by CharleyDavis, 27 Jun 2023 OpenPLi |
|
|||
Faild to flash or update OPENPLIStarted by dede_one, 8 Oct 2022 openpli |
|
|||
hd+ funktioneret nichtStarted by JeppeG, 29 Sep 2022 Vu+, hd+, oscam, openpli |
|
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users