Jump to content


mx3L

Member Since 16 Jan 2013
Offline Last Active 09 Oct 2017 18:28
*****

#514855 GStreamer 1.0

Posted by mx3L on 19 November 2015 - 14:45

 What I do not understand is that you "play" with (a)sync in gstreamer while in fact "behind" gestreamer the hardware buffer (and driver) guaranteed messed up with the "buffer".... So I do not understand how this could fix the pauze performance....???? How does it work-a-round that hardware (driver) buffer???

There is no workaround hardware (driver) buffer. When doing unpause in servicemp3 we are doing flush seek to current position.

flush seek to current position:

 1. discards buffers in pipeline + discards buffers in driver buffer

 2. source is set to current position, new buffers starts to flow through pipeline into sink and driver buffer.

 

I suggest to not to do flush seek to current position when unpause, but only unpause pipeline. There is no need to discard valid buffers, we just need to continue to push buffers to driver buffer after unpause.

 

With this said it should be now clear why it improves unpause performance, i.e we don't have to re-fill pipeline after flush seek with new buffers, but seamlessly continue in playback.
This is done in servicemp3 patch + fallback to flush seek to current position, in case pipeline is not in valid state or unpause is not used on supported sources.

 

but I still do not understand why the latest commit suggestion should solve it.... (it might be I miss the clue)

When we pause pipeline, sometimes happens that it's afterwards not in valid state. We cannot unpause pipeline from not valid state.
Not valid state means, that it's not in PAUSED state and has pending state set to PAUSED, which needs to be commited first, in order for state to be valid.

 

State of pipeline is defined by it's elements. I found out that problematic element which causes this state is dvbaudiosink. dvbaudiosink is in this state, because it waits for preroll buffer, which never comes.

By turning off async state changes in dvbaudiosink, we make sure that it will never get into this state, because it will no longer care when this preroll buffer comes, but will commit new state immediately. -> pipeline should be always in valid state when unpausing, i.e. fallback option to flush seek to current position, will be not used.

 

http://gstreamer.fre...t-async-enabled

Configures sink to perform all state changes asynchronously. When async is disabled, the sink will immediately go to PAUSED instead of waiting for a preroll buffer. This feature is useful if the sink does not synchronize against the clock or when it is dealing with sparse streams.

 

Summary:
servicemp3 patch:

 

should be enough, but when unpausing it sometimes fallbacks to flush seek to current position, when pipeline is not in valid state.

If this happens on Vu+ it sometimes triggers some kind of bug, which causes to stop video rendering and only audio can be heared, while A/V buffers are flowing to sinks but are far apart(pts).

async patch:

 

makes sure that we have pipeline always in valid state after pause, so no fallback to flush seek to current position happens -> always seamless unpause, assumed Vu+ bug in drivers is not triggered.

 

Patches were tested on et4x00, vusolose and vuduo2(@christophecvr)




#514821 GStreamer 1.0

Posted by mx3L on 19 November 2015 - 08:20

That is not true.... we need to better understand why this might work... as far I know there is a hardware buffer behind... So doing sync stuff in gstreamer should not have any effect on this behavior....

 

We just need a better clarification/description!

Hi,

 

Which patch needs more clarification?

dvbaudiosink patch: https://github.com/O...ediasink/pull/5

,servicemp3 patch: https://github.com/O...nigma2/pull/100

or both?

 

Is there anything specific what's not clear or most of it?

 

I tried to do some explanation in here:

http://forums.openpl...e-improvements/.

 

But I can try to clarify it even more if neccessary.




#512179 gstreamer1.0 and mpeg4-part2

Posted by mx3L on 5 November 2015 - 08:19

mpeg4-part2 is video-compression format standard, it's implemented by divx4,5,6, xvid, 3ivx, etc.. codecs.

 

-> we should be able to handle divx4,5,6, xvid as mpeg4-part2 in our dvbmediasink.

It's not the case, we are differentiating between this implementations, and informing decoder what it gets on input with streamtypes like STREAMTYPE_DIVX5, STREAMTYPE_DIVX4, STREAMTYPE_XVID.

 

In gstreamer 0.10 this worked quite well, since we could differentiate between this implementations, because xvid caps were still pass around.

In gstreamer 1.0 this became problem, since there are no xvid caps anymore(https://bugzilla.gno...g.cgi?id=739196), so we had to patch gstreamer in order to provide them.

 

To avoid all this problems, we can use STREAMTYPE_MPEG4-Part2 for every mpeg4-part2 implementation.

 

Decoder expectations for STREAMTYPE_MPEG4-Part2:

- PTS timestamps set for every frame (except xtrends, they only need PTS on keyframes)

- unpacked bitstream

 

PTS:

problem is that gstreamer demuxers/parsers set PTS only on keyframes(I) for mpeg4-part2

 

We can compute PTS from DTS like this:

https://software.int...ift_explain.gif

 

Unpacked bitstream:

Description of problem - https://bugzilla.gno...g.cgi?id=740015

 

Correct unpacking routine can be found here:

http://git.videolan....k_bframes_bsf.c

 

Solution:

- added unpacking of packed bitstream

- added PTS from DTS computation

 

pros:

- no need to patch gstreamer anymore

- possible to remove divx,xvid specific code from dvbmediasink

- fixed problems with videos with invalid metadata (wrong fourcc, marked as packed when not packed...)

 

cons:

- slightly higher load when unpacking and computing

- ...

git - https://github.com/m.../test_mpeg4p2_4

 

Testing:

In order to get this applied to dvbmediasink we need to do extensive testing

 

Some test files:

http://forums.openpl...-19#entry461035

 

All tested and works correctly on et4x00, vusolose, dm800se

 

In case you find some mpeg4-part2 which doesn't work, please post here link to sample

so we can test it.

 

PS:

Thanks to @athoik for tests on dm800se and suggestions




#505210 Physical CD/DVD support enigma2.

Posted by mx3L on 16 September 2015 - 10:45

Good to hear :)

 

gst_base_sink_set_blocksize function cannot have any effect, since it is used only when sink operates in pull mode, which is not.




#505174 Physical CD/DVD support enigma2.

Posted by mx3L on 16 September 2015 - 06:03

It looks to me that you're working with raw audio stream, if that's the case then dvbaudiosink has already sync enabled - http://forums.openpl...indpost&p=50447.

