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 #1001 mika-nl

  • Senior Member
  • 454 posts

+10
Neutral

Posted 9 April 2015 - 21:29

Yes, have respect ! it is nice people wil put free time in it to make it beter.

christophecvt proof also gst1 wil work on vu-duo after people tell him that it wil not work

I think it is beter to discus

 

Maybe a usb-dac can make a better sound when playing mp3 / flac from a stb ?

i personal was looking for pimusicbox or Volumio

 

Re: GStreamer 1.0 #1002 gorski

  • Senior Member
  • 1,699 posts

+46
Good

Posted 9 April 2015 - 21:39

Guys, for what it's worth... I studied phonetics.

 

Our hearing is not that great. Full stop. (Great big) Most of us can't hear 20 or 20K Hz - it's beyond our capacities. We are bombarded every day with way too much noise and our hearing suffers, plus normal ageing, illnesses and so on.

 

What we can hear is better dynamics in newer technology (from various sound bearers/carriers and players to cables and speakers) and considerably less noise (better noise to sound ratio). But not much in terms of being like dogs, cats or bats....

 

Well, if occasionally there is a human with hyper-sensitive hearing - fine... However, most of us are not that sensitive.

 

Chris, you may be generally hyper :D and that seems good in terms of it driving you to achieve! That is good, from what I can see, as it seemed to have pushed this whole thing forward! Great!

 

But on this issue you are not really in tune with science.

 

Malakudi's science is not his own. End of. He repeated what he read. And I tested it in labs of ZG University, Philosophical Faculty, SUVAG school. I was tested, too, on my request. I have a fairly good idea about all that. Plus, I am a musician. Have a good system at home. But what you are saying is a bit hyper. Really. Relax. And try testing yourself in a properly scientific, double blind :D manner... Friends can help. ;)

 

That is if you do not trust the rest of us, who have a proper training in the field and some knowledge and experience...

 

But keep on pushing with Gstreamer, please! It has been a delight seeing you learn and push and push and improve and...

 

We salute athoik and you and all the rest! And especially you since you are kicking arse against the conservative impulse of OpenPLi in this matter... (I repeat: in this matter! Not in everything!)

 

Keep on rocking! And leave this issue be, please. It's getting into the realm of belief. Unless you actually test yourself in proper conditions, in terms of what you can really hear, in a lab. All else is BS, trust me. And that's from somebody who likes what he sees you do, OK? (Never mind that I am a lay person when it comes to coding... :D )

 

Stay well and chillax a bit (on this issue), please..... ;) :)


Edited by gorski, 9 April 2015 - 21:42.

<span style='font-family: comic sans ms,cursive'>"Enlightenment is man's emergence from his self-incurred immaturity. Immaturity is the inability to use one's own understanding without the guidance of another. This immaturity is self-incurred if its cause is not lack of understanding, but lack of resolution and courage to use it without the guidance of another. The motto of enlightenment is therefore: Sapere aude! Have courage to use your own understanding!</span><br /> <br /><span style='font-family: comic sans ms,cursive'>Laziness and cowardice are the reasons why such a large proportion of men, even when nature has long emancipated them from alien guidance..." I. Kant, "Political writings" (1784)</span><br /> <br /><span style='font-family: comic sans ms,cursive'><a class='bbc_url' href='<a class='bbc_url' href='http://eserver.org/p...lightenment.txt'>http://eserver.org/p...ent.txt</a>'><a class='bbc_url' href='http://www.english.upenn.edu/~mgamer/Etexts/kant.html</a>'>http://www.english.upenn.edu/~mgamer/Etexts/kant.html</a></a> - the jolly text on Enlightenment, at the basis of Modernity...</span>

Re: GStreamer 1.0 #1003 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 9 April 2015 - 22:16

You are all right. Concentrate on the real problems.

 

One major which kept me now bussy for more the three weeks. Is that bloddy start delay off audio when the dtsdownmix is needed.  For the dreamboxes. Not the vuduo as this box do not need this downmix and work perfectly well in all cases now with gst-1.0.

 

I do not know if other boxes then dreambox need this downmix.

 

