4 ms·

Wait, to be clear, this 'dedicated return channel' is just for TVs to broadcast back to the station that they're watching the adverts? I thought ATSC 3.0 was go

Wait, to be clear, this 'dedicated return channel' is just for TVs to broadcast back to the station that they're watching the adverts? I thought ATSC 3.0 was going to rely on IP backhaul for that. Actually broadcasting back seems... impractical at best. I mean, let's keep in mind, even ATSC 1.0 had really awful reception issues; compared to analog NTSC where there was enough redundancy that you could just tune into a garbage station from way too far away and see something. Now imagine trying to make that already unreliable channel bidirectional. I just really hope all the return channel stuff is optional, because it sure as hell isn't going to work without way more stations broadcasting on more channels, and OOPS you've reinvented LTE.

timewizard 2y ago
Ironically there's no redundancy in NTSC. There are layers of information and they degrade downward until you have just a black and white picture with no sound. In ATSC there is two types of forward error correction on the digital bitstream. The problem it faces is it sits in the same channel allocations as NTSC while having to deliver significantly more information than NTSC. That and the actual digital modulation used is not as ideal for receivers to capture.
- kmeisthax 2y ago
  You can digitize and lossily compress an NTSC signal significantly without losing much detail; that's why I call it redundant. Compression removes redundancy. In ATSC the tradeoff between compression and error correction is such that a noisy channel is far more likely to cut out or otherwise be unusable than it would have been in NTSC.
DoubleGlazing 2y ago
Back in the late 90s when Ireland was starting to think about digital terrestrial TV a system called DVB-RCT was considered. Basically your receiver could also transmit back to the television transmitter. The system could handle thousands of concurrent connections, albeit each one had very low bandwidth - around 1Kbp/s in peak time.That was considered good enough for very basic interactivity and for authorising PPV purchases etc.In quieter hours or in areas were there were fewer receivers that bandwidth would be much higher, but in reality that would be rare. In the end the company that the governement selected to start the rollout of DTT went bust and I don't think the system was used anywhere else. The developer of the technology abandoned it in 2006 as other connection methods (broadband/mobile data) were preferred.
mindslight 2y ago
I would think that the expectation is for the common option to be IP backhaul based on embedded LTE/5G modems. Having a separate communication scheme is probably more of a hedge for super rural areas that don't have LTE/5G or other IP coverage, especially as that is where broadcast TV will have more staying power.
- Lammy 2y ago
  This is my understanding as well. You can see the usage-reporting scheme and data structure here: https://www.atsc.org/wp-content/uploads/2024/04/A333-2024-04-Service-Usage-Reporting.pdf https://www.atsc.org/wp-content/uploads/2024/04/A333-2024-04... “The fundamental record that captures consumption information is called a Consumption Data Unit (CDU). For a streaming A/V channel, each CDU identifies a reporting interval during which a service is accessed. Such a CDU includes the service identifier, the time the service access started and the time the service access ended. If any Applications are active during the report interval, it also records when the Applications are active (whether on a primary device or a “second screen”, companion device), including the Application Identifier, the time the Application started being active, and the time it stopped being active.” “For services, events logged into a CDU shall correspond to all usage intervals of no less than 10 seconds and may correspond to shorter usage intervals. For Application activity, events logged into a CDU shall correspond to all usage intervals of no less than 5 seconds and may correspond to shorter usage intervals. The precision and accuracy of start times and end times in the CDUs should be within 1 second.” The payload schema is a 4651-byte JSON structure, so I would imagine that a response-payload fitting this schema would be same-order-of-magnitude size. With 10-second granularity that works out to roughly a half-kilobyte-per-second data rate, and according to the DRC spec the maximum payload size of one DRC message is 2048 bytes. It will also report when you play something back from a DVR: “Component.SourceDeliveryPath – Delivery path used for or the source of the content component indicated by the parent Component element. SourceDeliveryPath.type – 0 – Broadcast delivery (content component is delivered by broadcast) 1 – Broadband delivery (content component is delivered directly by broadband by broadcaster) 2 – Time-shift-buffer source (content source is local time shift buffer) 3 – Hard-drive source (content source is local hard drive) 4 – Delivery via direct connection (HDMI) 5 – Alternate IP delivery (content component is delivered via intermediary)”

