|
|
|
|
|
by lxe
1423 days ago
|
|
I didn't think it would combine the downstream cable video as well as "data that is decoded and presented as information available for computer usage (i.e., the Internet). (whatever that means)" into mpeg2 frames. I was under the impression that internet downstream and upstream are simply operating on different multiple QAM channels in different distinct frequency bands. |
|
The document refers to "qam-lock" IMHO wrongly (I was a cable protocol/encryption wrangler in a previous life) - "qam-lock" is more a matter of tuning to a channel, sampling it to extract the signal (this means extracting a clock from it) then running the signal through enough of the error correction and framing logic so that you can extract the transport stream packets
That's "qam-lock" - at this point you still don't know what's in the stream - you could just look for 0x1ffe PIDs and decide you have DOCSIS - video qams will carry PAT tables in PID 0 which will point to PMTs (which can be in pid 0x1ffe) which in turn point to qams and PIDs containing video/audio/CA/etc (details vary greatly between implementations). Which is a long way of saying "just looking for PID 0x1ffe may not be enough"