55 replies to this topic

[rantanplan]

Yes, I see the same way as Taapat.
Sure, something can always be optimized on the exteplayer3, but in principle little changes there.
The dependencies of the hardware used have stagnated for years.
You don't need to adjust anything there for Hisi, as they use their own libeplayer3 variant.
ARM, mipsel has not changed in years. There is also nothing in prospect.
Therefore, there is no need for constant changes there.

 

The only important thing is a secure branch in github, so a separate branch within pli would be interesting.

[WanWizard]

I was under the impression exteplayer3 contained specific code to deal with all sorts of different stream formats (like merging seperate audio and video streams). Which would mean it would require regular updates when new techniques of formats are introduced.

 

If my assumption is wrong, what is exteplayer3 doing then, and why is servicemp3 not doing that?

[blzr]

AFAIK the core difference is that exteplayer is ffmpeg based media player solution, while servicemp3 uses gstreamer, and reportedly ffmpeg happens to somehow cope better with various more or less exotic streams and media...

[WanWizard]

So why don't we work on dumping servicemp3 and replace it by an ffmpeg driven solution? Like the HiSil boxes do too? It would solve the poor format support of gstreamer as well...

[blzr]

So why don't we work on dumping servicemp3 and replace it by an ffmpeg driven solution?

hmm, because of lack of manpower (with appropriate knowledge in this area)?

[Pr2]

exteplayer3 is defining itself as:  DESCRIPTION = "Core of movie player for E2 based on the libeplayer using the ffmpeg solution"

[betacentauri]

So why don't we work on dumping servicemp3 and replace it by an ffmpeg driven solution? Like the HiSil boxes do too? It would solve the poor format support of gstreamer as well...

It won't make things much better for non HISI boxes.

A ffmpeg solution could either like servicemp3 let the hardware do the job (for several media types) or do a software decode. But what should be do with software decoded raw data? We can't give it to the box drivers as they (currently) don't support raw video data. We could transcode it to something the hardware understands or try to draw the video data with something like OpenGL to the framebuffer. For me both is not a good idea. Not all boxes support OpenGL and are fast enough for transcoding (I doubt that any of the boxes is fast enough for software transcode FullHD oder 4k video).

[WanWizard]

If that is the case, what is the point of exteplayer3 then? Because that clearly does things servicemp3 isn't capable off, otherwise it would not have been needed.

 

So what is it, if it's not related to streaming formats, and not related to dealing with non-hardware-supported codecs?

[betacentauri]

I think it's related to streaming and less usage of resources. But that is only a guess.

[WanWizard]

That was my first assumption, that it supports streaming formats (like dash or separate audio and video streams) servicemp3 doesn't, but that was rejected above.

[rantanplan]

Taapat had initiated this as an idea years ago.
So separately ffmpeg based solution also for mipsel.
None of this is really a difficult thing at all.
 Actually, a solution already exists on the part of the DDT. You have already demonstrated this for Neutrino.
The libeplayer variant for sh4 was definitely a template for the Hisi receivers. There are a lot of lines of code.
So far, has been refused by enigma2 municipality to break away from the gst.
But if you need the libav from ffmpeg using gst anyway, it is of course very questionable why you stick to the gst solution.
It is possible.
The effort is not that great either.
In fact, the approaches have long been in place.
See sh4, see hisi ...

Edited by rantanplan, 3 March 2021 - 18:43.

[WanWizard]

I (personally, I can't speak for other team members) have no special affection with gst, if ffmpeg is better, can do more, is more equal to the HiSil solution, etc. I'm not really intrested in political or emotional discussions, if there is a good reason to dump gst, lets dump gst...

 

But to do this is way above my skill level...

[rantanplan]

As I said most things have already been done.
Pli separated the things regarding gst from the enigma2 years ago.
This elegantly creates the possibility of the player without internal dependencies on gst to ffmpeg.
I know from sh4 that this works excellently.
Perhaps Taapat would like to tackle this again?
From the code point of view, I would do this via a separate branch in servicemp3.
Logic possibly assign the name gst and the other name ffmpeg as branch.

[WanWizard]

Sounds like a plan.

[Taapat]

Sorry, but I also don't have enough knowledge and time for this.

But on Openpli now the exteplayer3 repo has been changed to technic: https://github.com/O...74ca7f1aa89304a

 

I remember he already wrote here in the forum that he would like to improve exteplayer3. And I know that he has enough knowledge  .

Maybe we should send him a signal that many others are also interested in improving exteplayer3 to drop gst later.

[technic]

But on Openpli now the exteplayer3 repo has been changed to technic: https://github.com/O...74ca7f1aa89304a

Whoa... this is a fork which I did as a backup, when samsamsam announced he closes the project. No plans for improvements

[WanWizard]

Is there anyone who does? I think the change was purely to have a stable repo to build from.

[mrvica]

maybe this, last commit from Sept. 2020

libstb-hal-ddt/libeplayer3 at master · Duckbox-Developers/libstb-hal-ddt · GitHub

[WanWizard]

libeplayer3 is not the same as exte3player?

[rantanplan]

Yes and no ...

exteplayer3 is based on the libeplayer2.

Libeplayer3 is actually more of a further development for sh4.

https://github.com/D...libeplayer3-sh4
Hisi is similar in structure.
In the meantime, ddt has also renamed libeplayer2 to libeplayer3.
In principle, the exteplayer3 has always been the libeplayer.