2520 replies to this topic

[mika-nl]

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

 

[gorski]

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

 

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

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

[christophecvr]

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.

[Rob van der Does]

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.

[mx3L]

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:

[Erik Slagter]

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.

[mx3L]

xtrend et4000

[pieterg]

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)

[Erik Slagter]

Thanks for the explanation.

[christophecvr]

@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

[christophecvr]

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

[athoik]

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

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

[peteru]

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.

[peteru]

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.

[pieterg]

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.

[athoik]

@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

[christophecvr]

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

[Rob van der Does]

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

[Erik Slagter]

It's not yet in our bsp.

[malakudi]

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