Re: Proposal from HbbTV

Hi Alexander,

Please see my responses to you comments in-line below.

Regards,
Bob

On 9/29/14, 9:50 AM, "Alexander Adolf"
<alexander.adolf@condition-alpha.com> wrote:

>Dear Bob,
>
>Thanks for thoughtful comments.
>
>On 2014-09-27, at 00:12 , Bob Lund <B.Lund@CableLabs.com> wrote:
>
>>> [...]
>>> 3. Changes for MPEG-2 TS section:
>>> ============================
>>> 1. 
>>>http://services.w3.org/htmldiff?doc1=https%3A%2F%2Frawgit.com%2Fsilviapf
>>>eiffer%2FHTMLSourcingInbandTracks%2Fmaster%2Findex.html&doc2=https%3A%2F
>>>%2Frawgit.com%2Fc-alpha%2FHTMLSourcingInbandTracks%2Fhbbtv-mpeg2ts-1%2Fi
>>>ndex.html
>> 
>> The added text for determining the type of broadcast system does not
>>appear to be something the UA needs to do. AFAICT in the diffs below,
>>all DVB cases reference DVB specific information or descriptors for
>>doing some DVB specific action. Theses wonıt exist in the ATSC case.
>>And, the ATSC specific information wonıt exist in DVB. So, the UA can
>>just do the ATSC action or DVB action based on the presence of ATSC or
>>DVB information.
>
>I don't think that's quite as true in the generality you seem to be
>stating it in. To my knowledge there is no unambiguous way for a receiver
>to tell whether a table with a table_id value of 0x40 is a NIT from a DVB
>system, or a user private table from an ATSC system, or a NIT from an
>ISDB system. A table with table_id 0xC7 could be an MGT from an ATSC
>system, or an LDT from an ISDB system, or a user private table from a DVB
>system. Yes, you could take the PID into account, but would still be
>second guessing. Similar examples could likely be found for PMT
>descriptors. Further knowledge is needed for the receiver to take a
>decision.

I think we need to concern ourselves with the specified set of descriptors
and tables referenced in the sourcing spec, not worry about the general
case. Have you identified cases of ambiguity between ATSC and DVB with
regard to this specific set?

A related question - does DVB require the use of the
transport_stream_descriptor? In other words, are transport streams without
this descriptor malformed DVB media containers?

>
>The problem is, that TV receivers are not designed for roaming users.
>Hence, a TV receiver will typically only implement a single broadcast
>standard. Co-ordination on code points between the broadcast standards
>bodies has not been a vital issue (and therefore has hardly happened). In
>the broadcast case, the receiver's decision is alleviated by the RF
>modulations not exactly being interoperable. I.e. if the device
>incorporates a tuner and demod for system X, and it can acquire a carrier
>lock and the frame error rate is within reason, it will be highly likely
>that it is indeed receiving a transmission according to X.
>
>For a Web UA we are talking about a different environment, however. A
>video/mp2t resource retrieved form a server over HTTP doesn't have any
>metadata attached to it (at least not in the current model;

What do you mean by ³metadata²? Do you mean data that identifies the
broadcast system? A transport stream with a single program will have a PMT
that contains descriptors used to source track attributes.

> maybe it should have in the future). A UA can just download it. To
>figure out what format the inband metadata inside the file has,
>additional information is needed.

Not if the specific set of descriptors and tables referenced in the
sourcing spec have unique ids across ATSC and DVB.

> Either new mime types could be defined (e.g. video/mp2t-dvb), or some
>sort of geolocation information is needed (W3C Geolocation API or by IP
>address geolocation (but which has limitations)). Hence my approach of
>hinting to the geographic location.

If there indeed is collision between ATSC and DVB descriptor/table ids
referenced in the sourcing spec and if the transport_stream_descriptor is
required in all valid DVB transport streams, this could be used to
distinguish DVB from ATSC.

>
>>> 2. 
>>>http://services.w3.org/htmldiff?doc1=https%3A%2F%2Frawgit.com%2Fsilviapf
>>>eiffer%2FHTMLSourcingInbandTracks%2Fmaster%2Findex.html&doc2=https%3A%2F
>>>%2Frawgit.com%2Fc-alpha%2FHTMLSourcingInbandTracks%2Fhbbtv-mpeg2ts-2%2Fi
>>>ndex.html
>> 
>> There doesnıt appear to be a need to the UA to distinguish based on
>>broadcast system so no need to change the first paragraph.
>> 
>> The table based on broadcast system type doesnıt add any value. Audio,
>>video and text tracks are identified in DVB just as in ATSC ­ based on
>>stream_type and the presence of specific descriptors. You should keep
>>the text format that is there and add to it. For example, in text tracks:
>> [...]
>
>With the tables, app developers can IMHO get a quick overview of what
>features are available on what broadcast systems. My hope was that this
>would help creating apps that are independent of the broadcast system
>type.
>
>As pointed out to Silvia earlier, I am fairly passionless about which way
>to structure things, as long as it meets the expectations and needs of
>your audience.
>
>>> 3. 
>>>http://services.w3.org/htmldiff?doc1=https%3A%2F%2Frawgit.com%2Fsilviapf
>>>eiffer%2FHTMLSourcingInbandTracks%2Fmaster%2Findex.html&doc2=https%3A%2F
>>>%2Frawgit.com%2Fc-alpha%2FHTMLSourcingInbandTracks%2Fhbbtv-mpeg2ts-3%2Fi
>>>ndex.html
>> 
>> Keep the existing table format
>> 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?

>
>> And, why canıt the pid be a decimal representation as in the case of
>>ATSC?
>> [...]
>
>Because we needed an easy way of telling whether the component_tag or the
>PID is given.
>
>>> 6. 
>>>http://services.w3.org/htmldiff?doc1=https%3A%2F%2Frawgit.com%2Fsilviapf
>>>eiffer%2FHTMLSourcingInbandTracks%2Fmaster%2Findex.html&doc2=https%3A%2F
>>>%2Frawgit.com%2Fc-alpha%2FHTMLSourcingInbandTracks%2Fhbbtv-mpeg2ts-6%2Fi
>>>ndex.html
>>> (note: this patch destroys the document structure)
>> 
>> I donıt understand this. First, you state generically that caption cues
>>are exposed as DataCue. This is may not be true for ATSC. Then you
>>define a DVB DataCue that doesnıt have any fields populated, except
>>pause_on_exit. I suggest the following instead:
>> 
>> MPEG-2 TS captions are in the CEA 708 format [CEA708].
>> [...]
>
>I agree that the "not used" column is probably not the best possible way
>of expressing this, and that a better solution can and will be found. But
>at least we would need to distinguish between the broadcast systems. The
>sentence "MPEG-2 TS captions are in the CEA 708 format [CEA708]." is true
>only for ATSC. For DVB and ISDB the format is a different one.

Yes, I agree. Thatıs why I suggested the change to ³MPEG-2 TS captions in
the CEA-708 format Š . This allows for MPEG-2 captions in other formats
without getting into the details of which format is used by which
broadcast system.

>
>
>
>Cheers,
>
>  --alexander
>
>
>

Received on Monday, 29 September 2014 21:46:43 UTC