2520 replies to this topic

[christophecvr]

This is exactly why I am hesitant to apply your patches. You have only goal in mind, gstreamer-1 as soon as possible, on your settopboxes. We have other things to consider end-users not accepting it when media playback won't work as it used to. There are also other considerations you don't even know about.

 

And that is why I ask the other participants to test your patches first and if they're ok, I'll apply just the same.

 

If you have a problem with that, I suggest you fork the OpenPLi repository and use that as playground, with or without other participants, I don't have a problem with that approach at all.

 

The whole adaptation for multibox can't be done in one patch. O yess it can but ..... (bugs and there will be some). As the mather off fact all the changes are only for other boxes then the only supported by openpli is ET. The only general part is the eos patch from xml3 which by the way also never was applied in despit the fact it was asked and he give the perfect ok git patch which was ready to push. Now we are much further already.

 

To avoid the stuck in developpement like it is now I needed to set an appart git  If you're interested perhaps better fork openpli gst-1.0 dvbapimediasink to my git. At least we can go on . Otherwise like it is done now I gues in the year 3000 we still will run with gst-0.10 in pli4. Perhaps I maybe even can add in that multisink a special --with-etserie  . And the goal is just to have a good gst-1.0 polivalent dvbmediasink. It is done on purpose with #ifdef  to avoid having a to big library with irelevant code for the targetbox.

[babsy98]

image builder like me its not a big job to add the patch to local build folder, problem allways the user can´t build image , to complex , less linux know or less time to read all

 

we get in atv forum first user response all positive but me must wait, we have start to include last updates for one day so one.. two weeks and we have more feedback

[WanWizard]

We need a proper development environment first, there is already too much fiddling going on in the live branch, with a lot of misery as a result.

[christophecvr]

@Erik Slagter

This is exactly why I am hesitant to apply your patches. You have only goal in mind, gstreamer-1 as soon as possible, on your settopboxes. We have other things to consider end-users not accepting it when media playback won't work as it used to. There are also other considerations you don't even know about.

Nice political answer which again makes any sense. And yes I do have in mind gst-1.0 as soon as possible as the mather off fact vuplus is no knock out with base gst-0.10 on pli4. But You're completely mistaken with "on your settopboxes". I'm working for ALL BOXES. I just only can test on vuduo2 and dm8000 . Unlike pli which is only working concerning dvbmediasink-gst1.0 ONLY FOR ET BOXES.

 

The gst-1.0 sink is "EXPERIMENTAL" and whitout any patch applied it will never evoluate. Like it is now it just as usseles as it was 1 year ago. Only the very limited boxes ET seems to work. If it was the MASTER stable git ok then it makes sence but for the EXPERIMENTAL git ........ Sorry but you're answer makes no sense att all.

 

Well and this " There are also other considerations you don't even know about."

 

Are You jocking or what .... Don't say such a thing whitout saying what.  And do not start with the idiot driver issue as this has really nothing to do whit this an interface != a driver. the interface needs to be adapted to the driver.

[malakudi]

@christophecvr: The main issue is that currently OpenPLi does not have a stable/experimental image separation. So, a change to gstreamer 1.4.X cannot happen unless every piece is updated. You understand that while many people will find the change usefull, also many will start complaining if some files that worked before now don't work, if hbbtv does not work etc etc.

 

We definitely need two images, one stable and one experimental, but I guess this would require more bandwidth and disk space on the feed servers, compiling resources on the build servers etc etc and these things cost.

[christophecvr]

@christophecvr: The main issue is that currently OpenPLi does not have a stable/experimental image separation. So, a change to gstreamer 1.4.X cannot happen unless every piece is updated. You understand that while many people will find the change usefull, also many will start complaining if some files that worked before now don't work, if hbbtv does not work etc etc.

 

We definitely need two images, one stable and one experimental, but I guess this would require more bandwidth and disk space on the feed servers, compiling resources on the build servers etc etc and these things cost.

THink You're missed something.

 

Now we are working with gst-1 branch for openpli-oe-core. Any change to it will never apply to the current master git.

For the dvbmediasink we are working with branch gst-1.0. not any change in it will affect the working on master.

 

