2520 replies to this topic

[christophecvr]

Yes I know how to remove it.

My only concern is why did it install -all- packages after a "opkg upgrade" when migrating to your recipes.

The original list of installed packages is like this:

gstreamer1.0 - 1.8.0+git16907+1abf889-r0
gstreamer1.0-libav - 1.8.0+git1959+2d362cc-r1
gstreamer1.0-plugin-multibox-dvbmediasink - 1.8.0+git116+2c3c99d-r3
gstreamer1.0-plugin-subsink - 1.0+git7+2c4288b-r2
gstreamer1.0-plugins-bad - 1.8.0+git20781+740d350-r2
gstreamer1.0-plugins-bad-dashdemux - 1.8.0+git20781+740d350-r2
gstreamer1.0-plugins-bad-faad - 1.8.0+git20781+740d350-r2
gstreamer1.0-plugins-bad-hls - 1.8.0+git20781+740d350-r2
gstreamer1.0-plugins-bad-mms - 1.8.0+git20781+740d350-r2
gstreamer1.0-plugins-bad-mpegpsdemux - 1.8.0+git20781+740d350-r2
gstreamer1.0-plugins-bad-mpegtsdemux - 1.8.0+git20781+740d350-r2
gstreamer1.0-plugins-bad-rtmp - 1.8.0+git20781+740d350-r2
gstreamer1.0-plugins-bad-smoothstreaming - 1.8.0+git20781+740d350-r2
gstreamer1.0-plugins-bad-videoparsersbad - 1.8.0+git20781+740d350-r2
gstreamer1.0-plugins-base - 1.8.0+git15113+d67525d-r0
gstreamer1.0-plugins-base-alsa - 1.8.0+git15113+d67525d-r0
gstreamer1.0-plugins-base-app - 1.8.0+git15113+d67525d-r0
gstreamer1.0-plugins-base-audioconvert - 1.8.0+git15113+d67525d-r0
gstreamer1.0-plugins-base-audioresample - 1.8.0+git15113+d67525d-r0
gstreamer1.0-plugins-base-ivorbisdec - 1.8.0+git15113+d67525d-r0
gstreamer1.0-plugins-base-ogg - 1.8.0+git15113+d67525d-r0
gstreamer1.0-plugins-base-playback - 1.8.0+git15113+d67525d-r0
gstreamer1.0-plugins-base-subparse - 1.8.0+git15113+d67525d-r0
gstreamer1.0-plugins-base-typefindfunctions - 1.8.0+git15113+d67525d-r0
gstreamer1.0-plugins-base-vorbis - 1.8.0+git15113+d67525d-r0
gstreamer1.0-plugins-good - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-apetag - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-audioparsers - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-autodetect - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-avi - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-flac - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-flv - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-icydemux - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-id3demux - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-isomp4 - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-matroska - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-rtp - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-rtpmanager - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-rtsp - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-souphttpsrc - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-udp - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-good-wavparse - 1.8.0+git15856+7b80920-r0
gstreamer1.0-plugins-ugly - 1.8.0+git5299+71c3943-r0
gstreamer1.0-plugins-ugly-amrnb - 1.8.0+git5299+71c3943-r0
gstreamer1.0-plugins-ugly-amrwbdec - 1.8.0+git5299+71c3943-r0
gstreamer1.0-plugins-ugly-asf - 1.8.0+git5299+71c3943-r0
gstreamer1.0-plugins-ugly-cdio - 1.8.0+git5299+71c3943-r0
gstreamer1.0-plugins-ugly-dvdsub - 1.8.0+git5299+71c3943-r0
gstreamer1.0-plugins-ugly-mad - 1.8.0+git5299+71c3943-r0
libgstadaptivedemux-1.0-0 - 1.8.0+git20781+740d350-r2
libgstapp-1.0-0 - 1.8.0+git15113+d67525d-r0
libgstaudio-1.0-0 - 1.8.0+git15113+d67525d-r0
libgstcodecparsers-1.0-0 - 1.8.0+git20781+740d350-r2
libgstmpegts-1.0-0 - 1.8.0+git20781+740d350-r2
libgstpbutils-1.0-0 - 1.8.0+git15113+d67525d-r0
libgstriff-1.0-0 - 1.8.0+git15113+d67525d-r0
libgstrtp-1.0-0 - 1.8.0+git15113+d67525d-r0
libgstrtsp-1.0-0 - 1.8.0+git15113+d67525d-r0
libgstsdp-1.0-0 - 1.8.0+git15113+d67525d-r0
libgsttag-1.0-0 - 1.8.0+git15113+d67525d-r0
libgsturidownloader-1.0-0 - 1.8.0+git20781+740d350-r2
libgstvideo-1.0-0 - 1.8.0+git15113+d67525d-r0

