Bug #4077
closed
Decryption Inconsistencies
0%
Description
Sorry, this is a bit of a unique problem.
On the Hispasat satellite (30W) there are several transponder containing feeds for the Spanish digital terrestrial network (11222H, 12548.5V, 12671V etc.) Each feed is a full assembled multi programme TS stream (ready to be fed into a DVB-T transmitter) contained within a single PID on the DVB-S2 transponder and encrypted with BISS (so a bit like a Russian doll, TS within a TS).
For example, on 12671V, PID 8006 contains a TS stream with the programmes La 1, La 1 HD, La 2, 24h, and Clan for the Catalonia region.
A few months ago, the version of TVHeadend I had installed was a version where the services were stored as files within directories for each multiplex. I created a fake service for 8006 and put the file in the 12671V directory. I set all of the PIDs (SID, PMT etc) in the file as 8006, and added a 'fake' H264 video PID of 8006. In TVHeadend I then added a CA entry for this service, and set the service to force CA as BISS (2600) so it uses this decryption.
Now when I stream the fake 8006 service through a Python script I have written to strip the outer TS packet headers, I am left with the decrypted data which is a valid transport stream containing the channels I have mentioned above. This works great, and since then I have updated TVHeadend to a newer version where the multiplexes and services aren't directories and files any more but just one GZIP archive for each mux, and it still works fine.
However, I wanted to add all of the other streams containing channels in the same way (more PIDs on other transponders). So yesterday to test this I reinstalled an older version of TVHeadend (on another hard drive in the same hardware setup) with the services still as files in folders rather than the new gzip version. I then added some fake services in the same way as 8006, e.g. 701, 702 and 703 on 12548V as dummy h264 streams with that PID in a fake service file.
These services all appeared in TVH and I added the CA info as before with the correct key. But, now when I run these services through my Python script I do get the actual valid TS content but the picture and sound break up as if the signal is low (the signal is fine). TVHeadend is reporting 'h264 continuity counter error' on the 701, 702 etc PIDs as it decrypts.
I can understand his because the data obviously is not an h264 stream (it's data), but I don't understand why it can ignore this on 8006 and decrypt it 'blind' without there being any errors but not do the same for the new services I have added. I have updated the TVHeadend version once I've added the fake services but the error still occurs. 8006 on my original set-up still works fine.
Is there any way of getting the CA to just decrypt the service without trying to validate the h264 data? Why is it working on one service and not others in the same way? I just want to be able to decrypt the data in each packet without TVHeadend knowing or caring what it contains.
Thanks!
Files
Updated by 
Updated by 