Perhaps you should try to turn it off.




#505086 GStreamer 1.0

Posted by mx3L on 15 September 2015 - 16:37

Hi,

 

Just found out that every raw audio is played by dvbaudiosink with enabled synchronization!

 

When decodebin tries to create decode chain for example for wav audio, it will not find dvbaudiosink as last element of chain, but it finds wavparse element, since it provides raw caps on src pad and decode chain is then finished:

GST_DEBUG_FILE=/tmp/waw_autoaudiosink_sync_true.log GST_DEBUG_NO_COLOR=1 GST_DEBUG=decodebin:6,autodetect:6,playbin:6,playsink:6,dvbaudiosink:5,basesink:6 gst-launch-1.0 playbin uri=file:///media/net/DOMA/Test/24bit_44kHz_
Brake5.wav
0:00:01.647201037  1888 0x763335b0 DEBUG              decodebin gstdecodebin2.c:2834:pad_added_cb:<wavparse0:src> pad added, chain:0x4fe9b0
0:00:01.647676481  1888 0x763335b0 DEBUG              decodebin gstdecodebin2.c:1499:analyze_new_pad:<decodebin0> Pad wavparse0:src caps:audio/x-raw, format=(string)S24LE, layout=(string)interleaved, channels=(int)2, channel-mask=(bitma
sk)0x0000000000000003, rate=(int)44100
0:00:01.659665999  1888 0x763335b0 DEBUG                playbin gstplaybin2.c:4490:autoplug_continue_cb:<playbin0> continue autoplugging group 0x4f9f20 for '':decodepad0, audio/x-raw, format=(string)S24LE, layout=(string)interleaved, ch
annels=(int)2, channel-mask=(bitmask)0x0000000000000003, rate=(int)44100: 1
0:00:01.660832777  1888 0x763335b0 DEBUG              decodebin gstdecodebin2.c:1351:gst_decode_bin_autoplug_continue:<decodebin0> autoplug-continue returns TRUE
0:00:01.661163999  1888 0x763335b0 LOG                decodebin gstdecodebin2.c:3042:are_final_caps:<decodebin0> Checking with caps audio/x-raw, format=(string)S24LE, layout=(string)interleaved, channels=(int)2, channel-mask=(bitmask)0x
0000000000000003, rate=(int)44100
0:00:01.661902703  1888 0x763335b0 LOG                decodebin gstdecodebin2.c:3049:are_final_caps:<decodebin0> Caps are final caps
0:00:01.662169259  1888 0x763335b0 LOG                decodebin gstdecodebin2.c:1791:analyze_new_pad:<decodebin0> Pad is final. autoplug-continue:1

If that happens then playsink is used for creation of sink element, which creates dvbaudiosink by using autoaudiosink, which sets sync setting to TRUE for dvbaudiosink after we initially set it to FALSE in NULL state:

0:00:01.720812074  1888 0x763335b0 DEBUG               playsink gstplaysink.c:3259:gst_play_sink_do_reconfigure:<playsink> audio:1, video:0, vis:0, text:0
0:00:01.721144925  1888 0x763335b0 DEBUG               playsink gstplaysink.c:3393:gst_play_sink_do_reconfigure:<playsink> no video needed
0:00:01.721435740  1888 0x763335b0 DEBUG               playsink gstplaysink.c:3460:gst_play_sink_do_reconfigure:<playsink> adding audio
0:00:01.721796518  1888 0x763335b0 DEBUG               playsink gstplaysink.c:3515:gst_play_sink_do_reconfigure:<playsink> creating new audio chain
0:00:01.722069036  1888 0x763335b0 DEBUG               playsink gstplaysink.c:2668:gen_audio_chain:<playsink> making audio chain 0x53cf88
0:00:01.722326222  1888 0x763335b0 DEBUG               playsink gstplaysink.c:2677:gen_audio_chain:<playsink> trying autoaudiosink
0:00:01.736406259  1888 0x763335b0 DEBUG             autodetect gstautodetect.c:369:gst_auto_detect_detect:<audiosink> Creating new kid
0:00:01.743965148  1888 0x763335b0 LOG               autodetect gstautodetect.c:277:gst_auto_detect_find_best:<audiosink> Trying to find usable audio elements ...
0:00:01.752318962  1888 0x763335b0 DEBUG             autodetect gstautodetect.c:286:gst_auto_detect_find_best:<audiosink> Testing dvbaudiosink
0:00:01.755005703  1888 0x763335b0 DEBUG             autodetect gstautodetect.c:296:gst_auto_detect_find_best:<audiosink> Checking caps: audio/x-raw vs. audio/mpeg, mpegversion=(int)1, layer=(int)[ 1, 3 ], parsed=(boolean)true; audio/mp
eg, mpegversion=(int){ 2, 4 }, profile=(string)lc, stream-format=(string){ raw, adts, adif, loas }, framed=(boolean)true; audio/x-ac3, framed=(boolean)true; audio/x-private1-ac3, framed=(boolean)true; audio/x-eac3, framed=(boolean)true;
 audio/x-private1-eac3, framed=(boolean)true; audio/x-private1-lpcm; audio/x-wma; audio/x-raw, format=(string){ S32LE, S24LE, S16LE, S8, U32LE, U24LE, U16LE, U8 }, layout=(string){ interleaved, non-interleaved }, rate=(int)[ 1, 48000 ],
 channels=(int)[ 1, 2 ]
0:00:01.756792592  1888 0x763335b0 DEBUG             autodetect gstautodetect.c:305:gst_auto_detect_find_best:<audiosink> Found compatible caps
0:00:01.757201888  1888 0x763335b0 DEBUG           dvbaudiosink gstdvbaudiosink.c:1525:gst_dvbaudiosink_change_state:<audiosink-actual-sink-dvbaudio> GST_STATE_CHANGE_NULL_TO_READY
0:00:01.757455111  1888 0x763335b0 DEBUG           dvbaudiosink gstdvbaudiosink.c:1423:gst_dvbaudiosink_start:<audiosink-actual-sink-dvbaudio> start
0:00:01.759019925  1888 0x763335b0 DEBUG             autodetect gstautodetect.c:312:gst_auto_detect_find_best:<audiosink> This worked!
0:00:01.759296222  1888 0x763335b0 DEBUG             autodetect gstautodetect.c:328:gst_auto_detect_find_best:<audiosink> done trying
0:00:01.760956259  1888 0x763335b0 DEBUG             autodetect gstautodetect.c:391:gst_auto_detect_detect:<audiosink> Re-assigning ghostpad
0:00:01.761625666  1888 0x763335b0 DEBUG             autodetect gstautodetect.c:396:gst_auto_detect_detect:<audiosink> done changing auto audio sink

