Jump to content


Photo

Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5)

DVB-T2 DVB-S2

  • Please log in to reply
45 replies to this topic

#1 Persian Prince

  • Senior Member
  • 1,385 posts

+167
Excellent

Posted 18 June 2018 - 08:42

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.

If you like my post click on green arrow :)

Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #2 Erik Slagter

  • PLi® Core member
  • 42,835 posts

+462
Excellent

Posted 20 June 2018 - 17:48

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.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)

I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.

Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #3 athoik

  • PLi® Core member
  • 7,196 posts

+246
Excellent

Posted 20 June 2018 - 19:28

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.

Wavefield T90: 0.8W - 5E - 7E - 13E - 16E - 19E - 23E - 26E - 28E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #4 samsamsam

  • Senior Member
  • 1,924 posts

+133
Excellent

Posted 21 June 2018 - 08:16

@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.


Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #5 athoik

  • PLi® Core member
  • 7,196 posts

+246
Excellent

Posted 21 June 2018 - 08:56

Can you point me what changed in uAPI?
Wavefield T90: 0.8W - 5E - 7E - 13E - 16E - 19E - 23E - 26E - 28E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #6 samsamsam

  • Senior Member
  • 1,924 posts

+133
Excellent

Posted 21 June 2018 - 09:15

For example, using IOCTL: VIDEO_SET_CODEC_DATA



Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #7 athoik

  • PLi® Core member
  • 7,196 posts

+246
Excellent

Posted 21 June 2018 - 09:47

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.
Wavefield T90: 0.8W - 5E - 7E - 13E - 16E - 19E - 23E - 26E - 28E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #8 samsamsam

  • Senior Member
  • 1,924 posts

+133
Excellent

Posted 21 June 2018 - 09:47

Another example is ioctl for audio decoder: AUDIO_SET_BYPASS_MODE

 

Read here:

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

 


int ioctl(int fdAUDIO_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.



Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #9 samsamsam

  • Senior Member
  • 1,924 posts

+133
Excellent

Posted 21 June 2018 - 09:51

@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 :P


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


Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #10 athoik

  • PLi® Core member
  • 7,196 posts

+246
Excellent

Posted 21 June 2018 - 10:07

@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]


Wavefield T90: 0.8W - 5E - 7E - 13E - 16E - 19E - 23E - 26E - 28E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #11 littlesat

  • PLi® Core member
  • 44,407 posts

+447
Excellent

Posted 21 June 2018 - 10:12

@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.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W Thanks to Henksat

Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #12 samsamsam

  • Senior Member
  • 1,924 posts

+133
Excellent

Posted 21 June 2018 - 10:13


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 :P



Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #13 samsamsam

  • Senior Member
  • 1,924 posts

+133
Excellent

Posted 21 June 2018 - 10:17

@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.


Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #14 athoik

  • PLi® Core member
  • 7,196 posts

+246
Excellent

Posted 21 June 2018 - 10:18

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
Wavefield T90: 0.8W - 5E - 7E - 13E - 16E - 19E - 23E - 26E - 28E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #15 littlesat

  • PLi® Core member
  • 44,407 posts

+447
Excellent

Posted 21 June 2018 - 10:25


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...


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W Thanks to Henksat

Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #16 samsamsam

  • Senior Member
  • 1,924 posts

+133
Excellent

Posted 21 June 2018 - 10:29

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.


Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #17 WanWizard

  • Forum Moderator
    PLi® Core member
  • 40,496 posts

+629
Excellent

Posted 21 June 2018 - 12:17

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". ;)


Many answers to your question can be found in our new and improved wiki.

Currently in active use: HD2400 (4xS2)VU+Duo2 (3xS2)VU+Zero, Edision OS mini+, ET10000 (4xS2)

For testing purposes: XP1000Formuler F1 (2xS2)Miraclebox Premium Micro (S2+C/T),  ET7500 (S2)ET8500 (S2), Zgemma H2.H (S2+C)Zgemma H5.2TC (S2+C/T), SAB TripleAlpha (S2+C/T), Galaxy 4K (FBC), VU Zero 4K, Edision OS nino 


Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #18 samsamsam

  • Senior Member
  • 1,924 posts

+133
Excellent

Posted 21 June 2018 - 13:02

@WanWizard

 

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



Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #19 WanWizard

  • Forum Moderator
    PLi® Core member
  • 40,496 posts

+629
Excellent

Posted 21 June 2018 - 13:09

Yes, as it should be fixed upstream.


Many answers to your question can be found in our new and improved wiki.

Currently in active use: HD2400 (4xS2)VU+Duo2 (3xS2)VU+Zero, Edision OS mini+, ET10000 (4xS2)

For testing purposes: XP1000Formuler F1 (2xS2)Miraclebox Premium Micro (S2+C/T),  ET7500 (S2)ET8500 (S2), Zgemma H2.H (S2+C)Zgemma H5.2TC (S2+C/T), SAB TripleAlpha (S2+C/T), Galaxy 4K (FBC), VU Zero 4K, Edision OS nino 


Re: Missing FECs (1/4, 1/3, 2/5) and (3/5, 4/5) #20 littlesat

  • PLi® Core member
  • 44,407 posts

+447
Excellent

Posted 21 June 2018 - 16:37

+1
WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W Thanks to Henksat





Also tagged with one or more of these keywords: DVB-T2, DVB-S2

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users