Which I find out is that video starts ok audio starts ok. No problem there. But kernels thinks (and its really thinks' as it is not like that) That video is not ready yet (in despit the fact that it is really already playing). as a consequence it ignores the first PTS. then everythings screws. The video stays playing and audio does resync but it takes time about 10 to 60 seconds.n It flushes stops flush. Then it restart audio unitil a sync pts is found with the video once found all ok audio plays. But with high vq streams where frames needed to be cut in two. It may sync with the second frame while video is at the first. Then audio plays with just one frame out of sync. While the rest find it nice in sync. Weird yess.

 

Analyzing now the more detailed outputs enigma2 log with the merged at playtime gst_debug or info level log (I added special debugs outputs info level to avoid having to go in deeper debug mode to highlight the specific problem whitout not relevant debug ouputs for this problem). And yes clearly can be seen that the audio always starts just before video. While it should be just the oposed.

 

Any hint as for how to solve this issue would be nice. Some boxes do catch this up with driver. And we are really speaking about a fraction in time around ms even just below ms. But whit a huge consequence.



Re: GStreamer 1.0 #1004 Rob van der Does

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 10 April 2015 - 06:57

I'm now running a GStreamer 1.4 image on my DUO2 and I noticed that one (for me) major issue, that has hampered the use of the DUO2 since it was born, has been fixed: jumping back 30s after resuming playback now actually works.

 

Thanks to all involved!


Edited by SatKiekerd, 10 April 2015 - 06:58.


Re: GStreamer 1.0 #1005 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 10 April 2015 - 09:47

You are all right. Concentrate on the real problems.

 

One major which kept me now bussy for more the three weeks. Is that bloddy start delay off audio when the dtsdownmix is needed.  For the dreamboxes. Not the vuduo as this box do not need this downmix and work perfectly well in all cases now with gst-1.0.

 

I do not know if other boxes then dreambox need this downmix.

 

Which I find out is that video starts ok audio starts ok. No problem there. But kernels thinks (and its really thinks' as it is not like that) That video is not ready yet (in despit the fact that it is really already playing). as a consequence it ignores the first PTS. then everythings screws. The video stays playing and audio does resync but it takes time about 10 to 60 seconds.n It flushes stops flush. Then it restart audio unitil a sync pts is found with the video once found all ok audio plays. But with high vq streams where frames needed to be cut in two. It may sync with the second frame while video is at the first. Then audio plays with just one frame out of sync. While the rest find it nice in sync. Weird yess.

 

Analyzing now the more detailed outputs enigma2 log with the merged at playtime gst_debug or info level log (I added special debugs outputs info level to avoid having to go in deeper debug mode to highlight the specific problem whitout not relevant debug ouputs for this problem). And yes clearly can be seen that the audio always starts just before video. While it should be just the oposed.

 

Any hint as for how to solve this issue would be nice. Some boxes do catch this up with driver. And we are really speaking about a fraction in time around ms even just below ms. But whit a huge consequence.

 

Maybe you could try to set our sinks to operate in sync mode and let the basessink do the synchronization of video/audio buffers against clock. I tested it and after seeking video is now immediately with audio.

diff --git a/gstdvbaudiosink.c b/gstdvbaudiosink.c
index 2b87caa..dc71400 100644
--- a/gstdvbaudiosink.c
+++ b/gstdvbaudiosink.c
@@ -314,8 +314,8 @@ static void gst_dvbaudiosink_init(GstDVBAudioSink *self)
 	self->rate = 1.0;
 	self->timestamp = GST_CLOCK_TIME_NONE;
 
-	gst_base_sink_set_sync(GST_BASE_SINK(self), FALSE);
-	gst_base_sink_set_async_enabled(GST_BASE_SINK(self), TRUE);
+	gst_base_sink_set_sync(GST_BASE_SINK(self), TRUE);
+	gst_base_sink_set_async_enabled(GST_BASE_SINK(self), FALSE);
 }
 
 static gint64 gst_dvbaudiosink_get_decoder_time(GstDVBAudioSink *self)
@@ -895,6 +895,7 @@ static gboolean gst_dvbaudiosink_event(GstBaseSink *sink, GstEvent *event)
 				self->rate = rate;
 			}
 		}
+		ret = GST_BASE_SINK_CLASS(parent_class)->event(sink, event);
 		break;
 	}
 	case GST_EVENT_CAPS:
diff --git a/gstdvbvideosink.c b/gstdvbvideosink.c
index fbebd11..694e823 100644
--- a/gstdvbvideosink.c
+++ b/gstdvbvideosink.c
@@ -350,8 +350,8 @@ static void gst_dvbvideosink_init(GstDVBVideoSink *self)
 	self->saved_fallback_framerate[0] = 0;
 	self->rate = 1.0;
 
-	gst_base_sink_set_sync(GST_BASE_SINK(self), FALSE);
-	gst_base_sink_set_async_enabled(GST_BASE_SINK(self), TRUE);
+	gst_base_sink_set_sync(GST_BASE_SINK(self), TRUE);
+	gst_base_sink_set_async_enabled(GST_BASE_SINK(self), FALSE);
 }
 
 static gint64 gst_dvbvideosink_get_decoder_time(GstDVBVideoSink *self)
@@ -510,6 +510,7 @@ static gboolean gst_dvbvideosink_event(GstBaseSink *sink, GstEvent *event)
 				self->rate = rate;
 			}
 		}
+		ret = GST_BASE_SINK_CLASS(parent_class)->event(sink, event);
 		break;
 	}
 	case GST_EVENT_CAPS:


Re: GStreamer 1.0 #1006 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 10 April 2015 - 10:08

This is interesting testing work. On what brands/models did you test this? Can some of you also test on other models or even better, brands? IIRC the non-sync mode was a hack to get things working on DMM receivers. I guess pieterg can tell the details.


