2520 replies to this topic

[MastaG]

So Erik,

 

Are there plans to eventually merge this with master?

[Erik Slagter]

"eventually" yes.

[christophecvr]

I just learned that VU+ are actually working on the gstreamer/driver adaptation, so it might pay off to have a little more patience.

Yes I think indeed better wait. For audio you can tell that pli's gst-1.0 mediasink works, and i'm pretty shure 100 % ok.

 

For video not I tried to use 16 for wmv1 and wmv2 ,17 for wmv3 , but audio always ok video does not play. The video could have something to to with the servicesmp3.cpp which is not 100 % yet for gst-1.0 .

[Rob van der Does]

See http://code.vuplus.c...817e95dc06826ae

[Erik Slagter]

That sounds promising!

[MastaG]

Nice, so now that the dm800se works, we'll also have VU working in the near future

[adri]

If it works for the DM800SE, doesn't that mean it should also work for all other DMM models, like the 8000, 7020HD etc.

[MastaG]

I don't know, I only have a dm800se.

[mx3L]

Buffering settings for playbin are not optimal. Currently we have buffer-size set to 5MB and buffer-duration set to 5 seconds. When one of this values is reached durring buffering than buffering stops.

This means that buffer-size of 5MB is almost never filled, since buffer-duration is too low.

 

For example:

 

SD media(45min - 350MB) : ~650KB/5s
HD media(90min - 4000MB) : ~3700KB/5s

 

This causes prefill buffer mode to be almost unusable, because of incessant re-buffering, since buffer is immediately drained after reaching 100% to bigger HW buffer.

 

So either we should increase buffer duration to some reasonable limit ~40s or turn it off, meaning that buffering will always stop after it reaches 5MB, which significantnly reduces re-buffering.

 

 

I did tests on et6500 with gst1.0:

 

There is no bottleneck on source's side

 

buffer-duration 5s:

- default buffer mode - 410MB/50min(SD)  sometimes stuttering

- default buffer mode - 900MB/50min(HD) stuttering

- prefill buffer mode - 410MB/50min(SD)  endless re-buffering

- prefill buffer mode - 900MB/50min(HD) endless re-buffering

 

buffer-duration turned off:

- default buffer mode - 410MB/50min(SD)  seamless playback

- default buffer mode - 900MB/50min(HD) stuttering

- prefill buffer mode - 410MB/50min(SD)  seamless playback

- prefill buffer mode - 900MB/50min(HD) one time re-buffering, then seamless playback

 

So it improves buffering performance, mainly in prefill buffer mode.

Attached Files

•  0001-servicemp3-disable-buffer-duration-for-playbin.patch   1.24KB   13 downloads

Edited by mx3L, 9 March 2015 - 10:54.

[christophecvr]

Ok here now adapted vuplus gst-1 branch patch. I added the gstreamer1.0-plugin-dvbmediasink.patch

 

Now on vuduo2 WMV plays with WMV3 media. video ok audio ok.

 

Here the renewed gst-1.0 git patch.

 

I also added separately the gstreamer1.0-plugin patch voor vuplus.

 

The only thing is that playing wav files from out of enigma2 does cause enigma2 crash after the song is played. unrecoverable except trough telanet by killing enigma2. The reason is a segfault.

 

When playing wav file out of telnet console (after init 5 enigma2 stopped) . It plays but we have warning concerning buffers and mutex. Which is the cause of enigma crash when playing out off enigma2.