And than after building with your recipes I get the list from my previous post with almost all -base, -good and -bad plugins.

Also afaik I didn't specify to include: "gstreamer1.0-plugins-bad-meta"  anywhere...

no you did at a certain point :

 

opkg install gstreamer1.0-plugins-bad

 

That did installed all builded plugins bad.

[MastaG]

No my friend, just tried it on a second receiver.

I build using your new recipes and push the feed to my private server.

Then on my receiver where I have 1.8.0 stable (like the above post) I only issue: opkg update && opkg upgrade.

I end up getting everything.

I didn't install something manually.

 

It seems it pulls in the meta recipes:

opkg list-installed | grep gst | grep meta
gstreamer1.0-plugins-bad-meta - 1.9.0.1+gitbase-r0
gstreamer1.0-plugins-base-meta - 1.9.0.1+gitbase-r0
gstreamer1.0-plugins-good-meta - 1.9.0.1+gitbase-r0
gstreamer1.0-plugins-ugly-meta - 1.9.0.1+gitbase-r0

 

I can post a full upgrade log if you want.

[christophecvr]

I just corrected. the base gstreamer recipes intended for use by developers/testers

 

But due to the wrong pkgv configure in bb recipe before use before : You best first do to the (if you had a build image) use :

MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0_git.bb -c cleanall
MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb -c cleanall
MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_git.bb -c cleanall
MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_git.bb -c cleanall
MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_git.bb -c cleanall
MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-multimedia/gstreamer/gstreamer1.0-libav_git.bb -c cleanall

This for all machines You have builded.

 

Then correct the gstreamer bundle with the last I made on :

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

 

Rebuild the images use

MACHINE=vuduo2 bitbake <you're-image>

Then reflash the stb.

 

After that it will be fine again.

[christophecvr]

No my friend, just tried it on a second receiver.

I build using your new recipes and push the feed to my private server.

Then on my receiver where I have 1.8.0 stable (like the above post) I only issue: opkg update && opkg upgrade.

I end up getting everything.

I didn't install something manually.

 

It seems it pulls in the meta recipes:

opkg list-installed | grep gst | grep meta
gstreamer1.0-plugins-bad-meta - 1.9.0.1+gitbase-r0
gstreamer1.0-plugins-base-meta - 1.9.0.1+gitbase-r0
gstreamer1.0-plugins-good-meta - 1.9.0.1+gitbase-r0
gstreamer1.0-plugins-ugly-meta - 1.9.0.1+gitbase-r0

I can post a full upgrade log if you want.

Then you must have it somewhere set. that the full plugins packages are always installed.

 

By me gstreamer master next it does not do that. And on a stb it is really not suposed to do that. We really only wan't the minimum required packages installed. There are flash space limitations.

 

The plugins which we install are set in enigma2.bb

Edited by christophecvr, 13 April 2016 - 14:29.

[MastaG]

Yes I know, for now I'll simply reflash it.

But since I'd like to push the feed to the public, it wouldn't be nice if everyone would be flooded

 

I think I know why now.

https://github.com/c...ins-package.inc has:

RRECOMMENDS_${PN} += "${PN}-meta"

In the bottom.

Now since I'm using it on PLi4 (older oe snapshot) it seems to make all plugins being installed by the "-meta" package?

 

I've commented it out and trying to push a new feed

[MastaG]

Yes that was the problem

RRECOMMENDS_${PN} += "${PN}-meta"

 

After removing it, upgrade works great again

 

So time to push the new gstreamer 1.9.0.1 built by your new recipes to the public

Now with ffmpeg users will be able to use libexteplayer as well and everyone is happy again.

 

Thanks again chris.

[christophecvr]

You are right that recomend should not be there. I wonder why it is. But by me it does not install all packages.

 

see what is installed included a list from all installed packages on vuduo2 .

 

On the dm8000 it's the same except that I do not have the gstreamer1.0-libav (not required since wma codecs are onboard by dm).

 

Then about the libav self. some plugins do require it. Wel quite simple since the only use off the gst-libav is till now only and only for the wma codecs, I adpated the build off gstreamer1.0-libav(which is using now ffmpeg n3.0 and not the original libav anymore) to :

LIBAV_INCLUDED_EXLUCED = "--disable-everything \
						--enable-decoder=wmalossless --enable-decoder=wmapro --enable-decoder=wmav1 --enable-decoder=wmav2 --enable-decoder=wmavoice"

