christophecvr

Ter info gstreamer recipes for 1.9.0.1 updated to today 2013-05-05 all ok.

https://github.com/c...TREAMER-RECIPES

@MastaG & @all self builders

I just added a change into servicemp3. Now when paused the actions like audio stream change and or chapter jups by mkv who have chapters (chapter support is only avbl with gst-1.0 since mkv demuxer gst-0.10 does not have toc support) But audio support is off course well avbl by gst-0.10.

here the patch to servicemp3.

Yeah, same here on all of my mips receivers.
It's just my spark7162 receiver thats heavily skipping and freezing on hls streams.

Normal mkv + srt plays fine.

Maybe the hls fix which is applied to plugins-bad is not fully compatible with sh4?
Because using your sink with gstreamer 1.6.3 I have no issues.
I'll try playing forced async mode.

It could be they are working on adaptif streaming and m3u8 is that.

p. s. there is in the mean time a better patch I'll put an update on the gstreamer reciepes.

So anyways.. the segfault wasn't related to enigma2- or gstreamer patches at all.

After reverting back to the gstreamer SRCREV's  used in chris's github recipes the segfault is gone.

So be prepared to face something ugly when upgrading to a newer gstreamer snapshot

Seg fault is indeed gstreamer .

The culprit commit is :

https://cgit.freedes...a39ff47d538fa68

I filed a bug report :

https://bugzilla.gno...g.cgi?id=765728

Further my recipes for gst-1.9.0.1 are updated but do contain a new patch wich revert the commit as long the error in the code which cause a seg fault on a stb can't be found.

https://github.com/c...1aac4278a16e897

I just found the reason why for file media with several audio track's when :

pausing the media (by remote command pause/play button)

- selecting same track again all ok and if due to some issue audio/video/subtitles  where out off sync all back in sync and ok when unpausing  all ok

- selecting a lower track then the current example if track 1 or 2 is used going to 0 or 1. where out off sync all back in sync and ok when unpausing  all ok

- selecting a higher track then the current immediate full freeze off enigma2 .

   In this situation some how the higher audio track has not been detected as started , when trying to flush a not started track it freezes (looks to be driver issue).

I found a good solution and it work's perfect on dm8000 and vuduo2.

 now we just will first set gstreamer to play select new track flush seek set new segment to all used sink's . audio/video/subsink and pause . There are no losses in image or audio fragments .

Here the patch. There was already made something for it but it was just wrongly placed and not complete.

O no problem a typo can always happen I just sended pull request with the little correction.

@Taapat for the time now I'll did you're way with patch gstreamer for the max hls speed. works well.

I Adapted the 1.9.0.1 recipes on :

https://github.com/c...TREAMER-RECIPES

Two ways :

wheather You include the full packageconfig like it is in the openembedded  ffmpeg + the extras You want,

or just do it like in commit:

https://github.com/O...d15e8960b355f2d

I just tried out the very last gstreamer recipes. 1.9.0.1.

common has been updated and a couple off works on hlsdemux.

I also just made a experimental patch for servicemp3.cpp of enigma2.

Now users are able to adapt the service links for m3u8 channels.

After this patch you can add  option #max-speed  .

The result is that if you're internet connection is ok you will have the max resolution at once.

Tested on vuduo2 and dm8000.

example:

link :

#SERVICE 4097:0:1:0:0:0:0:0:0:0:http%3A//live.rpctv.com/rpctv/tm.smil/playlist.m3u8:tm smil
#DESCRIPTION tm smill

changed into :

#SERVICE 4097:0:1:0:0:0:0:0:0:0:http%3A//live.rpctv.com/rpctv/tm.smil/playlist.m3u8#max-speed:tm smil
#DESCRIPTION tm smill

Update gstreamer recipes on :

https://github.com/c...TREAMER-RECIPES

Unfortunately this player is closed source ???? Not acceptable for  micro bit of code and extremely dangerous for pishing ware and even viruses this especially cause on a stb we working as root .

So long that all this stuff is based on closed source it's a lie at start. And I'll hope pli team will never accept this dangerous till fatal pishing    till deadly malware.

I find updates and improvements fine. I also ahve a dm8000 which can have 4 tuners  (real slots). Ok I only using A and B the build in ones and do not have extra ones installed. But in my opinion : it alwyas worked right 100 % .

Now with new e2 changes Beeker is fased with a very severe (actually blocking issue). Sorry but culprit commits should be reversed or at least adapted very very asap  that there is no regression.

Not so long ago we even have had a same issue about the base setup for a satellite with 4 fixed lnb's but even it was there for a classic two dish lnb.

I reported the problem long before the nightly builds which at the end only botther the standard users. But in despit the fact that I warned pli team just chose to continue  ......

WORSE EVEN they told me that i'm an idiot and this just to have warned for a problem which was real and after a xxx thousand complain is solved ....  ?

Ok better software for dishes and so on but please do not break all which worked ok for 10 years or ... even more.

Oeps I now just found out that There was a error into the bb recipe package handling sorry

Instead of :

inherit gitpkgv
PV = "${GST_VERSION_FULL}+git${SRCPV}"
PKGV = "${GST_VERSION_FULL}+git${SRCPV}"

This must be used

inherit gitpkgv

PV = "${GST_VERSION_FULL}+git${SRCPV}"
PKGV = "${GST_VERSION_FULL}+git${GITPKGV}"

Then SRCREV update will work.

note : the GST_VERSION_FULL is the one mentioned int the gstreamers make ac file.

Currently it is 1.9.0.1 (for the head)

With last openembedded problem with bitbake -b clean or cleanall task.  This task is really important for developpement.

error:

enigma2-2.7+gitAUTOINC+41d0298294-r0 do_cleanall: Taskhash mismatch a535889ad7d347da189568a32e8bd371 verses 8f437e901ddb905c2f7346ff17726841 for /home/christophe/openpli50/openpli-oe-core/meta-openpli/recipes-openpli/enigma2/enigma2.bb.do_cleanall

ok found it the -f from force is not required anymore.

@all

I just builded the very last master-next.

Some minor problems but easy to solve.

My build setup first :

vuduo2

gstreamer recipes:

https://github.com/c...TREAMER-RECIPES

dvbmediasink :

https://github.com/c...ox-dvbmediasink

First minor error replex package needs a patch I just included here my replex adaptation of map:

openpli-oe-core/meta-openpli/recipes-multimedia/replex .

Second error : Yes since the gst-libav now just only builds the gstlibav.so with only the needed wma codecs the libav self and libav format are not build anymore. for gst not required. by us we are using on board codecs.

However some plugins do require the libav since ffmpeg does build them also the selection to build libav has been done by ffmpeg now.

for that openpli-oe-core/meta-openpli/recipes-multimedia/ffmpeg/ffmpeg_3.%.bbappend must be modified to :

RSUGGESTS_${PN} = ""

PACKAGECONFIG ="gpl mp3lame x264 avcodec avformat vpx"

EXTRA_OECONF_append = " --disable-mipsdsp --disable-mipsdspr2 "

Test off images (since it's new openembedded core I always flash that is for tommorow)

Build dm8000 also fine.

I just now tested .

master-next

gstreamer-head off today

multibox-dvbmediasink.

All inclusif live streams are playing.

The only media who does not play is the old wmv. Media made with mediaplayer below 9. (wmv version 1 and 2 but looks that the codecs are not supported on a bcm chipset this means we can't do anything to this whatever player is used)

I just mad a git for recipes.

On :

https://github.com/c...TREAMER-RECIPES

You can find my last full gstreamer recipe bundle I'm using now.