Mailing List Archive

DVB-C service description tables
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.

Roger


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: DVB-C service description tables [ In reply to ]
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.

Regards,
Karl
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: DVB-C service description tables [ In reply to ]
On 14 April 2017 9:12:31 am Karl Dietz <dekarl@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.
>
> Regards,
> Karl
> _____________________________

Hi Karl,

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.

Roger


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org