It's not possible to see setup of sync property in debug, you can look in sources of gstautodetect.c(function gst_auto_detect_detect, 360 line) or you can see it in in basesink debug, when we synchronize in gst_base_sink_wait_clock:

0:00:04.438940886  1915   0x512320 DEBUG               basesink gstbasesink.c:3401:gst_base_sink_chain_unlocked:<audiosink-actual-sink-dvbaudio> got times start: 0:00:02.200000000, end: 0:00:02.240000000
0:00:04.439385108  1915   0x512320 DEBUG               basesink gstbasesink.c:1950:gst_base_sink_get_sync_times:<audiosink-actual-sink-dvbaudio> got times start: 0:00:02.200000000, stop: 0:00:02.240000000, do_sync 1
0:00:04.439879034  1915   0x512320 LOG                 basesink gstbasesink.c:2487:gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> avg frame diff 0:00:00.040000000
0:00:04.440212071  1915   0x512320 DEBUG               basesink gstbasesink.c:2527:gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> reset rc_time to time 0:00:02.200000000
0:00:04.440493627  1915   0x512320 DEBUG               basesink gstbasesink.c:2539:gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> possibly waiting for clock to reach 0:00:02.200000000, adjusted 0:00:02.200000000
0:00:04.440956627  1915   0x512320 LOG                 basesink gstbasesink.c:2121:gst_base_sink_wait_clock:<audiosink-actual-sink-dvbaudio> time 0:00:02.200000000, base_time 113:44:16.392776500
0:00:04.473878701  1915   0x512320 DEBUG               basesink gstbasesink.c:2546:gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> clock returned 0, jitter -0:00:00.032223298
0:00:04.474251256  1915   0x512320 DEBUG               basesink gstbasesink.c:2865:gst_base_sink_is_too_late:<audiosink-actual-sink-dvbaudio> object was scheduled in time
0:00:04.474469256  1915   0x512320 DEBUG               basesink gstbasesink.c:3501:gst_base_sink_chain_unlocked:<audiosink-actual-sink-dvbaudio> rendering object 0x5a7c08
0:00:04.474699701  1915   0x512320 DEBUG               basesink gstbasesink.c:946:gst_base_sink_set_last_buffer_unlocked:<audiosink-actual-sink-dvbaudio> setting last buffer to 0x5a7c08
0:00:04.476496775  1915   0x512320 DEBUG               basesink gstbasesink.c:3547:gst_base_sink_chain_unlocked:<audiosink-actual-sink-dvbaudio> object unref after render 0x5a7c08

If we don't synchronize it looks like this(look gst_base_sink_wait_clock):

GST_DEBUG_FILE=/tmp/waw_dvbaudiosink_sync_false.log GST_DEBUG_NO_COLOR=1 GST_DEBUG=decodebin:6,autodetect:6,playbin:6,playsink:6,dvbaudiosink:5,basesink:6 gst-launch-1.0 playbin uri=file:///media/net/DOMA/Test/24bit_44kHz_
Brake5.wav audio-sink="dvbaudiosink"
0:00:02.989006664  1922   0x515350 DEBUG               basesink gstbasesink.c:3401:gst_base_sink_chain_unlocked:<dvbaudiosink0> got times start: 0:00:03.520000000, end: 0:00:03.560000000
0:00:02.989405220  1922   0x515350 DEBUG               basesink gstbasesink.c:1950:gst_base_sink_get_sync_times:<dvbaudiosink0> got times start: 0:00:03.520000000, stop: 0:00:03.560000000, do_sync 1
0:00:02.989903776  1922   0x515350 LOG                 basesink gstbasesink.c:2487:gst_base_sink_do_sync:<dvbaudiosink0> avg frame diff 0:00:00.040000000
0:00:02.990242220  1922   0x515350 DEBUG               basesink gstbasesink.c:2527:gst_base_sink_do_sync:<dvbaudiosink0> reset rc_time to time 0:00:03.520000000
0:00:02.990517590  1922   0x515350 DEBUG               basesink gstbasesink.c:2539:gst_base_sink_do_sync:<dvbaudiosink0> possibly waiting for clock to reach 0:00:03.520000000, adjusted 0:00:03.520000000
0:00:02.990979887  1922   0x515350 DEBUG               basesink gstbasesink.c:2167:gst_base_sink_wait_clock:<dvbaudiosink0> sync disabled
0:00:02.991205442  1922   0x515350 DEBUG               basesink gstbasesink.c:2546:gst_base_sink_do_sync:<dvbaudiosink0> clock returned 4, jitter  0:00:00.000000000
0:00:02.991485887  1922   0x515350 DEBUG               basesink gstbasesink.c:3501:gst_base_sink_chain_unlocked:<dvbaudiosink0> rendering object 0x575ad8
0:00:02.991840590  1922   0x515350 DEBUG               basesink gstbasesink.c:946:gst_base_sink_set_last_buffer_unlocked:<dvbaudiosink0> setting last buffer to 0x575ad8
0:00:02.992983701  1922   0x515350 DEBUG               basesink gstbasesink.c:3547:gst_base_sink_chain_unlocked:<dvbaudiosink0> object unref after render 0x575ad8

It also triggered this resolved problem with preroll lock, which wouldn't happen if sync was turned off:

http://forums.openpl...-34#entry480811

 

So we should make sure that sync is disabled, currently is sync set in NULL state, for example we can postpone it as late as possible, just before rendering, when going from READY to PAUSED state:

diff --git a/gstdvbaudiosink.c b/gstdvbaudiosink.c
index 2b87caa..82d4167 100644
--- a/gstdvbaudiosink.c
+++ b/gstdvbaudiosink.c
@@ -314,7 +314,6 @@ static void gst_dvbaudiosink_init(GstDVBAudioSink *s
elf)
 	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);
 }
 
