45 replies to this topic

[Persian Prince]

According to https://en.wikipedia.org/wiki/DVB-S2 we have some missing FECs: 1/4, 1/3, 2/5 (DVB-S2)

 

According to https://en.wikipedia.org/wiki/DVB-T2 we have some missing FECs: 3/5, 4/5 (DVB-T2)

 

And there are some STBs that can receive so we need to define these values I guess: https://forums.openp...eceiver/page-52

Edited by Persian Prince, 18 June 2018 - 08:43.

[Erik Slagter]

The FEC values don't get much attentention nowadays because almost all tuners are blindscan capable, which mean they will lock with whatever FEC value you give them. Some FEC values (S2x) can't even be passed to the tuner, so we actually must rely on the auto scan feature.

[athoik]

We can use only what is defined in linux dvb.
 

enum fe_code_rate {
	FEC_NONE = 0,
	FEC_1_2,
	FEC_2_3,
	FEC_3_4,
	FEC_4_5,
	FEC_5_6,
	FEC_6_7,
	FEC_7_8,
	FEC_8_9,
	FEC_AUTO,
	FEC_3_5,
	FEC_9_10,
	FEC_2_5,
};

See: https://git.kernel.o...d.h?h=v4.18-rc1

If you think we are missing some values, then you should create a patch and submit to linux dvb.

https://patchwork.li...nux-media/list/

Any patch that changes uApi (in OpenPLi, out of kernel dvb) should be rejected ASAP.

Edited by athoik, 20 June 2018 - 19:29.

[samsamsam]

@athoik

 

 

Any patch that changes uApi (in OpenPLi, out of kernel dvb) should be rejected ASAP. 

 

 

So, why you use changed Linux DVB API in the media player "video" and "audio" decoders?

Let remove these use if you think that you should never use extend by drivers provided by producents Linux DVB API. 

Edited by samsamsam, 21 June 2018 - 08:18.

[athoik]

Can you point me what changed in uAPI?

[samsamsam]

For example, using IOCTL: VIDEO_SET_CODEC_DATA

[athoik]

I think you are wrong...

FEC's are delivered by the linux dvb api calls. How I am supposed to mantain one codebase if every manufacturer "defines" his own "enums".

Welcome to the "#if BOX" world, something we are trying to avoid.

IF you like to introduce a new FEC value, just commit it upstream (to kernel) and we are fine.

[samsamsam]

Another example is ioctl for audio decoder: AUDIO_SET_BYPASS_MODE

 

Read here:

https://linuxtv.org/...ypass-mode.html

 

int ioctl(int fd, AUDIO_SET_BYPASS_MODE, boolean mode)

 

This ioctl call asks the Audio Device to bypass the Audio decoder and forward the stream without decoding. This mode shall be used if streams that can’t be handled by the Digial TV system shall be decoded. Dolby DigitalTM streams are automatically forwarded by the Digital TV subsystem if the hardware can handle it.

 

and then check how it is used by the OpenPli. It is used to set audio codec and the parameter is int not bool in Enigma2 usecase. It is used same as VIDEO_SET_STREAMTYPE for video decoder.

[samsamsam]

@athoik

 

I not talking about FEC. I am talking about this your post:

 

Any patch that changes uApi (in OpenPLi, out of kernel dvb) should be rejected ASAP. 

 

 

I think you are wrong...

 

 

​Where I am wrong? 

 

You asked:

 

Can you point me what changed in uAPI? 

 

 

I gave you examples? What is wrong in this examples?

 

 

How I am supposed to mantain one codebase if every manufacturer "defines" his own "enums".

 

 

Why then you use different IOCTL values for VIDEO_SET_STREAMTYPE for different STB? This for sure is not "one" database

Edited by samsamsam, 21 June 2018 - 09:54.

[athoik]

@athoik
 
I not talking about FEC. I am talking about this your post:
 

Any patch that changes uApi (in OpenPLi, out of kernel dvb) should be rejected ASAP. 

 
You are quoting part of my answer. Please read the full text. I am talking about FEC!

We can use only what is defined in linux dvb.

enum fe_code_rate {
	FEC_NONE = 0,
	FEC_1_2,
	FEC_2_3,
	FEC_3_4,
	FEC_4_5,
	FEC_5_6,
	FEC_6_7,
	FEC_7_8,
	FEC_8_9,
	FEC_AUTO,
	FEC_3_5,
	FEC_9_10,
	FEC_2_5,
};

See: https://git.kernel.o...d.h?h=v4.18-rc1

If you think we are missing some values, then you should create a patch and submit to linux dvb.

https://patchwork.li...nux-media/list/

Any patch that changes uApi (in OpenPLi, out of kernel dvb) should be rejected ASAP.
[/quote]

[littlesat]

@SamSamSam...

 

FEC != Something that might be incorrect how we use API.... Please politely show us in a different thread how it should be done.

 

This thread is about FEC values and not we "accidently" might possibly identically do something API related 'thing' inappropriately....

Edited by littlesat, 21 June 2018 - 10:15.

[samsamsam]

Any patch that changes uApi

 

So, maybe you should wrote 

Any patch (which affect FEC) that changes uApi

 

But these are just words. We both know that you mean "ANY" no "ANY which affect FEC", but when I show you that you not use this rule, in the OpenPli code. 

You change strategy

[samsamsam]

@littlesat

 

It is really funny. You simply do not know a big party of the source code you maintaines now.

 

You excacly know that @athoik do not mean FEC but ANY change.

 

Please politely show us in a different thread how it should be done.

 

You use this because how it is implemented in the drivers. You don't have any choice.

 

Same think can be done with FEC. I know that better is when everything is used correctly. But the world is not perfect.

 

 

In case of FEC the value for database can be same and extended with new values, but when you use it to Linux API call you can add mapping depend on driver, set-top-box and or anything you need.

Edited by samsamsam, 21 June 2018 - 10:21.

[athoik]

You still have a point. You are not completely wrong. And your examples are of course a polution of "uAPI".

Of course you know who introduced those...

Personally I try to play "fair"..... https://git.kernel.o...9d6abd24ceba363

[littlesat]

Same think can be done with FEC. I know that better is when everything is used correctly. But the world is not perfect.

I thought that you were blaming us for something here... That is the reason for my offend... And that was also the reason why I asked you to point us to what we did wrong... but it seems you can't due to the non perfect world...

[samsamsam]

In case of FEC the value for database can be same and extended with new values, but when you use it to Linux API call you can add mapping depend on driver, set-top-box and or anything you need.

 

You can use default FEC mapping which will maps new values to UNKNOWN, but depend on driver diffrent mapping can be used. 

This is simple solution and does not break any API.

 

If you do not what to implement something you simple can say this.Just say this and do not cover behind using something like:

Any patch that changes uApi (in OpenPLi, out of kernel dvb) should be rejected ASAP. 

 

 

 

Because if you really want then you can implement this without breaking any API.

 

To be clear I do not have any interest with or without such changes. It's just about being honest with others.

Edited by samsamsam, 21 June 2018 - 10:31.

[WanWizard]

I think there is a lot of "baggage" in the E2 codebase, after 10 years. That is a given, and often very difficult to cleanup. That however is not an excuse to add more "baggage".

[samsamsam]

@WanWizard

 

Adding the FEC mapping it will be "baggage" in your opinion?

[WanWizard]

Yes, as it should be fixed upstream.

[littlesat]

+1