91 replies to this topic

[blzr]

gstreamer-libav

 

it's required by vu to play some audio formats AFAIK

problem is, untill gstreamer 1.18 there was "self-sufficient" gstreamer1.0-libav wher you could exclude/include codecs/transcoders/encoders you needed (defined in the recipe)

7.3 release recipe:

https://github.com/O...er1.0-libav.inc

 

starting from gstreamer 1.18 gst-libav is only a pure interface that requires full blown ffmpeg libraries like e.g.

libavcodec58  Installed-Size: 11251468 and soe others:

root@vs1500:~# opkg info gstreamer1.0-libav
Depends: ...libavcodec58 (>= 4.3.1), libavfilter7 (>= 4.3.1), libavformat58 (>= 4.3.1), libavutil56 (>= 4.3.1)...

Edited by blzr, 20 February 2021 - 19:21.

[Taapat]

We have already discussed this.

The problem is that the update is performed without thinking or it will be used somewhere and or it can be used on the receiver at all.

And here is the difference between mipsel, arm and hisilicon receivers.

 

When the discussion wins those who say that on modern receivers do not have to worry about the flash size are accepted changes that increase the ffmpeg size.

When wins the opinion that it is not suitable for older receivers, the size of ffmpeg is considered.

 

The same story is about samba.

Edited by Taapat, 20 February 2021 - 19:49.

[Taapat]

Returning to the plugin.

I didn't want to do that for a long time, because I'm sure that every extra config entry points to a non-thoughtful solution.

 

However, I added a config option in plugin settings where you can specify or use DASH MP4 or not.

 

@soidog2 wait a bit, I hope tomorrow to the feed will be an updated version.

Try specifying in the settings in the new plugin version do not use DASH MP4 format.

From your writing, I understand that despite to the low resolution you still use the DASH MP4 format.

Edited by Taapat, 20 February 2021 - 19:49.

[rantanplan]

So that with the gst ...
The libav exists today in exactly the same way as it is now built.
Is now no .inc but just a bb.

I see the thing with ffmpeg a little differently.
The construction should remain simple and enable everything as far as possible.
The image building of classic mipsel must therefore not get bigger.
From my point of view, the entire line there is wrong in the config.
gst is preferably built from Pli.

In effect, the image size would not change.
So flashable for everyone.
After that, ffmpeg is bigger, but also more powerful.
The receivers only have a flash problem, not really a memory problem.
Now the question is whether that would solve the problem with YouTube?

[WanWizard]

We have already discussed this.

The problem is that the update is performed without thinking or it will be used somewhere and or it can be used on the receiver at all.

And here is the difference between mipsel, arm and hisilicon receivers.

 

What is your suggestion?

 

Personally, I would like no difference in functionalitty between boxes (as that will be(come) a support nightware, as this topic clearly shows), and for owners of hardware, I would like to be able to provide an image for as long as it is possible (without having to bend over backwards).

 

One of the options is to remove samba from the image (not the feed), for boxes with 128MB flash,  which will save a lot of space, but has no impact on the primary function of the box. I prefer that to crippling ffmpeg, which does have an impact.

[blzr]

So that with the gst ...
The libav exists today in exactly the same way as it is now built.
Is now no .inc but just a bb.
I see the thing with ffmpeg a little differently.
The construction should remain simple and enable everything as far as possible.
The image building of classic mipsel must therefore not get bigger.

well, maybe I was not clear so I try to explain again:
pre 1.18 libav was ffmpeg independent and "self-suffficient" package - you could trim it to you needs, and it didn't affect at all a full ffmpeg that was still available to install when you want to use it
older gst-libav weighted ~1.5-2MB (?) and that's all, current is 250KB but requires additional dozen of MB ffmpeg libraries; and we are much less flexible in customize it - not possible to just slim gst-libav, you have to strip full ffmpeg from some functionalities in such case
 

From my point of view, the entire line there is wrong in the config.
gst is preferably built from Pli.

it's not openpli's "line" - it's vu+ bsp layer, driver rdepends on gst-libav because is not capable of playing some audio formats, and this is their workaround for this

Edited by blzr, 20 February 2021 - 20:15.

[Taapat]

I think you need to install samba in image.

If no one wants to work to reduce its size, let it remain as it is.

For mipsel receivers ffmpeg need only on the feed.

If it cannot be installed from the feed due to flash size, then the user can remove samba or something else by himself.

 

If minimal set of decoders for mipsel is the reason why you can't use exteplayer for youtube playback then it is a broken plugin serviceapp not a plugin youtube.

 

But I would like to say that the youtube plugin needs to work without any problems with gstreamer also with DASH MP4 format. Maybe that dreambox has some specifics.

 