@@ -1515,6 +1514,7 @@ static GstStateChangeReturn gst_dvbaudiosink_chang
e_state(GstElement *element, G
 		break;
 	case GST_STATE_CHANGE_READY_TO_PAUSED:
 		GST_DEBUG_OBJECT(self,"GST_STATE_CHANGE_READY_TO_PAUSED");
+		gst_base_sink_set_sync(GST_BASE_SINK(self), FALSE);
 		self->paused = TRUE;
 
 		if (self->fd >= 0)




#501301 AAC to AC3 transcoding

Posted by mx3L on 15 August 2015 - 21:44

Many AV-receivers cannot decode AAC streams when AAC passthrough is supported. This means that it's not possible to hear multichannel AAC.

To improve this situation I've created simple aactranscode gstreamer plugin which transcodes AAC to AC3 and passes it to dvbaudiosink.

 

There is no dowmixing so you've all channels in AC3 as in AAC, however price is degraded quality, since AAC and AC3 are both lossy codecs

 

How it works:

- aactranscode is sink bin which consist's of connected aac decoder, audioconvert, audioresample, ac3encoder and dvbaudiosink elements.

- aactranscode accepts only AAC caps, which means that it's selected only for AAC audio, however rank of aactranscode is lower then dvbaudiosink, so dvbaudiosink has to also not add AAC caps for aactranscode to be selected

- dvbaudiosink knows when to not include AAC caps by reading /etc/gstreamer/aactranscode file, if it contains ac3 or eac3 then AAC caps are not added

- aactranscode knows what kind of transcoding to use by reading /etc/gstreamer/aactranscode file, if it contains eac3 then AAC to E-AC3 transcoding is used else it's AAC to AC3

 

Dependencies: gstreamer1.0, gstreamer1.0-libav, (it's not possible to use gstreamer-0.10 since it's missing ac3 encoding element)

 

Installation:

1. 0001-added-aactranscode-plugin.patch is for gst-1.0 branch of gst-plugin-dvbmediasink

2. 0001-added-AAC-transcoding-support-to-AC3-EAC3.patch is for master branch of openpli-enigma2

 

3. update your machine config in openpli-oe-core:

This is mine for vusolose:

diff --git a/conf/machine/include/vuxxo2.inc b/conf/machine/include/vuxxo2.inc
index 6004c5a..c1efa1a 100644
--- a/conf/machine/include/vuxxo2.inc
+++ b/conf/machine/include/vuxxo2.inc
@@ -10,7 +10,8 @@ KERNEL_MODULE_AUTOLOAD += "xfs"

 MACHINE_EXTRA_RRECOMMENDS = " \
        vuplus-shutdown \
-       gst-plugin-dvbmediasink \
+       gstreamer1.0-libav \
+       gstreamer1.0-plugin-dvbmediasink \
        ntfs-3g \
 "

@@ -24,7 +25,8 @@ EXTRA_IMAGEDEPENDS += "\
 TARGET_ARCH = "mipsel"
 DEFAULTTUNE = "mips32el"

-DVBMEDIASINK_CONFIG = "--with-wmv --with-pcm --with-eac3"
+GST_VERSION = "1.0"
+DVBMEDIASINK_CONFIG = "--with-wmv --with-pcm --with-eac3 --with-aactranscode"

 PREFERRED_VERSION_linux-${MACHINE} = "3.13.5"

4. update gstreamer1.0-plugin-dvbmediasink recipe or use bbappend with added line

diff --git a/meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugin-dvbmediasink.bb b/meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugin-dvbmediasink.bb
index 57d7b35..b2b2e83 100644
--- a/meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugin-dvbmediasink.bb
+++ b/meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugin-dvbmediasink.bb
@@ -21,6 +21,7 @@ PKGV = "${GSTVERSION}+git${GITPKGV}"
 inherit autotools pkgconfig
 
 FILES_${PN} = "${libdir}/gstreamer-${GSTVERSION}/*.so*"
+FILES_${PN} += "${sysconfdir}/gstreamer/aactranscode"
 FILES_${PN}-dev += "${libdir}/gstreamer-${GSTVERSION}/*.la"
 FILES_${PN}-staticdev += "${libdir}/gstreamer-${GSTVERSION}/*.a"
 FILES_${PN}-dbg += "${libdir}/gstreamer-${GSTVERSION}/.debug"

Now you can build your image.

 

 

By default is AAC transcoding turned off. You can turn it on by setting Setup/System/AV settings/AAC transcode to AC3/E-AC3. In case you don't use patch for enigma2 you can turn on AAC transcoding like this:

echo -n "ac3" > /etc/gstreamer/aactranscode

For now I tested it on vusolosev2 connected via HDMI to AV receiver, cpu usage is around 10%, works good. On et4x00 it's 97% and sound was choppy, so you need fast receiver.

Attached Files




#494828 GStreamer 1.0

Posted by mx3L on 15 June 2015 - 18:31

Hi, 

 

Here are patches for dvbmediasink gst-1.0 branch:

commit 2b1bcb8f0c058c752b89922c15656b5e0002f6b2
Author: mx3L <mx3ldev@gmail.com>
Date:   Tue May 19 19:36:32 2015 +0200

    dvbmediasink: let basesink handle CAPS event
    
    We don't need to handle CAPS event ourselves.
    basesink will do that and will call our set_caps function when neccessary

diff --git a/gstdvbaudiosink.c b/gstdvbaudiosink.c
index 2b87caa..80ace1c 100644
--- a/gstdvbaudiosink.c
+++ b/gstdvbaudiosink.c
@@ -897,21 +897,6 @@ static gboolean gst_dvbaudiosink_event(GstBaseSink *sink, GstEvent *event)
 		}
 		break;
 	}
-	case GST_EVENT_CAPS:
-	{
-		GstCaps *caps;
-		gst_event_parse_caps(event, &caps);
-		if (caps)
-		{
-			ret = gst_dvbaudiosink_set_caps(sink, caps);
-			//gst_caps_unref(caps);
-			if (ret != TRUE)
-			{
-				//GST_ELEMENT_ERROR(self, STREAM, FORMAT,(NULL), ("Set caps failed. Stop render."));
-			}
-		}
-	}
-
 	default:
 		ret = GST_BASE_SINK_CLASS(parent_class)->event(sink, event);
 		break;