They al are experimental none off them are published and or used in beta devellopement.

 

As the mather off fact how they are now it's just zero . the dvbmediasink only ver very very limited ok for ET . x-raw wav file complete us. But yes nice work from xml3 not applied to git.

The gst-1 openpli-oe-core branch . Very incomplete concerning enigma2.bb gstreamer1.0 -pluginxxxx adds. and even a wrong non exeisting plugin added.

Then the packages build off gstreamer1.0 and all concerned plugins ... are just heavely incomplete. with result that even if the dvbmediasink is right it still won't work.

 

The details where not passed only one time to the Mod's and or Core members but a dozen and 100 hundred times. With extreme detailed explanations proved solution in really detail. And on top of it with very complete good commented and pure patches for the git's . Never applied.

 

For shure You're complete irelevant comment here is again a prove the by Core team Mods team and or Betateam. There is absolutelly no any will to let it work.

 

Even You are just proving the contrary breaking down everything. Every real contributor to this toppic wheater they are testers(and real  good testers) or helpers in developement have been sendd home with complete irrelevant comments. It's not for nothing that during one and a halve year no any ussefull stuff came out of it.

 

Each time someone brings in a good issue it is directly ignored by the pli team. They brake it down . And there comments and reasons if ever they give one are completely idiot irrelevant and really wrong.

 

In the year 3000 pli team will still be with gst-0.10 . And not any codec will not work.

 

Like now they with the latest openembedded upgrade fucked up all vuplus ok its the software codecs which are really needed. Unfortunatelly not working soft codecs anymore on pli. master and not any advanced box will be able to use it.

 

To patch the old software codecs tools an extra time to make it able to use modern software codecs well go ahead whithin the coming year it will be 0 point 0.

 

But really thank's for You support gues I will have to give it up such as I already did and the majority off contributors one Year ago.....  OK THATS WHAT PLI TEAMS WANT wel i will not this time.

 

I continue the positif work with my made git and with positif contributing testers or dev's and not anymore with downbreakers and negatif irrelevant commenters.

[babsy98]

here a patch gst 1.4.5 for all dags models

 

i have test and work with atv

 

 

Attached Files

•  0001-add-support-for-dags-models.patch   5.22KB   13 downloads

[betacentauri]

Hi guys,

please calm down a little bit. I guess we have the same goal and don't want to spend time fighting each other.

If all patches are against gstreamer 1.x branches I see no problems applying them, because it cannot have negative side effect to normal pli user. Perhaps that was not clear enough.
@christophecvr: Can you perhaps write which patch should be applied to which branch and then hopefully everything is clarified.

[peteru]

here a patch gst 1.4.5 for all dags models
 
i have test and work with atv

I can see how maintainers would have a problem with a patch like this. There is zero information about why the patch is needed (i.e the problem that is being solved), what it does (i.e how it solves the problem) and how to test that it works as intended.

As a maintainer of the source code I would want to know why this patch should be applied, how it works and how I can test it's effectiveness, both on the target platform and also to make sure there are no unwanted side-effects on other boxes.

Other projects also have an issue with proper authorship attribution and require the Signed-off-by: field. I have seen my changes included in various oe-alliance repositories, attributed to other people. That would be a big issue in projects like OpenEmbedded.

[babsy98]

i understand keep your patch and dont mess up pli it's this correct ?

[christophecvr]

here a patch gst 1.4.5 for all dags models

 

i have test and work with atv

 

I've seen You're patch. But really no need to ad the whole string.

 

I added You're patch modified to my git

 

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

 

Are You shure that streamtype from dags box and bypass is equal to that off ET box ?

[mx3L]

In attachment same preroll patch as before but with more detailed explanation

 

Attached Files

•  0001-dvbmediasink-hold-PREROLL_LOCK-on-passing-EOS-to-bas.patch   2.62KB   9 downloads

[littlesat]

There are many patches published here.... It would be nice to have an overview about our "backlog" because at least I do mot see anymore what is mendatory and what not....

[christophecvr]

