Re: Proposal from HbbTV

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.

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

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

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

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


Looking forward to your thoughts,

  --alexander

Received on Monday, 13 October 2014 20:45:25 UTC