Jump to content


Photo

GStreamer 1.0

gstreamer 1.0 openpli

  • Please log in to reply
2520 replies to this topic

Re: GStreamer 1.0 #1021 theparasol

  • Senior Member
  • 4,157 posts

+198
Excellent

Posted 11 April 2015 - 11:54

That happens if you have to do something more than  copy / paste from others ;)


@Camping: ZGemma H.2S, Technisat Multytenne 4-in-1 @Home: Edision Mini 4K, Wave Frontier T55, EMP Centauri EMP DiSEqC 8/1 switch, 4x Inverto Ultra Black single LNB


Re: GStreamer 1.0 #1022 Rob van der Does

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 11 April 2015 - 13:07

It's not yet in our bsp.

Then you have to wait again for others to do this minor job.....

Re: GStreamer 1.0 #1023 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 11 April 2015 - 16:03

Well with further test on dm8000, with dts_dowmix.

 

I found out that. That synchro issue is due to the fact that when audio starts playing kernel think video is not ok. (whats not really like that). This result in the skip off first audio pts  and al is screwed (for nothing).

 

As test I inserted a routine to let the audio only starts after video is started. It just for my test only occurs after a pauze. But then yes cause audio is not running video does not start and enigma2 ends in sandkeeper (not crash just hang in a loop). And since video is not started then audio can't unpause. If this is away audio starts unfortunately video starts only after audio and then we have this uneeded kernel error first pts is skipped.

 

Bloody hell



Re: GStreamer 1.0 #1024 malakudi

  • Senior Member
  • 1,449 posts

+69
Good

Posted 11 April 2015 - 17:07

 

It's not yet in our bsp.

Then you have to wait again for others to do this minor job.....

 

It's not in bsp and it can't get in bsp since openpli is still on gstreamer 0.10 . I think the time has come for a switch. I've been using the experimental OpenATV 5.0 for the last days and works great on VU+ Solo2 and Duo2.



Re: GStreamer 1.0 #1025 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 11 April 2015 - 18:07

For a switch to be considered, it would greatly help to know what brands/models are fully working. For us it's not acceptable if it only appears to work on a small row of receivers.

 

So I suggest we start to build a list of tested and proven brand/models combo's. Especially the DMM are interesting because their bsp isn't maintained actively.


Edited by Erik Slagter, 11 April 2015 - 18:07.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: GStreamer 1.0 #1026 metoo

  • Senior Member
  • 1,573 posts

+33
Good

Posted 11 April 2015 - 18:15

isn it easier to freeze the builds with gst 0.1 and start building with gst 1.45, so people that dont like gst 1.45 can go back if they dont like it?


ET10000 C C C C/T  2TB HDD ET7000 + ET6000 dvb-S  OpenPli Triax 88 multifeed quad LNBs VU Uno4K SE C+2TB HDD Mutant HD60


Re: GStreamer 1.0 #1027 littlesat

  • PLi® Core member
  • 57,101 posts

+698
Excellent

Posted 11 April 2015 - 18:22

Or arrange that the gstreamer type could be added via the bsp layer... enigma2 is al least build that way that it can use both gstreamer releases as far I understood.... So only "switch" the boxes that properly support it....


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: GStreamer 1.0 #1028 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 12 April 2015 - 08:56

Something like that. The only drawback is that the manufacturers need to adjust the bsp's. We can speed up that process by supplying ready-made patches that have been tested already. The xp1000's bsp is in our own repo, so we could use that as guinea pig.

 

The first step is to decide on a mechanism end-to-end to use.

 