root@vuduo2:/media/VIDAUD# gst-launch-1.0 playbin uri=file:///media/VIDAUD/Front_Right.wav
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
WARNING: from element /GstPlayBin:playbin0/GstPlaySink:playsink: No volume control found
Additional debug info:
/home/christophe/openpli40-gst1/openpli-oe-core/build/tmp/work/mips32el-oe-linux/gstreamer1.0-plugins-base/1.4.5-r0/gst-plugins-base-1.4.5/gst/playback/gstplaysink.c(2862): gen_audio_chain (): /GstPlayBin:playbin0/GstPlaySink:playsink:
Volume/mute is not available
WARNING: from element /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:abin/GstAutoAudioSink:audiosink/GstDVBAudioSink:audiosink-actual-sink-dvbaudio: Internal data flow problem.
Additional debug info:
/home/christophe/openpli40-gst1/openpli-oe-core/build/tmp/work/mips32el-oe-linux/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/libs/gst/base/gstbasesink.c(3307): gst_base_sink_chain_unlocked (): /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:abin/GstAutoAudioSink:audiosink/GstDVBAudioSink:audiosink-actual-sink-dvbaudio:
Received buffer without a new-segment. Assuming timestamps start from 0.
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Attempt to unlock mutex that was not locked
Aborted

maybe the patch from mx3L could solve the crash out off enigma2 , but the reason of error is still there.

 

 

Attached Files

•  GST-1-vuduo2-20150309.patch   38.97KB   5 downloads
•  vuplus-gst10-dvbmediasink.patch   3.86KB   10 downloads

[christophecvr]

I'm still trying to find a solution to the wav file problem. But no luck.

 

What I well found out is that for wav file its tries to use

WARNING: from element /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:abin/GstAutoAudioSink:audiosink/GstDVBAudioSink:audiosink-actual-sink-dvbaudio

instead off

/GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:abin/GstDVBAudioSink:dvbaudiosink0.GstPad:sink:

looks like it is cause there is no codec and it's uncompressed.

 

tag wav file

/GstPlayBin:playbin0/GstInputSelector:inputselector0.GstSelectorPad:sink_0: tags = "taglist\,\ audio-codec\=\(string\)\"Uncompressed\\\ 16-bit\\\ PCM\\\ audio\"\;"

and it plays with (it really plays but with warning )

/GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:abin/GstAutoAudioSink:audiosink/GstDVBAudioSink:audiosink-actual-sink-dvbaudio.GstPad:sink: caps = "audio/x-raw\,\ format\=\(string\)S16LE\,\ layout\=\(string\)interleaved\,\ channels\=\(int\)1\,\ rate\=\(int\)48000"

 When using gst-launch-1.0 playbin uri=file///xxxxx  (after init 5) play ok but error's are :

root@vuduo2:/media/VIDAUD# gst-launch-1.0 playbin uri=file:///media/VIDAUD/Front_Right.wav
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
WARNING: from element /GstPlayBin:playbin0/GstPlaySink:playsink: No volume control found
Additional debug info:
/home/christophe/openpli40-gst1/openpli-oe-core/build/tmp/work/mips32el-oe-linux/gstreamer1.0-plugins-base/1.4.5-r0/gst-plugins-base-1.4.5/gst/playback/gstplaysink.c(2862): gen_audio_chain (): /GstPlayBin:playbin0/GstPlaySink:playsink:
Volume/mute is not available
WARNING: from element /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:abin/GstAutoAudioSink:audiosink/GstDVBAudioSink:audiosink-actual-sink-dvbaudio: Internal data flow problem.
Additional debug info:
/home/christophe/openpli40-gst1/openpli-oe-core/build/tmp/work/mips32el-oe-linux/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/libs/gst/base/gstbasesink.c(3307): gst_base_sink_chain_unlocked (): /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:abin/GstAutoAudioSink:audiosink/GstDVBAudioSink:audiosink-actual-sink-dvbaudio:
Received buffer without a new-segment. Assuming timestamps start from 0.
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Attempt to unlock mutex that was not locked
Aborted

When playing out off enigma. It cause unrecoverable enigma2 crash (after the audio is played ) the audio plays that well.

 

I really can't find a solution . And problem is only for wav files . All other audio runs fine.

[christophecvr]

Would be nice if someone who nows more about gst-1.0 does have ideas to solve this wav isue. Since this issue is a blocker to any further use off gst-1.0. If any media or plugin or broadcast media such as out gemist or hbbtv has a wav format somewhere enigma2 will crash unrecoverable.

[mx3L]

