29 replies to this topic

[kurben]

From this experiment it is very clear where the cause can be found...

Erik, do you know what part of Enigma or drivers the bug is located? Is it totaly dependent on Vu+ code base or something else? 

[mx3L]

Can you post a link to sample of this ts file with AAC-HE?

[kurben]

Here are one recorded clip. This one is containing three audio streams, AAC-HE, AC3 and one for Visual impared.

 

When listening on this clip using VLC for example on your PC, the audio level is correct on both AAC-HE and AC3. But when played back on VU+ box the AAC-HE stream is much lower.

 

https://www.dropbox....Sverige.ts?dl=0

 

If you switch between AAC-HE and AC3 you can hear the droputs. Even on VLC

Edited by kurben, 9 December 2015 - 10:05.

[Erik Slagter]

 

From this experiment it is very clear where the cause can be found...

Erik, do you know what part of Enigma or drivers the bug is located? Is it totaly dependent on Vu+ code base or something else? 

Enigma has no part here.

[mx3L]

I tested your sample.

 

If my hearing is good, I believe I have exactly the same results on et4x00 and vusolose, i.e. sound volume is lower and doesn't sound good for AAC-HE when comparing to AC3 channel, however I didn't notice dropouts.

 

If I rename ".ts" extension to ".mp4" , i.e. gstreamer will be used -> sound is good, it's first sw-decoded to raw stream by gstreamer and then written to decoder.

It's decoded to raw because we are missing "profile" in caps, aacparse doesn't provide it(probably we hit another bug).

 

However removing "profile" from caps is not enough, since stream is in "loas" format and not in "adts". We have to set another bypass, AUDIOTYPE_AAC_HE.

diff --git a/gstdvbaudiosink.c b/gstdvbaudiosink.c
index 43270c3..5b161f0 100644
--- a/gstdvbaudiosink.c
+++ b/gstdvbaudiosink.c
@@ -109,7 +109,11 @@ static guint gst_dvbaudiosink_signals[LAST_SIGNAL] = { 0 };
                "audio/mpeg, " \
                "mpegversion = (int) { 2, 4 }, " \
                "profile = (string) lc, " \
-               "stream-format = (string) { raw, adts, adif, loas }, " \
+               "stream-format = (string) { raw, adts, adif }, " \
+               "framed = (boolean) true; " \
+               "audio/mpeg, " \
+               "mpegversion = (int) { 2, 4 }, " \
+               "stream-format = (string) loas, " \
                "framed = (boolean) true; "
 #else
 #define MPEGCAPS \
@@ -513,6 +517,11 @@ static gboolean gst_dvbaudiosink_set_caps(GstBaseSink *basesink, GstCaps *caps)
                                {
                                        GST_INFO_OBJECT(self, "MIMETYPE %s version %d(AAC-ADTS)", type, mpegversion);
                                }
+                               else if (stream_type && !strcmp(stream_type, "loas"))
+                               {
+                                       bypass = AUDIOTYPE_AAC_HE;
+                                       break;
+                               }
                                else

After this adjustments is stream working in gstreamer exactly as when we us demux as source for decoder -> AAC-HE low volume with comparison to AC3

 

Can you send also SD sample with HE-AAC where your sound is correct?

[kurben]

Will do later this evening.

[kurben]

Here is a recording from a SD channel with AAC-HE audio that has NO problems, the level is alright and no audio dropouts. 

 

https://www.dropbox....dkriget.ts?dl=0

[mx3L]

Thanks

 

If I compare AAC on SD channel with AAC on HD channel, there is no difference:

mediainfo dvbt2_aac_he_hd.ts

Audio #3
ID                                       : 1368 (0x558)
Menu ID                                  : 1360 (0x550)
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : HE-AAC / LC
Muxing mode                              : LATM
Codec ID                                 : 17
Duration                                 : 2mn 14s
Bit rate mode                            : Variable
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 48.0 KHz / 24.0 KHz
Compression mode                         : Lossy
Delay relative to video                  : -338ms
Language                                 : Swedish

mediainfo dvbt2_aac_he_sd.ts

Audio
ID                                       : 3388 (0xD3C)
Menu ID                                  : 3380 (0xD34)
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : HE-AAC / LC
Muxing mode                              : LATM
Codec ID                                 : 17
Duration                                 : 26s 624ms
Bit rate mode                            : Variable
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 48.0 KHz / 24.0 KHz
Compression mode                         : Lossy
Delay relative to video                  : -101ms
Language                                 : Swedish
Encryption                               : TPS-Crypt  or Viaccess

So, we should get same results on both SD and HD channel.
Problem with SD channel is that there is only AAC-HE audio stream, so I cannot really do comparison as with HD channel where AC3 has clearly higher volume.

But generally SD channel with AAC-HE sounds good.

 

I have to correct my statement:

 

If I rename ".ts" extension to ".mp4" , i.e. gstreamer will be used -> sound is good, it's first sw-decoded to raw stream by gstreamer and then written to decoder.

This is not true(mistake in test), SW decoded AAC-HE audio sounds like AAC-HE HW decoded.

 

Can you try to rename ".ts" extension to ".mp4" extension and play AAC-HE, what is the result?

Can you upload also your transcoded file to mp4(where you have normal sound)?

[anudanan]

Would it be possible to add a tiny buffer for (network)-TS-Streams?

My box doesn't have a tuner connected so i need Fallbacktuner/remotechannelconverter.

I have tested streaming with dreambox8000/800SE and Maxdigital XP1000.

Dreambox 8000 and XP1000 suffer from audio drops after switching channels till it finally normalizes and playback is perfectly fine.

Dreambox 800se never has audio drops but stops playback for about 1 second and then plays smoothly.

 

So basically it looks like the client/server needs to "catch up" and then it works flawless, would a buffer help here?

 

 

The problem probably exactly that is what happening. The DVB hardware wants to fill a buffer, but it only gets the stream at "play" rate, at a little delay from earlier buffering. The solution should be sought somewhere else, the stream should be "corked" for a little while before the decoder starts playing. But I am not sure if that's possible.

 

I´ve seen the same when I use RemoteChannel via bouqet from Partnerbox or RemoteChannelStreamConverter. It seems it depends on the hole traffic to the box and the networttraffic (during watching remote stream from remote tuner some movies from local tuners are recording to the hdd and some people are watching movies from the hdd over the network). After some dropouts (in the first minute) the stream from the remote tuner if fine with no dropsouts. So I think the jitterbuffer adjusts itself after dataunderrun. When I switch to an other channel on the remote tuner then the same situation. After nearly a minute the dropouts are not there.

 

Is it possible to set the initial fill rate of the buffer higher than today (config file, setup parameter, python source or ?) so that the first drops are not there? I Know the stream from the remote tuner starts  then with his first picture a little time later but that it ok for me if no dropout are there.

Edited by anudanan, 28 January 2016 - 08:00.

[Erik Slagter]

No, we have no influence on the buffer inside the DVB-subsystem.