I see that I will need to find the time and try how youtube and serviceapp work on mipsel receivers.

[WanWizard]

I think you need to install samba in image.

 
I said to only remove it from the image for boxes with 128MB flash, not from all others.
 

For mipsel receivers ffmpeg need only on the feed.

 
See the responses from @blzr: ffmpeg is in the feed, the problem are some of the ffmpeg libraries, which are needed by the VU+ and Xsarius drivers.
 

If no one wants to work to reduce its size, let it remain as it is.

 

I'm open to any suggestion that doesn't impact the primary functionality of the box, and doesn't lead to subtle functional differences between boxes.

[rantanplan]

The goal is to restore the standard image size for the few mipsel receivers?

So
SAB
VU + duo / solo
Xaurius

I leave out 4k receivers, they have no flash limit at around 100mb anyway.

For me there is only testing.
For me the line is completely superfluous and maybe someone can test it with the receiver.

https://github.com/n...b-mipsel.inc#L9
So build SAB locally without testing the line and the image.
As I said, that afterwards the image is bigger with ffmpeg is clear, but not bad.

[WanWizard]

No, the issue is limited to boxes with 128MB:  ET4000, ET5000, ET6000, ET9000, VuUno, VuSolo, VuDuo, XP1000. HD500c, HD1100.

 

Ideally the image size for these boxes should remain below 90MB to avoid flash issues, and to have a bit of space left for a softcam and an epg import plugin.

 

There are other boxes with driver dependencies with ffmpeg libraries (such as the SAB), but those have plenty of flash (256MB or more), so not an immediate issue. I only picked the SAB because I have that to test with...

[rantanplan]

But with the receivers nothing changes in the image size.
ffmpeg only becomes interesting afterwards, if you want to install it. It is important to flash the image.
Receivers with only 128mb would normally do their job well with gst.
In terms of plugins and extensions, they are of course limited

[WanWizard]

By removing samba, but including the full ffmpeg, from the image I get an SAB image of 90.8MB, which still means about 7MB larger than with a stripped ffmpeg.

[rantanplan]

The FFMpeg built with all the possibilities is bigger, I realize that.
Should be like that, but then it works.
If you now simply deactivate all functions of ffmpeg, then we do not need to install it.
Or am I wrong now?
I know it's a bit too simple, but it's similar for gst.
The packages are of course also larger with their range of functions.
It doesn't matter at SAB either.
Only the flash has to stay small.
Then the size of ffmpeg does not matter.

Of course we don't have to build anything that can't be used. But the building itself only builds what is possible.

[WanWizard]

But with the receivers nothing changes in the image size.
ffmpeg only becomes interesting afterwards, if you want to install it. It is important to flash the image.
Receivers with only 128mb would normally do their job well with gst.
In terms of plugins and extensions, they are of course limited

Not sure what you mean to say here.

 

The ffmpeg problem is with only with the VuUno, VuSolo, VuDuo: with the full ffmpeg (libav) in the image, the boxes can't be flashed anymore because the image is too big.

 

See for example https://openpli.org/...oad/vuplus/Duo/, the difference between yesterdays (ffmpeg stripped) and todays (full ffmpeg) image is 13MB. It contains an 111MB ubifs and an 8.7MB vmlinux. Too big to be useful for 128MB flash, even if you could flash something this size.

 

All other images in the 128MB list are around 76MB, which is fine. They will only have a problem runtime.

[rantanplan]

Yes.
So now I would look where the problem is with image construction.
Therefore I would start with SAB (the image is managed internally via neo) there the config can be adjusted quickly.
You have the SAB and could check the image.

I'm just building the SAB image without the line (just for fun), see what happens.
I guess, but wait and see.

[WanWizard]

You mean without the libav dependency? I've got the SAB plugged in here, so easy enough to test.

[blzr]

So now I would look where the problem is with image construction.

 

well, it's prettty much clear and was explained couple of times already (?)

some vendors introduced gst-libav workaround in their boxes to make them capable to playback some audio formats that their drivers did not support, simple as that...

if you remove gstreamer-libav from machine essential rdepends for them, some (more or less exotic) media will be silent, that's all

whether is it better way to slim down the images - it may be, but another thing - what vu says on this?
 

[WanWizard]

The main question I think is "which media".

 

Shouldn't that mean there should be a different mediasink too, as it needs to know how to play this media?

[WanWizard]

Builds fine without the dependency, and is also 87MB big now. Next up: flash the image.

[rantanplan]

mhh ...
I don't know what's clear
It is not clear to me what you are writing.
I don't want any deterioration and libav will always be part of it.
I just believe that these dependencies were not adapted to the current environment.