2520 replies to this topic

[theparasol]

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

[Rob van der Does]

It's not yet in our bsp.

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

[christophecvr]

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

[malakudi]

 

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.

[Erik Slagter]

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.

[metoo]

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?

[littlesat]

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....

[Erik Slagter]

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.

[christophecvr]

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.

[christophecvr]

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)

[hemertje]

Just stop supporting DMM

[christophecvr]

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.

[peteru]

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.

[Beeker]

@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.

[MastaG]

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?

[Beeker]

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

•  GST-1-VUPLUS-DREAMBOX-GITPATCH-20150317-2.patch   13.28KB   6 downloads

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

[MastaG]

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

[Beeker]

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.

[christophecvr]

@Beeker, should be fixed now

[Beeker]

@Beeker, should be fixed now

 

Yes that is better. Thanx.

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