IMHO the first step would be to decide on a machine_feature. Would it better to simply a machine_feature gstreamer_1 or something like gstreamer_0_1 (which would then be default for the bsp's not defining it) and gstreamer_1_4 etc, to ease possible future upgrading procedures, where we could introduce e.g. a gstreamer_2 feature.

 

Next step would be to decide on a procedure to incorporate all this into the building procedure. The machine_features are only available in the bitbake recipes, not for example in the enigma source, which is a known issue.

 

Also, would it be possible to build both gstreamer versions from one branch, or would we need to keep the old branch around for old builds. If the first is possible, we would need to be very cautious not to break anything existing.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: GStreamer 1.0 #1029 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 12 April 2015 - 12:39

That's a good idea the mechanism for end use , to overthink this seriousely .

 

How to proceed is very important to avoid to many different ways, which at the end leads to confusion in build.

 

Some hints.

 

I would keep enigma2 with both posybility's. With a mains gstreamer 0.10 like now , or gst-1  group (leave open further gst upgrades and eventually make a possibilitty to step to gst-2 when ever this appears).

The dvb-mediasink. I would really split it in one sink only gst-0.10 other only gst-1.xxxx .

for the gst-1.xxx dvbmediasink I suggest to add specific machine support. By using in in configure ac the avbl info exact machine. (vuduo or vuduo2 or sole or etxxx xpxxx ). Then the real compiled code is depended on the machine type.

This will lead to a sink at optimum performance for each machine.

 

Then during build which sink is taken is depended on the machine feature.  Also the bsp can be adapted to use gst-0.10 or gts-1.xxx in function off the base machine-feature.

 

For the subsink I would do a similar thing.

 

This all are only hints and would be nice that brainstorm about thi is done.

 

p.s about sample rate, Further findings. 48000, 96000 or 192000. 

Difference between 48000 and 96000 . Clear to hear (for classic music off quality). is proven with blind tests. is trough. (and this already thirty years ago I found it back in one off my course when a studied master analogic technics wave course)

Difference between 96000 and 192000 . Seams indeed only to be a commercial trick. In the physical wave representation it can be seen. As for hearing it has never been proved. 

As far I found out the current linux/dvb/audio  driver only handles two max rates . 48000 or 96000 . that's it. So actually depending off box 48000 or 96000 should be set. Trough hdmi You can hear it.



Re: GStreamer 1.0 #1030 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 12 April 2015 - 13:33

I just pushed a change to :

 

https://github.com/c.../commits/master

 

It works but by dm we will have to live with that bloody delay upon sync.

 

It is caused by a dm kernel/driver bug. Has been reported already several times to dreambox. They never did something to it.

 

I tried so what everything to work around this bug but could not find any solution.

 

At least now modern mkv videos with high VQ stream play's (with acceptable sound). Unfortunately with same errors like the old dtsdownmix.

 

I stop loosing my time with that dreambox issue.

 

More going to actuall stuff on vu now like the new (and finally avbl  hbbtv for gst-1)



Re: GStreamer 1.0 #1031 hemertje

  • Forum Moderator
    PLi® Core member
  • 33,503 posts

+118
Excellent

Posted 12 April 2015 - 15:40

Just stop supporting DMM ;)

on the Glassfibre 1GB DVB-C...


Re: GStreamer 1.0 #1032 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 12 April 2015 - 16:46

Just stop supporting DMM ;)

I very tempting thing especially cause dm starts to go his own closed source way . It's obvious that new types of dm will never be supported anymore in open source images. BUT :

 

We still have a lott of dm8000 and dm800se who are working with linux kernels above 3 and do have the drivers adapted to it ok with there bugs in which dm does not want't to solve, ... but still.

 

Let's speak about the dm harware self first.

 

1) price was very expensif ok but the components in where all ok and quality . Ok some base chips used the bcm is bcm that's it. But all the rest around needed to use the chip was from good quality. In those days a lot of manufacturers put lower quality for those components which causes very fast deterioration off the stb and unstable creepy issues.

 

Take a look on only the power supply off dm8000. You can't find any other box which such a quality power supply. Very high quality components. They make it also all more then needed at begin and that's good as in time you always have a deterioration off componenents and this is much much slower if they work in general at half capacity. And on top of it a capacitator can have very different prices for same specifications that's going up for resistor also and the diodes .

 