Edited by Erik Slagter, 10 April 2015 - 10:08.

* 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 #1007 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 10 April 2015 - 10:13

xtrend et4000



Re: GStreamer 1.0 #1008 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 10 April 2015 - 11:06

non-sync is needed because a/v are not synced by gstreamer, but by the drivers. (gstreamer does not handle the playback, so it cannot keep a/v in sync by itself)
There is a huge buffer in between, and gstreamer should try to keep both a and v buffers filled at all times, instead of slowing either a or v down in order to keep them sync.

Using sync might seem to speed up the av-sync recovery, because the video decoder buffer will underflow, and the a/v decoders will try to re-sync as soon as new data arrives.

But in the long run sync mode will be worse, I expect a lot of buffer underruns (especially for video)



Re: GStreamer 1.0 #1009 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 10 April 2015 - 11:23

Thanks for the explanation.


* 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 #1010 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 10 April 2015 - 11:37

@mx3L

 

Great Great Great.

 

Problem solved .

 

And the worst is that this was one of the first things a tried out. But like stupid fool I forgot to add the sync to gstdvbvideo.c and only did gstdvbaudiosink.c

 

The video now is even in perfect sink with image. Always. Before we had that bloody delay and in 1 out off 5 times the audio finally started but out off sink.

 

Wish I could give You +100 there



Re: GStreamer 1.0 #1011 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 10 April 2015 - 12:14

Unfortunately indeed video drops out after a while. Not the solution.



Re: GStreamer 1.0 #1012 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 10 April 2015 - 12:46

Maybe this helps?

The following patch was "forgotten".

I guess according to the comment: default blocksize is only 4096 we neeed to feed hardware decoder with more data

http://gstreamer.fre...eSrc--blocksize

diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp
index 7bfc989..298f6dc 100644
--- a/lib/service/servicemp3.cpp
+++ b/lib/service/servicemp3.cpp
@@ -2014,6 +2014,11 @@ void eServiceMP3::playbinNotifySource(GObject *object, GParamSpec *unused, gpoin
        g_object_get(object, "source", &source, NULL);
        if (source)
        {
+               if (g_object_class_find_property(G_OBJECT_GET_CLASS(source), "blocksize") != 0)
+               {
+                       /* default blocksize is only 4096 we neeed to feed hardware decoder with more data */
+                       g_object_set(G_OBJECT(source), "blocksize", 16*1024, NULL);
+               }
                if (g_object_class_find_property(G_OBJECT_GET_CLASS(source), "ssl-strict") != 0)
                {
                        g_object_set(G_OBJECT(source), "ssl-strict", FALSE, NULL);
I really don't remember what I was testing ... Most probably to improve streaming performance :P

Please test it and if you find that improves streaming, report it, in order to be pushed ...

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 #1013 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 10 April 2015 - 13:06

I don't know about other brands, but on the Beyonwiz hardware we have A/V buffers for the decode pipeline that would be closer to a MB - enough for several seconds.


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

 


Re: GStreamer 1.0 #1014 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 10 April 2015 - 13:19

I guess I should clarify. That is the maximum buffer size. You should not try to fill up the buffer with that much data in one operation - that would just screw up the data flow. However, you should be able to get away with feeding the pipeline with chunks that are bigger than 4k or 16k if you want to reduce the overhead of all the userspace/kernelspace switches that are associated with driver I/O.


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

 


Re: GStreamer 1.0 #1015 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 10 April 2015 - 13:30

if you make the chunks too big, audio (especially with low bitrates) might drain.

Smaller chunks is better for a continuous flow.

 

I think using pagesize chunks is optimal.



Re: GStreamer 1.0 #1016 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 10 April 2015 - 18:22

@christophecvr see porting-to-1.0.txt because I see adding deprecated code back.

GST_BUFFER_TIMESTAMP is gone, use GST_BUFFER_PTS or GST_BUFFER_DTS instead. Likewise GST_BUFFER_TIMESTAMP_IS_VALID() was changed to GST_BUFFER_PTS_IS_VALID and GST_BUFFER_DTS_IS_VALID

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 #1017 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 10 April 2015 - 20:46

Ye I know that . (so it was but will change it in one off next revs.)



Re: GStreamer 1.0 #1018 Rob van der Does

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 11 April 2015 - 02:48

With the new VU HbbTV plugin (see http://code.vuplus.c...90ec69982f11185 ) HbbTV now also works on GStreamer 1.4 images (tested on Ultimo).



Re: GStreamer 1.0 #1019 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 11 April 2015 - 08:27

It's not yet in our bsp.


* 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 #1020 malakudi

  • Senior Member
  • 1,449 posts

+69
Good

Posted 11 April 2015 - 11:10

The changelog mentions "support gstreamer-1.0 (1.5.4)". I guess they just misplaced 4 with 5 since there is only gstreamer 1.4.5





4 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users


    Bing (1), Google (1)