103 replies to this topic

[samsamsam]

Hi Samsamsam,

Thanks for your feedback.
I wasn't aware of the fact that using ffmpeg is the better choice for iptv player.
I only do some limited testing with iptv player and for me gstreamer works ok.

Reason for adapting taapat's minimal recipes for ffmpeg (for use with gst-libav) is because it greatly reduces size.

Its a small thing to change the recipes and ship the full version again.
I'll do that for the next release :-)

Keep in mind that these images were intented for testing more recent versions of gstreamer for use with OpenPLi.

 

Hello,

 

I understand it very well. I completely do not blame you.

But it seems that users do not understand this.

And this is the problem. They should know that this is test image, but they need.

 

Regards,

SSS

Edited by samsamsam, 10 April 2016 - 13:30.

[MastaG]

@samsamsam
So in order to have my images fully compatible with iptv player I should build the full version of ffmpeg and link it against OpenSSL.
Also I should downgrade OpenSSL back to 1.0.0 right?

Will ffmpeg 3.0.1 be sufficient? Or do I have to downgrade that as well?

[malakudi]

Plugins should be compatible with images, not the other way around ...

You can't stick to OpenSSL 1.0 for ever. 1.0.2 is used now, plugin should either adapt or die.

[sportfootbol]

 

Please link to download the latest ffmpeg (ipk.)...Otherwise you can not install the eplayer...

#samsam --please answer --which is the most stable version of ffmpeg

...Thanks..

Edited by sportfootbol, 10 April 2016 - 14:01.

[MastaG]

@sportfootbol
I don't have it as I don't install pre-compiled ipks.
I like to build it myself so it intergrates more nicely with my feeds.

However there should be plenty of guides out there on howto install the full version of ffmpeg.
Gorski contributed a lot to these howto's.
Google is your friend :-)

[samsamsam]

Plugins should be compatible with images, not the other way around ...

You can't stick to OpenSSL 1.0 for ever. 1.0.2 is used now, plugin should either adapt or die.

 

You still not answer 

 

@samsamsam
So in order to have my images fully compatible with iptv player I should build the full version of ffmpeg and link it against OpenSSL.
Also I should downgrade OpenSSL back to 1.0.0 right?

Will ffmpeg 3.0.1 be sufficient? Or do I have to downgrade that as well?

 

You can use ffmpeg 3.0.1 not problem.

[samsamsam]

Plugins should be compatible with images, not the other way around ...

You can't stick to OpenSSL 1.0 for ever. 1.0.2 is used now, plugin should either adapt or die.

 

At first I not push any one to use IPTVPlayer or make it compatible with image.

 

And maybe you have good eyesight and read:

 

For E2 images I do not see any advetyges using never OpenSSL.

So, it is not priority for me to add support for new OpenSSL.

 

Or not?

 

 either adapt or die.

 

 

Please do not be funny, You really think that everyone uses OpenPLi?

There is many user using very old imges with OpenSSL 0.9.8 and plugin support this old lib for user.

 

So dont worry even if the plugin will not work on any OpenPLI distro it will stil not die and will be used by users.

Got it?

 

OpenPLI is very good distro but not the only one.

 

Regards,

SSS

Edited by samsamsam, 10 April 2016 - 15:04.

[samsamsam]

And at think that when you update somethink you should have the reason. 

OpenSSL 1.0.2 remove support for potentially dangerous function.

Did you know this? Or not and the only reason to use openssl 1.0.2 is because it is newer?

 

Regards,

SSS

[MastaG]

Hi samsamsam,

I'm a great fan of your work and I think IPTV player and TSmedia are the greatest plugins for serving e2-users with iptv content with such great level of user-friendlyness.

However most e2 images follow openembedded which upgrades it's packages like OpenSSL.
A newer version of OpenSSL carries lots of cve fixes and disables unsafe protocols such as sslv3.
I can agree with you that this isn't a big issue for a setopbox or media player.
However it does mean that once an image maintainer decides to upgrade its oe snapshot he has to keep a set of bbappends for an older version of OpenSSL just to satisfy a plugin or addon.
This is a bit overkill in my opinion.
So I think you should eventually support newer versions of OpenSSL as well.

[Taapat]

To use the IPTVPlayer does not need any full version of ffmpeg.

I do not want to specify samsamsam what he needs to do, he can choose for what spend his time,
but it seems to me that he would pay more attention on that, what from the ffmpeg is used.

 

As far as I understand the ffmpeg version is determined using ffmpeg binary.
It is simple but wrong.

As I understand then exteplayer is slightly rewritten standard libeplayer of duckbox-developers and he does not use ffmpeg binary.
He uses only ffmpeg libraries libavutil and libavformat.
This library versions is changed independent of the ffmeg versions, and at every ffmpeg version change its does not change.

I think that the correct is check this library versions rather than ffmpeg.

In addition, on OE this librarys are distributed in separate packages.

 

Of course the problem would not be if IPTVPlayer be open source and all of its individual components must be able to build from git, but it certainly is the samsamsam choice, comply the GPL license or not (libeplayer3 from which it is made exteplayer is distributed under the GPL).

Edited by Taapat, 10 April 2016 - 15:38.

[samsamsam]

@MastaG I think we agree. As I write here https://gitlab.com/i...or-e2/issues/15

I will add support but at now this task is not priority one.

 

Regards,

SSS

[samsamsam]

To use the IPTVPlayer does not need any full version of ffmpeg.

I do not want to specify samsamsam what he needs to do, he can choose for what spend his time,
but it seems to me that he would pay more attention on that, what from the ffmpeg is used.

 

