[Req] PMT.C : process_sdt() and clean PSI

[lars18th]

Hi @catalinii ,

After fixing #340, and partially related to #339, I request if you can enhance the process_sdt() function in pmt.c to clear the encrypted identification of the service. The processing is quite simple:

• When opts.clean_psi is set, inside the processing of the SDT table, for the corresponding service the "FreeCAMode" descriptor will be changed to "0" (not encrypted).

This is necessary for clients that process the SDT table in order to stablish the content of the stream.

I hope you agree with this. Regards.

[lars18th]

Hi @catalinii ,

I prepared a new patch to start to solve this problem. You can merge now the PR #917 as it's standalone. But I need your help:

• The process_sdt() function is only called one time. We need to change the filtering to receive all packets of the SDT to patch it. In addition, we need to prepare a patched version of the SDT table and replace it, as the current code does with the PMT tables.

Futhermore, I don't know how to rewrite rightly the TS packet of the table. I've done some modification to execute the function process_sdt for every SDT packet (removing the FILTER_REVERSE of the filter flags). However, I need help because all modifications are not sended (the b buffer seems to be a copy). Futhermore, I don't know how to recalculate the CRC of the table.

So, as the PR contains the code to patch the CA flag for every service in the table (if (opts.clean_psi) b[3] &= 0xEF;), I ask if you can complete the code or point about how to finish it.

Regards.

[catalinii]

I did a bit of digging and is more complex than I thought. By looking at the code, I am not sure even clean_psi works as expected. Basically the flow is this: for every packet: 1) process_filters is called to identify the required filter to be processed (a filter is needed for each pid) 2) process_filter is then called for that specific filters which calls assemble_normal to get the data from potentially multiple packets which copies the data in a new buffer (f->data) 3) process_sdt/process_pmt is called with f->data 4) process_pmt calls clean_psi which seems to change f->data and not the original adapter data (which is then sent to the client).

Can u confirm clean_psi actually cleans the PMT ?

[lars18th]

Hi @catalinii ,

I frustrated with this: f->data seems to not be the original adapter data.

However, from my tests...

Can u confirm clean_psi actually cleans the PMT ?

in the PMT of the channels decrypted the Descriptor 0x09 (Conditional Access) continues on the table. Therefore it seems to not work.

Regards.

[lars18th]

Hi @catalinii ,

Because you removed the option of clean_psi... we will close this issue?

[catalinii]

Yeah I think is best.

They both (this issue and clean_psi)relies on rewriting the TS which can be done but it is a lot of duplication with DDCI.

[lars18th]

...which can be done but it is a lot of duplication with DDCI.

Can you explain this more, please?

[catalinii]

For example ddci_create_pmt is very similar to clean_psi_buffer except it adds also the CA information from pmt. But there are 3 main issues:

• complexity associated with rewriting the TS
• potential flip flop between encrypted and decrypted PMT that is sent over the wire
• not sure any client cares at this point

[lars18th]

not sure any client cares at this point

I agree. Only if we ever encounter any specific scenario where this is needed, then it will be useful to reincorporate it again.

Many thanks for continuing to maintain this wonderful project. Regards.