2520 replies to this topic

[peteru]

I was just making a general point based on some of the tests, where you have been constructing specific pipelines with avidemux. If you can specify the right caps in the sink to cause the right nodes to be inserted upstream then all is good.

[mx3L]

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

•  0001-servicemp3-start-HTTP-timeout-timer-only-once.patch   2.32KB   3 downloads

Edited by mx3L, 16 November 2014 - 22:27.

[pieterg]

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.

[mx3L]

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

[athoik]

Maybe we can keep track of state in GST_MESSAGE_STATE_CHANGED or ask current state using gst_element_get_state.

Or check if m_is_live is false.

[pieterg]

Ok, the patch is fine then.

[mx3L]

@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

•  0001-servicemp3-start-HTTP-timeout-timer-only-once2.patch   1.71KB   8 downloads
•  0001-servicemp3-stop-HTTP-timeout-timer-on-Stop.patch   686bytes   6 downloads

[addybo]

is this compatible to 0.10?

[urkagan]

is this compatible to 0.10?

None!!!

[Erik Slagter]

Applied.

[theparasol]

Good news: the hickups for SBS6 uitzendinggemist on my xp1000 have been fixed by the latest patches!

[athoik]

[mx3L]

Applied.

Thanks.

[Anzo]

could it be a nice Christmas present for us?

[Fischreiher]

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?

[athoik]

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..

[mx3L]

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'
...

[doubledip]

Restart your ET4000 and try again. It may be caused by Driver issues since Kernel 3.14.16

[mx3L]

@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

•  gst1.0_https_xvid.READY_PAUSED.dot.txt   29.65KB   2 downloads
•  gst10_filesrc_xvid.READY_PAUSED.dot.txt   28.06KB   2 downloads
•  gst10_like_gst010_https_xvid.READY_PAUSED.dot.txt   27.03KB   2 downloads

[athoik]

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