A/344, dated December 18, 2017, is titled "ATSC 3.0 Interactive Content." So it
finally explains what has confused so many trade scribes for so long. The long
as the short of it is:
For interactivity (leaving aside interacting merely with content stored in a TV
set or STB), in addition to (or instead of) the ATSC 3.0 broadcast channel, you
need a two-way broadband channel.
I used this example years ago, and it continues to apply. The principle is the
same as what has been done for decades with call-in radio programs. If you want
to call in to a radio show, it takes more than a "backchannel." In addition to
the radio channel you are listening to, to call in, you need a fully
bidirectional, standard, telephone connection. In fact, the broadcast radio
channel is not even necessary, when making the phone call. Same applies exactly
to ATSC 3.0 interactivity. It requires a separate, two-way, broadband
connection.
https://www.atsc.org/wp-content/uploads/2017/12/A344-2017-Interactive-Content.pdf
The above link is the A/344 standard. To point out what's involved, it says:
"Specifically, ATSC is working to coordinate television standards among
different communications media focusing on digital television, interactive
systems, and broadband multimedia communications."
So, "coordinate among different media" is the key concept.
Sure, one has always been able to store broadcast material, and then later do
what appears to be an interactive session locally. As a trivial example, any
PVR can do that. No need for IP overhead. But we all know that's cheating, when
we talk about interactivity. The main focus of this new standard is to allow
use of broadband service, to the TV set or STB.
ATSC 3.0 adds a (functionally) minor wrinkle, in that it can broadcast to local
storage one or more of the potential interactive links, regardless of user
interest, and then fool the user into thinking that requesting the stored
link(s) is the same as requesting other Internet-based content. A bit of a tour
de force if you ask me, but okay. It goes into these explanations here:
--------------------------
5.3 Origin Considerations
Each file that is delivered via broadband has the usual absolute URL associated
with it. Each file that is delivered via broadcast has a relative URL reference
associated with it, signaled in the broadcast, and it also has one or more
Application Context Identifiers associated with it, signaled in the broadcast.
As specified below, Receivers assign to each broadcast file a Base URI that
converts the relative URL reference to one or more absolute URLs, taking its
Application Context Identifier(s) into account.
An Application Context Identifier is a unique URI that determines which
resources are provided to an associated Broadcaster Application by the
Receiver. The Application Context Identifier to be bound to the Broadcaster
Application is signaled in the HELD [3]. An Application Context Identifier may
be associated with many Broadcaster Applications however each Broadcaster
Application shall be associated with a single Application Context Identifier.
Each Application Context Identifier forms a unique conceptual environment in
which the Receiver is expected to comingle resources for use by the associated
Broadcaster Applications. This unique conceptual environment is referred to
herein as the Application Context Cache.
...
As described in Section 6, when delivered via broadcast, a Broadcaster
Application is launched with a URI defined by the Receiver. The Base URI
portion of the URI, that is, the portion of the URI prior to the relative path
supplied by ROUTE transmission, shall uniquely correspond to the Application
Context Identifier.
The algorithm used to generate the Base URI for a given Application Context
Identifier should be consistent, that is, the algorithm should repeatedly
produce the same URI over time. Thus, the combination of scheme, authority and
path prefix should always be unique. However, Broadcaster Applications should
not rely on the uniqueness by itself of either the origin or path prefix
provided by the Receiver as part of the Entry Page URL. The Broadcaster
Application is expected to manage a local name space for setting cookies and
other local User Agent storage elements.
--------------------------
So, they go to considerable lengths to allow for locally stored content to
appear to be like other Internet-based content, although for the true Internet
content, no clever tricks need to be played with URLs. And naturally, numerous
IETF standards have to be cited.
In practice, for uses such as VOD, it seems unlikely that stored content would
be used much of the time. Doing so would consume loads of broadcast channel
capacity, for something that very few people in a market will want, anytime
soon. Seems to me that ATSC 3.0 broadcasters are free to broadcast nothing at
all, for interactive service, and just allow TV receivers that support A/344 to
interact with real Web-based content. No one will be the wiser. A broadcaster
could even provide its own web site, for this purpose, and never use the URI
broadcast method. The KISS principle, in other words.
The current crop of "connected TVs" don't have standard browsers, but rather
some proprietary scheme, typically Roku. A/344 needs something much more like
standard browsers. Will be interesting to see what will come of any of this.
Bert
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.