Only for this You could make a power supply very cheap which looks ok at first but will not take very long and even destroy further electronic components during use due to poor stability and deterioration. For about 30 E . Or You can choose for a power supply with good componenets long live , well it may go up to 200 E for same.  See vu they lost a big part of market just for that reason cheap power supply.

 

2) My dm at least does run (in despit from liitle things we discusing now) much better with openpli then any original dm image.



Re: GStreamer 1.0 #1033 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 12 April 2015 - 17:28

for the gst-1.xxx dvbmediasink I suggest to add specific machine support. By using in in configure ac the avbl info exact machine. (vuduo or vuduo2 or sole or etxxx xpxxx ). Then the real compiled code is depended on the machine type.
This will lead to a sink at optimum performance for each machine.

That's back to front. The dvbmediasink code and configure scripts should only ever care about the features, such as max sample rate or supported data formats. The machine specific configurations for each box (and possibly for each driver release) should then define what is supported.

 

It is entirely conceivable that a driver update will introduce additional support for features that were not available in previous releases. For example, the Beyonwiz drivers added support for new video and audio formats in the past and may add more in the future. It would be wrong for dvbmediasink to assume that the feature set will always be the same for a specific machine.


"Beauty lies in the hands of the beer holder."

 


Re: GStreamer 1.0 #1034 Beeker

  • PLi® Contributor
  • 1,602 posts

+203
Excellent

Posted 12 April 2015 - 19:22

@Christophecvr

After your latest commit, i get this error when compiling:

openpli-oe-core/build/tmp/work/dm8000-oe-linux/gstreamer1.0-plugin-multibox-dvbmediasink/1.0+gitAUTOINC+a6f32d18d2-r0/git/gstdtsdownmix.c:205:10: error: 'GstDtsDec' has no member named 'start_ok'
|    if(!dts->start_ok)
|           ^
|openpli-oe-core/build/tmp/work/dm8000-oe-linux/gstreamer1.0-plugin-multibox-dvbmediasink/1.0+gitAUTOINC+a6f32d18d2-r0/git/gstdtsdownmix.c: In function 'gst_dtsdec_change_state':
| /home/hains/Gstreamer1.0/openpli-oe-core/build/tmp/work/dm8000-oe-linux/gstreamer1.0-plugin-multibox-dvbmediasink/1.0+gitAUTOINC+a6f32d18d2-r0/git/gstdtsdownmix.c:891:8: error: 'GstDtsDec' has no member named 'start_ok'
|      dts->start_ok = 0;
|         ^
|openpli-oe-core/build/tmp/work/dm8000-oe-linux/gstreamer1.0-plugin-multibox-dvbmediasink/1.0+gitAUTOINC+a6f32d18d2-r0/git/gstdtsdownmix.c:898:8: error: 'GstDtsDec' has no member named 'start_ok'
|      dts->start_ok = 0;
|         ^
|openpli-oe-core/build/tmp/work/dm8000-oe-linux/gstreamer1.0-plugin-multibox-dvbmediasink/1.0+gitAUTOINC+a6f32d18d2-r0/git/gstdtsdownmix.c:903:8: error: 'GstDtsDec' has no member named 'start_ok'
|      dts->start_ok = 1;
|         ^
| Makefile:580: recipe for target 'libgstdtsdownmix_la-gstdtsdownmix.lo' failed
| make[1]: *** [libgstdtsdownmix_la-gstdtsdownmix.lo] Error 1
| make[1]: *** Waiting for unfinished jobs....



Previous commit bc45f6e2ad4bc86f642edf3ce064690214cedba(Set get_decoder_time_patch for dreambox) is ok.


Dreambox dm920, Uclan Ustym4Kpro, Gigablue UHD TRIO 4K and Dreambox dm8000. Wavefrontier T55 13.0|19.2|23.5|28.2 + Ziggo.