timewizard 2y ago

Ironically there's no redundancy in NTSC. There are layers of information and they degrade downward until you have just a black and white picture with no sound. In ATSC there is two types of forward error correction on the digital bitstream. The problem it faces is it sits in the same channel allocations as NTSC while having to deliver significantly more information than NTSC. That and the actual digital modulation used is not as ideal for receivers to capture.

kmeisthax 2y ago
You can digitize and lossily compress an NTSC signal significantly without losing much detail; that's why I call it redundant. Compression removes redundancy. In ATSC the tradeoff between compression and error correction is such that a noisy channel is far more likely to cut out or otherwise be unusable than it would have been in NTSC.

DoubleGlazing 2y ago

Back in the late 90s when Ireland was starting to think about digital terrestrial TV a system called DVB-RCT was considered. Basically your receiver could also transmit back to the television transmitter. The system could handle thousands of concurrent connections, albeit each one had very low bandwidth - around 1Kbp/s in peak time.That was considered good enough for very basic interactivity and for authorising PPV purchases etc.In quieter hours or in areas were there were fewer receivers that bandwidth would be much higher, but in reality that would be rare. In the end the company that the governement selected to start the rollout of DTT went bust and I don't think the system was used anywhere else. The developer of the technology abandoned it in 2006 as other connection methods (broadband/mobile data) were preferred.

mindslight 2y ago

I would think that the expectation is for the common option to be IP backhaul based on embedded LTE/5G modems. Having a separate communication scheme is probably more of a hedge for super rural areas that don't have LTE/5G or other IP coverage, especially as that is where broadcast TV will have more staying power.

Lammy 2y ago
This is my understanding as well. You can see the usage-reporting scheme and data structure here: https://www.atsc.org/wp-content/uploads/2024/04/A333-2024-04-Service-Usage-Reporting.pdf https://www.atsc.org/wp-content/uploads/2024/04/A333-2024-04... “The fundamental record that captures consumption information is called a Consumption Data Unit (CDU). For a streaming A/V channel, each CDU identifies a reporting interval during which a service is accessed. Such a CDU includes the service identifier, the time the service access started and the time the service access ended. If any Applications are active during the report interval, it also records when the Applications are active (whether on a primary device or a “second screen”, companion device), including the Application Identifier, the time the Application started being active, and the time it stopped being active.” “For services, events logged into a CDU shall correspond to all usage intervals of no less than 10 seconds and may correspond to shorter usage intervals. For Application activity, events logged into a CDU shall correspond to all usage intervals of no less than 5 seconds and may correspond to shorter usage intervals. The precision and accuracy of start times and end times in the CDUs should be within 1 second.” The payload schema is a 4651-byte JSON structure, so I would imagine that a response-payload fitting this schema would be same-order-of-magnitude size. With 10-second granularity that works out to roughly a half-kilobyte-per-second data rate, and according to the DRC spec the maximum payload size of one DRC message is 2048 bytes. It will also report when you play something back from a DVR: “Component.SourceDeliveryPath – Delivery path used for or the source of the content component indicated by the parent Component element. SourceDeliveryPath.type – 0 – Broadcast delivery (content component is delivered by broadcast) 1 – Broadband delivery (content component is delivered directly by broadband by broadcaster) 2 – Time-shift-buffer source (content source is local time shift buffer) 3 – Hard-drive source (content source is local hard drive) 4 – Delivery via direct connection (HDMI) 5 – Alternate IP delivery (content component is delivered via intermediary)”