Re: Proposal from HbbTV

Hi Alexander,

One other comment. Iım looking at this document
http://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.11.01_60/en_300
468v011101p.pdf as the DVB_SI reference. Is that correct. Rather than
using a localBiblio in the sourcing spec, weıve been updating the master
respec database https://github.com/tobie/specref. Please do a pull request
to add your DVB references.

Thanks,
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.
>
>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%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.
>
>> 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.
>
>
>
>Cheers,
>
>  --alexander
>
>
>

Received on Monday, 29 September 2014 21:52:38 UTC