Re: GStreamer 1.0 #1035 MastaG

  • Senior Member
  • 1,531 posts

+118
Excellent

Posted 12 April 2015 - 22:09

So quick (and probably stupid) question.

I'm building for dm800 with:

MACHINE_EXTRA_RRECOMMENDS = " \
    gstreamer1.0-plugin-dvbmediasink \
    ntfs-3g \
    kernel-module-cifs \
    kernel-module-hmac \
    kernel-module-md4 \
    kernel-module-ecb \
    dreambox-boot-progress \
    "

In my dreambox.inc.

 

But it still builds gstreamer 0.10 next to 1.0..

How can I get rid of 0.10?



Re: GStreamer 1.0 #1036 Beeker

  • PLi® Contributor
  • 1,602 posts

+203
Excellent

Posted 12 April 2015 - 22:30

You need to adapt more.

 

Use the attached patch in this post.

 

Maybe you have to remove this part out of the patch due to changes in the gst-1 branch.

 

 MACHINE_FEATURES += "alsa usbhost 3dtv switchoff tpm dreambox"
 # Add "dreambox" override for recipes
diff --git a/meta-dream/recipes-bsp/drivers/dreambox-blindscan-utils_1.7.bb b/meta-dream/recipes-bsp/drivers/dreambox-blindscan-utils_1.7.bb
index f7df0a0..30e93d4 100644
--- a/meta-dream/recipes-bsp/drivers/dreambox-blindscan-utils_1.7.bb
+++ b/meta-dream/recipes-bsp/drivers/dreambox-blindscan-utils_1.7.bb
@@ -8,9 +8,9 @@ DEPENDS = "ncurses"
 
 PR = "r3"
 
-SRC_URI += "http://dreamboxupdat...{PACKAGE_ARCH}"
-
-S = "${WORKDIR}/blindscan-utils_${PV}_${PACKAGE_ARCH}"
+SRC_URI += "http://dreamboxupdat...{TUNE_PKGARCH}"
+
+S = "${WORKDIR}/blindscan-utils_${PV}_${TUNE_PKGARCH}"
 
 PACKAGES = "${PN}"

 

 

But remember, In case of dreambox, it is for DM8000/DM800se only.

Attached Files


Edited by Beeker, 12 April 2015 - 22:33.

Dreambox dm920, Uclan Ustym4Kpro, Gigablue UHD TRIO 4K and Dreambox dm8000. Wavefrontier T55 13.0|19.2|23.5|28.2 + Ziggo.


Re: GStreamer 1.0 #1037 MastaG

  • Senior Member
  • 1,531 posts

+118
Excellent

Posted 12 April 2015 - 23:09

I see, so that's the only patch I need for building for dm800se after cloning the gst-1 branch right?



Re: GStreamer 1.0 #1038 Beeker

  • PLi® Contributor
  • 1,602 posts

+203
Excellent

Posted 12 April 2015 - 23:15

I see, so that's the only patch I need for building for dm800se after cloning the gst-1 branch right?

 

As far as i know yes.


Dreambox dm920, Uclan Ustym4Kpro, Gigablue UHD TRIO 4K and Dreambox dm8000. Wavefrontier T55 13.0|19.2|23.5|28.2 + Ziggo.


Re: GStreamer 1.0 #1039 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 12 April 2015 - 23:16

@Beeker, should be fixed now



Re: GStreamer 1.0 #1040 Beeker

  • PLi® Contributor
  • 1,602 posts

+203
Excellent

Posted 12 April 2015 - 23:20

@Beeker, should be fixed now

 

Yes that is better. Thanx.


Edited by Beeker, 12 April 2015 - 23:22.

Dreambox dm920, Uclan Ustym4Kpro, Gigablue UHD TRIO 4K and Dreambox dm8000. Wavefrontier T55 13.0|19.2|23.5|28.2 + Ziggo.




7 user(s) are reading this topic

0 members, 5 guests, 0 anonymous users


    Google (1), Bing (1)