diff --git a/gstdvbvideosink.c b/gstdvbvideosink.c
index fbebd11..fe52596 100644
--- a/gstdvbvideosink.c
+++ b/gstdvbvideosink.c
@@ -512,17 +512,6 @@ static gboolean gst_dvbvideosink_event(GstBaseSink *sink, GstEvent *event)
 		}
 		break;
 	}
-	case GST_EVENT_CAPS:
-	{
-		GstCaps *caps;
-		gst_event_parse_caps(event, &caps);
-		if (caps)
-		{
-			ret = gst_dvbvideosink_set_caps(sink, caps);
-			gst_caps_unref(caps);
-		}
-		break;
-	}
 	default:
 		ret = GST_BASE_SINK_CLASS(parent_class)->event(sink, event);
 		break;

commit faeff0c5d3ad8aadb553989a0ebe8b0ce57e6f86
Author: mx3L <mx3ldev@gmail.com>
Date:   Tue May 19 19:39:26 2015 +0200

    dvbvideosink: send codec-data header after caps negotiation

diff --git a/gstdvbvideosink.c b/gstdvbvideosink.c
index fe52596..d3f6cf8 100644
--- a/gstdvbvideosink.c
+++ b/gstdvbvideosink.c
@@ -1277,6 +1277,7 @@ static gboolean gst_dvbvideosink_set_caps(GstBaseSink *basesink, GstCaps *caps)
 	GstStructure *structure = gst_caps_get_structure (caps, 0);
 	const char *mimetype = gst_structure_get_name (structure);
 	self->stream_type = STREAMTYPE_UNKNOWN;
+	self->must_send_header = TRUE;
 
 	GST_INFO_OBJECT (self, "caps = %" GST_PTR_FORMAT, caps);
 

Attached Files




#489772 GStreamer 1.0

Posted by mx3L on 2 May 2015 - 18:21

@athoik

/**
 * GstPlayFlags:
 * @GST_PLAY_FLAG_VIDEO: Enable rendering of the video stream
 * @GST_PLAY_FLAG_AUDIO: Enable rendering of the audio stream
 * @GST_PLAY_FLAG_TEXT: Enable rendering of subtitles
 * @GST_PLAY_FLAG_VIS: Enable rendering of visualisations when there is
 *       no video stream.
 * @GST_PLAY_FLAG_SOFT_VOLUME: Use software volume
 * @GST_PLAY_FLAG_NATIVE_AUDIO: only allow native audio formats, this omits
 *   configuration of audioconvert and audioresample.
 * @GST_PLAY_FLAG_NATIVE_VIDEO: only allow native video formats, this omits
 *   configuration of videoconvert and videoscale.
 * @GST_PLAY_FLAG_DOWNLOAD: enable progressice download buffering for selected
 *   formats.
 * @GST_PLAY_FLAG_BUFFERING: enable buffering of the demuxed or parsed data.
 * @GST_PLAY_FLAG_DEINTERLACE: deinterlace raw video (if native not forced).
 * @GST_PLAY_FLAG_FORCE_FILTERS: force audio/video filters to be applied if
 *   set.
 *
 * Extra flags to configure the behaviour of the sinks.
 */
typedef enum {
  GST_PLAY_FLAG_VIDEO         = (1 << 0),
  GST_PLAY_FLAG_AUDIO         = (1 << 1),
  GST_PLAY_FLAG_TEXT          = (1 << 2),
  GST_PLAY_FLAG_VIS           = (1 << 3),
  GST_PLAY_FLAG_SOFT_VOLUME   = (1 << 4),
  GST_PLAY_FLAG_NATIVE_AUDIO  = (1 << 5),
  GST_PLAY_FLAG_NATIVE_VIDEO  = (1 << 6),
  GST_PLAY_FLAG_DOWNLOAD      = (1 << 7),
  GST_PLAY_FLAG_BUFFERING     = (1 << 8),
  GST_PLAY_FLAG_DEINTERLACE   = (1 << 9),
  GST_PLAY_FLAG_SOFT_COLORBALANCE = (1 << 10),
  GST_PLAY_FLAG_FORCE_FILTERS = (1 << 11),
} GstPlayFlags;

default playbin flags:

GST_PLAY_FLAG_AUDIO | GST_PLAY_FLAG_VIDEO | GST_PLAY_FLAG_TEXT | GST_PLAY_FLAG_SOFT_VOLUME | GST_PLAY_FLAG_DEINTERLACE | GST_PLAY_FLAG_SOFT_COLORBALANCE
>>> hex((1 << 0)|(1 << 1)|(1 << 2)|(1 << 4)|(1 << 9)|(1 << 10))
'0x617'

servicemp3 flags for playbin:

GST_PLAY_FLAG_AUDIO | GST_PLAY_FLAG_VIDEO | GST_PLAY_FLAG_TEXT | GST_PLAY_FLAG_NATIVE_VIDEO | GST_PLAY_FLAG_DEINTERLACE | GST_PLAY_FLAG_SOFT_COLORBALANCE
hex((1 << 0)|(1 << 1)|(1 << 2)|(1 << 4)|(1 << 6)|(1 << 9)|(1 << 10))
'0x657'

gst-launch-1.0 playbin uri=http://megahdlive1-f...260/master.m3u8 flags=0x617 -> no issues

gst-launch-1.0 playbin uri=http://megahdlive1-f...260/master.m3u8 flags=0x657 -> caps problems

 

So videoconverter plugin is not required in case flag GST_PLAY_FLAG_NATIVE_VIDEO is set(servicemp3) and I suppose we don't need one, since we don't do and can't do any live video conversions.

By installing it we are just masking some bug.




#488808 GStreamer 1.0

Posted by mx3L on 25 April 2015 - 19:56

smoothstreaming -  gstreamer plugin - typefind cannot convert input from UTF16-LE to UTF-8 when determining if we are dealing with smoothstreaming or not, you have to install glibc-gconv-utf-16 -> opkg install glibc-gconv-utf-16.

 

Hovewer we have another problem:

