- September 1, 2008
- 21,577
- 8,224
- Home Country
- New Zealand
Re: early response about ATSC/QAM channel data
Hi again x4mer
mm
Hi again x4mer
We are indeed parsing that table.Apparently ATSC uses TVCT (terrestrial virtual channel table), to store the name and virtual channel number like 5-1. MP must already be parsing this, as I see the names and virtual channel info in the edit interface of the channel.
We're also parsing that table.For QAM, CVCT (cable virtual channel table) is used.
Hmmm, well obviously that explains why the names of channels for you folks will be "unknown ***" (where I think *** is the MPEG 2 transport service ID) - MP uses that naming pattern for channels that don't have names. When you say open QAM is not supported, it just doesn't make sense to me though. The cable installers obviously don't go out and manually enter the channel names and details in their subscribers' boxes like many of you are forced to do with MP. Surely that means the naming and type information must be buried in the streams somewhere. It could be encrypted or compressed... I couldn't see any "raw" ascii that looked anything like potential channel names in ryan1's TS dump, and there were no unusual PIDs either. My suspicion is that the entire set of information is on one "mux" (channel) that the box knows how to find. Maybe channel 1 even. I wish I had the ability to check that......in Canada open QAM is not officially supported, so none of the channels have this table filled in. A guy from the board I asked on, is from the U.S.. According to him, the in the clear local channels have the table filled in for those QAM channels on his cable provider. All other channels on his system, have the table blank like here in Canada...
As above - we know how to parse these tables, and we already do that. The problems that have been raised in this thread correspond with the situation where the table is not present. MP 1.2.0b changed the criteria for channels being picked up because the "older" detection method isn't really ideal, and it is also slower than the new method.He said he was going to post some tsreader outputs for me, showing the CVCT for a properly labelled/remapped channel on his cable system, as well as one with the table not filled in.
He said that in the case of either TVCT or CVCT, if the table is not filled in, the channel name is parsed as blank, and the channel number will be referenced as (RF CH#)-(SID #).
Okay, noted. Adding the ability to zap with that style of channel number could probably be added relatively easily for 1.3.x...So it would seem the request I made for 5-1, 7-1 etc channel handling support, would be useful for people using ATSC via OTA, and users of Open QAM stations via cable in the U.S.(provided MP supports parsing the CVCT).
When you say encrypted, do you mean that a CableCard tuner (eg. Ceton InfiniTV4) + WMC + appropriate card would be able to decrypt these channels?Any other ATSC/QAM stations, while not having any useful naming or remapping, wouldn't need it anyways, as those channels are more than likely encrypted...
That could be more complex as the RF channel number is not known (we scan by raw frequency), and I think the numbering scheme varies from country to country. Do you know if the US and Canada use the same RF channel numbering scheme?...or one of a handful of open cable stations in Canada (which could be accessed as (RF CH#)-(SID #) with name added in by the MP user).
Please do.I've also further pushed the question of how the boxes "know" about the channels with no CVCT. If there's any further on that, I'll update also.
mm