2520 replies to this topic

[MiLo]

We *should* be able to use the mainstream OE gstreamer. We may need some bbappends for package configuration options. If there are any problems/bugs, it's best to submit them upstream directly in to OE-core.

[christophecvr]

We *should* be able to use the mainstream OE gstreamer. We may need some bbappends for package configuration options. If there are any problems/bugs, it's best to submit them upstream directly in to OE-core.

Yes to use the oe-core gstreamer, is a good idea. Actually I did proposed this already 3 months (maybe 4) ago.

 

But then the next question is . The git or fixed tar packages.

 

Problem with the fixed tar , is that there are bugs in it. They are solved on git version. Current master is still att 1.4.5 .

[Erik Slagter]

But then the next question is . The git or fixed tar packages.

Using fixed tar's would be at least ehhhh unpractical. Just use gstreamer from OE like MiLo says.

Edited by Erik Slagter, 27 April 2015 - 16:05.

[christophecvr]

 

But then the next question is . The git or fixed tar packages.

Using fixed tar's would be at least ehhhh unpractical. Just use gstreamer from OE like MiLo says.

 

gues You not follow.

 

There are two types off gstreamer1.0  in OE-core. One is git the other fixed tar.

[betacentauri]

Both have advantages and disadvantages:

- Patches for git version may become unusable when git changes. Fixed tar don't have this problem.

- Patches for fixed tar are needed. Applying latest patches is maybe difficult because affected files were changed by different commits.

- ...

 

To be sure that build always works, you should use fixed tar. If you don't mind that sometimes a build can fail, you can use git version.

[daif01]

 

Ah I see, I missed it, since it was on the previous page.

Well using the HEAD branch there is much improvement.

 

I've built an image for dm800 and dm800se with:

- All patches of the previous posts applied

- ca-certificated, gdb and openuitzendinggemist included

- christophecvr's multibox mediasink with mx3L's patch: 'self->must_send_header = TRUE;'

 

So far:

- HLS switches to a higher bitrate more smooth

- Smooth does not segfault anymore, however:

http://mediadl.micro...0p.ism/Manifest <- this video plays but it's all blocky

http://playready.dir...20.ism/Manifest <- this video only shows the first frame and freezes

- MPEG-Dash streaming needs some further testing since I only have one url to play with.

- OpenUItzendingGemist works except for RTL XL Gemist, it will buffer until 100% and then stall.

 

If anyone would like to play with it:

openpli-enigma2-4-dm800se.nfi 54.5 MB

https://mega.co.nz/#!G1VgyJzI!n8iZ-pqwcSNXWsA7jz8Asl8wtK1rveLpKbs8YceMKtU

 

openpli-enigma2-4-dm800.nfi 51.0 MB

https://mega.co.nz/#!zx8wSIoB!jYnyjcKNdnmCijs-4OXZBzFtHPQG_TKsaxQBQjOsP0s

 