root@et4x00:/var/volatile/tmp# gst-launch-1.0 playbin uri='http://playready.directtaps.net/smoothstreaming/SSWSS720H264/SuperSpeedway_720.ism/Manifest' -v
Setting pipeline to PAUSED ...
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: ring-buffer-max-size = 0
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-size = -1
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: buffer-duration = -1
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: use-buffering = false
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: download = false
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: uri = http://playready.directtaps.net/smoothstreaming/SSWSS720H264/SuperSpeedway_720.ism/Manifest
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: connection-speed = 0
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0: source = "\(GstSoupHTTPSrc\)\ source"
Pipeline is PREROLLING ...
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstTypeFindElement:typefindelement0.GstPad:src: caps = application/vnd.ms-sstr+xml
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind: force-caps = application/vnd.ms-sstr+xml
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: sink-caps = application/vnd.ms-sstr+xml
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstQueue2:queue2-0.GstPad:src: caps = application/vnd.ms-sstr+xml
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = application/vnd.ms-sstr+xml
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = application/vnd.ms-sstr+xml
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = application/vnd.ms-sstr+xml
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMssDemux:mssdemux0: connection-speed = 0
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:sink: caps = application/vnd.ms-sstr+xml
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0.GstGhostPad:sink: caps = application/vnd.ms-sstr+xml
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMssDemux:mssdemux0.GstPad:sink: caps = application/vnd.ms-sstr+xml
Caught SIGSEGV00%  
exec gdb failed: No such file or directory
Spinning.  Please run 'gdb gst-launch-1.0 1844' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.

On PC with latest gstreamer git is smoothstream working. Maybe there was some update since 1.4.5 which fixes this issue or I have messed up gstreamer on my reciever from various testing, so please test.




#486349 GStreamer 1.0

Posted by mx3L on 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:



#481551 GStreamer 1.0

Posted by mx3L on 15 March 2015 - 20:52

@christophecvr correct cdxaparse should'nt be there.

 

We are also missing some base plugins

root@et4x00:/var/volatile/tmp# opkg install enigma2_2.7\+git12647\+57ef2d4-r0_et4x00.ipk 
Installing enigma2 (2.7+git12647+57ef2d4-r0) on root.
enigma2: unsatisfied recommendation for gstreamer1.0-plugins-base-vorbis
enigma2: unsatisfied recommendation for gstreamer1.0-plugins-base-ogg
enigma2: unsatisfied recommendation for gstreamer1.0-plugins-bad-cdxaparse
enigma2: unsatisfied recommendation for gstreamer1.0-plugins-base-ivorbisdec
enigma2: unsatisfied recommendation for gstreamer1.0-plugins-base-alsa

This will build them all, except mentioned cdxaparse

diff --git a/meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.%.bbappend b/meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.%.bbappend
index 4f1f0f5..98d8a66 100644
--- a/meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.%.bbappend
+++ b/meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.4.%.bbappend
@@ -1,8 +1,9 @@
 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 PACKAGECONFIG[cdparanoia]     = "--enable-cdparanoia,--disable-cdparanoia,cdparanoia"
-PACKAGECONFIG += "cdparanoia"
+PACKAGECONFIG += "cdparanoia ogg vorbis ivorbis alsa"
 EXTRA_OECONF := "${@bb.data.getVar('EXTRA_OECONF',d,1).replace('--disable-cdparanoia', '--enable-cdparanoia')}"
 SRC_URI += "file://0001-riff-media-added-fourcc-to-all-mpeg4-video-caps.patch"
+PR="r1"
 
 # Do not strip binary
 #INHIBIT_PACKAGE_STRIP = "1"



#481388 ET9200 problems with mp4 playback

Posted by mx3L on 15 March 2015 - 12:34

Suggestion to improve unpause performance:

diff --git a/lib/service/servicemp3.cpp b/lib/service/servicemp3.cpp
index 59237bc..48fb8e4 100644
--- a/lib/service/servicemp3.cpp
+++ b/lib/service/servicemp3.cpp
@@ -467,8 +467,10 @@ eServiceMP3::eServiceMP3(eServiceReference ref):
 		m_sourceinfo.is_video = TRUE;
 	}
 	if ( strstr(filename, "://") )
+	{
 		m_sourceinfo.is_streaming = TRUE;
-
+		m_sourceinfo.protocol = m_ref.path.substr(0, m_ref.path.find("://"));
+	}
 	gchar *uri;
 
 	if ( m_sourceinfo.is_streaming )
@@ -861,7 +863,6 @@ RESULT eServiceMP3::trickSeek(gdouble ratio)
 		return 0;
 	}
 
-	m_currentTrickRatio = ratio;
 
 	bool validposition = false;
 	gint64 pos = 0;
@@ -876,7 +877,28 @@ RESULT eServiceMP3::trickSeek(gdouble ratio)
 
 	if (validposition)
 	{
-		if (ratio >= 0.0)
+		if (m_currentTrickRatio == 1.0 && ratio == 1.0)
+		{
+#if GST_VERSION_MAJOR >= 1
+			if ( !m_sourceinfo.is_streaming || (strcasecmp(m_sourceinfo.protocol.c_str(), "http") && strcasecmp(m_sourceinfo.protocol.c_str(), "https") ) == 0)
+#else
+			if ( !m_sourceinfo.is_streaming )
+#endif
+			{
+					eDebug("eServiceMP3::trickSeek - standard unpause");
+					if ( !(gst_element_get_state(m_gst_playbin, NULL, NULL, 100LL * GST_MSECOND) == GST_STATE_CHANGE_SUCCESS) )
+					{
+						eDebug("eServiceMP3:trickSeek - standard unpause was not successfull, doing seeking unpause");
+						gst_element_seek(m_gst_playbin, ratio, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT), GST_SEEK_TYPE_SET, pos, GST_SEEK_TYPE_SET, -1);
+					}
+			}
+			else
+			{
+				eDebug("eServiceMP3::trickSeek - seeking unpause");
+				gst_element_seek(m_gst_playbin, ratio, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT), GST_SEEK_TYPE_SET, pos, GST_SEEK_TYPE_SET, -1);
+			}
+		}
+		else if (ratio >= 0.0)
 		{
 			gst_element_seek(m_gst_playbin, ratio, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_SKIP), GST_SEEK_TYPE_SET, pos, GST_SEEK_TYPE_SET, -1);
 		}
@@ -886,7 +908,7 @@ RESULT eServiceMP3::trickSeek(gdouble ratio)
 			gst_element_seek(m_gst_playbin, ratio, GST_FORMAT_TIME, (GstSeekFlags)(GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_SKIP), GST_SEEK_TYPE_SET, 0, GST_SEEK_TYPE_SET, pos);
 		}
 	}
