Jump to content


Photo

GStreamer 1.0

gstreamer 1.0 openpli

  • Please log in to reply
2520 replies to this topic

Re: GStreamer 1.0 #321 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 16 November 2014 - 07:17

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.

"Beauty lies in the hands of the beer holder."

 


Re: GStreamer 1.0 #322 mx3L

  • Senior Member
  • 616 posts

+79
Good

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 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 16 November 2014 - 23:05

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.



Re: GStreamer 1.0 #324 mx3L

  • Senior Member
  • 616 posts

+79
Good

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 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 16 November 2014 - 23:49

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.
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: GStreamer 1.0 #326 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 17 November 2014 - 08:07

Ok, the patch is fine then.

Re: GStreamer 1.0 #327 mx3L

  • Senior Member
  • 616 posts

+79
Good

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 addybo

  • Senior Member
  • 45 posts

0
Neutral

Posted 18 November 2014 - 13:20

is this compatible to 0.10?



Re: GStreamer 1.0 #329 urkagan

  • Member
  • 2 posts

0
Neutral

Posted 18 November 2014 - 14:57

is this compatible to 0.10?

None!!!



Re: GStreamer 1.0 #330 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 20 November 2014 - 14:05

Applied.

* 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 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 20 November 2014 - 22:03

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


@Camping: ZGemma H.2S, Technisat Multytenne 4-in-1 @Home: Edision Mini 4K, Wave Frontier T55, EMP Centauri EMP DiSEqC 8/1 switch, 4x Inverto Ultra Black single LNB


Re: GStreamer 1.0 #332 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 20 November 2014 - 22:09

;)
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: GStreamer 1.0 #333 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 20 November 2014 - 22:49

Applied.

Thanks.



Re: GStreamer 1.0 #334 Anzo

  • Senior Member
  • 313 posts

+5
Neutral

Posted 20 November 2014 - 23:04

could it be a nice Christmas present for us?


Groet, André

:blink:


Re: GStreamer 1.0 #335 Fischreiher

  • Senior Member
  • 26 posts

+2
Neutral

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 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

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..
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: GStreamer 1.0 #337 mx3L

  • Senior Member
  • 616 posts

+79
Good

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 doubledip

  • Senior Member
  • 334 posts

+7
Neutral

Posted 22 November 2014 - 13:28

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



Re: GStreamer 1.0 #339 mx3L

  • Senior Member
  • 616 posts

+79
Good

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 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

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 ;)
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



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users