There are many patches published here.... It would be nice to have an overview about our "backlog" because at least I do mot see anymore what is mendatory and what not....

Well take a look on

 

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

 

The Prerol patch from mx3L is inbedded in the set to multibox commit. Sorry it's not an appart patch anymore But that's due to the PLI team we are not waiting another year and a half before any progress is made concerning gts-1.0

And I've been forced to create a git self.

[christophecvr]

And this multibox commit is nothing else then this patch. Sorry was very well commented

 

What is done From who and really mentioning that it was for gst-1.0 branch Not the master like Erik is telling in his comments whitout sence.

 

 

Attached Files

•  0001-0002-eos-vuplus-dreambox-3.patch   10.76KB   6 downloads

Edited by christophecvr, 17 March 2015 - 08:18.

[christophecvr]

Hi guys,

please calm down a little bit. I guess we have the same goal and don't want to spend time fighting each other.

If all patches are against gstreamer 1.x branches I see no problems applying them, because it cannot have negative side effect to normal pli user. Perhaps that was not clear enough.
@christophecvr: Can you perhaps write which patch should be applied to which branch and then hopefully everything is clarified.

 

I did this really several times so did mx3L. In patch is clearly mentionned what is done and why and the branch.

I did told I really can't tell how many times which branch.

I did mentioned what is missing in the openpli-oe-core BRANCH gst-1 EXPERIMENTAL enigma2.bb file with extreme details.

The patch at the end becomes to big to follow up.

 

Calm Down ??? well that's what was done during one and a half year, almost nothing happened.

[babsy98]

vu update drivers for new subsink

 

update proxy drivers and utils
20150317
- Support new Gstreamer sink interface(OE update will follow)
- Fix blurred graphic problem

[malakudi]

@christophecvr: You misunderstood what I wrote. I know your patches are for the gst-1 branch. But since there is no daily build of experimental images for people to try, the progress in using gstreamer 1.4 will take some more time. Anyone who wants it "right here, right now" can of course fork OpenPLi and start building and distributing test images for people to try.

About your patch, it is clear that OpenPLi core team do not want to implement code with (if dreambox, if vu, if whatever), unless absolutely necessary. While you can disagree with this approach (and I have disagreed in the past), you can't change their point of view. In OpenPLi's point of view, the hardware manufacturers should make their drivers (the only thing they develop after all) "compatible" with OpenPLi and not the other way around. So, the ifdef dreambox etc is difficult to get in the code.

 

edit: and if VU+ does indeed make their drivers compatible like it seems they are going to do, then only dreambox will not be supported, which, of course, we don't care. They choose the path of not being open source.

Edited by malakudi, 17 March 2015 - 09:23.

[mx3L]

@christophecvr

 

I was looking into 0001-0002-eos-vuplus-dreambox-3.patch, and I think you should separate my patch from it, there is no reason to bundle everything into one big patch.

Also is this neccessary?

diff --git a/gstdvbaudiosink.c b/gstdvbaudiosink.c
index 2725def..9cd12e0 100644
--- a/gstdvbaudiosink.c
+++ b/gstdvbaudiosink.c
@@ -74,9 +74,15 @@
#include <poll.h>
#include <stdio.h>

+#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

Other then that I think patch looks fine, maybe you could add more info to commit message about where did you get DREAMBOX and VUPLUS specifics (dreambox/vu+ dvbmediasink I assume)

 

@littlesat

1. recommended - http://forums.openpl...ndpost&p=480012

2. important - http://forums.openpl...ndpost&p=481794

Edited by mx3L, 17 March 2015 - 09:40.

[peteru]

i understand keep your patch and dont mess up pli it's this correct ?

 

I don't know what pli's policies are. When I submitted my patches to OpenPLi, I had to provide more info about them and wait a while before they were accepted. I did not find it all that strange - clearly this is a small scale project, so resources are limited and turn around time can be long if people are busy with real life.

 

I do know that other projects, such as the Linux kernel, Bitbake, OpenEmbedded, GStreamer, Samba, etc. would not even consider a patch submission like the one I commented about. It's just not good enough for high profile projects. OpenPLi and OE-Alliance have much more relaxed standards.