HbbTV Developer Portal
Search ⌘K
Developer Guide API Reference News & Insight Deployments Showcase

Resource Management

In clause 4.4.5 of the OIPF DAE specification [1], the STATIC_ALLOCATION model is not included in the present document. All resource allocation is under the DYNAMIC_ALLOCATION model.

Resource allocation between any number of A/V control objects and/or video/broadcast objects shall be based on a “first-come, first-served” policy. Resources shall not be taken away from one object of either of these types in order to meet a request on a second object of either of these types:

  • If the resources needed for the request on the second object (suitable video decoder, suitable audio decoder and, if the second object is a video/broadcast object, suitable tuner) are not available then the request on the second object shall fail as defined by the API for the type of object concerned.
  • If the resources needed for the request on the second object are available (e.g. the terminal has multiple audio and video decoders available to the HbbTV®implementation) then the resources shall be allocated to the second object and the request shall not fail due to lack of resources (although it may fail for an another unrelated reason).
  • If the request on the second object succeeds then the terminal shall present both objects at the same time without synchronization. If applications wish to have multiple objects present media with synchronization then the objects need to be added to a MediaSynchroniser object.

NOTE 1:  Broadcast-related applications that wish to use a video/broadcast object and also wish to use broadband-delivered content need to put the video/broadcast object into the stopped state to release the media decoders. Calling the unselectComponent method on a video/broadcast object does not release the media decoder for that component type. Changing a video/broadcast object from presenting a TV service to presenting a radio service should not release the video decoder. Changing a video/broadcast object from presenting a TV or radio service to presenting a data service (see clause 7.2.6 of the present document) should not release the video or audio decoder.

NOTE 2:  The policy for managing hardware resources defined here that applies to the A/V Control object and video/broadcast objects (first-come, first-served) is intentionally the exact opposite of the policy defined for the HTML 5 media element in clause 9.6.2 of the present document.

If a broadcast-related application that either:

  • does not include a video/broadcast object at all; or
  • includes a video/broadcast object that is in the unrealized state;

attempts to start playing broadband-delivered video/audio then the presentation of the broadcast channel shall be suspended and allocation of the required media resources by the A/V control object shall succeed. After the A/V control object release the allocated resources, e.g. by stopping the media, presentation of the broadcast service shall resume.

NOTE 3:  In spite of the above requirement, applications wishing to present only broadband-delivered video/audio should explicitly stop broadcast video/audio presentation in order to avoid implementation-dependent behaviour during the transition.

NOTE 4:  The above requirement is unrelated to availability of video and audio decoder resources. Hence such applications will give the same user experience on terminals supporting multiple video and audio decoders as they do on terminals supporting only one decoder of each type. Applications wishing to simultaneously present broadcast-delivered video/audio and broadband-delivered video/audio need to create both a video/broadcast object and an A/V control object or HTML5 media element.

When an HTML5 media element is unable to obtain the resources it needs to present media, then the request to present media through the media element shall fail with a MediaError with code MEDIA_ERR_DECODE.

An HTML5 media element shall not be able to obtain resources that are already in use either by an A/V control object or to present broadcast video (either by the HbbTV® application through a video/broadcast object, or by the terminal when it is presenting broadcast content not under the control of a video/broadcast object). An exception to the previous requirement is when the HTML5 media element and the resources that are in use are under the control of a single MediaSynchroniser object.

Resources are under the control of a single MediaSynchroniser object if there are media objects using those resources (video/broadcast object, A/V control object or HTML5 media element) and they are all currently added to the same MediaSynchroniser object (by means of the initMediaSynchroniser()and addMediaObject() methods).If the resources that would be needed by an A/V Control object or a video/broadcast object are allocated to an HTML5 media element (see clause 9.6.2), and the media element requiring the resource and the current media element owning the resource have not been added to the same media synchronizer object, then the request to present media through the object shall fail. For an A/V control object, the object shall go to playState 6 with the error property being 3, “insufficient resources”. For a video/broadcast object, this shall be reported by an onChannelChangeError with errorState 11, “insufficient resources are available to present the given channel (e.g. a lack of available codec resources)”.

NOTE 5:  Component selection and resource management behaviour is different after a media element has been added to a MediaSynchroniser object. This behaviour ensures that only one audio or video component is decoded simultaneously and the terminal allocates resources across the media objects to achieve this. See clauses 10.2.7.3, 10.2.7.4 and 10.2.7.5 for more details.

The properties extraSDVideoDecodes and extraHDVideoDecodes shall return the number of additional A/V decoders available at the time the application reads the properties and that can be used with either the A/V Control object or HTML5 media elements to render additional broadband streams.