Re: Proposal from HbbTV



On 10/6/14, 4:51 AM, "Alexander Adolf"
<alexander.adolf@condition-alpha.com> wrote:

>Dear Bob,
>
>On 2014-09-30, at 18:13 , Bob Lund <B.Lund@CableLabs.com> wrote:
>>>>>> [...]
>>>>>> 
>>>>>> For @id, why doesn©öt the use of PID work.
>>>> 
>>>>> PID can't work in Europe as we do a lot of forwarding of broadcast
>>>>> streams and service aggregation. A service on a cable trunk for
>>>>>instance
>>>>> may come from a terrestrial feed, which in turn is sourced from a
>>>>> satellite feed, and the cable operator is mixing is some more
>>>>>services
>>>>> from another satellite or another cable. The probability that the PID
>>>>> will be changed a couple of times along the way is quite high. For
>>>>>this
>>>>> reason DVB has invented the stream identifier descriptor, bearing a
>>>>> component_tag. Even if the PID changes the tag is retained.
>>> 
>>>> But why does it matter? The transport stream still requires that PIDs
>>>>be
>>>> unique. So, each HTML track will have a unique id if PID is used. What
>>>> else does the track.id need to convey to the Web application?
>
>Ah that's a very good question! Apologies for not having provided more
>explanation earlier on in.
>
>Beyond unambiguously distinguishing the tracks in the player - for which
>PID would be sufficient - in HbbTV we are looking at applications
>referencing tracks. Such an application will typically be authored and
>provided by the content originator. If the original broadcaster in their
>app were to use the PID under which they broadcast a particular track,
>that PID would become altered after the signal going e.g. from satellite
>into a cable network. But the cable provider downlinking the satellite
>service will of course not be able to change the JS to accommodate the
>new PID value. Hence, for HbbTV, we need and end-to-end unique identifier
>that is independent of the underlying transport, so that a document or JS
>script can unambiguously reference a particular track no matter what
>sausage machines the TS has gone through.
>
>I was wondering whether OCAP might not have similar requirements on track
>identification?

Thanks for the explanation. eTV does have applications bound to specific
content items but it is done using EBIF [1] for defining ¡°bound apps¡± and
EISS [2] for signaling of those apps. The basic concept is that an EBIF
app gets downloaded from a data carousel and EISS signaling embedded in an
MPEG-2 TS (or conceivably ISOBMFF trak or DASH AdaptationSet) controls the
launching and life cycle of the app. So, an app is ¡°bound¡± to content by
virtue of the signaling being a track in the content.

CableLabs has demonstrated how this can work in the Web world. The EBIF
app is replaced by a Web page. EISS messages are delivered as metadata
text track cues. The messages specify the app URL and control the
lifecycle of the app. This approach removes the need for a globally unique
content id to be associated , and instead, uses an app signaling channel
associated with the content item.

We¡¯ve got a demo and reference code if you¡¯re interested.

>
>>> For DVB systems, the spec might as well just require that the id be a
>>> unique identifier arbitrarily assigned by the UA rather than requiring
>>> that identifier to be the PID.
>
>I am afraid that I'm not fully with Nigel here. See my explanations above.
>
>> So the unique identifier assigned by the UA could be the PID, right? It
>> would best for interoperability if the the UA set the MPEG-2 TS track id
>> the same way in all cases.
>
>As opposed to the Web, the broadcast landscape is segmented into national
>profiles since governments traditionally very closely regulate their
>broadcast market. Hence, historically there is a different, national
>broadcast profile in each and every country. Back in the analogue days,
>there were eight different flavours of PAL, seven flavours of SECAM, and
>three flavours of NTSC. Hence, there unfortunately still is no one, true,
>global digital TV receiver implementation that fits all.
>
>But of course there is a one, true, global UA implementation that ought
>to fit all. Apparently there is a structural gap to bridge here, and the
>segmentation of the MPEG2-TS section as we are suggesting is a symptom of
>this gap.
>
>I am fully with you that a single, global TV standard would have
>benefited industry and consumers alike. But then - for numerous reasons -
>we are stuck with the history we have.
>
>Looking forward to your comments,
>
>  --alexander

Received on Monday, 6 October 2014 16:01:43 UTC