[mythtv] DVB-C service description tables
roger at beardandsandals.co.uk
Fri Apr 14 09:12:39 UTC 2017
On 14 April 2017 9:12:31 am Karl Dietz <dekarl at spaetfruehstuecken.org> wrote:
> Hi Roger,
> On 14.04.2017 09:28, Roger James wrote:
>> I knew that messing with this would come back to bite me. There is a
>> hack in DVBStreamdata to handle the misuse of the the Service
>> Description (other) table to transmit the data for the actual (currently
>> tuned) stream. I need to improve the handling of this in my new SI code.
>> To help me do this, can anyone explain to me why some cable providers
>> feel the need to break the DVB spec in this way, or point me at any info
>> about it.
> They don't violate or hack anything. There are things in the spec from
> the dark ages of digital data transmission to get away with the most
> primitive equipment possible.
> Its perfectly valid to push a pack of network information tables down
> the satellite link for DVB-S and various DVB-C networks.
> Then the local cable headends just convert the bitstream from the DVB-S
> modulation to DVB-C modulation and send it to the customers unmodified.
> A random DVB-C NIT will be marked active, all others as other. The cable
> operator send their customers the correct network_id when they book the
> service so they can configure their TV sets.
> I have to look where this mode of operation is documented, IIRC some
> technical recommendation or network/device implementers guide.
> A quick search over collected standards didn't highlight anything. I
> must have been using the wrong search terms.
Thanks for the quick response. As per usual I was exaggerating. It is the
SD table I was referring to not the NI. I will have a poke round the ETSI
site for any DVB-C implementation guides.
What I was thinking of was trying to get rid of the rewriting of SDo
sections as SDa (that is the hack I was referring to) in DVBStreamdata,
just leaving the setting of the current/desired onid and tsid in there.
Handling of the other aspects of this use case of SDTo would then be passed
up to HandleSDTo in the recorders/monitors. I think it only really affects
the handling of tuning with possibly some knock on in encryption. It may
need the addition of a flag in the signal monitor to say we have seen a
SDTo for our desired stream (instead of a SDTa) or maybe just set the SDTa
flag as well when we see the one we want.
More information about the mythtv-dev