LIBAV_EXTRA_CONFIGURE_COMMON_ARG = "--target-os=linux \
  --cc='${CC}' --as='${CC}' --ld='${CC}' --nm='${NM}' --ar='${AR}' \
  ${GSTREAMER_1_0_DEBUG} \
  --disable-mipsdsp \
  --disable-mipsdspr2 \
  ${LIBAV_INCLUDED_EXLUCED} \
  --cross-prefix='${HOST_PREFIX}'"

I exclude all except the wma codecs.

 

The result is well that the libav and libavformat is not build anymore. Some plugins do require them and that is  now done by ffmpeg adaptation off openpli-oe-core/meta-openpli/recipes-multimedia/ffmpegffmpeg_3.%.bbappend to :

RSUGGESTS_${PN} = ""

PACKAGECONFIG ="gpl mp3lame x264 avcodec avformat vpx"

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

Attached Files

•  installed-gst-packages.txt   2.81KB   11 downloads

[Taapat]

@MastaG of course you can go easy way, and not to worry about your image components.
But you have to understand that in libav ffmpeg is duplicated.
If in the system is not used ffmpeg and used only wma codec, then there is no difference whether to use ffmpeg from libav, or from the system.

I think that it is better to use it from the libav.
Another situation is when in the system is used ffmpeg. In this case, if you not using system ffmpeg, you unnecessarily duplicating 1,2Mb large library.

[MastaG]

Yes, but I know that my friend.
However I have to think about the dm800se and dm500hd which only have 64mb of flash.
So I've adapted chris' libav which will build a small libav with only wma.
The full ffmpeg package will be in the feed for the ones with plenty of flash space.
And I think not everyone care about libexteplayer.

[samsamsam]

@MastaG of course you can go easy way, and not to worry about your image components.
But you have to understand that in libav ffmpeg is duplicated.
If in the system is not used ffmpeg and used only wma codec, then there is no difference whether to use ffmpeg from libav, or from the system.

I think that it is better to use it from the libav.
Another situation is when in the system is used ffmpeg. In this case, if you not using system ffmpeg, you unnecessarily duplicating 1,2Mb large library.

 

Why do you think that libav is better? I do not think so.

The main developer of ffmpeg is where? In ffmpeg repo.

 

libav is branch of ffmpeg and not vice versa.

[athoik]

Why do you think that libav is better? I do not think so.
The main developer of ffmpeg is where? In ffmpeg repo.
 
libav is branch of ffmpeg and not vice versa.

Libavi most probably will be just another fork that failed

https://lwn.net/Articles/650816/

[MastaG]

Well maybe I wasn't clear.
My previous gstreamer1.0-libav was based on Taapat's recipe which builds against the system's ffmpeg (a reduced version).
However since I'd like the system ffmpeg to be a full version for use with iptv player's libexteplayer.
I've chosen to use chris' aproach and build gstreamer1.0-libav using its own libav which is reduced to only wma.
The full ffmpeg will be in the feed if a user requires libexteplayer.
Gstreamer1.0-libav will be installed by default.
I know there will be two ffmpeg libraries carrying wma if you install both but then again I will not be forcing full ffmpeg if one only needs support for wma.

Edited by MastaG, 13 April 2016 - 17:57.

[christophecvr]

It's a bit fun to see all this.

 

ffmpeg

gstreamer.

 

In both cases a player must be developed which interact with e2 to be efficient and really usable that player must be in cpp (c++)

 

The player which is only using ffmpeg extplayer : sorry closed source very deprecated build about very very important openssl versions (crucial and blocker) do not use deprecated ssl and certainly not obsolete ssl versions.

SEE CVE REPORTS ABOUT ssl you'lle notice the reason why it is needed to keep up. (this comment for some persons who still do not get the importance to adapt there developments to a descent security level)

 

Pli is an open source software project , so is openembedded. (just the stb drivers are closed due to forced multimedia laws). But for the rest all most be open source . keep it like that.

[samsamsam]

@MastaG

Why you use name "libexteplayer"? It is not "libexteplayer" but exteplayer3.

It is not lib.

[athoik]

just the stb drivers are closed due to forced multimedia laws

Some parts of the drivers are not covered by multimedia laws. Like tuner drivers, etc.

But ... all manufactures prefer to have everything closed...

Also they can implement some features in firmware, and open more parts, but again Broadcom most probably has very strict NDA.

[Taapat]

Why do you think that libav is better? I do not think so.