Is this only vu+ related? If not can you upload your problematic wav file and post direct link here? I will test it on xtrend.

[christophecvr]

No I do not think it's related to vu+ . Ok I test on vuplus.

 

Same file does work perfect on vu+ when using gst-0.10 (with the schwerchcraft sink from dvb elite , but also work's perfect with gst-0.10 using pli's dvb mediasink on vuduo2).

 

links  I put same file once the original .wav (it's just an audio speaker test wav file very short). Once the converted file into flac format. And one a reconvert off the flac file back to wav.

 

http://users.telenet...nsp/Front_Right.wav original play with error

 

plays perfect

 

http://users.telenet...ront_Right2.wav plays with the error .

Edited by christophecvr, 11 March 2015 - 21:13.

[christophecvr]

http://users.telenet...Front_Right.wav original

 

http://users.telenet...ront_Right.flac  plays ok

 

previous podt did not take link correct

Edited by christophecvr, 11 March 2015 - 21:17.

[christophecvr]

er is al vast nog een aanpassing nodig and dvbmediasink namelijk

#if GST_VERSION_MAJOR < 1
#include <gst/gst.h>
#include <gst/audio/audio.h>
#include <gst/base/gstbasesink.h>
#else
#include <gstreamer-1.0/gst/gst.h>
#include <gstreamer-1.0/gst/audio/audio.h>
#include <gstreamer-1.0/gst/base/gstbasesink.h>
#endif

[christophecvr]

and does the xtrend have same problem with wav files ?

[christophecvr]

It seems that gst-1.4.5 uses the autoaudiosink element when a stream type is obtained with autodetect (which on it is needed for wav files). Somehow there must be a way to disable the autoaudiosink element into playbin . If that element is disabled most probably problems will be solved. Since it then should use the defined sink. which is dvbaudiosink0 .

.

 

But how ? thats the question.

 

p.s. when playing al other encoded formats autodetect is not used. That's why we have the correct bin for those formats.

Edited by christophecvr, 12 March 2015 - 12:33.

[mx3L]

Its the same on xtrend, deadlock after EOS event:

root@et4x00:~# gst-launch-1.0 --gst-debug basesink:5,dvbaudiosink:5 playbin uri=file:///home/root/Front_Right.wav
...
ual-sink-dvbaudio> received event 0x545010 eos event: 0x545010, time 99:99:99.999999999, seq-num 164, (NULL)
0:00:03.525170517   454   0x50db80 DEBUG           dvbaudiosink gstdvbaudiosink.c:769:gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> EVENT eos
0:00:03.526496294   454   0x50db80 DEBUG           dvbaudiosink gstdvbaudiosink.c:830:gst_dvbaudiosink_event:<audiosink-actual-sink-dvbaudio> got buffer empty from driver!

0:00:03.527866554   454   0x50db80 DEBUG               basesink gstbasesink.c:1854:gst_base_sink_get_sync_times:<audiosink-actual-sink-dvbaudio> sync times for EOS 0:00:01.530687500
0:00:03.529396331   454   0x50db80 DEBUG               basesink gstbasesink.c:2475:gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> reset rc_time to time 0:00:01.530687500
0:00:03.531241776   454   0x50db80 DEBUG               basesink gstbasesink.c:2487: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.552463813   454   0x50db80 DEBUG               basesink gstbasesink.c:2494:gst_base_sink_do_sync:<audiosink-actual-sink-dvbaudio> clock returned 0, jitter -0:00:00.020159612
0:00:03.555313776   454   0x50db80 DEBUG               basesink gstbasesink.c:2813:gst_base_sink_is_too_late:<audiosink-actual-sink-dvbaudio> object was scheduled in time
0:00:03.556923220   454   0x50db80 DEBUG               basesink gstbasesink.c:3039:gst_base_sink_default_event:<audiosink-actual-sink-dvbaudio> Now posting EOS
0:00:03.558537405   454   0x50db80 DEBUG               basesink gstbasesink.c:3042:gst_base_sink_default_event:<audiosink-actual-sink-dvbaudio> Got seqnum #164
Got EOS from element "playbin0".
Execution ended after 0:00:01.466575851
Setting pipeline to PAUSED ...
0:00:03.566266628   454   0x4fab80 DEBUG               basesink gstbasesink.c:4996:gst_base_sink_change_state:<audiosink-actual-sink-dvbaudio> PLAYING to PAUSED
0:00:03.567709517   454   0x4fab80 DEBUG           dvbaudiosink gstdvbaudiosink.c:347:gst_dvbaudiosink_unlock:<audiosink-actual-sink-dvbaudio> unlock

This is how it should looks like:

root@et4x00:~# gst-launch-1.0 --gst-debug basesink:5,dvbaudiosink:5 playbin uri=http://www.tonycuffe.com/mp3/pipers%20hut.mp3
...
:<dvbaudiosink0> EVENT eos
0:01:08.792675589   469   0x67c800 DEBUG           dvbaudiosink gstdvbaudiosink.c:830:gst_dvbaudiosink_event:<dvbaudiosink0> got buffer empty from driver!

0:01:08.794105922   469   0x67c800 DEBUG               basesink gstbasesink.c:1854:gst_base_sink_get_sync_times:<dvbaudiosink0> sync times for EOS 0:01:13.012242160
0:01:08.795611181   469   0x67c800 DEBUG               basesink gstbasesink.c:2475:gst_base_sink_do_sync:<dvbaudiosink0> reset rc_time to time 0:01:13.012242160
0:01:08.797022181   469   0x67c800 DEBUG               basesink gstbasesink.c:2487:gst_base_sink_do_sync:<dvbaudiosink0> possibly waiting for clock to reach 0:01:13.012242160, adjusted 0:01:13.012242160
0:01:08.798739477   469   0x67c800 DEBUG               basesink gstbasesink.c:2119:gst_base_sink_wait_clock:<dvbaudiosink0> sync disabled
0:01:08.800386811   469   0x67c800 DEBUG               basesink gstbasesink.c:2494:gst_base_sink_do_sync:<dvbaudiosink0> clock returned 4, jitter  0:00:00.000000000
0:01:08.801725626   469   0x67c800 DEBUG               basesink gstbasesink.c:3039:gst_base_sink_default_event:<dvbaudiosink0> Now posting EOS
0:01:08.804299514   469   0x67c800 DEBUG               basesink gstbasesink.c:3042:gst_base_sink_default_event:<dvbaudiosink0> Got seqnum #249
Got EOS from element "playbin0".
Execution ended after 0:01:03.658184332
Setting pipeline to PAUSED ...
0:01:08.812010663   469   0x4f05a0 DEBUG               basesink gstbasesink.c:4996:gst_base_sink_change_state:<dvbaudiosink0> PLAYING to PAUSED
0:01:08.813526552   469   0x4f05a0 DEBUG           dvbaudiosink gstdvbaudiosink.c:347:gst_dvbaudiosink_unlock:<dvbaudiosink0> unlock
0:01:08.814806144   469   0x4f05a0 DEBUG               basesink gstbasesink.c:5005:gst_base_sink_change_state:<dvbaudiosink0> got preroll lock
0:01:08.816199626   469   0x4f05a0 DEBUG           dvbaudiosink gstdvbaudiosink.c:355:gst_dvbaudiosink_unlock_stop:<dvbaudiosink0> unlock_stop
0:01:08.817616663   469   0x4f05a0 DEBUG               basesink gstbasesink.c:3251:gst_base_sink_needs_preroll:<dvbaudiosink0> have_preroll: 0, EOS: 1 => needs preroll: 0
0:01:08.819194589   469   0x4f05a0 DEBUG               basesink gstbasesink.c:5023:gst_base_sink_change_state:<dvbaudiosink0> PLAYING to PAUSED, we are prerolled
0:01:08.820435996   469   0x4f05a0 DEBUG               basesink gstbasesink.c:5044:gst_base_sink_change_state:<dvbaudiosink0> rendered: 2795, dropped: 0
0:01:08.821083144   469   0x4f05a0 DEBUG           dvbaudiosink gstdvbaudiosink.c:1542:gst_dvbaudiosink_change_state:<dvbaudiosink0> GST_STATE_CHANGE_PLAYING_TO_PAUSED
Setting pipeline to READY ...
0:01:08.900554255   469   0x4f05a0 DEBUG           dvbaudiosink gstdvbaudiosink.c:347:gst_dvbaudiosink_unlock:<dvbaudiosink0> unlock
0:01:08.901874626   469   0x4f05a0 DEBUG           dvbaudiosink gstdvbaudiosink.c:355:gst_dvbaudiosink_unlock_stop:<dvbaudiosink0> unlock_stop
0:01:08.904473218   469   0x4f05a0 DEBUG               basesink gstbasesink.c:4026:gst_base_sink_set_flushing:<dvbaudiosink0> flushing out data thread, need preroll to TRUE
0:01:08.906224626   469   0x4f05a0 DEBUG               basesink gstbasesink.c:936:gst_base_sink_set_last_buffer_unlocked:<dvbaudiosink0> setting last buffer to (nil)
0:01:08.907663885   469   0x4f05a0 DEBUG               basesink gstbasesink.c:5083:gst_base_sink_change_state:<dvbaudiosink0> PAUSED to READY, don't need_preroll
0:01:08.909238626   469   0x4f05a0 DEBUG           dvbaudiosink gstdvbaudiosink.c:1549:gst_dvbaudiosink_change_state:<dvbaudiosink0> GST_STATE_CHANGE_PAUSED_TO_READY
0:01:08.922353255   469   0x4f05a0 DEBUG           dvbaudiosink gstdvbaudiosink.c:1445:gst_dvbaudiosink_stop:<dvbaudiosink0> stop
0:01:08.952003996   469   0x4f05a0 DEBUG           dvbaudiosink gstdvbaudiosink.c:1552:gst_dvbaudiosink_change_state:<dvbaudiosink0> GST_STATE_CHANGE_READY_TO_NULL
Setting pipeline to NULL ...
Freeing pipeline ...

So its stuck on unlock and never gets to basesink gst_base_sink_change_state:<dvbaudiosink0> got preroll lock

Edited by mx3L, 12 March 2015 - 18:36.

[christophecvr]

Yes what's the log when You play out off enigma.

 

It's all comming from gstreamer 10 self. They there fore add a work around , if there is no new segment they create one whit start position 0 . And or won dvbmediasink does not have the keps using the old. Therefore it continu's playing while there is no audio to play anymore which result's in a usseles lock command but followed by an unlock and there it's going wrong.

root@vuduo2:/media/VIDAUD# gst-launch-1.0 playbin uri=file:///media/VIDAUD/Front_Right.wav
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
WARNING: from element /GstPlayBin:playbin0/GstPlaySink:playsink: No volume control found
Additional debug info:
/home/christophe/openpli40-gst1/openpli-oe-core/build/tmp/work/mips32el-oe-linux/gstreamer1.0-plugins-base/1.4.5-r0/gst-plugins-base-1.4.5/gst/playback/gstplaysink.c(2862): gen_audio_chain (): /GstPlayBin:playbin0/GstPlaySink:playsink:
Volume/mute is not available
WARNING: from element /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:abin/GstAutoAudioSink:audiosink/GstDVBAudioSink:audiosink-actual-sink-dvbaudio: Internal data flow problem.
Additional debug info:
/home/christophe/openpli40-gst1/openpli-oe-core/build/tmp/work/mips32el-oe-linux/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/libs/gst/base/gstbasesink.c(3307): gst_base_sink_chain_unlocked (): /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:abin/GstAutoAudioSink:audiosink/GstDVBAudioSink:audiosink-actual-sink-dvbaudio:
Received buffer without a new-segment. Assuming timestamps start from 0.
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Attempt to unlock mutex that was not locked
Aborted