Please could  you test this stream ( http://live.kurdstre...p/playlist.m3u8 )

Itried with openpli , openatv, satdreamgr image , the same issue video freeze after about 5 min, only audio, i tried with resolution 720 but same issue. the question is it possible to adjust the stream so that enigma 2 can manage ti ? Does karwan tv (http://karwan.tv/kurdmax-tv.html ) use the same source to stream the channel? Thanks in advance.

[mx3L]

 

But then the next question is . The git or fixed tar packages.

Using fixed tar's would be at least ehhhh unpractical. Just use gstreamer from OE like MiLo says.

 

So we should remove gstreamer1.0 recipes fixed for our needs from meta-openpli and instead use gstreamer1.0 recipes from oe-core and adjust them for our needs with bbappends in meta-openpli? How can somebody do custom local changes(meta-local) without modifying bbappends in meta-openpli? Is it possible to do bbappend on top of another bbappend, and if so would'nt it be kind of messy? Isn't it better to sometimes cherry pick what we need from oe-core to our recipes in meta-openpli?

 

git vs tar - maybe we can use git and set SRCREV to specific commit, this way we can get basically same behaviour as with tar if we set SRCREV to commit as was tar created, right?

[christophecvr]

For me whatever. But It would be good to have one standard. Eventually the git with a fix rev why not. The tar packages are really to behind and do have famous bugs.

[athoik]

Mine opinion is close to @mx3L opinion. Better to go with GIT and fixed SRCREV.

 

It is better to keep our local "GStreamer recipes" because we need the freedom to adapt more frequent than oe-core does. Although "cherry-picking" updates from oe-core is not bad.

 

Also we need to tune "GStreamer recipes" based on our needs (eg remove x11, cairo and so), it can happen using bbappend, but it's better using our bb.

 

Today we have GStreamer 1.0 working thanks to this thread and thanks to people contributing here (although I was hoping things to move on faster).

 

If @OpenPLi believes that beta milestone has come, then please adapt and start (actively) support Gstreamer 1.0.

[MastaG]

So to clear things up, what do the OpenPLi members expect from gstreamer 1.x ?

 

In my opinion it would be streaming related enhancements/features.

 

From my limited testing on the dm800se:

+ I gained HLS streaming with support for multibitrates/chunks

- Broken smooth streaming

- Broken mpeg-dash

- segfault when playing h265 videos

- Broken TSMedia 9.3 only video, no audio (of course this doesn't have to be a gst issue, but can also be related to the way TSMedia serves videos to gstreamer)

 

So if I were the average Joe, I wouldn't be that happy (no disrecpecting intended).

 

I have an idea:

Let's say I would do a clean checkout of gst-1 with only minor enhancements for all boxes:

* Set gstreamer1.0-plugin-dvbmediasink instead of the default 0.10 sink.

* Set: GST_VERSION = "1.0"

* Include a manual install of TSMedia 9.3 (just the 'TSmedia' /usr/lib/enigma2/python/Plugins/Extensions and the config dir in /etc)

* Include python-gdata and python-html (to satisfy TSMedia)

* Optionally include gdb if it can be of good use

* Compile a list of public internet streams in a tv bouquet for people to play with (maybe mfaraj can help me with that)

- No custom patches to enigma2

- No custom multibox sink or other dmm or vu+ related patches (and I'll shutup about the dm800 )

 

Then just compile for each and every receiver from time to time, upload it and publish the urls here with a small note:

"In order to help testing, please telnet into your receiver and issue a:

init 4

enigma2

Then play your favorite streams and report back any issues in this thread"

 

Then we can get it to a wider audience and maybe get some useful input wether it's good for primetime.

 

I'm willing to do this task if anyone finds it'll help the project.

[christophecvr]

unfortunately No custom multibox sink those are needed for dm8000 and dm800se.

[mx3L]

@MastaG

Just some points:

 

- Broken smooth streaming - not working in 0.10

- Broken mpeg-dash - not working in 0.10

- segfault when playing h265 videos - probably same issue in 0.10

- Broken TSMedia 9.3 only video, no audio (of course this doesn't have to be a gst issue, but can also be related to the way TSMedia serves videos to gstreamer) - be specific, post links to video, does the same media work in 0.10

 

I can say from my tests on et4000 and et6500 that every media which plays on 0.10 is working also in 1.0.

Edited by mx3L, 27 April 2015 - 22:15.

[athoik]

I tested some h265 files and dvbmediasink is not plugged at all, but there is an error in gst-launch (I will post tomorow).

Here you can find samples:
http://www.elecard.c...oad/videos.html
http://www.h265files.com/

[MastaG]

@christophecvr,

Yes I know that bro and I'm greatly thankful for your work and will always continue to use your sink for my own projects (just like oe-alliance does if I'm not mistaken).

But I think the OpenPLi team are not very dreambox-friendly (e.g. no ac3 bypass).

So I think we need some word from the OpenPLi team wether they're going to include your sink for Dreambox and VU receivers (or maybe backport the code to the official sink).

If not, then I still need to compile test-images for VU and DMM without your sink and maybe we can continue your enhancements in a seperate thread for DMM and VU?

 

In my opinion they should just include your fixes or make a decision to either drop support for DMM or continue building DMM images with gst 0.10.

No point in using gstreamer 1.x for official DMM images if it's going to make it worse I guess (but we can always blame it on the drivers ).

 

But that's not up to me.

 

@mx3L,

Points well taken.

Well I tried using TSMedia to play two different videos h264 / aac audio in a mkv container from two different sources using different addons.

And I was using the gstreamer head branch so it wasn't even a clear test case.

 

I'll do more testing later this week, that's why I wanted to help contribute by building testing images for each supported receiver with minimal changes (only including testing streams and TSMedia so we can get some feedback).

Edited by MastaG, 27 April 2015 - 22:28.

[betacentauri]

I tested some h265 files and dvbmediasink is not plugged at all, but there is an error in gst-launch (I will post tomorow).

Here you can find samples:
http://www.elecard.c...oad/videos.html
http://www.h265files.com/

 

There are several patches for h265 in latest git:

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

[athoik]

Regarding MSS with UTF-16: http://cgit.freedesk...f9bcb07c5ece2c0

typefinding: detect MSS manifests without using g_convert()
Embedded systems often have limited charset conversion
functionality, so don't rely on g_convert() (i.e. iconv)
for UTF-16 to UTF-8 conversions, we can easily enough do
that ourselves by converting to native endianness and
then using GLib's helper functions.

It seems that they fix it after reporting the issue on IRC.

Edited by athoik, 28 April 2015 - 05:56.

[christophecvr]

Regarding smoutstream and dash.

 

On vuduo2 everything runs fine 100 % no hickups.

 

This with the latest gstreamer-1.0 master up to date today. Fresh flashed box. I used my gstreamer-plugin-multibox-dvbmediasink, but for vu You can also use that from pli.

gst-launch-1.0  playbin uri=http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-avc1-high_profile.mpd
gst-launch-1.0 playbin uri=http://mediadl.microsoft.com/mediadl/iisnet/smoothmedia/Experience/BigBuckBunny_720p.ism/Manifest 
gst-launch-1.0 playbin uri=http://playready.directtaps.net/smoothstreaming/SSWSS720H264/SuperSpeedway_720.ism/Manifest

the audio only also ok.
gst-launch-1.0 playbin uri=http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-audio.mpd

On the dm8000 not so good

 

Image block's sound horrible(if there is any).

 

Gues it's the dm8000 resources are to limited to play such media.

 

For vuduo2 we are as far I could test 100 % with everything concerning gst-1.0 . And very much better then the old gst-0.1.

 

For dm8000 the demanding streams are not working that well , but I gues it's not the gstreamer, enigma2 or dvbmediasink but the to limited box resources. Especially not enough ram.

All the rest plays fine on dm8000 and for the video and audio that works , it's better then with the old gst-1.0.

 

Now there should other persons test on xp1000 and the et series.

 

I well think that for early et series and a couple others the same issues as on dm will be there.

 

A note : All media which does not run ok on dm8000 with gst-1.0 did not on gst-0.1.

Edited by christophecvr, 28 April 2015 - 06:29.

[littlesat]

But do you think it is release ready now???

[christophecvr]

But do you think it is release ready now???

 

Well yes and no. Some things needs really to be finally decided.

 

1) The gstreamer-1.0 version git dynamic, git with fixed rev or the fixed tar.gz.

    - Dynamic is to many updates and case off server drops it will be again package which breaks daily builds. Not really ok

    - Git with fixed srcrev looks the best to me but wich rev will we use ?

    - The fixed tars pretty behind and with a couple off severe bugs . That's the worst way but stall a way.

 

2) The dm800se (Athoik). The dm8000 and vuduo2 tested by me .

     What with the other boxes , Et series Xp1000 and ... Seems not very much testers there.

     As the mather off fact I don't have a clou if it's working on those boxes.

[athoik]

Hopefully today I will test latest HEAD and see what is going on with smoothstreaming.

 

As said before it is really possible that we need new drivers in order to handle such streams.

 

Actually @betacentauri and @mx3L are already testing on ET.

 

Currently I am using dm800se as testing box. I have also Formuler F1 it is my main box (2xsat & 2xdvb-t) and I want it for watching TV (and everything works just fine and really fast!).

 

I have also a Medi@link Ixuss Zero but most probably they (manufacturer) abandoned this box.