-
+	m_currentTrickRatio = ratio;
 	m_prev_decoder_time = -1;
 	m_decoder_time_valid_state = 0;
 	return 0;
diff --git a/lib/service/servicemp3.h b/lib/service/servicemp3.h
index b3a685e..ab793e4 100644
--- a/lib/service/servicemp3.h
+++ b/lib/service/servicemp3.h
@@ -202,6 +202,7 @@ public:
 		containertype_t containertype;
 		bool is_video;
 		bool is_streaming;
+		std::string protocol;
 		sourceStream()
 			:audiotype(atUnknown), containertype(ctNone), is_video(FALSE), is_streaming(FALSE)
 		{



1. We are doing unpause by seeking to current position.

- this is unnecessary thing to do for local (on GST1.0 also for http[s] streams), since we don't timeout on local streams(on GST1.0 souphttpsrc will not timeout - https://bugzilla.gno...g.cgi?id=683536)

- sometimes state change didn't happen in standard unpause, so then it will fallback to seeking unpause.

 

2. We are doing unpausing by default seeking(not keyframe seeking)

- this is also unneccesary, we can do keyframe seeking instead, since we are doing it already but with overhead caused by looking for segment offset, which we are ignoring in our sinks:


1. DEFAULT BEHAVIOUR:

When a seek to a certain position is requested, the demuxer/parser will
do two things (ignoring flushing and segment seeks, and simplified for
illustration purposes):

 - send a segment event with a new start position

 - start pushing data/buffers again

To ensure that the data corresponding to the requested seek position
can actually be decoded, a demuxer or parser needs to start pushing data
from a keyframe/keyunit at or before the requested seek position.

Unless requested differently (via the KEY_UNIT flag), the start of the
segment event should be the requested seek position.

So by default a demuxer/parser will then start pushing data from
position DATA and send a segment event with start position SEG_START,
and DATA <= SEG_START.

If DATA < SEG_START, a well-behaved video decoder will start decoding frames
from DATA, but take into account the segment configured by the demuxer via
the segment event, and only actually output decoded video frames from
SEG_START onwards, dropping all decoded frames that are before the
segment start and adjusting the timestamp/duration of the buffer that
overlaps the segment start ("clipping"). A not-so-well-behaved video decoder
will start decoding frames from DATA and push decoded video frames out
starting from position DATA, in which case the frames that are before
the configured segment start will usually be dropped/clipped downstream
(e.g. by the video sink).

 

- http://cgit.freedesk...art-seeking.txt

 

So what's added value:

 

1. faster unpause, starting with same frame as in pause mode

1. unpausing will now work on some mp4, which didn't work before(big gops?)

2. added possibility to prefill buffer in default buffering mode for http(s) streams, by pause - > wait to 100% buffer - > unpause, since buffer will be not dropped by seeking event

 

Tested on gstreamer1.0.

 




#480840 GStreamer 1.0

Posted by mx3L on 13 March 2015 - 09:48

Here it is

Attached Files




#480811 GStreamer 1.0

Posted by mx3L on 13 March 2015 - 08:10

Hmm thats wierd, because it looks to me clear what is happening:

We are not helding PREROLL_LOCK, while passing EOS to basesink event handler, since we called before GST_BASE_SINK_PREROLL_UNLOCK.

Then basesink does according to log this(not fixed version + added debug messages):

root@et4x00:/var/volatile/tmp# gst-launch-1.0 --gst-debug basesink:6,dvbaudiosink:5 playbin uri='file:///home/root/Front_Right.wav'
0:00:03.649135479  1103   0x507380 DEBUG           dvbaudiosink :gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> EVENT eos
0:00:03.650607442  1103   0x507380 DEBUG           dvbaudiosink :gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> PRE - GST_BASE_SINK_PREROLL_UNLOCK!!
0:00:03.652081331  1103   0x507380 DEBUG           dvbaudiosink :gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> POST - GST_BASE_SINK_PREROLL_UNLOCK!!
0:00:03.653453738  1103   0x507380 DEBUG           dvbaudiosink :gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> got buffer empty from driver!
0:00:03.654772887  1103   0x507380 DEBUG           dvbaudiosink :gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> PRE - SEND EOS EVENT TO BASESINK
0:00:03.655821220  1103   0x507380 DEBUG               basesink :gst_base_sink_get_sync_times:<audiosink-actual-sink-dvbaudio> sync times for EOS 0:00:01.530687500
0:00:03.657828442  1103   0x507380 LOG                 basesink :gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> avg frame diff 0:00:00.042002603
0:00:03.659519775  1103   0x507380 DEBUG               basesink :gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> reset rc_time to time 0:00:01.530687500
0:00:03.660821627  1103   0x507380 DEBUG               basesink :gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> possibly waiting for clock to reach 0:00:01.530687500, adjusted 0:00:01.530687500
0:00:03.662318405  1103   0x507380 LOG                 basesink :gst_base_sink_wait_clock:<audiosink-actual-sink-dvbaudio> time 0:00:01.530687500, base_time 9:44:30.172565429
Attempt to unlock mutex that was not locked

Last function which is called is gst_base_sink_wait_clock: http://cgit.freedesk...e/gstbasesink.c - 2028 line

 

/**
 * gst_base_sink_wait_clock:
 * @sink: the sink
 * @time: the running_time to be reached
 * @jitter: (out) (allow-none): the jitter to be filled with time diff, or %NULL
 *
........
........
 *
 * This function should only be called with the PREROLL_LOCK held, like when
 * receiving an EOS event in the #GstBaseSinkClass.event() vmethod or when
 * receiving a buffer in
 * the #GstBaseSinkClass.render() vmethod.
........
........
 *
 * Returns: #GstClockReturn
 */

 

We are not helding PREROLL_LOCK(same in dvbvideosink) and it tries to unlock it - line 2101, resulting in Attempt to unlock mutex that was not locked.

 

with flac/mp3 it works because sync is disabled:

root@et4x00:/var/volatile/tmp# gst-launch-1.0 --gst-debug basesink:6,dvbaudiosink:5 playbin uri='file:///home/root/Front_Right.flac'
0:00:02.424767554  1111   0x506920 DEBUG               basesink :gst_base_sink_do_sync:<dvbaudiosink0> reset rc_time to time 0:00:01.530687500
0:00:02.426053739  1111   0x506920 DEBUG               basesink :gst_base_sink_do_sync:<dvbaudiosink0> possibly waiting for clock to reach 0:00:01.530687500, adjusted 0:00:01.530687500
0:00:02.432915924  1111   0x506920 DEBUG               basesink :gst_base_sink_wait_clock:<dvbaudiosink0> sync disabled

meaning it skips unlocking already unlocked lock by jumping to no_sync label - line 2116

 

working version + debug messages:

root@et4x00:/var/volatile/tmp# gst-launch-1.0 --gst-debug basesink:6,dvbaudiosink:5 playbin uri='file:///home/root/Front_Right.wav'
0:00:04.436699627  1131   0x56ed80 DEBUG           dvbaudiosink :gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> got buffer empty from driver!
0:00:04.438271998  1131   0x56ed80 DEBUG           dvbaudiosink :gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> PRE - GST_BASE_SINK_PREROLL_LOCK
0:00:04.438806294  1131   0x56ed80 DEBUG           dvbaudiosink :gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> POST - GST_BASE_SINK_PREROLL_LOCK!!
0:00:04.440364849  1131   0x56ed80 DEBUG           dvbaudiosink :gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> PRE - SEND EOS EVENT TO BASESINK
0:00:04.441792183  1131   0x56ed80 DEBUG               basesink :gst_base_sink_get_sync_times:<audiosink-actual-sink-dvbaudio> sync times for EOS 0:00:01.530687500
0:00:04.443017109  1131   0x56ed80 LOG                 basesink :gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> avg frame diff 0:00:00.042002603
0:00:04.444214405  1131   0x56ed80 DEBUG               basesink :gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> reset rc_time to time 0:00:01.530687500
0:00:04.445229405  1131   0x56ed80 DEBUG               basesink :gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> possibly waiting for clock to reach 0:00:01.530687500, adjusted 0:00:01.530687500
0:00:04.446589590  1131   0x56ed80 LOG                 basesink :gst_base_sink_wait_clock:<audiosink-actual-sink-dvbaudio> time 0:00:01.530687500, base_time 10:22:59.807729349
0:00:04.457691109  1131   0x56ed80 DEBUG               basesink :gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> clock returned 0, jitter -0:00:00.008846501
0:00:04.459115738  1131   0x56ed80 DEBUG               basesink :gst_base_sink_is_too_late:<audiosink-actual-sink-dvbaudio> object was scheduled in time
0:00:04.460449590  1131   0x56ed80 DEBUG               basesink :gst_base_sink_default_event:<audiosink-actual-sink-dvbaudio> Now posting EOS
0:00:04.461767849  1131   0x56ed80 DEBUG               basesink :gst_base_sink_default_event:<audiosink-actual-sink-dvbaudio> Got seqnum #164
Got EOS from element "playbin0".
Execution ended after 0:00:01.466254147
0:00:04.467600516  1131   0x56ed80 DEBUG           dvbaudiosink :gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> POST - SEND EOS EVENT TO BASESINK
Setting pipeline to PAUSED ...
0:00:04.472165368  1131   0x57e180 DEBUG               basesink :gst_base_sink_change_state:<audiosink-actual-sink-dvbaudio> PLAYING to PAUSED
0:00:04.473988998  1131   0x57e180 DEBUG           dvbaudiosink :gst_dvbaudiosink_unlock:<audiosink-actual-sink-dvbaudio> unlock
0:00:04.476396627  1131   0x57e180 DEBUG               basesink :gst_base_sink_change_state:<audiosink-actual-sink-dvbaudio> got preroll lock
0:00:04.478303590  1131   0x57e180 DEBUG           dvbaudiosink :gst_dvbaudiosink_unlock_stop:<audiosink-actual-sink-dvbaudio> unlock_stop
0:00:04.479618701  1131   0x57e180 DEBUG               basesink :gst_base_sink_needs_preroll:<audiosink-actual-sink-dvbaudio> have_preroll: 0, EOS: 1 => needs preroll: 0
0:00:04.481205812  1131   0x57e180 DEBUG               basesink :gst_base_sink_change_state:<audiosink-actual-sink-dvbaudio> PLAYING to PAUSED, we are prerolled
0:00:04.482523701  1131   0x57e180 DEBUG               basesink :gst_base_sink_change_state:<audiosink-actual-sink-dvbaudio> rendered: 36, dropped: 0
0:00:04.484027442  1131   0x57e180 DEBUG           dvbaudiosink :gst_dvbaudiosink_change_state:<audiosink-actual-sink-dvbaudio> GST_STATE_CHANGE_PLAYING_TO_PAUSED
Setting pipeline to READY ...
0:00:04.581402146  1131   0x57e180 DEBUG           dvbaudiosink :gst_dvbaudiosink_unlock:<audiosink-actual-sink-dvbaudio> unlock
0:00:04.582567886  1131   0x57e180 DEBUG           dvbaudiosink :gst_dvbaudiosink_unlock_stop:<audiosink-actual-sink-dvbaudio> unlock_stop
0:00:04.584013923  1131   0x57e180 DEBUG               basesink :gst_base_sink_set_flushing:<audiosink-actual-sink-dvbaudio> flushing out data thread, need preroll to TRUE
0:00:04.585789146  1131   0x57e180 DEBUG               basesink :gst_base_sink_set_last_buffer_unlocked:<audiosink-actual-sink-dvbaudio> setting last buffer to (nil)
0:00:04.587397294  1131   0x57e180 DEBUG               basesink :gst_base_sink_change_state:<audiosink-actual-sink-dvbaudio> PAUSED to READY, don't need_preroll
0:00:04.588579923  1131   0x57e180 DEBUG           dvbaudiosink :gst_dvbaudiosink_change_state:<audiosink-actual-sink-dvbaudio> GST_STATE_CHANGE_PAUSED_TO_READY
0:00:04.608949368  1131   0x57e180 DEBUG           dvbaudiosink :gst_dvbaudiosink_stop:<audiosink-actual-sink-dvbaudio> stop
0:00:04.639208664  1131   0x57e180 DEBUG           dvbaudiosink :gst_dvbaudiosink_change_state:<audiosink-actual-sink-dvbaudio> GST_STATE_CHANGE_READY_TO_NULL
Setting pipeline to NULL ...
Freeing pipeline ...

Can you try to apply this patch and post debug output?

Attached Files