I did not say that libav is better. I said well that it is better to use ffmpeg from libav.
Currently libav is not an independent library. In it is used the original ffmpeg, but only a specific version. At this moment it is 3.0.0.
If it's used only wma, then I do not think that in 3.0.1 version is any improvement for wma, and therefore it may be better to use ffmpeg version which has been tested by the gstreamer developers.

Edited by Taapat, 13 April 2016 - 18:10.

[Taapat]

P.S.

I'm talking about gstreamer gst-libav rather than a library libav: https://cgit.freedes...amer/gst-libav/

Edited by Taapat, 13 April 2016 - 18:17.

[samsamsam]

It's a bit fun to see all this.

 

ffmpeg

gstreamer.

 

In both cases a player must be developed which interact with e2 to be efficient and really usable that player must be in cpp (c++)

 

The player which is only using ffmpeg extplayer : sorry closed source very deprecated build about very very important openssl versions (crucial and blocker) do not use deprecated ssl and certainly not obsolete ssl versions.

 

 

 

The player which is only using ffmpeg extplayer : sorry closed source very deprecated build about very very important openssl versions (crucial and blocker) do not use deprecated ssl and certainly not obsolete ssl versions.

SEE CVE REPORTS ABOUT ssl you'lle notice the reason why it is needed to keep up. (this comment for some persons who still do not get the importance to adapt there developments to a descent security level)

 

 

 

@christophecvr

It seems to me that you have problem with reading my firend.

 

At first please check if exteplayer3 use OpenSSL. NOT IT IS NOT USING OPENSSL!

So, what for did you write such nonsense? At first please check then writes, and not vice versa.

 

Source of exteplayer3 will be published very soon, and already I wrote about it I do not want to repeat.

 

 

really usable that player must be in cpp (c++)

 

 

This is really funny Please check solution friend @mx3L how player in separate process can be integrated with E2.

And you are saying about "really usable". As I understand you say that IPTVPlayer users do not use player really?

 

The stability do you know this word? Player in separate process is more stable. I think that you are agree with this? 

Even Google knows this: all tabs in google chrome web browser are working as separate processes.

 

I am almost sure you never try to use it and check how it work.

 

I understand that you are frustrated but quietly all will be fine.

 

And to your knowledge the IPTVPlayer since yesterday supports OpenSSL 1.0.2.

 

But once again this has no connection with exteplayer3.

exteplayer3 use ffmpeg libs which uses openssl.

Do you see the difference? The same binary of the exteplayer3 can works on system were there is openssl 1.0.0 and openssl 1.0.2. No, problem.

 

 

Regards,

SSS

Edited by samsamsam, 13 April 2016 - 18:34.

[samsamsam]

 

Why do you think that libav is better? I do not think so.

I did not say that libav is better. I said well that it is better to use ffmpeg from libav.
Currently libav is not an independent library. In it is used the original ffmpeg, but only a specific version. At this moment it is 3.0.0.
If it's used only wma, then I do not think that in 3.0.1 version is any improvement for wma, and therefore it may be better to use ffmpeg version which has been tested by the gstreamer developers.

 

 

I'm sorry. I wrongly understood you.

[christophecvr]

Well maybe I wasn't clear.
My previous gstreamer1.0-libav was based on Taapat's recipe which builds against the system's ffmpeg (a reduced version).
However since I'd like the system ffmpeg to be a full version for use with iptv player's libexteplayer.
I've chosen to use chris' aproach and build gstreamer1.0-libav using its own libav which is reduced to only wma.
The full ffmpeg will be in the feed if a user requires libexteplayer.
Gstreamer1.0-libav will be installed by default.
I know there will be two ffmpeg libraries carrying wma if you install both but then again I will not be forcing full ffmpeg if one only needs support for wma.

Almost right but ...

 

The only thing which will be installed extra to a stb if by gstreamer1.0-libav is included is the file libgstlibav.so. A file which is only used by gstreamer self and does contain all the needed things for gstreamer alone. This means that the codecs and all are embedded inti that library file. This is now reduced to the smallest possible size which is 1.2 MB now. In base build fase libav and libavformat will not be build anymore by gstreamer recipes. This is now done by ffmpeg recipe.

 

The gstreamer in enigma2 is a must for so what all fixed media.

 

all (not streamed or live media) mkv,mp3,flac,wav,mpg,mpeg,ogg,wmv,wma,mp4,avi,vob   I'm shure i forgot some in the list ...

 

So if some persons do want another player , Ok but see that it really does play all the media mentioned (and not only live streams) . It MUST MUST be 100 % open (not closed sources) and it MUST MUST follow the last ssl versions those are really required for security issues .

 

at this point @malakudi is 100 % right.