Re: Proposal from HbbTV



On 10/13/14, 2:44 PM, "Alexander Adolf"
<alexander.adolf@condition-alpha.com> wrote:

>Dear Bob,
>
>On 2014-10-07, at 17:39 , Bob Lund <B.Lund@CableLabs.com> wrote:
>
>> [...]
>> I have created PR #28 [1] that is the proposed additions to handle DVB
>>in
>> the MPEG-2 TS section. Your additions have been reformatted into the
>> existing spec format. The proposal for a multi-field track ID in the DVB
>> case is added. This will require the application to determine that the
>> content is DVB format by parsing the track ID format.
>
>Apologies for my delay in responding, and thanks for your efforts and
>support.
>
>This looks quite good overall. I do have a concern however with the
>auto-detect approach you are taking. As explained earlier, the
>coordination on code points between the broadcast standards has ben
>minimal at best.
>
>Just a few examples:
>
>- In 3.2 a text track is assumed if the PID is 0x0002. This may be true
>for one broadcast standard, but under another system the PID 0x0002 may
>be present, but may not carry a text track.

PID 0x02 is reserved by MPEG (ISO 13818-1 2013) for carrying transport
stream description tables.

>
>- In 3.3 for @id you use program_number zero to detect a DVB stream. That
>program number is however assigned by MPEG (not DVB) for the network
>information table. Unfortunately DVB is not the only standard to use this
>mechanism; ISDB uses it too. Therefore, if program zero is present it may
>be a DVB or an ISDB stream.

Doesn¡¯t the original_network_id (or some other field) carried in the
program 0 identify whether it is DVB or something else?.

>
>I could continue this list for a little more; but then the point is
>already made I hope.

Not yet. I can imagine in the general case there might be a case where it
is ambiguous how to interpret some element of a TS between ATSC, DVB and
ISDB. But, the sourcing spec has a well defined set of information the UA
needs to interpret and you haven¡¯t pointed out a clear case where
ambiguity arises.

With that said, I had asked in a previous email whether it is mandatory
for a DVB TS to carry something that identifies is as DVB, for the example
the transport_stream_descriptor in PID 0x02. Your original contribution in
this regard [1] described several things a UA might be able to look at to
distinguish DVB but there didn¡¯t seem to be anything the UA could count on
being there. If there was something the UA could count on to identify DVB
then this could be referenced.

[1] 
http://rawgit.com/c-alpha/HTMLSourcingInbandTracks/hbbtv-mpeg2ts-1/index.ht

ml#mpeg2ts-determining-the-system-type
 
>
>Hence, relying on the broadcast systems being auto-detectable from the
>MPEG2-TS content alone IMO is not a sufficiently robust approach.
>
>Based on my impression that my initially proposed way of extending the
>text was perceived as overly complex, I'd like to propose yet another
>approach for structuring it:
>
>3. MPEG-2 Transport Streams
>3.1 MPEG-2 TS originating from ATSC broadcast systems
>3.2 MPEG-2 TS originating from DVB broadcast systems

This is of course possible but it begs the question what can the UA count
on to identify the TS as DVB, the question in my comment above.

>
>Happy to prepare a pull request for this.
>
>> There is a question for you in section 4 ©øTrack Attributes for sourced
>> Audio and Video Tracks©÷ for sourcing @kind (NOTE paragraph). You state
>> ©øthat the user agent would select by default©÷. In DVB, how is it
>>signaled
>> to the UA that a track is the default? I will update the PR with your
>> answer.
>> [...]
>
>DVB does not signal the default track. The model there is that the
>receiver has been configured with the user's preferences for audio
>language, subtitle language, and any assistive stuff (signing, audio
>description etc.). Based on these preferences the receiver picks those
>tracks that meet the user's expectation of "default". We have had long
>and passionate discussions in DVB whether signalling of a "default"
>component should be added, but it already breaks down at the language. If
>a satellite operator serving Western Europe would e.g. signal English as
>the default audio, and also provide other language audios, it would not
>be the right choice for all non English speaking countries, and users in
>those other countries would have to manually change back to their native
>audio language after zapping to that channel.
>
>I hence wouldn't recommend trying to have the document define a default
>track. Instead, the UA should make a decision based on the user's
>preferences as outlined above. Where that would fit in the W3C canon?
>Good point...

I asked this question specifically in the context of identifying whether
an audio track is ¡°main¡± or ¡°translation¡±. I guess absent some mechanism,
all candidate audio tracks could have the @kind set to ¡°translation¡± and
the app could decide which is the default, and therefore ¡°main¡±. It would
not be able to change the @kind, however.
 
>
>
>Looking forward to your thoughts,
>
>  --alexander

Received on Monday, 13 October 2014 21:40:53 UTC