As far as I understand the ffmpeg version is determined using ffmpeg binary.
It is simple but wrong.

As I understand then exteplayer is slightly rewritten standard libeplayer of duckbox-developers and he does not use ffmpeg binary.
He uses only ffmpeg libraries libavutil and libavformat.
This library versions is changed independent of the ffmeg versions, and at every ffmpeg version change its does not change.

I think that the correct is check this library versions rather than ffmpeg.

In addition, on OE this librarys are distributed in separate packages.

 

Of course the problem would not be if IPTVPlayer be open source and all of its individual components must be able to build from git, but it certainly is the samsamsam choice, comply the GPL license or not (libeplayer3 from which it is made exteplayer is distributed under the GPL).

 

@Taapat

 

You are wrong. IPTVPlayer need ffmpeg binary not only for check. So, simple check code and you will see.

 

Of course the problem would not be if IPTVPlayer be open source and all of its individual components must be able to build from git, but it certainly is the samsamsam choice, comply the GPL license or not (libeplayer3 from which it is made exteplayer is distributed under the GPL)

 

Here you are also wrong. Did you know why exteplayer3 is not open source yet? So, maybe you will be able to found my answer why not. And also the info that it will be.

Edited by samsamsam, 10 April 2016 - 15:42.

[samsamsam]

As I understand it then exteplayer is slightly rewritten standard libeplayer of duckbox-developers and he does not use ffmpeg binary.

 

 

And here you are wrong to. exteplayer3 is not only simple  rewritten  libeplayer3. And you probably know that libeplayer3 was based on the libeplayer2? 

 

So, please read before before you start writing nonsense. OK?

Edited by samsamsam, 10 April 2016 - 15:46.

[samsamsam]

@MastaG

 

When you will build ffmpeg please aplly this patch:

# patch hls
echo "HLS FIX"
sed -i '/for (i = 0; i < s->nb_streams; i++) {/c\for (i = 0; i < s->nb_streams && s->streams[i]->id < c->n_playlists; i++) {' $FFMPEG_PATH/libavformat/hls.c

[Taapat]

@MastaG
When you will build ffmpeg please aplly this patch:

 

Maybe I'm wrong, but I think that it is not necessary if you on building use the my ffmpeg patches: https://github.com/T...g-fix-hls.patch

[samsamsam]

@Taapat

 

You are using my code even you are not know about this. For example in your youtube plugin.

So, really do not say me about Open Source. And you should be ashamed accuse me that I'm hiding something.

 

You should know that not everything can be open at once.

For example there is need time to replace not open source code.

 

So think before you start to write out something like this.

Edited by samsamsam, 10 April 2016 - 16:18.

[samsamsam]

 

@MastaG
When you will build ffmpeg please aplly this patch:

 

Maybe I'm wrong, but I think that it is not necessary if you on building use the my ffmpeg patches: https://github.com/T...g-fix-hls.patch

 

 

Yes. This looks like the fix for the same crash

[sportfootbol]

Whether the image will appear where you can use IPTV player or will appear IPTV player using SSL 1.0.2....

[malakudi]

 

Plugins should be compatible with images, not the other way around ...

You can't stick to OpenSSL 1.0 for ever. 1.0.2 is used now, plugin should either adapt or die.

 

At first I not push any one to use IPTVPlayer or make it compatible with image.

 

And maybe you have good eyesight and read:

 

For E2 images I do not see any advetyges using never OpenSSL.

So, it is not priority for me to add support for new OpenSSL.

 

Or not?

 

 either adapt or die.

 

 

Please do not be funny, You really think that everyone uses OpenPLi?

There is many user using very old imges with OpenSSL 0.9.8 and plugin support this old lib for user.

 

So dont worry even if the plugin will not work on any OpenPLI distro it will stil not die and will be used by users.

Got it?

 

OpenPLI is very good distro but not the only one.

 

Regards,

SSS

 

 

OpenPLi follows openembedded as closely as possible. Sticking to various older libraries is not an option from a developer's point of view. You will get obsolete sooner or later. But you could try building static binaries if you wish, then you would not need compatibility from libraries in images. Statically linked binary will be larger of course but that is no problem on today's STBs, they all have plenty of flash space.

[samsamsam]

@malakudi

May I ask what for you're writing such obvious info?

 

Did you read what I wrote? I wrote that I will add support but this is not priority task for me.

I wrote it at start this whole discussion.

 

But keep in mind that I will not follow up each image and make changes immediately.

For me stability is most important.

 

So, stop push on me to do something.

I will do something when I decide that this is needed and when I have time.

I also must have space on the server to store additional binaries and so on.

 

I not force anyone to use IPTVPlayer or exteplayer3 or gstplayer or standard palyer. 

IPTVPlayer gives you a choice.

 

 

but the truth is that the extapler3 in many cases works the best . I start the discussion about advantages of player based on ffmpeg maybe you read this in this thread http://forums.openpl...-gstreamer-10/?

And what? Some of your frineds from "PLi® Core member" laugh from me and says that resources are no problem.

Player based on ffmpeg need much less  resources  than gstreamer based solution especially (1.X). 

Then nothinkg was ready only some h264 and AAC (works and ony on some STB) - as proof of concept.

 

At now many users recognize the advantage of exteplayer3 by themselves.

 

I would like to say now: who was right?

 

There are many works wich must be done to make exteplayer3 well working player but even now in many cases it is better then gstreamer solution.

Edited by samsamsam, 10 April 2016 - 20:59.