Re: Proposal from HbbTV

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%2Fsilviapfeiffer%2FHTMLSourcingInbandTracks%2Fmaster%2Findex.html&doc2=https%3A%2F%2Frawgit.com%2Fc-alpha%2FHTMLSourcingInbandTracks%2Fhbbtv-mpeg2ts-1%2Findex.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.

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; 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. 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.

>> 2. http://services.w3.org/htmldiff?doc1=https%3A%2F%2Frawgit.com%2Fsilviapfeiffer%2FHTMLSourcingInbandTracks%2Fmaster%2Findex.html&doc2=https%3A%2F%2Frawgit.com%2Fc-alpha%2FHTMLSourcingInbandTracks%2Fhbbtv-mpeg2ts-2%2Findex.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%2Fsilviapfeiffer%2FHTMLSourcingInbandTracks%2Fmaster%2Findex.html&doc2=https%3A%2F%2Frawgit.com%2Fc-alpha%2FHTMLSourcingInbandTracks%2Fhbbtv-mpeg2ts-3%2Findex.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.

> 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%2Fsilviapfeiffer%2FHTMLSourcingInbandTracks%2Fmaster%2Findex.html&doc2=https%3A%2F%2Frawgit.com%2Fc-alpha%2FHTMLSourcingInbandTracks%2Fhbbtv-mpeg2ts-6%2Findex.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.



Cheers,

  --alexander

Received on Monday, 29 September 2014 15:50:43 UTC