List of Approved Test Assertions applicable to HbbTV Specifications ≥ v1.4.1 from test suite 2024-2 generated on 06 Dec 24 at 04:27:52.
| ID | Version | Title | Assertion text | Test Suite Version | Additional Information | Applicability | Specification reference | Required terminal options | Optional features |
|---|---|---|---|---|---|---|---|---|---|
| com.eurofins_UHD-ADAPTATION-1010 | 1 | HTML5 DASH video representation transition from UHD PQ10 (without Optional Supplemental Enhancement Information) HDR to HD PQ10 (without Optional Supplemental Enhancement Information) HDR content with same frame rate within the same adaptation set following bandwidth restriction | When the available bandwidth is restricted, the device shall smoothly transition from a PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 5.1 3840x2160p 50fps video representation to a PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 4.1 1920x1080p 50fps video representation within the same adaptation set of the HTML5 DASH content being played back | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply: * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows: * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +PQ10 | ||
| com.eurofins_UHD-ADAPTATION-1020 | 1 | HTML5 DASH video representation transition from HD PQ10 (without Optional Supplemental Enhancement Information) HDR to UHD PQ10 (without Optional Supplemental Enhancement Information) HDR content with same frame rate within the same adaptation set following bandwidth being unrestricted | When the available bandwidth is unrestricted, the device shall smoothly transition from a PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 4.1 1920x1080p 50fps video representation to a PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 5.1 3840x2160p 50fps video representation within the same adaptation set of the HTML5 DASH content being played back | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply: * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows: * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +PQ10 | ||
| com.eurofins_UHD-ADAPTATION-1030 | 1 | HTML5 DASH video representation transition from UHD PQ10 (without Optional Supplemental Enhancement Information) HDR to HD PQ10 (without Optional Supplemental Enhancement Information) HDR content with different frame rate within the same adaptation set following bandwidth restriction | When the available bandwidth is restricted, the device shall smoothly transition from a PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 5.1 3840x2160p 50fps video representation to a PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 4.1 1920x1080p 25fps video representation within the same adaptation set of the HTML5 DASH content being played back | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply: * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows: * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +PQ10 | ||
| com.eurofins_UHD-ADAPTATION-1040 | 1 | HTML5 DASH video representation transition from HD PQ10 (without Optional Supplemental Enhancement Information) HDR to UHD PQ10 (without Optional Supplemental Enhancement Information) HDR content with different frame rate within the same adaptation set following bandwidth becoming unrestricted | When the available bandwidth becomes unrestricted, the device shall smoothly transition from a PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 4.1 1920x1080p 25fps video representation to a PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 5.1 3840x2160p 50fps video representation within the same adaptation set of the HTML5 DASH content being played back | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply: * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows: * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +PQ10 | ||
| com.eurofins_UHD-ADAPTATION-1050 | 1 | HTML5 DASH video representation transition from UHD HLG10 HDR to HD HLG10 HDR content with same frame rate within the same adaptation set following bandwidth restriction | When the available bandwidth is restricted, the device shall smoothly transition from a HLG10 HEVC, Main 10, Level 5.1 3840x2160p 50fps video representation to a HLG10 HEVC, Main 10, Level 4.1 1920x1080p 50fps video representation within the same adaptation set of the HTML5 DASH content being played back | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +HEVC_UHD | ||
| com.eurofins_UHD-ADAPTATION-1060 | 1 | HTML5 DASH video representation transition from HD HLG10 HDR to UHD HLG10 HDR content with same frame rate within the same adaptation set following bandwidth becoming unrestricted | When the available bandwidth becomes unrestricted, the device shall smoothly transition from a HLG10 HEVC, Main 10, Level 4.1 1920x1080p 50fps video representation to a HLG10 HEVC, Main 10, Level 5.1 3840x2160p 50fps video representation within the same adaptation set of the HTML5 DASH content being played back | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +HEVC_UHD | ||
| com.eurofins_UHD-ADAPTATION-1070 | 1 | HTML5 DASH video representation transition from UHD HLG10 HDR to HD HLG10 HDR content with different frame rate within the same adaptation set following bandwidth restriction | When the available bandwidth is restricted, the device shall smoothly transition from a HLG10 HEVC, Main 10, Level 5.1 3840x2160p 50fps video representation to a HLG10 HEVC, Main 10, Level 4.1 1920x1080p 25fps video representation within the same adaptation set of the HTML5 DASH content being played back | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +HEVC_UHD | ||
| com.eurofins_UHD-ADAPTATION-1080 | 1 | HTML5 DASH video representation transition from HD HLG10 HDR to UHD HLG10 HDR content with different frame rate within the same adaptation set following bandwidth becoming unrestricted | When the available bandwidth becomes unrestricted, the device shall smoothly transition from a HLG10 HEVC, Main 10, Level 4.1 1920x1080p 25fps video representation to a HLG10 HEVC, Main 10, Level 5.1 3840x2160p 50fps video representation within the same adaptation set of the HTML5 DASH content being played back | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +HEVC_UHD | ||
| com.eurofins_UHD-ADAPTATION-1090 | 1 | HTML5 DASH video representation transition from PQ10 (without Optional Supplemental Enhancement Information) HDR 3840x2160 to PQ10 (without Optional Supplemental Enhancement Information) HDR 3200x1800 content with same frame rate within the same adaptation set following bandwidth restriction | When the available bandwidth is restricted, the device shall smoothly transition from a PQ10 HDR, Main 10, Level 5.1 3840x2160p 50fps video representation to a PQ10 HDR, Main 10, Level 5.1 3200x1800p 50fps video representation within the same adaptation set of the HTML5 DASH content being played back | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2020-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply: * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows: * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +PQ10 | ||
| com.eurofins_UHD-ADAPTATION-1100 | 1 | HTML5 DASH video representation transition from PQ10 (without Optional Supplemental Enhancement Information) HDR 2560x1440 to PQ10 (without Optional Supplemental Enhancement Information) HDR 3840x2160 content with same frame rate within the same adaptation set following bandwidth becoming unrestricted | When the available bandwidth becomes unrestricted, the device shall smoothly transition from a PQ10 HDR, Main 10, Level 5.1 2560x1440p 50fps video representation to a PQ10 HDR, Main 10, Level 5.1 3840x2160p 50fps video representation within the same adaptation set of the HTML5 DASH content being played back | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply: * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows: * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +PQ10 | ||
| com.eurofins_UHD-ADAPTATION-1110 | 1 | HTML5 DASH video representation transition from HLG10 HDR (3840x2160) to HLG10 HDR (3200x1800) content with same frame rate within the same adaptation set following bandwidth restriction | When the available bandwidth is restricted, the device shall smoothly transition from a HLG10 HDR, Main 10, Level 5.1 3840x2160p 50fps video representation to a HLG10 HDR, Main 10, Level 5.1 3200x1800p 50fps video representation within the same adaptation set of the HTML5 DASH content being played back. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +HEVC_UHD | ||
| com.eurofins_UHD-ADAPTATION-1120 | 1 | HTML5 DASH video representation transition from HLG10 HDR (2560x1440) to HLG10 HDR (3840x2160) content with same frame rate within the same adaptation set following bandwidth becoming unrestricted | When the available bandwidth becomes unrestricted, the device shall smoothly transition from a HLG10 HDR, Main 10, Level 5.1 2560x1440p 50fps video representation to a HLG10 HDR, Main 10, Level 5.1 3840x2160p 50fps video representation within the same adaptation set of the HTML5 DASH content being played back | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2020-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content delivered within an MPEG-DASH adaption set, devices shall transition seamlessly between video representations where any combination of frame rate, bit-rate, codec/profile/level and resolution differ, as specified in section 10.4 [10] TS-103-285,section 10.4: [...] Players shall support seamless switching between video Representations which differ only in any combination of the following properties: * Frame rate, providing the frame rate is within one of the following families and is supported by the player (e.g. HFR): - 25, 50, 100 fps - 30/1,001, 60/1,001, 120/1,001 fps - 30, 60, 120 fps - 24 fps - 24/1,001 fps * Bit rate * Profile and/or level * Resolution, subject to maintaining the same picture aspect ratio HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +HEVC_UHD | ||
| com.eurofins_UHD-ADINS-1010 | 1 | HTML5 post-roll advert insertion, DASH PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 5.1 and MP4 AVC_HD_25 | Content is presented when a currently playing HTML5 media element referencing DASH with PQ10 HEVC, Main 10, Level 5.1 media is ended, and preloaded MP4 with AVC_HD_25 media is played in its entirety | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content transitions at a period boundary or between media objects (i.e. for advert insertion) devices shall be capable of transitioning between content with different frame rates, bit-rates, codecs/profiles/levels, and resolutions (as per section 10.5.3 [10] and Annex J [11]) as well as SDR/HDR format. The transition may be seamless but that is not mandated. HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply: * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows: * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met: [...] * the readyState of the second HTML5 media element has reached HAVE_FUTURE_DATA or greater (as indicated by the "canplay" event); HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | +PQ10 | ||
| com.eurofins_UHD-ADINS-1020 | 1 | HTML5 pre-roll advert insertion, MP4 AVC_HD_25 and DASH PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 5.1 | Content is presented when a currently playing preloaded MP4 with AVC_HD_25 media is played in its entirety, and then an HTML5 media element referencing DASH with PQ10 HEVC, Main 10, Level 5.1 media is played | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content transitions at a period boundary or between media objects (i.e. for advert insertion) devices shall be capable of transitioning between content with different frame rates, bit-rates, codecs/profiles/levels, and resolutions (as per section 10.5.3 [10] and Annex J [11]) as well as SDR/HDR format. The transition may be seamless but that is not mandated. HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply: * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows: * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met: [...] * the readyState of the second HTML5 media element has reached HAVE_FUTURE_DATA or greater (as indicated by the "canplay" event); HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | +PQ10 | ||
| com.eurofins_UHD-ADINS-1030 | 1 | HTML5 post-roll advert insertion, DASH HLG10 HEVC, Main 10, Level 5.1 and MP4 AVC_HD_25 | Content is presented when a currently playing HTML5 media element referencing DASH with HLG10 HEVC, Main 10, Level 5.1 media is ended, and preloaded MP4 with AVC_HD_25 media is played in its entirety | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content transitions at a period boundary or between media objects (i.e. for advert insertion) devices shall be capable of transitioning between content with different frame rates, bit-rates, codecs/profiles/levels, and resolutions (as per section 10.5.3 [10] and Annex J [11]) as well as SDR/HDR format. The transition may be seamless but that is not mandated. HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met: [...] * the readyState of the second HTML5 media element has reached HAVE_FUTURE_DATA or greater (as indicated by the "canplay" event); HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | +HEVC_UHD | ||
| com.eurofins_UHD-ADINS-1040 | 1 | HTML5 pre-roll advert insertion, MP4 AVC_HD_25 and DASH HLG10 HEVC, Main 10, Level 5.1 | Content is presented when a currently playing MP4 with AVC_HD_25 media is played in its entirety, and then an HTML5 media element referencing pre-buffered DASH with HLG10 HEVC, Main 10, Level 5.1 media is played. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.4.2: For content transitions at a period boundary or between media objects (i.e. for advert insertion) devices shall be capable of transitioning between content with different frame rates, bit-rates, codecs/profiles/levels, and resolutions (as per section 10.5.3 [10] and Annex J [11]) as well as SDR/HDR format. The transition may be seamless but that is not mandated. HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met: [...] * the readyState of the second HTML5 media element has reached HAVE_FUTURE_DATA or greater (as indicated by the "canplay" event); HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | +HEVC_UHD | ||
| com.eurofins_UHD-DRM-CLEARKEY-1010 | 1 | HTML5 static video element to display DASH PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 5.1, 50 FPS EME CLEARKEY-protected content | When the terminal loads an HbbTV Application including an HTML5 media object which media source is initialized with a static MPD defining a stream containing AAC audio and HEVC-encoded 3840x2160p 50fps PQ10 HDR format video content, both protected with the "Clear Key" System the media shall be correctly presented by the terminal and the playback shall be smooth and contain no decoding artifacts. | 2024-2 2024-1 2023-3 2023-2 2020-3 2020-2 2020-1 | The challenge exists but not validated | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.3.2: Devices shall support decryption of protected content delivered via broadband. Devices shall support use of W3C Encrypted Media Extensions (EME) to the HTMLMediaElement [18] to enable decryption of content delivered via broadband. Devices shall support decryption of content protected with the "Clear Key" System as defined in clause B.3 of [11]. HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply: * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the media elements as follows: * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +PQ10 | |
| com.eurofins_UHD-EAC3-1010 | 1 | HTML5 static video element displaying DASH HLG10 HEVC, Main 10, Level 5.1, 50 FPS video and EAC3 audio content | When the terminal loads an HbbTV Application including an HTML5 media object which references a static MPD defining a stream containing EAC3 audio and HEVC-encoded 3840x2160p 50fps HLG10 HDR format video content with BT.2020 colour space, the media shall be correctly presented by the terminal and the playback shall be smooth and contain no decoding artifacts. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 4K_HDR_UHD,section 2.1.1.2: Devices shall be capable of decoding video for at least the luminance resolutions, scan types, aspect ratios and frame rates in Table 2. ... Luminance resolution: 3840*2160, Scan: Progressive, Aspect Ratio: 16x9, Frame Rate: 50 FPS. 4K_HDR_UHD,section 2.1.1.3: Signalling of HLG10 and PQ10 shall be supported as described in sections 5.14.4.4.2 and 5.14.4.4.3 of [1] respectively. 4K_HDR_UHD,section 2.1.2: Devices shall be capable of decoding the following audio stream formats: ... * EAC-3 [19] for streams delivered via broadcast and broadband (optional). 4K_HDR_UHD,section 2.1.3.1: Devices shall support content being delivered over broadband via HbbTV [11]. HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +EAC3 +HEVC_UHD | ||
| org.hbbtv_00000020 | 2 | Test for running PRESENT application after service selection (Service Bound) | After service selection, with an already running service bound application, and the same application signaled as PRESENT in the AIT of the newly selected service, the terminal shall kill the currently running application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.2: Transition in state diagram: New service selected - App running - Service bound yes - Signaled as PRESENT yes - Kill - Done. | |||
| org.hbbtv_00000030 | 1 | Test for running AUTOSTART application after service selection (Not Service Bound) | After service selection, with an already running not service bound application, and the same application signaled with control code AUTOSTART in the AIT of the newly selected service, the terminal shall allow the application to run uninterrupted. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.2: Transition in state diagram: New service selected - App running - Service bound no - Signaled as AUTOSTART yes - Allow to run - Done. | |||
| org.hbbtv_00000040 | 2 | Test for running PRESENT application after service selection (Not Service Bound) | After service selection, with an already running not service bound application, and the same application signalled with control code PRESENT in the AIT of the newly selected service, the terminal shall allow the application to run uninterrupted. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.2: Transition in state diagram: New service selected - App running - Service bound no - Signalled as PRESENT yes - Allow to run - Done. | |||
| org.hbbtv_00000050 | 2 | Test for running DISABLED application after service selection (Not Service Bound) | After service selection, with an already running not service bound application, and the same application signalled with control code DISABLED in the AIT of the newly selected service, the terminal shall allow the application to run uninterrupted. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.2: Transition in state diagram: New service selected - App running - Service bound no - Signalled as DISABLED yes - Allow to run - Done. | |||
| org.hbbtv_00000060 | 2 | Test for KILLED application after service selection (Not Service Bound) | After service selection, with an already running not service bound application, and the same application signaled with control code KILL in the AIT of the newly selected service, the terminal shall kill the currently running application. | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.2: Transition in state diagram: New service selected - App running - Service bound no - Signaled as KILL yes - Kill application - Done. | |||
| org.hbbtv_00000070 | 2 | Test for NOT SIGNALLED application after service selection (Not Service Bound) | After service selection, with an already running not service bound application, and the same application is not signalled in the AIT of the newly selected service, the terminal shall kill the currently running application. | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.2: Transition in state diagram: New service selected - App running - Service bound no - Not signalled - Kill application | |||
| org.hbbtv_00000110 | 3 | AIT changes while no broadcast related application is running, AUTOSTART application from DSMCC signalled, part 1 | While a service is selected and no application is signalled, the terminal shall detect a change in the AIT; which is updated to contain one AUTOSTART application carried on a DSMCC carousel. The terminal shall start that application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - Does the terminal have an operational broadband connection? Yes - Is an App signalled as AUTOSTART? Yes - ... - Load application via DSMCC - Done. | |||
| org.hbbtv_00000160 | 2 | AIT changes while no broadcast related application is running, multiple AUTOSTART applications signalled, broadband and broadcast, part 1 | While a service is selected and no application is signalled, the terminal shall detect a change in the AIT; which is updated to contain two AUTOSTART applications. App1 is carried via HTTP; App2 via DSMCC; App1 has a higher priority. The terminal has an operational broadband connection. The terminal shall start App1. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - Does terminal have broadband connection? Yes - Is an App signalled as AUTOSTART? Yes - Load App1 via HTTP - Did it load successfully? Yes - Done. | |||
| org.hbbtv_00000170 | 2 | AIT changes while no broadcast related application is running, multiple AUTOSTART applications signalled, broadband and broadcast, part 2 | While a service is selected and no application is signalled, the terminal shall detect a change in the AIT; which is updated to contain two AUTOSTART applications. App1 is carried via HTTP; App2 via DSMCC; App1 has a higher priority. The terminal has an operational broadband conntection. App1 is temporarily unavailable. The terminal shall finally start App2. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - Does terminal have broadband connection? Yes - Is an App signalled as AUTOSTART? Yes - Load App1 via HTTP - Did it load successfully? No - Find app with next highest priority - Load App2 via DSMCC - Did the application load successfully? Yes! - Done. | |||
| org.hbbtv_00000190 | 2 | AIT changes while no broadcast related application is running, multiple AUTOSTART applications signalled, broadband, part 1 | While a service is selected and no application is signalled, the terminal shall detect a change in the AIT; which is updated to contain two AUTOSTART applications carried via HTTP, App1 and App2; App1 has a higher priority. The terminal has an operational broadband connection. The terminal shall start App1. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - Does terminal have broadband connection? Yes - Is an App signalled as AUTOSTART? Yes - Load App1 via HTTP - Did it load successfully? Yes - Done. | |||
| org.hbbtv_00000200 | 2 | AIT changes while no broadcast related application is running, multiple AUTOSTART applications, broadband signalled, part 2 | While a service is selected and no application is signalled, the terminal shall detect a change in the AIT; which is updated to contain two AUTOSTART applications carried via HTTP, App1 and App2; App1 has a higher priority. The terminal has an operational broadband connection. App1 is temporarily unavailable. The terminal shall finally start App2. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - Does terminal have broadband connection? Yes - Is an App signalled as AUTOSTART? Yes - Load App1 via HTTP - Did it load successfully? No - Find app with next highest priority - Load App2 via HTTP - Did it load successfully? Yes - Done. | |||
| org.hbbtv_00000210 | 3 | AIT changes while no broadcast related application is running, AUTOSTART application signalled on broadband and broadcast, part 1 | While a service is selected and no application is signalled, the terminal shall detect a change in the AIT; which is updated to contain an AUTOSTART application carried on HTTP and DSMCC, with a higher priority for HTTP. The terminal has an operational broadband connection. The terminal shall finally start the application from broadband via HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - Does terminal have broadband connection? Yes - Is an App signalled as AUTOSTART? Yes - Load App via HTTP - Did it load successfully? Yes - Done. | |||
| org.hbbtv_00000220 | 3 | AIT changes while no broadcast related application is running, AUTOSTART application signalled on broadband and broadcast, part 2 | While a service is selected and no application is signalled, the terminal shall detect a change in the AIT; which is updated to contain an AUTOSTART application carried on HTTP and DSMCC, with a higher priority for HTTP. The terminal has an operational broadband connection. The app is temporarily not available via the broadband connection. The terminal shall finally start the application from broadcast. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - Does terminal have broadband connection? Yes - Find the next highest priority app signalled as AUTOSTART - Find the next highest priority transport: load app via HTTP - Did it load successfully? No - Find the next highest priority transport: load app via DSMCC - Did it load successfully? Yes - Done. | |||
| org.hbbtv_00000240 | 3 | AIT changes while no broadcast related application is running, AUTOSTART application signalled on broadcast (higher priority) and broadband, part 1 | While a service is selected and no application is signalled, the terminal shall detect a change in the AIT; which is updated to contain an AUTOSTART application carried on HTTP and DSMCC, with a higher priority for DSMCC. The terminal shall start the application from broadcast. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - Does terminal have broadband connection? Yes - Find the next highest priority app signalled as AUTOSTART - Find the next highest priority transport: load app via DSMCC - Did it load successfully? Yes - Done. | |||
| org.hbbtv_00000250 | 2 | AIT changes while no broadcast related application is running, AUTOSTART application signalled on broadcast (higher prio) and broadband, part 2 (failure) | While a service is selected and no application is signalled, the terminal shall detect a change in the AIT; which is updated to contain an AUTOSTART application carried on HTTP and DSMCC, with a higher priority for DSMCC. The DSMCC carousel is not present. The terminal shall start the application finally from broadband. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - no App running - Does terminal have broadband connection, yes - Is an App signalled as AUTOSTART, yes - Which is the highest priority transport, DSMCC - Load app from DSMCC - Did it load successfully, no - Find the next highest priority transport - Load the application from broadband protocol - Did the applicaiton load successfully, yes - Done. | |||
| org.hbbtv_00000260 | 2 | AIT update with no AUTOSTART applications, broadband and broadcast, part 3 | While a service is selected and no application is signalled the terminal detects an AIT which signals one application with control code PRESENT. The terminal shall not start the application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - no App running - one application in AIT but not signalled as AUTOSTART - Do nothing - Done. | |||
| org.hbbtv_00000270 | 2 | AIT changes while broadcast related application is running, application still signalled | While service selected, the terminal detects a change in the AIT, a broadcast related application is running and it is still signalled with a control other than KILL. The application SHALL continue to run. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - App running - Still signalled, yes - Signalled with control kill, no - Application continues to run - Done. | |||
| org.hbbtv_00000280 | 2 | AIT changes while broadcast related application is running, application signaled with KILL | While a service is selected, the terminal detects a change in the AIT, a broadcast related application is running and it is still signaled, but with the control code KILL and a new application is signaled as AUTOSTART. The running application SHALL be killed and the new application shall be started. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - App running - Still signaled, yes - Signalled with control code KILL, yes - Application is killed - operational broadband, yes - find next highest priority app signaled as AUTOSTART - find next highest transport - load app via HTTP - Done. | |||
| org.hbbtv_00000290 | 2 | AIT changes while broadcast related application is running, application not signalled | While a service is selected the terminal detects a change in the AIT, a broadcast related application is running and it is not signalled in the AIT anymore and a new application is signalled as AUTOSTART. The running application SHALL be killed and the new application shall be started. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - App running - Still signalled, no - Application is killed - operational broadband, yes - find next highest priority app signalled as AUTOSTART - find next highest transport - load app via HTTP - Done. | |||
| org.hbbtv_00000300 | 2 | AIT changes while no broadcast related application is running, AUTOSTART application from HTTP signalled. | While a service is selected and a broadcast related application is not running, the terminal detects a change in the AIT with an autostart application signalled carried over HTTP. The autostart application SHALL be started. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: AIT updated - App running, no - Is an application signalled as AUTOSTART, yes - Start this application via HTTP - Done. | |||
| org.hbbtv_00000310 | 2 | Application exits | While a service is selected and a broadcast related application is running, the application exits. The AIT signals an autostart application The terminal SHALL start the autostart application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.3: Transition in state diagram: Application exits - Is an application signalled as AUTOSTART, yes - Start this application - Done. | |||
| org.hbbtv_00000320 | 2 | Triggering ChannelChangeSucceededEvent when transitioning from Broadcast Related to Broadcast Independent state | When a broadcast-related application calls the setChannel() method on the video/broadcast object with a value of null for its channel argument, a ChannelChangeSucceededEvent shall be dispatched to the video/broadcast object that caused the transition with a value of null for the channel property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: A broadcast-related application can transition to a broadcast-independent application by calling the setChannel() method on the video/broadcast object with a value of null for its channel argument. [...] A ChannelChangeSucceededEvent shall be dispatched to the video/broadcast object that caused the transition with a value of null for the channel property. | |||
| org.hbbtv_00000330 | 4 | Broadcast Independent Applications created from an HTML page accessed over HTTP | Calling Application.createApplication() with a valid HTTP URL pointing to an HTML page shall create a broadcast-independent application without an organization_id or application_id. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: A broadcast-independent application can be created [...] By calling the Application.createApplication() method with either an HTTP or an HTTPS URL. The URL shall refer to either an HTML page or an XML AIT (see clause 7.2.3.2). [...] Where the URL refers to an HTML page directly, the broadcast-independent application shall be created without an organization_id or application_id. OIPF-DAE,section 7.2.2.2: | |||
| org.hbbtv_00000340 | 4 | A broadcast-independent application transitioning to a broadcast-related application shall not be killed if all specified conditions are met | A broadcast-independent application that wants to become a broadcast-related application, by successfully selecting a broadcast service, SHALL NOT be killed if all the following conditions are met: 1. The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). 2. An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. 3. The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. 4. The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. 5. The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: * The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). * An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. * The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. * The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. * The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. | |||
| org.hbbtv_00000350 | 4 | A broadcast-independent application transitioning to a broadcast-related application shall be killed if the first of the specified conditions are not met | A broadcast-independent application that wants to transition back to a broadcast-related application SHALL be killed if the following condition is not met: 1. The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: * The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). * An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. * The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. * The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. * The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. | |||
| org.hbbtv_00000360 | 4 | A broadcast-independent application transitioning to a broadcast-related application shall be killed if the second of the specified conditions are not met (app_id) | A broadcast-independent application that wants to transition back to a broadcast-related application SHALL be killed if the following condition is not met: 2. An application of the same application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: * The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). * An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. * The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. * The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. * The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. | |||
| org.hbbtv_00000365 | 1 | A broadcast-independent application transitioning to a broadcast-related application shall be killed if the second of the specified conditions are not met (org_id) | A broadcast-independent application that wants to transition back to a broadcast-related application SHALL be killed if the following condition is not met: 2. An application of the same organization_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: * The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). * An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. * The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. * The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. * The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. | |||
| org.hbbtv_00000370 | 5 | A broadcast-independent application transitioning to a broadcast-related application shall be killed if the third of the specified conditions are not met | A broadcast-independent application that wants to transition back to a broadcast-related application SHALL be killed if the following condition is not met: 3. The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: * The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). * An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. * The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. * The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. * The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. | |||
| org.hbbtv_00000380 | 5 | A broadcast-independent application transitioning to a broadcast-related application shall be killed if the fourth of the specified conditions are not met | A broadcast-independent application that wants to transition back to a broadcast-related application SHALL be killed if the following condition is not met: 4. The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: * The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). * An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. * The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. * The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. * The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. | |||
| org.hbbtv_00000400 | 4 | Broadcast Independent Applications created from an XML AIT over HTTP and with no boundary defined | Calling Application.createApplication() with a valid HTTP URL pointing to an XML AIT shall create a broadcast-independent application with the org_id and app_id specified in the XML AIT and an application domain that is the "fully qualified domain name" (FQDN) of the first page of the application in the absence of an application_boundary_descriptor. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: A broadcast-independent application can be created [...] calling the Application.createApplication() method with either an HTTP or an HTTPS URL. The URL shall refer to either an HTML page or an XML AIT (see clause 7.2.3.2). [...] Where the URL refers to an XML AIT, the broadcast-independent application shall be created with the organization_id and application_id specified in the XML AIT. In both cases, the application shall be associated with an application boundary as defined in clause 6.3. HBBTV,section 6.3: For applications loaded via HTTP or HTTPS, the application boundary shall include the origin of the URL used to launch the application e.g. as signalled in the AIT or XML AIT or passed as argument of createApplication(). OIPF-DAE,section 7.2.2.2: | |||
| org.hbbtv_00000440 | 4 | Broadcast Independent Applications started from a Broadcast Related application | When a broadcast-related application starts a broadcast-independent application, the application is started but the broadcast service shall cease to be selected and access to broadcast resources shall be lost | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: When a broadcast-related application starts a broadcast-independent application, the application is started but the broadcast service shall cease to be selected - logically equivalent to selecting a "null service" as described above. Access to broadcast resources shall be lost and the object shall transition to the unrealized state. HBBTV,section 6.2.2.7: [Suspension of access to broadcast resources] | |||
| org.hbbtv_00000450 | 3 | Transition of an Application from Broadcast Related to Broadcast Independent state using Set Channel | When a broadcast-related application calls the setChannel(null) method on the video/broadcast object with a value of null for its channel argument it shall become a broadcast independent application. Access to broadcast resources shall be lost | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: A broadcast-related application can transition to a broadcast-independent application by calling the setChannel() method on the video/broadcast object with a value of null for its channel argument. Access to broadcast resources shall be lost, as described in clause 6.2.2.7. HBBTV,section 6.2.2.7: [Suspension of access to broadcast resources] | |||
| org.hbbtv_00000460 | 4 | A broadcast-independent application transitioning to a broadcast-related application shall be killed if the fifth of the specified conditions are not met | A broadcast-independent application that wants to transition back to a broadcast-related application SHALL be killed if the following condition is not met: 5. The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: * The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). * An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. * The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. * The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. * The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. | |||
| org.hbbtv_00000570 | 2 | User input - VK_BACK | When user press the BACK button, there should be a key event of VK_BACK dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input BACK button VK_BACK "BrowserBack" Mandatory Always available to applications OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000580 | 2 | User input - VK_0 | When user press the 0 button, there should be a key event of VK_0 dispatched | 2024-2 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000590 | 2 | User input - VK_1 | When user press the 1 button, there should be a key event of VK_1 dispatched | 2024-2 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000600 | 2 | User input - VK_2 | When user press the 2 button, there should be a key event of VK_2 dispatched | 2024-2 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000610 | 2 | User input - VK_3 | When user press the 3 button, there should be a key event of VK_3 dispatched | 2024-2 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000620 | 2 | User input - VK_4 | When user press the 4 button, there should be a key event of VK_4 dispatched | 2024-2 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000630 | 2 | User input - VK_REWIND | When user press the rewind button, there should be a key event of VK_REWIND dispatched | 2024-2 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Fast forward and fast rewind| VK_FAST_FWD VK_REWIND | "MediaFastForward" "MediaRewind" | |||
| org.hbbtv_00000640 | 2 | User input - VK_RED | When user press the red button, there should be a key event of VK_RED dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000650 | 2 | User input - VK_GREEN | When user press the GREEN button, there should be a key event of VK_GREEN dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000660 | 2 | User input - VK_YELLOW | When user press the YELLOW button, there should be a key event of VK_YELLOW dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000670 | 2 | User input - VK_BLUE | When user press the BLUE button, there should be a key event of VK_BLUE dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000680 | 2 | User input - VK_UP | When user press the UP button, there should be a key event of VK_UP dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000690 | 2 | User input - VK_DOWN | When user press the DOWN button, there should be a key event of VK_DOWN dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000700 | 2 | User input - VK_LEFT | When user press the LEFT button, there should be a key event of VK_LEFT dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000710 | 2 | User input - VK_RIGHT | When user press the RIGHT button, there should be a key event of VK_RIGHT dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000720 | 2 | User input - VK_ENTER | When user press the ENTER or OK button, there should be a key event of VK_ENTER dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000730 | 2 | User input - VK_5 | When user press the 5 button, there should be a key event of VK_5 dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000740 | 2 | User input - VK_6 | When user press the 6 button, there should be a key event of VK_6 dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000750 | 2 | User input - VK_7 | When user press the 7 button, there should be a key event of VK_7 dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000760 | 2 | User input - VK_8 | When user press the 8 button, there should be a key event of VK_8 dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000770 | 2 | User input - VK_9 | When user press the 9 button, there should be a key event of VK_9 dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" OIPF-DAE,section 9.1: Minimum DAE capability requirements | |||
| org.hbbtv_00000780 | 2 | User input - VK_STOP | When user press the STOP button, there should be a key event of VK_STOP dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" | |||
| org.hbbtv_00000790 | 2 | User input - VK_PLAY | When user press the PLAY button, there should be a key event of VK_PLAY dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" | +VK_PLAY | ||
| org.hbbtv_00000800 | 2 | User input - VK_PAUSE | When user press the PAUSE button, there should be a key event of VK_PAUSE dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" | +VK_PAUSE | ||
| org.hbbtv_00000810 | 2 | User input - VK_PLAY_PAUSE | When user press the PLAY_PAUSE button, there should be a key event of VK_PLAY_PAUSE dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Number keys | VK_0 to VK_9 inclusive | "Digit0" to "Digit9" inclusive Play, stop, pause | VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE | "MediaStop" and either "MediaPlay" and "MediaPause" or "MediaPlayPause" | +VK_PLAY_PAUSE | ||
| org.hbbtv_00000820 | 2 | User input - VK_FAST_FWD | When user press the FAST_FWD button, there should be a key event of VK_FAST_FWD dispatched | 2024-2 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input Fast forward and fast rewind| VK_FAST_FWD VK_REWIND | "MediaFastForward" "MediaRewind" | |||
| org.hbbtv_00000830 | 2 | User input - CSS3 directional focus navigation - VK_UP | On UP keydown events, the terminal shall handle CSS3 directional focus navigation when the nav-up CSS property is used by the application and UP key events are not captured by the application (no JavaScript Navigation). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as “Javascript navigation”). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. OIPF-DAE,section B: The client SHOULD use the same physical keys for generating the VK_UP, VK_DOWN, VK_LEFT and VK_RIGHT key events that are used for a spatial navigation mechanism provided by the client. The same keys SHOULD also be used for spatial navigation specified through the CSS properties ‘nav-up’, ‘nav-down’, ‘nav-left’ and ‘nav-right’. | |||
| org.hbbtv_00000840 | 2 | User input - CSS3 directional focus navigation - VK_DOWN | On DOWN keydown events, the terminal shall handle CSS3 directional focus navigation when the nav-down CSS property is used by the application and DOWN key events are not captured by the application (no JavaScript Navigation). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as “Javascript navigation”). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. OIPF-DAE,section B: The client SHOULD use the same physical keys for generating the VK_UP, VK_DOWN, VK_LEFT and VK_RIGHT key events that are used for a spatial navigation mechanism provided by the client. The same keys SHOULD also be used for spatial navigation specified through the CSS properties ‘nav-up’, ‘nav-down’, ‘nav-left’ and ‘nav-right’. | |||
| org.hbbtv_00000850 | 2 | User input - CSS3 directional focus navigation - VK_LEFT | On LEFT keydown events, the terminal shall handle CSS3 directional focus navigation when the nav-left CSS property is used by the application and LEFT key events are not captured by the application (no JavaScript Navigation). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as “Javascript navigation”). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. OIPF-DAE,section B: The client SHOULD use the same physical keys for generating the VK_UP, VK_DOWN, VK_LEFT and VK_RIGHT key events that are used for a spatial navigation mechanism provided by the client. The same keys SHOULD also be used for spatial navigation specified through the CSS properties ‘nav-up’, ‘nav-down’, ‘nav-left’ and ‘nav-right’. | |||
| org.hbbtv_00000860 | 2 | User input - CSS3 directional focus navigation - VK_RIGHT | On RIGHT keydown events, the terminal shall handle CSS3 directional focus navigation when the nav-right CSS property is used by the application and RIGHT key events are not captured by the application (no JavaScript Navigation). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as “Javascript navigation”). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. OIPF-DAE,section B: The client SHOULD use the same physical keys for generating the VK_UP, VK_DOWN, VK_LEFT and VK_RIGHT key events that are used for a spatial navigation mechanism provided by the client. The same keys SHOULD also be used for spatial navigation specified through the CSS properties ‘nav-up’, ‘nav-down’, ‘nav-left’ and ‘nav-right’. | |||
| org.hbbtv_00000910 | 2 | User input - Javascript navigation - VK_UP | On UP keydown events, terminals shall allow applications to capture the events and prevent the default action (known as "Javascript navigation"). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as "Javascript navigation"). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. OIPF-DAE,section B: For all elements which can receive focus events, a focus event SHALL be generated and the CSS “:focus” selector must be activated, irrespective if the focus is received through keyboard interaction, pointer interaction, calling an DOM focus() method through JavaScript, or any other mechanism by which the focus can be changed. | |||
| org.hbbtv_00000920 | 2 | User input - Javascript navigation - VK_DOWN | On DOWN keydown events, terminals shall allow applications to capture the events and prevent the default action (known as "Javascript navigation"). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as "Javascript navigation"). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. OIPF-DAE,section B: For all elements which can receive focus events, a focus event SHALL be generated and the CSS “:focus” selector must be activated, irrespective if the focus is received through keyboard interaction, pointer interaction, calling an DOM focus() method through JavaScript, or any other mechanism by which the focus can be changed. | |||
| org.hbbtv_00000930 | 2 | User input - Javascript navigation - VK_LEFT | On LEFT keydown events, terminals shall allow applications to capture the events and prevent the default action (known as "Javascript navigation"). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as "Javascript navigation"). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. OIPF-DAE,section B: For all elements which can receive focus events, a focus event SHALL be generated and the CSS “:focus” selector must be activated, irrespective if the focus is received through keyboard interaction, pointer interaction, calling an DOM focus() method through JavaScript, or any other mechanism by which the focus can be changed. | |||
| org.hbbtv_00000940 | 2 | User input - Javascript navigation - VK_RIGHT | On RIGHT keydown events, terminals shall allow applications to capture the events and prevent the default action (known as "Javascript navigation"). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as "Javascript navigation"). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. OIPF-DAE,section B: For all elements which can receive focus events, a focus event SHALL be generated and the CSS “:focus” selector must be activated, irrespective if the focus is received through keyboard interaction, pointer interaction, calling an DOM focus() method through JavaScript, or any other mechanism by which the focus can be changed. | |||
| org.hbbtv_00000950 | 2 | User input - Navigation priority - VK_RIGHT | On RIGHT keydown events, the terminal shall prioritize javascript navigation over CSS3 directional focus navigation if both are used by an application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as “Javascript navigation”). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. | |||
| org.hbbtv_00000960 | 2 | User input - Navigation priority - VK_UP | On UP keydown events, the terminal shall prioritize javascript navigation over CSS3 directional focus navigation if both are used by an application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as “Javascript navigation”). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. | |||
| org.hbbtv_00000970 | 2 | User input - Navigation priority - VK_DOWN | On DOWN keydown events, the terminal shall prioritize javascript navigation over CSS3 directional focus navigation if both are used by an application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as “Javascript navigation”). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. | |||
| org.hbbtv_00000980 | 2 | User input - Navigation priority - VK_LEFT | On LEFT keydown events, the terminal shall prioritize javascript navigation over CSS3 directional focus navigation if both are used by an application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2: User input [...] On up, down, left, right keydown events, terminals shall choose one of the following navigation mechanisms in the priority order listed [...]: * Allow applications to capture the events and prevent the default action (known as “Javascript navigation”). * Handle CSS3 directional focus navigation when the nav-up, nav-right, nav-down and nav-left CSS properties are used by the application. * A default navigation mechanism provided by the terminal based which shall allow focus to be moved between navigable elements and allow all navigable elements to gain focus. | |||
| org.hbbtv_00000990 | 2 | Access to resources inside the boundary of an application loaded from carousel | Adding application boundaries to a "trusted" application loaded via a carousel grants elements within the extended application domain access to API functions marked with security "trusted". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application domain HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | +DL | ||
| org.hbbtv_00001000 | 4 | Loading a document outside the boundary of an application loaded via HTTP | Loading a document from outside the application boundary of a "trusted" application loaded via HTTP, suspends access to API functions marked with security "trusted". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application boundary HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | +DL | ||
| org.hbbtv_00001010 | 4 | Loading a document from outside the application boundary including a document from within the application boundary | When presenting a document from outside the application boundary of a trusted application loaded via HTTP, loading a document from within the application boundary of the trusted application restores access to API functions marked with security "trusted". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application boundary HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | +DL | ||
| org.hbbtv_00001020 | 3 | Access to resources within the Application domain via XMLHttpRequest | Adding application boundaries to an application loaded via HTTP grants XMLHttpRequests within the extended application domain access to those resources. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application domain HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | |||
| org.hbbtv_00001030 | 2 | Access to resources outside the application domain via XmlHttpRequest | XMLHttpRequests to resources outside the application domain of an application loaded via HTTP is not allowed. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application domain HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 10.1.5: As described in section 5.1.3, for files requested with XMLHttpRequest, the Same-Origin Policy SHALL be extended using the application domain as defined in section 5.1.3. | |||
| org.hbbtv_00001040 | 2 | Access to "trusted" API from within an iframe loaded from inside the application domain | Adding application boundaries to an application loaded via HTTP grants documents loaded in an <iframe> within the extended application domain access to API functions marked with security "trusted". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application domain HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | +DL | ||
| org.hbbtv_00001050 | 4 | Block access to trusted API from document outside the application boundary | Documents that are outside the application boundary of an application, where the application is loaded via HTTP and has no application boundaries set, do not have access to API functions marked with security "trusted". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Documents loaded from outside the application boundary shall be untrusted (in the sense of the word "trusted" as defined in clause 11), for example documents loaded in an <iframe> element or documents loaded as a result of following a link or an HTTP redirect. HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | +DL | ||
| org.hbbtv_00001060 | 2 | Access to trusted APIs from a document inside the application boundary of a trusted application loaded via HTTP | Adding application boundaries to a trusted application loaded via HTTP grants elements within the extended application domain access to API functions marked with security "trusted". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application domain HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | +DL | ||
| org.hbbtv_00001150 | 4 | Access to trusted API from a document outside the application boundary (app loaded via HTTP) | Documents loaded in an <iframe> outside the application boundary of an application loaded via HTTP have no access to API functions marked with security "trusted". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application boundary HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | +DL | ||
| org.hbbtv_00001160 | 4 | Access to trusted API from a document outside the application boundary (app loaded via carousel) | Loading a document from outside the application boundary of a trusted application loaded via a carousel, suspends access to API functions marked with security "trusted". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application boundary HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | +DL | ||
| org.hbbtv_00001170 | 4 | Access to trusted API from a document inside the application boundary (app loaded via carousel) | When presenting a document from outside the application boundary of a trusted application loaded via a carousel, loading a document from within the application boundary of the trusted application restores access to API functions marked with security "trusted". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application boundary HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | +DL | ||
| org.hbbtv_00001190 | 2 | Access to resources outside the application domain via XMLHttpRequest | XMLHttpRequests to resources outside the application domain of an application loaded via a carousel is not allowed. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application domain HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | |||
| org.hbbtv_00001200 | 2 | Access to trusted API from a document inside the application domain (app loaded via carousel) | Adding application boundaries to a trusted application loaded via a carousel grants documents loaded in an <iframe> within the extended application domain access to API functions marked with security "trusted". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application domain HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | +DL | ||
| org.hbbtv_00001210 | 4 | Blocking access to trusted API from a document outside the application boundary (app loaded via carousel) | Documents loaded in an <iframe> outside the application boundary of a trusted application loaded via a carousel have no access to API functions marked with security "trusted". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.3: Application boundary HBBTV,section 11.1: Application and service security HBBTV,section A.1: Detailed section by section definition | +DL | ||
| org.hbbtv_00001220 | 1 | Stopping applications: Application.destroyApplication | A DVB service with an AUTOSTART Application is tuned. The AUTOSTART Application can be requested to kill itself using the Application.destroyApplication() method | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-DAE,section 7.2.2: The Application class HBBTV,section 6.2.2.4: Any application shall be stopped under the following circumstances: * The application itself exits using the Application.destroyApplication() method (as defined in clause 7.2.2 of the OIPF DAE specification [2]). | |||
| org.hbbtv_00001230 | 2 | Stopping applications: out of resources | A DVB service with an AUTOSTART Application is tuned. The AUTOSTART Application continuously allocates resources without freeing them. Once the terminal runs out of resources, the terminal stops the Application | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-DAE,section 7.2.2: The Application class HBBTV,section 6.2.2.4: Any application shall be stopped under the following circumstances: * The terminal has run out of resources for executing the application and therefore has to terminate it in order to keep operating correctly. | |||
| org.hbbtv_00001240 | 1 | Starting broadcast related applications invisible | The terminal starts a broadcast related application. Application.show() is not called. The Application is not visible. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.4: By default, newly started broadcast-related applications shall not be visible to the end user. | |||
| org.hbbtv_00001260 | 1 | Starting broadcast independent applications | The terminal starts a broadcast-independent Application, by calling createApplication(). The Application is visible. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.4: Newly started broadcast-independent applications shall be visible and active without needing to call the method Application.show(). HBBTV,section 6.2.2.6: A broadcast-independent application can be created in one of the following ways: By calling the Application.createApplication() method with either an HTTP or an HTTPS URL. The URL shall refer to either an HTML page or an XML AIT (see clause 7.2.3.2). | |||
| org.hbbtv_00001403 | 1 | HTTP User Agent header grammar | The User-Agent header shall match the HbbTvUserAgent production in the following ABNF grammar that operates on ASCII characters: HbbTvUserAgent = HbbTvUserAgent_1 HbbTvUserAgent_2 HbbTvUserAgent_1 = TEXT "HbbTV/1.4.1" [LWS] "(" [HbbTvOptions] ";" [LWS] vendorName ";" [LWS] modelName ";" HbbTvUserAgent_2 = [LWS] softwareVersion ";" [LWS] [hardwareVersion] ";" [LWS] familyName ";" [LWS] reserved ")" TEXT vendorName = TEXT modelName = TEXT softwareVersion = TEXT hardwareVersion = TEXT familyName = TEXT reserved = TEXT HbbTvOptions = 1*HbbTvOption HbbTvOption = DLOption | PVROption | DRMOption | SyncOption | IPHOption | AFSOption DLOption = "+DL" PVROption = "+PVR" DRMOption = "+DRM" SyncOption = "+SYNC_SLAVE" IPHOption = "+IPH" AFSOption = "+AFS" TEXT, LWS non-terminals are specified in RFC2616, except that LWS is restricted to 1*( SP | HT ) | 2024-2 2024-1 2023-3 2023-2 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 | HBBTV,section 7.3.2.4: All outgoing HTTP requests made on behalf of an HbbTV application, and during the process of launching an HbbTV application, shall include a User-Agent header using the syntax described in this clause. [...] The User-Agent header shall include: HbbTV/1.4.1 (<capabilities>; <vendorName>; <modelName>; <softwareVersion>; [<hardwareVersion>]; <familyName>; <reserved>) [...] IETF RFC 2616 [6] permits a User-Agent header to be split over multiple lines by including the sequence CRLF 1*( SP | HT ). The User-Agent shall not include this sequence and shall only include linear whitespace matching the sequence 1*( SP | HT ) | |||
| org.hbbtv_00001404 | 1 | HTTP User Agent header grammar - vendor, model and family | The vendorName, modelName and familyName elements of the User-Agent header shall respectively reflect the consumer-facing make/brand of the terminal, the consumer-facing model name of the terminal, and the device family of terminal, either prefixed with a reverse domain name of the organisation or encoded as a version 4 UUID. | 2024-2 2024-1 2023-3 2023-2 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 | HBBTV,section 7.3.2.4: All outgoing HTTP requests made on behalf of an HbbTV application, and during the process of launching an HbbTV application, shall include a User-Agent header using the syntax described in this clause. [...] The User-Agent header shall include: HbbTV/1.4.1 (<capabilities>; <vendorName>; <modelName>; <softwareVersion>; [<hardwareVersion>]; <familyName>; <reserved>) [...] The <vendorName> field shall reflect the consumer-facing make / brand of the terminal. [...] The <modelName> field should be representative of the consumer-facing model name to allow log messages to be matched up with user reported problems. The <familyName> field shall have the semantics defined in clause 7.3.3.2 of the OIPF DAE specification [1] but shall additionally be chosen so as to be globally unique. This shall be achieved either by prefixing with a reverse domain name of the organisation allocating the remaining portion of the familyName, or by using a version 4 UUID as the familyName, formatted as a simple string (i.e. without any urn:uuid prefix) [64]. OIPF-DAE,section 7.3.3.2: readonly String familyName String identifying the name of the family that the device belongs to. Devices in a family differ only by details that do not impact the behaviour of the OITF aspect of the device, e.g. screen size, remote control, number of HDMI ports, size of hard disc. Family names are allocated by the vendor and the combination of vendorName and familyName should uniquely identify a family of devices. Different vendors may use the same familyName, although they are recommended to use conventions that avoid this. | |||
| org.hbbtv_00001405 | 1 | HTTP User Agent header grammar | The User-Agent header shall match the HbbTvUserAgent production in the following ABNF grammar that operates on ASCII characters: HbbTvUserAgent = HbbTvUserAgent_1 HbbTvUserAgent_2 HbbTvUserAgent_1 = TEXT "HbbTV/1.5.1" [LWS] "(" [HbbTvOptions] ";" [LWS] vendorName ";" [LWS] modelName ";" HbbTvUserAgent_2 = [LWS] softwareVersion ";" [LWS] [hardwareVersion] ";" [LWS] familyName ";" [LWS] reserved ")" TEXT vendorName = TEXT modelName = TEXT softwareVersion = TEXT hardwareVersion = TEXT familyName = TEXT reserved = TEXT HbbTvOptions = 1*HbbTvOption HbbTvOption = DLOption | PVROption | DRMOption | SyncOption | IPHOption | AFSOption DLOption = "+DL" PVROption = "+PVR" DRMOption = "+DRM" SyncOption = "+SYNC_SLAVE" IPHOption = "+IPH" AFSOption = "+AFS" TEXT, LWS non-terminals are specified in RFC2616, except that LWS is restricted to 1*( SP | HT ) | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 | HBBTV 1.5.1 | HBBTV,section 7.3.2.4: All outgoing HTTP requests made on behalf of an HbbTV application, and during the process of launching an HbbTV application, shall include a User-Agent header using the syntax described in this clause. [...] The User-Agent header shall include: HbbTV/1.5.1 (<capabilities>; <vendorName>; <modelName>; <softwareVersion>; [<hardwareVersion>]; <familyName>; <reserved>) [...] IETF RFC 2616 [6] permits a User-Agent header to be split over multiple lines by including the sequence CRLF 1*( SP | HT ). The User-Agent header shall not include this sequence and shall only include linear whitespace matching the sequence 1*( SP | HT ) | |||
| org.hbbtv_00001406 | 1 | HTTP User Agent header grammar - vendor, model and family | The vendorName, modelName and familyName elements of the User-Agent header shall respectively reflect the consumer-facing make/brand of the terminal, the consumer-facing model name of the terminal, and the device family of terminal, either prefixed with a reverse domain name of the organisation or encoded as a version 4 UUID. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 | HBBTV 1.5.1 | HBBTV,section 7.3.2.4: All outgoing HTTP requests made on behalf of an HbbTV application, and during the process of launching an HbbTV application, shall include a User-Agent header using the syntax described in this clause. [...] The User-Agent header shall include: HbbTV/1.5.1 (<capabilities>; <vendorName>; <modelName>; <softwareVersion>; [<hardwareVersion>]; <familyName>; <reserved>) [...] The <vendorName> field shall reflect the consumer-facing make / brand of the terminal. [...] The <modelName> field should be representative of the consumer-facing model name to allow log messages to be matched up with user reported problems. The <familyName> field shall have the semantics defined in clause 7.3.3.2 of the OIPF DAE specification [1] but shall additionally be chosen so as to be globally unique. This shall be achieved either by prefixing with a reverse domain name of the organization allocating the remaining portion of the familyName, or by using a version 4 UUID as the familyName, formatted as a simple string (i.e. without any urn:uuid prefix) [64]. OIPF-DAE,section 7.3.3.2: readonly String familyName String identifying the name of the family that the device belongs to. Devices in a family differ only by details that do not impact the behaviour of the OITF aspect of the device, e.g. screen size, remote control, number of HDMI ports, size of hard disc. Family names are allocated by the vendor and the combination of vendorName and familyName should uniquely identify a family of devices. Different vendors may use the same familyName, although they are recommended to use conventions that avoid this. | |||
| org.hbbtv_00001407 | 1 | HTTP User Agent header grammar | The User-Agent header shall match the HbbTvUserAgent production in the following ABNF grammar that operates on ASCII characters: HbbTvUserAgent = HbbTvUserAgent_1 HbbTvUserAgent_2 HbbTvUserAgent_1 = TEXT "HbbTV/1.6.1" [LWS] "(" [HbbTvOptions] ";" [LWS] vendorName ";" [LWS] modelName ";" HbbTvUserAgent_2 = [LWS] softwareVersion ";" [LWS] [hardwareVersion] ";" [LWS] familyName ";" [LWS] reserved ")" TEXT vendorName = TEXT modelName = TEXT softwareVersion = TEXT hardwareVersion = TEXT familyName = TEXT reserved = TEXT HbbTvOptions = 1*HbbTvOption HbbTvOption = DLOption | PVROption | DRMOption | SyncOption | IPHOption | AFSOption DLOption = "+DL" PVROption = "+PVR" DRMOption = "+DRM" SyncOption = "+SYNC_SLAVE" IPHOption = "+IPH" AFSOption = "+AFS" TEXT, LWS non-terminals are specified in RFC2616, except that LWS is restricted to 1*( SP | HT ) | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.6.1 | HBBTV,section 7.3.2.4: All outgoing HTTP requests made on behalf of an HbbTV application, and during the process of launching an HbbTV application, shall include a User-Agent header using the syntax described in this clause. [...] The User-Agent header shall include: HbbTV/1.6.1 (<capabilities>; <vendorName>; <modelName>; <softwareVersion>; [<hardwareVersion>]; <familyName>; <reserved>) [...] IETF RFC 2616 [6] permits a User-Agent header to be split over multiple lines by including the sequence CRLF 1*( SP | HT ). The User-Agent header shall not include this sequence and shall only include linear whitespace matching the sequence 1*( SP | HT ) | |||
| org.hbbtv_00001408 | 1 | HTTP User Agent header grammar - vendor, model and family | The vendorName, modelName and familyName elements of the User-Agent header shall respectively reflect the consumer-facing make/brand of the terminal, the consumer-facing model name of the terminal, and the device family of terminal, either prefixed with a reverse domain name of the organisation or encoded as a version 4 UUID. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.6.1 | HBBTV,section 7.3.2.4: All outgoing HTTP requests made on behalf of an HbbTV application, and during the process of launching an HbbTV application, shall include a User-Agent header using the syntax described in this clause. [...] The User-Agent header shall include: HbbTV/1.6.1 (<capabilities>; <vendorName>; <modelName>; <softwareVersion>; [<hardwareVersion>]; <familyName>; <reserved>) [...] The <vendorName> field shall reflect the consumer-facing make / brand of the terminal. [...] The <modelName> field should be representative of the consumer-facing model name to allow log messages to be matched up with user reported problems. The <familyName> field shall have the semantics defined in clause 7.3.3.2 of the OIPF DAE specification [1] but shall additionally be chosen so as to be globally unique. This shall be achieved either by prefixing with a reverse domain name of the organization allocating the remaining portion of the familyName, or by using a version 4 UUID as the familyName, formatted as a simple string (i.e. without any urn:uuid prefix) [64]. OIPF-DAE,section 7.3.3.2: readonly String familyName String identifying the name of the family that the device belongs to. Devices in a family differ only by details that do not impact the behaviour of the OITF aspect of the device, e.g. screen size, remote control, number of HDMI ports, size of hard disc. Family names are allocated by the vendor and the combination of vendorName and familyName should uniquely identify a family of devices. Different vendors may use the same familyName, although they are recommended to use conventions that avoid this. | |||
| org.hbbtv_00001410 | 2 | Status value is 404 when trying to access non-existing DSM-CC objects with XMLHttpRequest | The status property will return value 404 when trying to access non-existing DSM-CC objects in a mounted carousel with XMLHttpRequest. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.2: Carousel objects access with XMLHttpRequest | |||
| org.hbbtv_00001450 | 2 | Calls to getAllResponseHeaders() return an empty string when accessing DSM-CC objects with XMLHttpRequest | Calls to getAllResponseHeaders() return an empty string when accessing DSM-CC objects with XMLHttpRequest. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.2: Carousel objects access with XMLHttpRequest | |||
| org.hbbtv_00001460 | 2 | When accessing a DSM-CC File object with XMLHttpRequest, responseText returns the content of the requested file | When accessing a DSM-CC File object with XMLHttpRequest, responseText returns the content of the requested file. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.2: Carousel objects access with XMLHttpRequest | |||
| org.hbbtv_00001470 | 2 | When accessing a DSM-CC Directory object with XMLHttpRequest, responseText returns a comma-separated list of objects in the directory | When accessing a DSM-CC Directory object with XMLHttpRequest, responseText returns a comma-separated list of objects in the directory. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.2: Carousel objects access with XMLHttpRequest | |||
| org.hbbtv_00001480 | 2 | When accessing a DSM-CC File object with ".xml" extension with XMLHttpRequest, responseXML returns an XML document object | When accessing a DSM-CC File object with ".xml" extension with XMLHttpRequest, responseXML returns an XML document object representation of the requested XML document. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.2: Carousel objects access with XMLHttpRequest | |||
| org.hbbtv_00001490 | 2 | When accessing a DSM-CC Directory object with XMLHttpRequest, responseXML returns null | When accessing a DSM-CC Directory object with XMLHttpRequest, responseXML returns null. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.2: Carousel objects access with XMLHttpRequest | |||
| org.hbbtv_00001550 | 2 | Test of minimum terminal capabilities. Supported proportional font | When "sans serif" generic family is used for a "font family" CSS rule (i.e. font-family: sans-serif), the terminal shall use the "Tirerias Screenfont" font (or equivalent). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum terminal capabilities which shall be available to applications are listed in the table below for general capabilities. Supported proportional font OIPF-DAE,section 9.1: OITFs SHALL support the "Tiresias Screenfont" font or equivalent with the "Generic Application Western European Character Set" as defined in Annex C of [TS 102 809]. They MAY support other fonts in addition. OIPF-DAE,section 9.2: <font type="sans-serif" defaultsize="16">Tiresias</font> with support for the Unicode character range "Generic Application Western European Character set" as defined in Annex C of [TS 102 809] | |||
| org.hbbtv_00001560 | 2 | Test of minimum terminal capabilities. Supported non-proportional font | The terminal shall support the "Letter Gothic 12 Pitch" (or equivalent) font with the support for the Unicode character range "Basic Euro Latin Character set" as defined in Annex C of TS 102 809 | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum terminal capabilities which shall be available to applications are listed in the table below for general capabilities. Supported non-proportional font TS-102-809,section C: | |||
| org.hbbtv_00001590 | 2 | Test of minimum terminal capabilities. Text entry method | The terminal shall support either multi-tap (e.g. as defined in ES 201 130 [i. 2]) or an equivalent (e.g. software keyboard) where characters are input character by character in the text field. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 10.2.1: Minimum terminal capabilities which shall be available to applications are listed in the table below for general capabilities. Text Entry Method Either multi-tap (e.g. as defined in ES 202 130 [i.2]) or an equivalent (e.g. software keyboard) where characters are input character by character in the text field. For multi-tap or other methods which use multiple supported key events to generate a single characters, these intermediate key events shall not be reported to applications. Only the final character result shall be reported to applications. | |||
| org.hbbtv_00001600 | 2 | Test of minimum terminal capabilities, text entry method | For multi-tap or other methods which use supported key events to generate characters, these intermediate key events shall not be reported to applications. Only the final result shall be reported to applications. For speech-to-text or autocomplete / predictive text in virtual keyboards, terminals are not required to generate any key events. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 10.2.1: Minimum terminal capabilities which shall be available to applications are listed in the table below for general capabilities. Text Entry Method Either multi-tap (e.g. as defined in ES 202 130 [i.2]) or an equivalent (e.g. software keyboard) where characters are input character by character in the text field. For multi-tap or other methods which use multiple supported key events to generate a single characters, these intermediate key events shall not be reported to applications. Only the final character result shall be reported to applications. OIPF-DAE,section B: Every Remote UI Client SHALL support the DOM event [type ...] "keypress" [...] For "keypress" events, if pressing a key (or sequence of keys) has resulted in generating a Unicode character, the resulting Unicode character code SHALL be included in property charCode. | |||
| org.hbbtv_00001620 | 1 | Test of minimum terminal capabilities, PVR management | The manageRecordings attribute of the recording capability shall have the value 'samedomain'. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum terminal capabilities which shall be available to applications are listed in the table below for general capabilities. PVR management. OIPF-DAE,section 9.3.3: PVR capability indication | +PVR | ||
| org.hbbtv_00001630 | 1 | Test of minimum terminal capabilities, download management | The manageDownload attribute of the download capability shall have the value "samedomain". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum terminal capabilities which shall be available to applications are listed in the table below for general capabilities. Download management. OIPF-DAE,section 9.3.4: Download CoD capability indication | +DL | ||
| org.hbbtv_00001680 | 2 | State of a video/broadcast object when it is instantiated | When a video/broadcast object is instantiated, it shall be in the unrealized state. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | |||
| org.hbbtv_00001720 | 2 | Change of state of a video/broadcast object when the release() method is called while it is in the unrealized state | When a video/broadcast object is in the unrealized state and the release() method is called, this shall have no effect. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | |||
| org.hbbtv_00001730 | 2 | Change of state of a video/broadcast object when the stop() method is called while it is in the unrealized state | When a video/broadcast object is in the unrealized state and the stop() method is called, this shall have no effect. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | |||
| org.hbbtv_00001810 | 2 | Change of state of a video/broadcast object when the nextChannel() method is called while it is in the presenting state | When a video/broadcast object is in the presenting state and the nextChannel() method is called, the video/broadcast object shall transition to the connecting state. A PlayStateChange DOM event shall be triggered with the state property set to 1 (connecting) and the error property set to undefined (i.e. unallocated error value) and the target property set to the video/broadcast object. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | |||
| org.hbbtv_00001820 | 2 | Change of state of a video/broadcast object when the prevChannel() method is called while it is in the presenting state | When a video/broadcast object is in the presenting state and the prevChannel() method is called, the video/broadcast object shall transition to the connecting state. A PlayStateChange DOM event shall be triggered with the state property set to 1 (connecting) and the error property set to undefined (i.e. unallocated error value) and the target property set to the video/broadcast object. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | |||
| org.hbbtv_00001830 | 2 | Change of state of a video/broadcast object when the bindToCurrentChannel() method is called while it is in the presenting state | When a video/broadcast object is in the presenting state and the bindToCurrentChannel() method is called, this shall have no effect. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | |||
| org.hbbtv_00001840 | 2 | Change of state of a video/broadcast object when the release() method is called while it is in the presenting state | When a video/broadcast object is in the presenting state and the release() method is called, the video/broadcast object shall transition to the unrealized state. A PlayStateChange DOM event shall be triggered with the state property set to 0 (unrealized) and the error property set to undefined (i.e. unallocated error value) and the target property set to the video/broadcast object. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | |||
| org.hbbtv_00001850 | 2 | Change of state of a video/broadcast object when the stop() method is called while it is in the presenting state | When a video/broadcast object is in the presenting state and the stop() method is called, the video/broadcast object shall transition to the stopped state. A PlayStateChange DOM event shall be triggered with the state property set to 3 (stopped) and the error property set to undefined (i.e. unallocated error value) and the target property set to the video/broadcast object. The playState property of the video/broadcast object shall be 3 while the state is stopped. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | |||
| org.hbbtv_00001900 | 2 | Change of state of a video/broadcast object when the bindToCurrentChannel() method is called while it is in the stopped state | When a video/broadcast object is in the stopped state and the bindToCurrentChannel() method is called, the video/broadcast object shall transition to the connecting state. A PlayStateChange DOM event shall be triggered with the state property set to 1 (connecting) and the error property set to undefined (i.e. unallocated error value). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | |||
| org.hbbtv_00001910 | 2 | Change of state of a video/broadcast object when the release() method is called while it is in the stopped state | When a video/broadcast object is in the stopped state and the release() method is called, the video/broadcast object shall transition to the unrealized state. A PlayStateChange DOM event shall be triggered with the state property set to 0 (unrealized) and the error property set to undefined (i.e. unallocated error value). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | |||
| org.hbbtv_00001920 | 2 | Change of state of a video/broadcast object when the stop() method is called while it is in the stopped state | When a video/broadcast object is in the stopped state and the stop() method is called, this shall have no effect. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | |||
| org.hbbtv_00001940 | 2 | video/broadcast object presentation - presenting state | When the video/broadcast object is in the presenting state, the video/broadcast object contains the video being presented. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Errata section 6.1.2: Behaviour of video and audio for a stopped video/broadcast object | |||
| org.hbbtv_00001950 | 2 | video/broadcast object presentation - stopped state | When the video/broadcast object is in the stopped state, the content of the video/broadcast object shall be an opaque black rectangle. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Errata section 6.1.2: Behaviour of video and audio for a stopped video/broadcast object | |||
| org.hbbtv_00001970 | 2 | Change of state of a video/broadcast object when the setChannel() method is called (with a null parameter) while it is in the unrealized state | When a video/broadcast object is in the unrealized state and the setChannel() method is called (with a null parameter), the video/broadcast object shall stay in the unrealized state. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes + Errata section 6.1.4: Calling setChannel() with a null parameter | |||
| org.hbbtv_00002000 | 2 | Change of state of a video/broadcast object when the setChannel() method is called (with a correct parameter) while it is in the presenting state | When a video/broadcast object is in the presenting state and the setChannel(x) method is called (where 'x' is a correct parameter for setChannel() method), the video/broadcast object shall transition to the connecting state. A PlayStateChange DOM event shall be triggered with the state property set to 1 (connecting) and the error property set to undefined (i.e. unallocated error value). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes + Errata section 6.1.4 Calling setChannel() with a null parameter | |||
| org.hbbtv_00002010 | 2 | Change of state of a video/broadcast object when the setChannel() method is called (with a null parameter) while it is in the presenting state | When a video/broadcast object is in the presenting state and the setChannel() method is called (with a null parameter), the video/broadcast object shall transition to the unrealized state. A PlayStateChange DOM event shall be triggered with the state property set to 0 (unrealized) and the error property set to undefined (i.e. unallocated error value) and the target property set to the video/broadcast object. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes + Errata section 6.1.4 Calling setChannel() with a null parameter | |||
| org.hbbtv_00002020 | 2 | Change of state of a video/broadcast object when the setChannel() method is called (with a correct parameter) while it is in the stopped state | When a video/broadcast object is in the stopped state and the setChannel(x) method is called (where 'x' is a correct parameter for setChannel() method), the video/broadcast object shall transition to the connecting state. A PlayStateChange DOM event shall be triggered with the state property set to 1 (connecting) and the error property set to undefined (i.e. unallocated error value) and the target property set to the video/broadcast object. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes + Errata section 6.1.4 Calling setChannel() with a null parameter | |||
| org.hbbtv_00002030 | 2 | Change of state of a video/broadcast object when the setChannel() method is called (with a null parameter) while it is in the stopped state | When a video/broadcast object is in the stopped state and the setChannel() method is called (with a null parameter), the video/broadcast object shall transition to the unrealized state. A PlayStateChange DOM event shall be triggered with the state property set to 0 (unrealized) and the error property set to undefined (i.e. unallocated error value) and the target property set to the video/broadcast object. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes + Errata section 6.1.4 Calling setChannel() with a null parameter | |||
| org.hbbtv_00002230 | 2 | AV Object Overlap (Partial overlap of object with a higher Z index) | When an AV object having a higher z index as compared to the HTML Objects, the AV Object shall partially overlap HTML objects. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.1: This clause is replaced by annex H, "Display Model" of the OIPF DAE specification [1]. OIPF-DAE,section H.2: Depending on the Z index of the video/broadcast or AV Control object with respect to other HTML elements (regardless of whether the object is in "fullscreen mode" or not), presented opaque video [...] may [...] be [...] partially overlapped by HTML elements with a higher Z index. | |||
| org.hbbtv_00002240 | 2 | AV Object Overlap (Partial overlap of object with a lower Z index) | When a AV object having a lower z index as compared to the HTML objects, the AV Object shall be partially overlapped by the HTML objects. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.1: This clause is replaced by annex H, "Display Model" of the OIPF DAE specification [1]. OIPF-DAE,section H.2: Depending on the Z index of the video/broadcast or AV Control object with respect to other HTML elements (regardless of whether the object is in "fullscreen mode" or not), presented opaque video may [...] partially overlap other HTML elements with a lower Z index. | |||
| org.hbbtv_00002250 | 2 | AV Object Overlap (Total overlap of object with a higher Z index) | When an AV object having a higher z index as compared to the HTML Objects, the AV Object shall completely overlap HTML objects. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.1: This clause is replaced by annex H, "Display Model" of the OIPF DAE specification [1]. OIPF-DAE,section H.2: Depending on the Z index of the video/broadcast or AV Control object with respect to other HTML elements (regardless of whether the object is in "fullscreen mode" or not), presented opaque video [...] may [...] be fully [...] overlapped by HTML elements with a higher Z index. | |||
| org.hbbtv_00002260 | 2 | AV Object Overlap (Total overlap of object with a lower Z index) | When an AV object having a lower z-index as compared to the HTML objects, the AV Object shall be completely overlapped by the HTML objects. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.1: This clause is replaced by annex H, "Display Model" of the OIPF DAE specification [1]. OIPF-DAE,section H.2: Depending on the Z index of the video/broadcast or AV Control object with respect to other HTML elements (regardless of whether the object is in "fullscreen mode" or not), presented opaque video may fully [...] overlap other HTML elements with a lower Z index. | |||
| org.hbbtv_00002270 | 2 | AV Object Scaling (1/8; Video Res 1280x720; 16:9) | Terminals shall be able to scale video having resolution of 1280x720, at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002280 | 2 | AV Object Scaling (1/8; Video Res 640x720; 16:9) | Terminals shall be able to scale video having resolution of 640x720 at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002290 | 2 | AV Object Scaling (1/8; Video Res 720x576; 16:9) | Terminals shall be able to scale video having resolution of 720x576 at sizes down to 1/8 by 1/8 of the width and height of the logical video plane for videos contained in a MP4 format - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002300 | 2 | AV Object Scaling (1/8; Video Res 352x288; 4:3) | Terminals shall be able to scale video having resolution of 352x288 at sizes down to 1/8 by 1/8 of the width and height of the logical video plane for videos contained in a MP4 format - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002310 | 3 | AV Object Scaling (2/13; Video Res 1280x720; 16:9) | Terminals shall be able to scale video having resolution of 1280x720, at sizes down to 2/13 of the width and height of the logical video plane for videos contained in a MP4 format - equivalent to 196 x 110 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002320 | 3 | AV Object Scaling (2/13; Video Res 640x720; 16:9) | Terminals shall be able to scale video having resolution of 640x720, at sizes down to 2/13 of the width and height of the logical video plane for videos contained in a MP4 format - equivalent to 196 x 110 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002330 | 3 | AV Object Scaling (2/13; Video Res 720x576; 16:9) | Terminals shall be able to scale video having resolution of 720x576, at sizes down to 2/13 of the width and height of the logical video plane for videos contained in a MP4 format - equivalent to 196 x 110 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002340 | 3 | AV Object Scaling (2/13; Video Res 352x288; 4:3) | Terminals shall be able to scale video having resolution of 352x288, at sizes down to 2/13 of the width and height of the logical video plane for videos contained in a MP4 format - equivalent to 196 x 110 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002350 | 2 | AV Object Scaling (x2; Video Res 1280x720) | Terminals shall be able to scale video having resolution of 1280x720 up to 2 x 2 of the width and height of the logical video plane - equivalent to 2560x1440 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is in "full-screen mode", presented video SHALL be scaled to fill the entire logical video plane. The OITF MAY further scale and/or position video, for example to remove black bars. | |||
| org.hbbtv_00002360 | 2 | AV Object Scaling (x2; Video Res 640x720) | Terminals shall be able to scale video having resolution of 640x720 up to 2 x 2 of the width and height of the logical video plane - equivalent to 2560x1440 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is in "full-screen mode", presented video SHALL be scaled to fill the entire logical video plane. The OITF MAY further scale and/or position video, for example to remove black bars. | |||
| org.hbbtv_00002370 | 2 | AV Object Scaling (x2; Video Res 720x576) | Terminals shall be able to scale video having resolution of 720x576 up to 2 x 2 of the width and height of the logical video plane - equivalent to 2560x1440 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is in "full-screen mode", presented video SHALL be scaled to fill the entire logical video plane. The OITF MAY further scale and/or position video, for example to remove black bars. | |||
| org.hbbtv_00002380 | 3 | AV Object Scaling (x2; Video Res 352x288) | Terminals shall be able to scale video having resolution of 352x288 up to 2 x 2 of the width and height of the logical video plane - equivalent to 2560x1440 pixels in the Hybrid Broadcast Broadband TV application graphics plane. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is in "full-screen mode", presented video SHALL be scaled to fill the entire logical video plane. The OITF MAY further scale and/or position video, for example to remove black bars. | |||
| org.hbbtv_00002390 | 2 | AV Object Scaling (1/2x1/4; Video Res 1280x720) | Terminals shall be able to scale video having resolution of 1280x720 to 1/2 x 1/4 of the width and height of the logical video plane. The aspect ratio of decoded video shall be preserved such that all of the decoded video is visible within the area of the video/broadcast or AV Control object. Finally a video having a resolution of 640x180 pixels in the Hybrid Broadcast Broadband TV application graphics plane shall be visible. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002400 | 2 | AV Object Scaling (1/2x1/4; Video Res 640x720) | Terminals shall be able to scale video having resolution of 640x720 up to 1/2 x 1/4 of the width and height of the logical video plane. The aspect ratio of decoded video shall be preserved such that all of the decoded video is visible within the area of the video/broadcast or AV Control object. Finally a video having a resolution of 640x180 pixels in the Hybrid Broadcast Broadband TV application graphics plane shall be visible. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002410 | 2 | AV Object Scaling (1/2x1/4; Video Res 720x576) | Terminals shall be able to scale video having resolution of 720x576 up to 1/2 x 1/4 of the width and height of the logical video plane. The aspect ratio of decoded video shall be preserved such that all of the decoded video is visible within the area of the video/broadcast or AV Control object. Finally a video having a resolution of 640x180 pixels in the Hybrid Broadcast Broadband TV application graphics plane shall be visible. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002420 | 2 | AV Object Scaling (1/2x1/4; Video Res 352x288) | Terminals shall be able to scale video having resolution of 352x288 up to 1/2 x 1/4 of the width and height of the logical video plane. The aspect ratio of decoded video shall be preserved such that all of the decoded video is visible within the area of the video/broadcast or AV Control object. Finally a video having a resolution of 640x180 pixels in the Hybrid Broadcast Broadband TV application graphics plane shall be visible. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Terminals shall be able to present video at sizes down to 1/8 by 1/8 of the width and height of the logical video plane - equivalent to 160 x 90 pixels in the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video down to 1/4 by 1/4 and should be able to scale video down to 1/8 by 1/8. For sizes between 1/4 by 1/4 and 1/8 by 1/8, terminals which cannot scale video shall crop the video instead and display it centered in the according video object of the Hybrid Broadcast Broadband TV application graphics plane. Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. Within these limits, any arbitrary scaling factor shall be allowed. The aspect ratio of the video shall be preserved at all scaling factors. See OIPF DAE Annex H.2 for more information. OIPF-DAE,section H.2: When the video/broadcast object or AV Control object is not in "full-screen mode", any video being presented SHALL be scaled and positioned in the following way: if the video/broadcast object has the same aspect ratio as the video the four corners of the video SHALL match exactly the corners of the video/broadcast object ::: otherwise the video SHALL be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio SHALL be preserved. Along the side where the video is shorter than the video/broadcast object, the video SHALL be centered. The area of the video plane not containing video SHALL be opaque black. | |||
| org.hbbtv_00002440 | 2 | Cookies expire at the correct time | Terminals shall respect the expiry date of the cookie and remove them once they expire. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum terminal capabilities: Cookies with an expiry date shall be stored in persistent memory. Terminals shall respect the expiry date of the cookie. OIPF-DAE,section 9.1: OITFs SHALL follow [RFC6265] when implementing cookies support. RFC6265,section 5.3: The user agent MUST evict all expired cookies from the cookie store if, at any time, an expired cookie exists in the cookie store. | |||
| org.hbbtv_00002441 | 1 | Cookies removal: delete cookie with expire time in the past | The HbbTV application creates a cookie with expiry date in the future. Next the application is restarted. When after launch, the application sets the cookie with the same name, domain, path, and expiry date in the past, then the cookie is evicted. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum terminal capabilities: Cookies with an expiry date shall be stored in persistent memory. Terminals shall respect the expiry date of the cookie. OIPF-DAE,section 9.1: OITFs SHALL follow [RFC6265] when implementing cookies support. RFC6265,section 5.3: 11. If the cookie store contains a cookie with the same name, domain, and path as the newly created cookie: 1. Let old-cookie be the existing cookie with the same name, domain, and path as the newly created cookie. (Notice that this algorithm maintains the invariant that there is at most one such cookie.) 2. If the newly created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is set, abort these steps and ignore the newly created cookie entirely. 3. Update the creation-time of the newly created cookie to match the creation-time of the old-cookie. 4. Remove the old-cookie from the cookie store. [...] The user agent MUST evict all expired cookies from the cookie store if, at any time, an expired cookie exists in the cookie store. | |||
| org.hbbtv_00002450 | 1 | Terminal supports cookies of 4096 bytes | The terminal shall support storage and retrieval of a cookie with a size of 4096 bytes | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum terminal capabilities: Cookie Support At least 4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes). | |||
| org.hbbtv_00002460 | 1 | Terminal supports at least 100 cookies | The terminal shall support a minimum of 100 cookies | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum terminal capabilities: Cookie Support At least 100 cookies total | |||
| org.hbbtv_00002470 | 1 | Terminal supports at least 100 x 4KB cookies | The terminal shall support a minimum of 100 cookies having a maximum individual size of 4k each. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum terminal capabilities: Cookie Support At least 4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes). At least 20 cookies per domain At least 100 cookies total | |||
| org.hbbtv_00002480 | 1 | Terminal supports 20 cookies per domain | The terminal shall support storage and retrieval of 20 cookies for a single domain. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum terminal capabilities: Cookie Support At least 20 cookies per domain | |||
| org.hbbtv_00002490 | 1 | Memory Audio - Infinite Looping | When an A/V Control object is initialised for memory audio, and its 'loop' PARAM element has the value 'infinite'; when the play() method is called on the A/V Control object with its 'speed' argument specified as 1, the terminal shall play the whole memory audio clip in full and shall repeat playback indefinitely | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Audio format for audio from memory - HEAAC shall be supported (as defined in clause 6.3.2 of the OIPF DAE specification HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF-Media-Formats specification OIPF-DAE,section 6.3.2: Media format of A/V media for audio from memory | |||
| org.hbbtv_00002500 | 1 | Memory Audio - Stopping looping playback | When the terminal is continuously playing looping memory audio, it shall be able to stop playback when the stop() method is called on the A/V Control object | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Audio format for audio from memory - HEAAC shall be supported (as defined in clause 6.3.2 of the OIPF DAE specification HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF-Media-Formats specification OIPF-DAE,section 6.3.2: Media format of A/V media for audio from memory | |||
| org.hbbtv_00002510 | 2 | Test of support for MP4 File Format streamed over HTTP; 1280x720p@25, 16:9 | The terminal shall correctly decode and display AV from MP4 File Formats streamed over HTTP (1280x720p@25, 16:9). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.2: The MP4 File Format shall comply with clause 4 of the OIPF Media Formats specification HBBTV,section 10.2.1: System layer for unicast streaming using HTTP and file download. Both MPEG-2 TS and MP4 file format (as defined in clause 7.3.1.2) shall be supported. OIPF-Media-Formats,section 4: Systems Layer | |||
| org.hbbtv_00002520 | 2 | Test of support for MP4 File Format streamed over HTTP; 352x288i@25, 4:3 | The terminal shall correctly decode and display AV from MP4 File Formats streamed over HTTP (352x288i@25, 4:3). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.2: The MP4 File Format shall comply with clause 4 of the OIPF Media Formats specification HBBTV,section 10.2.1: System layer for unicast streaming using HTTP and file download. Both MPEG-2 TS and MP4 file format (as defined in clause 7.3.1.2) shall be supported. OIPF-Media-Formats,section 4: Systems Layer | |||
| org.hbbtv_00002530 | 2 | Test of support for MPEG-2 TS streamed over HTTP; 1280x720p@25, 16:9 | The terminal shall correctly decode and display AV from MPEG-2 TS streamed over HTTP (1280x720p@25, 16:9). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.2: The usage of the systems layer format MPEG-2 Transport Stream shall comply with clause 4 of the OIPF Media Formats specification HBBTV,section 10.2.1: System layer for unicast streaming using HTTP and file download. Both MPEG-2 TS and MP4 file format (as defined in clause 7.3.1.2) shall be supported. OIPF-Media-Formats,section 4: Systems Layer | |||
| org.hbbtv_00002540 | 2 | Test of support for MPEG-2 TS streamed over HTTP; 352x288i@25, 4:3 | The terminal shall correctly decode and display AV from MPEG-2 TS streamed over HTTP (352x288i@25, 4:3). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.2: The usage of the systems layer format MPEG-2 Transport Stream shall comply with clause 4 of the OIPF Media Formats specification HBBTV,section 10.2.1: System layer for unicast streaming using HTTP and file download. Both MPEG-2 TS and MP4 file format (as defined in clause 7.3.1.2) shall be supported. OIPF-Media-Formats,section 4: Systems Layer | |||
| org.hbbtv_00002590 | 2 | Test of High Bitrate Streaming; MP4 File Format | The terminal shall correctly decode and display AV from an MP4 streamed over HTTP at 8Mbit/s. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.2: Bitrates of up to 8 MBit/sec for the stream (including protocol overheads, e.g. TCP and HTTP) shall be supported. | |||
| org.hbbtv_00002600 | 1 | Test of High Bitrate Streaming; MPEG-2 TS | The terminal shall correctly decode and present AV from an MPEG-2 TS streamed over HTTP at 8 Mbit/s | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.2: Bitrates of up to 8 MBit/sec for the stream (including protocol overheads, e.g. TCP and HTTP) shall be supported. | |||
| org.hbbtv_00002610 | 2 | Test that terminal ignores any AIT signalling present in MPEG-2 TS streamed over HTTP | The terminal shall ignore any AIT data present in an MPEG-2 TS streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.2: AIT signalling as defined in clause 7.2.3.1 shall not be processed for MPEG-2 TS delivered via unicast broadband content. | |||
| org.hbbtv_00002630 | 2 | Test of support for AVC_SD_25; 720x576p@25, 16:9 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 720x576p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002640 | 2 | Test of support for AVC_SD_25; 544x576p@25, 16:9 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 544x576p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002650 | 2 | Test of support for AVC_SD_25; 480x576p@25, 16:9 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 480x576p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002660 | 2 | Test of support for AVC_SD_25; 352x576p@25, 16:9 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 352x576p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002670 | 2 | Test of support for AVC_SD_25; 352x288p@25, 16:9 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 352x288p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002680 | 2 | Test of support for AVC_SD_25; 720x576i@25, 16:9 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 720x576i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002690 | 2 | Test of support for AVC_SD_25; 544x576i@25, 16:9 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 544x576i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002700 | 2 | Test of support for AVC_SD_25; 480x576i@25, 16:9 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 480x576i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002710 | 2 | Test of support for AVC_SD_25; 352x576i@25, 16:9 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 352x576i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002720 | 2 | Test of support for AVC_SD_25; 352x288i@25, 16:9 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 352x288i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002730 | 2 | Test of support for AVC_SD_25; 720x576p@25, 4:3 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 720x576p@25, 4:3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002740 | 2 | Test of support for AVC_SD_25; 544x576p@25, 4:3 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 544x576p@25, 4:3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002750 | 2 | Test of support for AVC_SD_25; 480x576p@25, 4:3 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 480x576p@25, 4:3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002760 | 2 | Test of support for AVC_SD_25; 352x576p@25, 4:3 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 352x576p@25, 4:3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002770 | 2 | Test of support for AVC_SD_25; 352x288p@25, 4:3 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 352x288p@25, 4:3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002780 | 2 | Test of support for AVC_SD_25; 720x576i@25, 4:3 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 720x576i@25, 4:3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002790 | 2 | Test of support for AVC_SD_25; 544x576i@25, 4:3 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 544x576i@25, 4:3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002800 | 2 | Test of support for AVC_SD_25; 480x576i@25, 4:3 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 480x576i@25, 4:3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002810 | 2 | Test of support for AVC_SD_25; 352x576i@25, 4:3 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 352x576i@25, 4:3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002820 | 2 | Test of support for AVC_SD_25; 352x288i@25, 4:3 | The terminal shall correctly decode and display AVC_SD_25 streaming video at 352x288i@25, 4:3. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.2.1: Standard Definition Profile; H.264/AVC | |||
| org.hbbtv_00002830 | 2 | Test of support for AVC_HD_25; 1280x720p@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 1280x720p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002840 | 2 | Test of support for AVC_HD_25; 960x720p@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 960x720p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002850 | 2 | Test of support for AVC_HD_25; 640x720p@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 640x720p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002860 | 2 | Test of support for AVC_HD_25; 1280x720i@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 1280x720i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002870 | 2 | Test of support for AVC_HD_25; 960x720i@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 960x720i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002880 | 2 | Test of support for AVC_HD_25; 640x720i@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 640x720i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002890 | 2 | Test of support for AVC_HD_25; 1920x1080p@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 1920x1080p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002900 | 2 | Test of support for AVC_HD_25; 1440x1080p@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 1440x1080p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002910 | 2 | Test of support for AVC_HD_25; 1280x1080p@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 1280x1080p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002920 | 2 | Test of support for AVC_HD_25; 960x1080p@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 960x1080p@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002930 | 2 | Test of support for AVC_HD_25; 1920x1080i@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 1920x1080i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002940 | 2 | Test of support for AVC_HD_25; 1440x1080i@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 1440x1080i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002950 | 2 | Test of support for AVC_HD_25; 1280x1080i@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 1280x1080i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002960 | 2 | Test of support for AVC_HD_25; 960x1080i@25, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 960x1080i@25, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002970 | 2 | Test of support for AVC_HD_25; 1280x720p@50, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 1280x720p@50, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002980 | 2 | Test of support for AVC_HD_25; 960x720p@50, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 960x720p@50, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00002990 | 2 | Test of support for AVC_HD_25; 640x720p@50, 16:9 | The terminal shall correctly decode and display AVC_HD_25 streaming video at 640x720p@50, 16:9. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.3: The video format AVC_HD_25 shall comply with clauses 5.1.1.1 and 5.1.3 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 5.1.1.1: High Definition Profile; H.264/AVC | |||
| org.hbbtv_00003000 | 2 | Test of support for HE-AAC; Mono, AV Content, Streamed over HTTP | The terminal shall correctly decode and present mono HE-AAC audio as part of AV Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003010 | 2 | Test of support for HE-AAC; Stereo, AV Content, Streamed over HTTP | The terminal shall correctly decode and present stereo HE-AAC audio as part of AV Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003020 | 2 | Test of support for HE-AAC; Multichannel, AV Content, Streamed over HTTP | The terminal shall correctly decode and present multichannel HE-AAC audio as part of AV Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003030 | 2 | Test of support for AAC; Mono, AV Content, Streamed over HTTP | The terminal shall correctly decode and present mono AAC audio as part of AV Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003040 | 2 | Test of support for AAC; Stereo, AV Content, Streamed over HTTP | The terminal shall correctly decode and present stereo AAC audio as part of AV Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003050 | 2 | Test of support for AAC; Multichannel, AV Content, Streamed over HTTP | The terminal shall correctly decode and present multichannel AAC audio as part of AV Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003060 | 3 | Test of support for AC-3; Mono, AV Content, Streamed over HTTP | The terminal shall correctly decode and present mono AC-3 audio as part of AV Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | +EAC3 | ||
| org.hbbtv_00003070 | 3 | Test of support for AC-3; Stereo, AV Content, Streamed over HTTP | The terminal shall correctly decode and present stereo AC-3 audio as part of AV Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | +EAC3 | ||
| org.hbbtv_00003080 | 3 | Test of support for AC-3; Multichannel, AV Content, Streamed over HTTP | The terminal shall correctly decode and present multichannel AC-3 audio as part of AV Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | +EAC3 | ||
| org.hbbtv_00003090 | 1 | Test of support for MP4 E-AC-3; Mono, AV Content, Streamed over HTTP | The terminal shall correctly decode and present mono E-AC-3 audio as part of AV Content encapsulated in an MP4 container and streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | +EAC3 | ||
| org.hbbtv_00003100 | 1 | Test of support for MP4 E-AC-3; Stereo, AV Content, Streamed over HTTP | The terminal shall correctly decode and present stereo E-AC-3 audio as part of AV Content encapsulated in an MP4 container and streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | +EAC3 | ||
| org.hbbtv_00003110 | 1 | Test of support for MP4 E-AC-3; Multichannel, AV Content, Streamed over HTTP | The terminal shall correctly decode and present multichannel E-AC-3 audio as part of AV Content encapsulated in an MP4 container and streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | +EAC3 | ||
| org.hbbtv_00003120 | 2 | Test of support for HE-AAC; Mono, Audio Only (Radio) Content, Streamed over HTTP | The terminal shall correctly decode and present mono HE-AAC audio as part of Audio Only (Radio) Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003130 | 2 | Test of support for HE-AAC; Stereo, Audio Only (Radio) Content, Streamed over HTTP | The terminal shall correctly decode and present stereo HE-AAC audio as part of Audio Only (Radio) Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003140 | 2 | Test of support for HE-AAC; Multichannel, Audio Only (Radio) Content, Streamed over HTTP | The terminal shall correctly decode and present multichannel HE-AAC audio as part of Audio Only (Radio) Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003170 | 1 | Test of support for MP4 AAC; Multichannel, Audio Only (Radio) Content, Streamed over HTTP | The terminal shall correctly decode and present multichannel AAC audio as part of audio only (radio) content encapsulated in an MP4 container and streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF-Media-Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003180 | 2 | Test of support for MP3; Mono, Audio Only (Radio) Content, Streamed over HTTP | The terminal shall correctly decode and present mono MP3 audio as part of Audio Only (Radio) Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003190 | 2 | Test of support for MP3; Stereo, Audio Only (Radio) Content, Streamed over HTTP | The terminal shall correctly decode and present stereo MP3 audio as part of Audio Only (Radio) Content streamed over HTTP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification OIPF-Media-Formats,section 8.1: Audio Formats | |||
| org.hbbtv_00003400 | 2 | Test of downmixing Multichannel HE-AAC (AV Content) Streamed over HTTP | The terminal shall correctly downmix multichannel HE-AAC for presentation over a stereo output. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: If the terminal supports a stereo output, it shall be capable of providing a down-mix of multichannel audio to stereo. OIPF-Media-Formats,section 8.2.4: For stereo output interfaces, 5.1 surround audio streams SHALL be down-mixed to stereo | +STEREO | ||
| org.hbbtv_00003410 | 2 | Test of downmixing Multichannel AAC (AV Content) Streamed over HTTP | The terminal shall correctly downmix multichannel AAC for presentation over a stereo output. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: If the terminal supports a stereo output, it shall be capable of providing a down-mix of multichannel audio to stereo. OIPF-Media-Formats,section 8.2.4: For stereo output interfaces, 5.1 surround audio streams SHALL be down-mixed to stereo | +STEREO | ||
| org.hbbtv_00003420 | 3 | Test of downmixing Multichannel AC-3 (AV Content) Streamed over HTTP | The terminal shall correctly downmix multichannel AC-3 for presentation over a stereo output. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: If the terminal supports a stereo output, it shall be capable of providing a down-mix of multichannel audio to stereo. OIPF-Media-Formats,section 8.2.4: For stereo output interfaces, 5.1 surround audio streams SHALL be down-mixed to stereo | +EAC3 +STEREO | ||
| org.hbbtv_00003430 | 1 | Test of downmixing Multichannel E-AC-3 (AV Content) Streamed over HTTP | The terminal shall correctly downmix multichannel E-AC-3 for presentation over a stereo output | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: If the terminal supports a stereo output, it shall be capable of providing a down-mix of multichannel audio to stereo OIPF-Media-Formats,section 8.1: Audio Formats | +EAC3 +STEREO | ||
| org.hbbtv_00003441 | 1 | Test of interpretation of audio metadata when downmixing Multichannel HE-AAC (AV Content) Streamed over HTTP | The terminal shall correctly interpret downmix parameters from the audio metadata when downmixing multichannel HE-AAC for presentation over a stereo output. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: The terminal shall use metadata, where provided, to control the stereo down-mix from multichannel audio OIPF-Media-Formats,section 8.1: Audio Formats | -HAS_SPEAKER +STEREO | ||
| org.hbbtv_00003451 | 1 | Test of interpretation of audio metadata when downmixing Multichannel AAC (AV Content) Streamed over HTTP | The terminal shall correctly interpret downmix parameters from the audio metadata when downmixing multichannel AAC for presentation over a stereo output. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: The terminal shall use metadata, where provided, to control the stereo down-mix from multichannel audio OIPF-Media-Formats,section 8.1: Audio Formats | -HAS_SPEAKER +STEREO | ||
| org.hbbtv_00003460 | 3 | Test of interpretation of audio metadata when downmixing Multichannel AC-3 (AV Content) Streamed over HTTP | The terminal shall correctly interpret downmix parameters from the audio metadata when downmixing multichannel AC-3 for presentation over a stereo output. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: The terminal shall use metadata, where provided, to control the stereo down-mix from multichannel audio OIPF-Media-Formats,section 8.1.1.3: For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. | +EAC3 +STEREO | ||
| org.hbbtv_00003471 | 2 | Test of interpretation of audio metadata when downmixing Multichannel E-AC-3 (AV Content) Streamed over HTTP | The terminal shall correctly interpret downmix parameters from the audio metadata when downmixing multichannel E-AC-3 for presentation over a stereo output. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: The terminal shall use metadata, where provided, to control the stereo down-mix from multichannel audio OIPF-Media-Formats,section 8.1: Audio Formats | +EAC3 -HAS_SPEAKER +STEREO | ||
| org.hbbtv_00003480 | 2 | Test of passthrough of HE-AAC (AV Content) Streamed over HTTP | The terminal shall correctly passthrough an HE-AAC bitstream onto the digital audio output. | 2024-2 2024-1 2023-3 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: If the terminal is equipped with a digital audio output then it shall be capable of providing the bitstream at this output (pass-through) and should be capable of transcoding multi-channel audio from HEAAC to AC3 format. | +SPDIF | |
| org.hbbtv_00003490 | 2 | Test of passthrough of AAC (AV Content) Streamed over HTTP | The terminal shall correctly passthrough an AAC-LC bitstream onto the digital audio output. | 2024-2 2024-1 2023-3 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: If the terminal is equipped with a digital audio output then it shall be capable of providing the bitstream at this output (pass-through) and should be capable of transcoding multi-channel audio from HEAAC to AC3 format. OIPF-Media-Formats,section 8.1.1: AAC and HE-AAC formats correspond to the audio format label HEAAC. | +SPDIF | |
| org.hbbtv_00003500 | 1 | Test of passthrough of AC-3 (AV Content) Streamed over HTTP | The terminal shall correctly passthrough an AC-3 bitstream onto the digital audio output. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: If the terminal is equipped with a digital audio output then it shall be capable of providing the bitstream at this output (pass-through) and should be capable of transcoding multi-channel audio from HEAAC to AC3 format. OIPF-Media-Formats,section 8.2.4: For digital outputs (e.g. S/PDIF [SPDIF] or HDMI) one of the following conversions MAY be used: * Conversion of the received Enhanced AC-3 audio streams to AC-3 [AC3] * Transcoding of the received HEAAC, HEAAC_MPS or MPEG1_L2_MPS audio streams to the AC3 [AC3] or DTS [DTS] formats * Decoding of the received DTS, HEAAC, HEAAC_MPS or MPEG1_L2_MPS audio streams and output of PCM multi-channel over HDMI Volume | +SPDIF | ||
| org.hbbtv_00003510 | 2 | Test of passthrough of EAC-3 (AV Content) Streamed over HTTP | The terminal shall correctly passthrough an EAC-3 bitstream onto the digital audio output. | 2024-2 2024-1 2023-3 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: If the terminal is equipped with a digital audio output then it shall be capable of providing the bitstream at this output (pass-through) and should be capable of transcoding multi-channel audio from HEAAC to AC3 format. OIPF-Media-Formats,section 8.2.4: For digital outputs (e.g. S/PDIF [SPDIF] or HDMI) one of the following conversions MAY be used: * Conversion of the received Enhanced AC-3 audio streams to AC-3 [AC3] * Transcoding of the received HEAAC, HEAAC_MPS or MPEG1_L2_MPS audio streams to the AC3 [AC3] or DTS [DTS] formats * Decoding of the received DTS, HEAAC, HEAAC_MPS or MPEG1_L2_MPS audio streams and output of PCM multi-channel over HDMI Volume | +EAC3 +SPDIF | |
| org.hbbtv_00003520 | 2 | Transcoding to AC3 from HE-AAC v1 | When streaming an MP4 containing 5.1 channel, HE-AAC v1 audio and accompanying video data over HTTP; the terminal shall correctly transcode the audio to AC-3 over the S/PDIF output | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: If the terminal is equipped with a digital audio output then it shall be capable of providing the bitstream at this output (pass-through) and should be capable of transcoding multi-channel audio from HEAAC to AC3 format. | +MULTI_CHANNEL_AUDIO +SPDIF | ||
| org.hbbtv_00003530 | 2 | Transcoding to AC3 from AAC LC | When streaming an MP4 containing 5.1 channel, AAC LC audio and accompanying video data over HTTP; the terminal shall correctly transcode the audio to AC-3 over the S/PDIF output | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.4: If the terminal is equipped with a digital audio output then it shall be capable of providing the bitstream at this output (pass-through) and should be capable of transcoding multi-channel audio from HEAAC to AC3 format. | +MULTI_CHANNEL_AUDIO +SPDIF | ||
| org.hbbtv_00003540 | 3 | AV Object Seeking Within Buffer (MP4 Forward 5s) | The terminal shall correctly seek to a new position inside buffer for a video contained in a MP4 format. The terminal shall seek to 5s forward within buffer. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: Unicast streaming using HTTP 1.1 shall be supported as defined in clause 5.2.2.2 of the OIPF protocols specification [...] with the addition that the Content-range header shall be supported in seek operations thus allowing the application to seek to any arbitrary position within the streaming video without the need of downloading the complete video first. The terminal should only buffer data equivalent to approximately 10 seconds of normal play in advance of the current play position unless the download rate is consistently lower than the consumption rate. OIPF-Protocol,section 5.2.2.2: Protocol for streaming for unmanaged model over UNIT-17 | |||
| org.hbbtv_00003580 | 2 | AV Object Seeking Outside Buffer (MP4 Backward) | The terminal shall correctly seek backward to an earlier position outside buffer for a video contained in a MP4 format. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: Unicast streaming using HTTP 1.1 shall be supported as defined in clause 5.2.2.2 of the OIPF protocols specification [...] with the addition that the Content-range header shall be supported in seek operations thus allowing the application to seek to any arbitrary position within the streaming video without the need of downloading the complete video first. The terminal should only buffer data equivalent to approximately 10 seconds of normal play in advance of the current play position unless the download rate is consistently lower than the consumption rate. OIPF-Protocol,section 5.2.2.2: Protocol for streaming for unmanaged model over UNIT-17 | |||
| org.hbbtv_00003600 | 3 | AV Object Seeking Within Buffer (MP4 Backward 5s) | The terminal shall correctly seek backward to an earlier position within buffer for a video contained in a MP4 format. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: Unicast streaming using HTTP 1.1 shall be supported as defined in clause 5.2.2.2 of the OIPF protocols specification [...] with the addition that the Content-range header shall be supported in seek operations thus allowing the application to seek to any arbitrary position within the streaming video without the need of downloading the complete video first. The terminal should only buffer data equivalent to approximately 10 seconds of normal play in advance of the current play position unless the download rate is consistently lower than the consumption rate. OIPF-Protocol,section 5.2.2.2: Protocol for streaming for unmanaged model over UNIT-17 | |||
| org.hbbtv_00003630 | 2 | AV Streaming Tests: AV Object (Pause) | Setting the A/V control object's play speed property to 0('paused') while streaming video over HTTP SHALL cause the video to freeze and audio to suspend | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.1.1.1: Unicast streaming. General streaming requirements OIPF-DAE,section 8.2.3.1: Streaming CoD | |||
| org.hbbtv_00003640 | 2 | AV Streaming Tests: AV Object (Stop) | Stopping playback shall cause the video plane to be made opaque black and the audio to stop. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.1.1.1: Unicast streaming. General streaming requirements OIPF-DAE,section 8.2.3.1: Streaming CoD | |||
| org.hbbtv_00003650 | 2 | Test for onPlayStateChanged event when transitioning from Play to Pause | When the A/V Control Object successfully transitions from 'playing' state to 'paused' state, an onPlayStateChanged event with a state of 2 shall be generated. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: State diagram for A/V control objects: 7.14.1.1: Mandatory OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects: The following state transition diagram SHOULD be used for an A/V control object: | |||
| org.hbbtv_00003660 | 2 | Test for onPlayStateChanged event when transitioning from Play to Stop | When the A/V Control Object successfully transitions from 'playing' state to 'stopped' state, an onPlayStateChanged event with a state of 0 shall be generated. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: State diagram for A/V control objects: 7.14.1.1: Mandatory OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects: The following state transition diagram SHOULD be used for an A/V control object: | |||
| org.hbbtv_00003670 | 2 | Test for onPlayStateChanged event when transitioning from Paused to Playing | When the A/V Control Object successfully transitions from 'paused' state to 'playing' state, an onPlayStateChanged event with a state of 1 shall be generated. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: State diagram for A/V control objects: 7.14.1.1: Mandatory OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects: The following state transition diagram SHOULD be used for an A/V control object: | |||
| org.hbbtv_00003680 | 2 | Test for onPlayStateChanged event when transitioning from Paused to Stop | When the A/V Control Object successfully transitions from 'paused' state to 'stopped' state, an onPlayStateChanged event with a state of 0 shall be generated. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: State diagram for A/V control objects: 7.14.1.1: Mandatory OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects: The following state transition diagram SHOULD be used for an A/V control object: | |||
| org.hbbtv_00003690 | 2 | Test for onPlayStateChanged event when transitioning from Stop to Play | When the A/V Control Object successfully transitions from 'stopped' state to 'playing' state, an onPlayStateChanged event with a state of 1 shall be generated. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: State diagram for A/V control objects: 7.14.1.1: Mandatory OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects: The following state transition diagram SHOULD be used for an A/V control object: | |||
| org.hbbtv_00003700 | 3 | Test for onPlayStateChanged event when transitioning from Stopped to Pause | When the A/V Control Object successfully transitions from 'stopped' state to 'paused' state, an onPlayStateChanged event with a state of 2 shall be generated. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: State diagram for A/V control objects: 7.14.1.1: Mandatory OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects: The following state transition diagram SHOULD be used for an A/V control object: | |||
| org.hbbtv_00003710 | 2 | the application.privateData.currentChannel after application start | After selecting a service programmatically, the currentChannel property of the application.privateData object shall reflect new channel. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.2: readonly Channel currentChannel: For a broadcast-related application, the value of the property contains the channel whose AIT is currently controlling the lifecycle of this application. | |||
| org.hbbtv_00003730 | 2 | the application.privateData.currentChannel after channel selection by application | After start of application, the currentChannel property of the application.privateData object shall reflect the channel the application was started from. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.2: readonly Channel currentChannel: For a broadcast-related application, the value of the property contains the channel whose AIT is currently controlling the lifecycle of this application. | |||
| org.hbbtv_00003740 | 2 | CreateApplication with parameters in URL | When calling an application via createApplication, the parameters signalled in the AIT (?param1=value1) and the parameters of the createApplication call (?param2=value2) are combined. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.2: Parameters assigned to this DVB URL shall be parsed and attached to the application location URL signaled inside the corresponding AIT. OIPF-DAE,section 7.2.2.2: Application createApplication(String uri, Boolean createChild) | |||
| org.hbbtv_00003750 | 2 | CreateApplication with hash in URL | When calling an application via createApplication, the parameters signalled in the AIT (?param1=value1) and the parameters of the createApplication call (#test) are combined. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.2: Parameters assigned to this DVB URL shall be parsed and attached to the application location URL signaled inside the corresponding AIT. OIPF-DAE,section 7.2.2.2: Application createApplication(String uri, Boolean createChild) | |||
| org.hbbtv_00003760 | 2 | video.currentChannel after channel selection by application | After selecting a service programmatically, the currentChannel property on the video/broadcast shall reflect the new channel. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: The currentChannel property of the video/broadcast object shall be supported. OIPF-DAE,section 7.13.7.1: readonly Channel currentChannel: The channel currently being presented by this embedded object if the user has given permission to share this information | |||
| org.hbbtv_00003780 | 2 | video.currentChannel after application start | After start of application, the currentChannel property on the video/broadcast shall reflect the channel the application was started from. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: The currentChannel property of the video/broadcast object shall be supported. OIPF-DAE,section 7.13.7.1: readonly Channel currentChannel: The channel currently being presented by this embedded object if the user has given permission to share this information | |||
| org.hbbtv_00003790 | 2 | EIT p/f | When video/broadcast object is tuned to a channel, EIT present/following data can be retrieved using the programmes property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Access to DVB-SI EIT p/f OIPF-DAE,section 7.13.3: readonly ProgrammeCollection programmes: The collection of programmes available on the currently tuned channel. This list is a ProgrammeCollection as defined in Section 7.16.3 and is ordered by start time. | |||
| org.hbbtv_00003800 | 2 | Letter Gothic font rendering width | Rendering width of Letter Gothic 12 Pitch font (or equivalent) should match pre-defined rendering width. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Letter Gothic 12 Pitch (or equivalent) [...]. This font (even if it is an equivalent of Letter Gothic 12 Pitch) shall be accessible with the following CSS rule: font-family: Letter Gothic 12 Pitch; | |||
| org.hbbtv_00003810 | 2 | Line-height CSS style | The actual line-height in font rendering should match the specified line-height CSS style, even when font-weight is bold. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Tiresias Screenfont (or equivalent) with the support for the Unicode character range Basic Euro Latin Character set as defined in Annex D of TS 102 809 OIPF-DAE,section 2.1: W3C CSS definition, chapter 10.8: Line height calculations: the 'line-height' [...] properties | |||
| org.hbbtv_00003820 | 2 | Tiresias font rendering width | Rendering width of Tiresias font (or equivalent) should match pre-defined rendering width. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Tiresias Screenfont (or equivalent) [...]. This font (even if it is an equivalent of Tiresias Screenfont) shall be accessible with the following CSS rule: font-family: Tiresias; | |||
| org.hbbtv_00003830 | 2 | OIPF capabilities: hasCapability() | When calling the hasCapability method on the application/oipfCapabilities object for the following string arguments, a boolean value is returned: +DL, +PVR, +RTSP. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: The hasCapability() method shall be supported with the profile names being the Hybrid Broadcast Broadband TV option strings as defined in clause 10.2.4. OIPF-DAE,section 7.15.3.2: Boolean hasCapability(String profileName): Check if the OITF supports the passed capability. | |||
| org.hbbtv_00003840 | 2 | OIPF Capabilities: extra decodes | The properties extraSDVideoDecodes and extraHDVideoDecodes are numeric integer values greater or equal to 0. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.3: Extensions to the oipfCapabilities embedded object | |||
| org.hbbtv_00003870 | 2 | OIPF Configuration: countryId | The configuration.countryId property of the application/oipfConfiguration is set to an ISO-3166 three character country code. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: The configuration property shall be supported. OIPF-DAE,section 7.3.1: readonly Configuration configuration OIPF-DAE,section 7.3.2: String countryId: An ISO-3166 three character country code identifying the country in which the receiver is deployed. | |||
| org.hbbtv_00003880 | 2 | StreamEvent reference DVB URL | After registering a StreamEvent listener via a dvb: URL referencing a carousel and stream event PID on the same service, stream events are received. After removing the listener, no more stream event is received. | 2024-2 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.1: Acquisition of DSM-CC stream events | |||
| org.hbbtv_00003890 | 2 | StreamEvent reference event description file | After registering a StreamEvent listener via a HTTP URL referencing a event description file which itself references a stream event PID on the same service (via a component tag), stream events are received. After removing the listener, no more stream event is received. The stream event name of the received event is equal to the one that was used to register the listener. | 2024-2 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.1: Acquisition of DSM-CC stream events | |||
| org.hbbtv_00003920 | 3 | invalid video playback: A/V format | When playing back a video with invalid video format, a single error event should occur, the error property should be set to 0, 2, or 4. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: CEA2014A,section 5.7.1: Number error [R] - error details; [...] 0 - A/V format not supported | |||
| org.hbbtv_00003930 | 3 | invalid video playback: cannot connect | When playing back a video with an URL referencing a port on a server that allows no connection, a single error event should occur, the error property should be set to 1. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: CEA2014A,section 5.7.1: Number error [R] - error details; [...] 1 - cannot connect to server or connection lost | |||
| org.hbbtv_00003940 | 3 | invalid video playback: video not found | When playing back a video URL that results in a HTTP error 404 (not found), a single error event should occur, the error property should be set to 1, 2, 5 or 6. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: CEA2014A,section 5.7.1: Number error [R] - error details | |||
| org.hbbtv_00003950 | 3 | Playback of video without content-range support | Terminal should be able to play back video from servers that do not support HTTP content-range headers (e.g. when playing back live video). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: System, video and audio formats | |||
| org.hbbtv_00003960 | 3 | Video playTime | During broadband video playback, playTime returns the total duration of the video in milliseconds. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: CE-HTML Profiling: 5.7 addition to 5.7.1.f CEA2014A,section 5.7.1: Number playTime [R] -the total duration in milliseconds of the media referenced by data. | |||
| org.hbbtv_00003970 | 3 | video queue | During playback, queuing another video makes play the video after the first video has finished playing. Calling queue(null) will erase the queue and return true. Next video queued is actually played back. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.5: Queue the media referred to by url for playback after the current media item has finished playing. If a media item is already queued, url will not be queued for playback and this method will return false. If the item is queued successfully, this method returns true. If no media is currently playing, the queued item will be played immediately. If url is null, any currently queued item will be removed from the queue and this method will return true. | |||
| org.hbbtv_00003980 | 3 | seek in broadband video playback | During playback, of a broadband served video, seek sets the current play position. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: Unicast streaming using HTTP 1.1 shall be supported [...] with the addition that the Content-Range header shall be supported in seek operations thus allowing the application to seek to any arbitrary position within the streaming video without the need of downloading the complete video first. CEA2014A,section 5.7.1: seek(Number pos) - sets the current play position (in milliseconds) to the value of pos. | |||
| org.hbbtv_00003990 | 3 | video/mp4 keeps aspect ratio | video/mp4 object displays video with correct aspect ratio and letterboxing. Note: this may lead to problems, as it is quite complicated for many platforms/implementations to support transparency in the video/mp4 object. However, background color is black which should avoid problems in this case (video-broadcast test is not black). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.1.2: the video shall be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio shall be preserved. Along the side where the video is shorter than the video/broadcast object, the video shall be centered. The area of the video plane not containing video shall be transparent. | |||
| org.hbbtv_00004000 | 2 | video/broadcast keeps aspect ratio | video/broadcast object displays video with correct aspect ratio and letterboxing. Note: this may lead to problems, as it is quite complicated for many platforms/implementations to support transparency in the video/broadcast object. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.1.2: the video shall be scaled such that one side of the video fills the video/broadcast object fully without cropping the picture. The aspect ratio shall be preserved. Along the side where the video is shorter than the video/broadcast object, the video shall be centered. The area of the video plane not containing video shall be transparent. | |||
| org.hbbtv_00005010 | 4 | MetadataSearch - addChannelConstraint() - Channel constraint with single channel | When passing a Channel object to addChannelConstraint() on the MetadataSearch object, the terminal shall constrain query-based searches to that channel | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Metadata APIs OIPF-DAE,section 7.12.2.2: void addChannelConstraint( Channel channel ) Constrain the search to only include results from the specified channel. ... | |||
| org.hbbtv_00005020 | 4 | MetadataSearch - addChannelConstraint() - Clearing channel constraints when no constraints have been set | When passing null to addChannelConstraint() on the MetadataSearch object when no channel constraints have been set, the terminal shall continue to constrain query-based searches to all channels | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: OIPF DAE Specification Profile: Access to EIT Schedule Information OIPF-DAE,section 7.12.2.2: void addChannelConstraint( Channel channels ) [...] If the value of this argument is null, any existing channel constraint SHALL be removed. | |||
| org.hbbtv_00007009 | 1 | DASH: playing state of A/V Control object. | The A/V control has transitioned to playing state due to the play() method on DASH content. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: In order to play the content, the terminal shall fetch the MPD from the URL, interpret the MPD and select an initial set of representations. OIPF-DAE,section 7.14.1.1: Figure 18: State diagram for embedded A/V Control objects | |||
| org.hbbtv_00007040 | 4 | MetadataSearch - createQuery() - 'startTime' field - Comparison: Greater than | The terminal shall be able to generate a metadata query specifying that the programme's 'startTime' field is greater than a specified value when the createQuery() method is called from the MetadataSearch object | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Metadata APIs OIPF-DAE,section 7.12.2.2: Query createQuery( String field, Integer comparison, String value ) Create a metadata query for a specific value in a specific field within the metadata. ... Arguments - comparison - 2 True if the value of the specified field is greater than the specified value. | |||
| org.hbbtv_00007050 | 4 | MetadataSearch - createQuery() - 'Programme.startTime' field - Comparison: Greater than or equal to | The terminal shall be able to generate a metadata query specifying that the programme's 'startTime' field is greater than or equal to a specified value when the createQuery() method is called from the MetadataSearch object | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Metadata APIs OIPF-DAE,section 7.12.2.2: Query createQuery( String field, Integer comparison, String value ) Create a metadata query for a specific value in a specific field within the metadata. ... Arguments - comparison - 3: True if the value of the specified field is greater than or equal to the specified value. | |||
| org.hbbtv_00007060 | 4 | MetadataSearch - createQuery() - 'startTime' field - Comparison: Less than | The terminal shall be able to generate a metadata query specifying that the programme's 'startTime' field is less than a specified value when the createQuery() method is called from the MetadataSearch object | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Metadata APIs OIPF-DAE,section 7.12.2.2: Query createQuery( String field, Integer comparison, String value ) Create a metadata query for a specific value in a specific field within the metadata. ... Arguments - comparison - 4: True if the value of the specified field is less than the specified value. | |||
| org.hbbtv_00007070 | 4 | MetadataSearch - createQuery() - 'startTime' field - Comparison: Less than or equal to | The terminal shall be able to generate a metadata query specifying that the programme's 'startTime' field is less than or equal to a specified value when the createQuery() method is called from the MetadataSearch object | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Metadata APIs OIPF-DAE,section 7.12.2.2: Query createQuery( String field, Integer comparison, String value ) Create a metadata query for a specific value in a specific field within the metadata. ... Arguments - comparison - 5: True if the value of the specified field is less than or equal to the specified value. | |||
| org.hbbtv_00007120 | 1 | DASH: buffering state of A/V Control | The A/V Control has transitioned to the buffering state from connecting state due to play() method on DASH content. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: In order to play the content, the terminal shall fetch the MPD from the URL, interpret the MPD and select an initial set of representations. OIPF-DAE,section 7.14.1.1: Figure 18: State diagram for embedded A/V Control objects OIPF-DAE,section B.5: 4 - buffering; the buffer is being filled in order to have sufficient data available to initiate or continue playback. | |||
| org.hbbtv_00007121 | 3 | DASH: MPD file size 100 kB | The terminal correctly handles MPEG DASH MPD file with size 100 kbytes and plays content defined in it. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: In order to play the content, the terminal shall fetch the MPD from the URL, interpret the MPD and select an initial set of representations. HBBTV,section E.2.1: the size of a MPD shall not exceed 100 kbytes OIPF-DAE,section 7.14.1.1: Figure 18: State diagram for embedded A/V Control objects | ||
| org.hbbtv_00007122 | 1 | Terminal plays MPEG DASH video segment files that are fifteen seconds long. | The A/V Control has played DASH content that contains fifteen seconds length segments. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: In order to play the content, the terminal shall fetch the MPD from the URL, interpret the MPD and select an initial set of representations. HBBTV,section E.3.2: Each video Segment shall have a duration of not more than fifteen seconds. OIPF-DAE,section 7.14.1.1: Figure 18: State diagram for embedded A/V Control objects | |||
| org.hbbtv_00007124 | 1 | Terminal plays last MPEG DASH video fragment that is shorter than 1 second. | A/V Control displays correct DASH video when last segment is shorter than one second. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: In order to play the content, the terminal shall fetch the MPD from the URL, interpret the MPD and select an initial set of representations. HBBTV,section E.3.2: Segments shall be at least 1s long, except for the last segment in an MPD which may be shorter. OIPF-DAE,section 7.14.1.1: Figure 18: State diagram for embedded A/V Control objects | |||
| org.hbbtv_00007181 | 1 | DASH, change dimensions of A/V player | Terminal shall correctly play DASH content when video player layer dimensions change from 1/4 x 1/4 of logical video plane to fullscreen. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 10.2.1: Terminal shall be able to scale video down to 1/4 of the width and height of the logical video plane. OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects | |||
| org.hbbtv_00007201 | 1 | DASH: maximum number of Adaptation Sets (16). | Terminal supports the mpd with maximum number of Adaptation Sets (16) in the period. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] . HBBTV,section E.2.2: Maximum numeric requirements on HbbTV ISOBMFF Live MPD OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects | |||
| org.hbbtv_00007236 | 1 | hasCapability method returns +DRM string for terminal supporting DRM feature | A terminal that supports the DRM feature must indicate this by returning the option string "+DRM" by hasCapability method. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.4: Hybrid Broadcast Broadband TV reported capabilities and option strings | +DRM | ||
| org.hbbtv_00007354 | 1 | DASH: XML validation error (updated mpd) | A/V control object shall switch play state to 6 - 'error' with error value 4 - 'content corrupt or invalid' if updated mpd is invalid. The playback starts with correct mpd file. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: If at any time the MPD is found to be not valid according to the XML schema or semantics defined in DASH [29], the A/V control object shall go to play state 6 ('error') with error value 4 ('content corrupt or invalid'). | |||
| org.hbbtv_00007374 | 1 | DASH: update with overlapping Periods. | Dynamic mpd file contains one period only, after updating second period is available. Second period @start attribute points to the end time of the first period. Terminal shall start playing the second Period. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] HBBTV,section E: Profiles of MPEG DASH DASH,section 4.3: DASH data model overview DASH,section 5.3.2: Period | |||
| org.hbbtv_00007375 | 1 | DASH: update with non-overlapping Periods. | Dynamic mpd file contains one period only, it have set @duration attribute. After updating second period without start time is available. Terminal shall start playing the second Period. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] HBBTV,section E: Profiles of MPEG DASH DASH,section 4.3: DASH data model overview DASH,section 5.3.2: Period | |||
| org.hbbtv_00007377 | 1 | DASH: update baseURL on MPD level. | Terminal should change request address, when baseURL is updated on MPD level. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] HBBTV,section E: Profiles of MPEG DASH DASH,section 5.6: Base URL Processing | |||
| org.hbbtv_00007378 | 1 | DASH: update of SegmentTimeline on AdaptationSet level. | After MPD update, terminal shall play MPD with SegmentTimeline inside SegmentTemplate on AdaptationSet level | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] HBBTV,section E: Profiles of MPEG DASH DASH,section 5.3.9.4.4: Template-based Segment URL construction DASH,section 5.3.9.6.2: Table 17 — Semantics of SegmentTimeline element | |||
| org.hbbtv_00007402 | 1 | DASH: BaseURL at the Adaptation Set, SegmentTemplates at Representation. | BaseURL defined at the Adaptation Set level and segments described by SegmentTemplates in Representation Level. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] HBBTV,section E: Profiles of MPEG DASH DASH,section 5.6.4: Reference resolution DASH,section 5.3.9: Segments and Segment information DASH,section 5.3.9.4.4: Template-based Segment URL construction | |||
| org.hbbtv_00007403 | 1 | DASH: BaseURL at the MPD level, SegmentTemplates in Adaptation Set. | Terminal shall present content when BaseURL is defined at the MPD level and segments are described by SegmentTemplates at Adaptation Set level. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] HBBTV,section E: Profiles of MPEG DASH DASH,section 5.6.4: Reference resolution DASH,section 5.3.9.1: The elements SegmentBase, SegmentTemplate and SegmentList may be present in the Representation element itself. In addition, to express default values, they may be present in the Period and AdaptationSet element. | |||
| org.hbbtv_00008000 | 4 | MetadataSearch - findProgrammesFromStream() - Scheduled programmes in the current channel after and including the current programme | When the findProgrammesFromStream() method is called from the application/oipfSearchManager with the channel specified as the current channel and the startTime specified as null; the terminal shall return results for all programmes on the current service after the current time when the getResults() method is called. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Metadata APIs OIPF-DAE,section 7.12.2.2: void findProgrammesFromStream( Channel channel, Integer startTime, Integer count ) Retrieve guide data for a specified number of programmes from a given channel from metadata contained in the stream as defined in section 4.1.3 of [META]. Searches made using this method will implicitly remove any existing constraints, ordering or queries created by prior calls to methods on this object. | |||
| org.hbbtv_00008010 | 4 | MetadataSearch - findProgrammesFromStream() - Scheduled programmes from a different channel after and including the current programme | When the findProgrammesFromStream() method is called from the application/oipfSearchManager with the channel specified as a channel other than the current channel and the startTime specified as null; the terminal shall return results for all programmes on the channel after and including the current programme when the getResults() method is called. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Metadata APIs OIPF-DAE,section 7.12.2.2: void findProgrammesFromStream( Channel channel, Integer startTime, Integer count ) Retrieve guide data for a specified number of programmes from a given channel from metadata contained in the stream as defined in section 4.1.3 of [META]. Searches made using this method will implicitly remove any existing constraints, ordering or queries created by prior calls to methods on this object. | |||
| org.hbbtv_00008020 | 4 | MetadataSearch - findProgrammesFromStream() - Scheduled programmes from a different channel after and including the following programme | When the findProgrammesFromStream() method is called from the application/oipfSearchManager with the channel specified as a channel other than the current channel and the startTime specified as the startTime of the following programme (UTC, expressed in seconds from Unix epoch); the terminal shall return all programmes after and including the following programme when the getResults() method is called. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Metadata APIs OIPF-DAE,section 7.12.2.2: void findProgrammesFromStream( Channel channel, Integer startTime, Integer count ) Retrieve guide data for a specified number of programmes from a given channel from metadata contained in the stream as defined in section 4.1.3 of [META]. Searches made using this method will implicitly remove any existing constraints, ordering or queries created by prior calls to methods on this object. | |||
| org.hbbtv_0000D000 | 3 | item() method in SearchResults class | The item() method of the SearchResults object shall return the item at the expected position in the collection, or undefined if no item is present at that position | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Access to EIT Schedule Information OIPF-DAE,section 7.12.4.2: Object item( Integer index ) Return the item at position index in the collection of currently available results, or undefined if no item is present at that position. ... | |||
| org.hbbtv_0000F000 | 4 | abort() method in SearchResults class | When the abort() method of a SearchResults instance is called after its getResults() method is called, its 'length' property shall equal 0 and the item() method shall return undefined when its 'index' parameter is specified as 0 | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Access to EIT Schedule Information OIPF-DAE,section 7.12.4.2: void abort() Abort any outstanding request for results. Items currently in the collection SHALL be removed (i.e. the value of the length property SHALL be 0 and any calls to item() SHALL return undefined). | |||
| org.hbbtv_0000G000 | 3 | setQuery() in MetadataSearch class | When a MetadataSearch object's setQuery() method is called with its 'query' parameter set to a Query object, no exception shall be thrown | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Metadata APIs OIPF-DAE,section 7.12.2.2: void setQuery( Query query ). Description : Set the query terms to be used for this search, discarding any previously-set query terms. | |||
| org.hbbtv_0000G001 | 3 | setQuery(Query) - Transition from 'Found' to 'Idle' State | After the setQuery() method is called on the MetadataSearch object while it is in the search state 'Found', the 'length' property of the associated SearchResults object shall be equal to 0 | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Access to EIT Schedule Information OIPF-DAE,section 7.12.2: Table 11 - State: Idle - [...] any calls to SearchResults.item() SHALL return undefined and the values of the length and totalSize properties on the SearchResults object SHALL return zero. [...] State: Found - Any modification of the search parameters (e.g. changing the query [...]) by the application SHALL cause the current set of results to be discarded and SHALL cause a transition to the Idle state. [...] | |||
| org.hbbtv_0000G002 | 3 | setQuery(Query) - Abort event when in 'Found' state | When a search has completed and the MetadataSearch object is in the search state 'Found', calling the setQuery() method with its 'query' argument specified as a Query object shall cause a 'MetadataSearch' event with its 'state' context equal to 3 to be dispatched | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Metadata APIs OIPF-DAE,section 7.12.2: Table 11: Metadata search states (normative) State Found: [...] Any modification of the search parameters (e.g. changing the query or adding/removing constraints, or calling findProgrammesFromStream()) by the application SHALL cause the current set of results to be discarded and SHALL cause a transition to the Idle state. The terminal SHALL dispatch a MetadataSearch event with state=3. | |||
| org.hbbtv_00013000 | 3 | ChannelConfig object in application/oipfSearchManager object | Terminal shall be able to create a ChannelConfig object when the getChannelConfig() method is called on the application/oipfSearchManager object and its 'channelList' property shall contain all expected channels | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: ChannelConfig object - 7.13.9, M(*) - The channelList property shall be supported. Other properties and methods are not included. ... OIPF-DAE,section 7.12.1.2: ChannelConfig getChannelConfig() - Returns the channel line-up of the tuner in the form of a ChannelConfig object as defined in Section 7.13.9. This includes the favourite lists. ... OIPF-DAE,section 7.13.10: The ChannelList object represents a list of channels. ... OIPF-DAE,section 7.13.9.1: readonly ChannelList channelList - The list of channels. - If an OITF includes a platform-specific application that enables the end-user to choose a channel to be presented from a list then all the channels in the list offered to the user by that application SHALL be included in this ChannelList. ... | |||
| org.hbbtv_00020041 | 1 | The Window object supports close() method. | The terminal shall support the window.close() method. close() is equivalent to calling method destroyApplication(). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML OIPF-DAE,section B: close(): calling this method on the Window object of a DAE application SHALL be equivalent to calling method destroyApplication() of the DAE application | |||
| org.hbbtv_00020042 | 1 | The Window object supports debug() method. | The terminal shall support the window.debug() method. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML OIPF-DAE,section 7.15.5: Debug print API | |||
| org.hbbtv_00021000 | 1 | Test for on-demand support of AVC - 1280 x 720 px MP4 - with moov box size = 2.5 Mb | The terminal shall correctly present an AVC encoded video file with a moov box size of 2.5 MB | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 4.2: MP4 File Format [...] For services that allow the real-time playback of downloaded content before the download has been completed (e.g. Progressive Download), the following additional constraints apply: * The moov and moof boxes SHALL be used according to section 9.4.4;3;10 of [DLNAMEDIA]. [...] In addition, carriage of H.264/AVC content in the MP4 systems layer SHALL be conformant to the AVC File Format standard [AVCFF]. HBBTV,section 7.3.1.2: Systems layers The MP4 File Format shall comply with clause 4 of the OIPF Media Formats specification [2] and the following additions: [...] * The size of the moov box should not exceed 2,5 MByte HBBTV,section 7.3.1.3: Video The video format AVC_SD_25 shall comply with clauses 5.1.2.1 and 5.1.3 of the OIPF Media Formats specification [2]. | |||
| org.hbbtv_00021010 | 2 | A/V Control object - HTTP chunked transfer coding | The terminal shall be able to present A/V content which is served using HTTP chunked transfer coding | 2024-2 2024-1 2023-3 2023-2 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP chunked transfer coding shall be supported as defined by section 3.6.1 of RFC 2616 [6] | |||
| org.hbbtv_00021011 | 2 | Video Object - HTTP chunked transfer coding | The terminal shall be able to present HTML5 video content which is served using HTTP chunked transfer coding | 2024-2 2024-1 2023-3 2023-2 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2018-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP chunked transfer coding shall be supported as defined by section 3.6.1 of IETF RFC 2616 [6] | |||
| org.hbbtv_00021020 | 1 | HTTP Status Code 302 (Found) - MP4 AVC | When an HTTP request is initiated by the A/V Control object and an HTTP response with status code 302 (found) and content type 'video/mp4' is received, the terminal shall then correctly present the MP4 AVC file referenced by the URL in the 'Location' field of the HTTP response | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.5: HTTP redirects as defined in [HTTP] in response to a HTTP request shall be supported as described in this clause. - The terminal shall support responses with a status code of "302 Found" [...] by using the temporary URL given in the Location field. - The terminal shall support at least one redirection. | |||
| org.hbbtv_00021030 | 1 | HTTP Status Code 307 (Temporary Redirect) - MP4 AVC file | When an HTTP request is initiated by the A/V Control object and an HTTP response with status code 307 (temporary redirect) and content type 'video/mp4' is received, the terminal shall then correctly present the MP4 AVC file referenced by the URL in the 'Location' field of the HTTP response | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.5: HTTP redirects as defined in [HTTP] in response to a HTTP request shall be supported as described in this clause. - The terminal shall support responses with a status code of [...] "307 Temporary Redirect" by using the temporary URL given in the Location field. - The terminal shall support at least one redirection. | |||
| org.hbbtv_00027213 | 1 | DASH video transitions: profile and level, over Period boundaries. | Terminal supports video transitions between DASH Representations which differ by profile and level during during playback over Period boundaries. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] . HBBTV,section E.4.2.1: During playback of adaptively streamed content encoded using AVC, terminals shall support transitions between video Representations as follows: [...] Between Representations which differ by profile and/or level | |||
| org.hbbtv_00027215 | 1 | DASH video transitions: full-screen resolution (high to low), over Period boundaries. | Terminal supports video transitions between DASH Representations which differ by full-screen resolution (from high resolution to low resolution) during playback over Period boundaries. During transition video does not contain artifacts or picture corruption. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] . HBBTV,section E.4.2.1: During playback of adaptively streamed content encoded using AVC, terminals shall support transitions between video Representations as follows: [...] Between Representations which differ by full-screen resolution (e.g. 1 920 × 1 080 and 720 × 576) | |||
| org.hbbtv_00027216 | 1 | DASH video transitions: full-screen resolution (low to high ), over Period boundaries. | Terminal supports video transitions between DASH Representations which differ by full-screen resolution (from low resolution to high resolution) during playback over Period boundaries. During transition video does not contain artifacts or picture corruption. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] . HBBTV,section E.4.2.1: During playback of adaptively streamed content encoded using AVC, terminals shall support transitions between video Representations as follows: [...] Between Representations which differ by full-screen resolution (e.g. 1 920 × 1 080 and 720 × 576) | |||
| org.hbbtv_00027223 | 1 | DASH video transitions: bitrate - low to high, over Period boundaries. | Terminal supports video transitions between DASH Representations which differ by bitrate, from low bitrate to high bitrate during playback over Period boundaries. During transition video does not contain artifacts or picture corruption. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] . HBBTV,section E.4.2.1: During playback of adaptively streamed content encoded using AVC, terminals shall support transitions between video Representations as follows: 1) Between Representations which differ by bit-rate | |||
| org.hbbtv_00027224 | 1 | Terminal supports video transitions between MPEG DASH Representations which differ by bitrate, from high bitrate to low bitrate during playback over Period boundaries. | Terminal supports video transitions between DASH Representations which differ by bitrate, from high bitrate to low bitrate during playback over Period boundaries. During transition video does not contain artifacts or picture corruption. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] . HBBTV,section E.4.2.1: During playback of adaptively streamed content encoded using AVC, terminals shall support transitions between video Representations as follows: 1) Between Representations which differ by bit-rate | |||
| org.hbbtv_02003101 | 1 | The Window object supports "document" property. | The terminal shall support the window.document property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003102 | 1 | The Window object supports "frames" property. | The terminal shall support the window.frames property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003103 | 1 | The Window object supports "history" property | The terminal shall support the window.history property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003104 | 1 | The Window object supports "innerHeight" and "innerWidth" properties | The terminal shall support the window.innerHeight and window.innerWidth properties. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 4.4.6: Use of the display OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003105 | 1 | The Window object supports "location" property | The terminal shall support the window.location property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003107 | 1 | The Window object supports "name" property | The terminal shall support the window.name property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003108 | 1 | The Window object supports "navigator" property | The terminal shall support the window.navigator property. The userAgent indicates HbbTV marker. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.4: HTTP User-Agent header HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML OIPF-DAE,section 8.1.1: HTTP User-Agent header | |||
| org.hbbtv_02003109 | 1 | The Window object supports "oipfObjectFactory" property | The terminal shall support the window.oipfObjectFactory property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML OIPF-DAE,section 7.1: Object factory API | |||
| org.hbbtv_02003111 | 1 | The Window object supports "onkeydown", "onkeyup" and "onkeypress" properties | The terminal shall support the properties: window.onkeydown, window.onkeyup and window.onkeypress. The sequence of events triggering shall be correct. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003112 | 1 | The Window object supports "parent" property | The terminal shall support the window.parent property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003114 | 1 | The Window object supports "self" property | The terminal shall support the window.self property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003115 | 1 | The Window object supports "top" property | The terminal shall support the window.top property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003116 | 1 | The Window object supports "XMLHttpRequest" property | The terminal shall support the window.XMLHttpRequest property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML CEA2014A,section 5.5.2: XMLHttpRequest Scripting Object | |||
| org.hbbtv_02003117 | 1 | The Window object supports setTimeout() method. | The terminal shall support the window.setTimeout() method. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003118 | 1 | The Window object supports setInterval() method. | The terminal shall support the window.setInterval() method. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003119 | 1 | The Window object supports clearTimeout() method. | The terminal shall support the window.clearTimeout() method. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003120 | 1 | The Window object supports clearInterval() method. | The terminal shall support the window.clearInterval() method. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003121 | 1 | The Window object supports addEventListener() method. | The terminal shall support the window.addEventListener() method. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003122 | 1 | The Window object supports removeEventListener() method. | The terminal shall support the window.removeEventListener() method. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003123 | 1 | The Window object supports "onfocus" callback. | The terminal shall support the window.onfocus callback. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003124 | 1 | The Window object supports "onblur" callback. | The terminal shall support the window.onblur callback. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_02003125 | 1 | The Window object supports "frameElement" property. | The terminal shall support the window.frameElement property. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.8.1: The Window object OIPF-DAE,section 6.1: CE-HTML | |||
| org.hbbtv_A11Y_0010 | 1 | Accessibility JSON-RPC capability negotiation | A newly started application is connected to the JSON-RPC WSS server but has not yet negotiated any capabilities. The application incrementally negotiates the Accessibility capabilities using valid and correctly formed org.hbbtv.negotiateMethods request messages, confirming each capability is added in turn by inspecting the responses to ensure that each capability has been added. All the request messages listed below are dispatched in the following order and each request is only sent after the response to a previous request has been received. The following appToTerminal capabilities are incrementally negotiated and successfully confirmed by inspection of a valid and correct org.hbbtv.negotiateMethods response message. - org.hbbtv.af.featureSupportInfo - org.hbbtv.af.featureSuppress - org.hbbtv.af.featureSettingsQuery - org.hbbtv.subscribe - org.hbbtv.unsubscribe The following terminalToApp capabilities are then negotiated in a single org.hbbtv.negotiateMethods request message and are successfully confirmed by inspecting the valid and correctly formed org.hbbtv.negotiateMethods response message: - org.hbbtv.negotiateMethods - org.hbbtv.notify | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.2.2.1.1: Terminals shall: - provide a JSON-RPC WebSocket server as defined in clause 9.9.2 | |||
| org.hbbtv_A11Y_0020 | 1 | Accessibility Framework Feature Query | An application is connected to the JSON-RPC WSS server, and negotiates the capability for the org.hbbtv.af.featureSettingsQuery, org.hbbtv.af.featureSuppress and org.hbbtv.af.featureSupportInfo methods. The application to queries the terminals accessibility feature support by issuing a sequence of org.hbbtv.af.featureSupportInfo request messages to the terminal, with the following feature queries: - subtitles - dialogueEnhancement - uiMagnifier - highContrast - screenReader - responseToUserAction - audioDescription - inVisionSigning The responses are recorded for later comparison with the declared "support level" in the manufacturer supplied Accessibility Result Declaration. Then the application requests to suppress the same features by issuing a sequence of org.hbbtv.af.featureSuppress request messages to the terminal. The responses are recorded for consistency checking and later comparison with the declared "support response" in the manufacturer supplied Accessibility Result Declaration. Then the application requests feature setting information for all the same features by issuing a sequence of org.hbbtv.af.featureSettingsQuery request messages to the terminal. The responses are recorded for consistency checking and later comparison with the declared "settings query info" in the manufacturer supplied Accessibilty Result Declaration. The consistency checks are performed successfully on a per feature basis. These are for checking that responses are consistent with other responses for other message types for the same feature. The comparison with the manufacturer supplied Accessibility Result Declaration is a match. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1 - support the org.hbbtv.af.featureSuppress API defined in clause 15.2.2.2 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.1.1: For an application to determine what level of support a TV OS has for a particular Accessibility Feature, a JSON-RPC message with the method name org.hbbtv.af.featureSupportInfo API shall be used. ... Only a single feature support information request can be made at any one time. HBBTV,section 15.2.2.1.2: The value parameter of a non-error JSON-RPC response message shall contain any one of the following results codes: Results code String ... "notSupported" ... "tvosSettingOnly" ... "tvosOnly" ... "tvosAndHbbTV" ... "supportedNoSetting" ... HBBTV,section 15.2.2.2.2: Terminals responses shall be consistent with previous responses to org.hbbtv.af.featureSupportInfo messages for the corresponding feature. Responses containing "suppressing" or "notSuppressing" are only valid when a terminals most recent response to an org.hbbtv.af.featureSupportInfo request for the corresponding feature was "tvosAndHbbTV" or "supportedNoSetting". Responses containing "featureNotSupported" are only valid when a terminals most recent response to an org.hbbtv.af.featureSupportInfo request for the corresponding feature was "notSupported", "tvosOnly", or "tvosSettingOnly". HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. | |||
| org.hbbtv_A11Y_0030 | 1 | Accessibility Settings Change Notifications | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.subscribe and org.hbbtv.notify messages and registers for all notifications using the org.hbbtv.subscribe API for each of the Accessibility features defined by the msgType list from Table 10d. For all Accessibility features that expose settings to the user (declared as "Setting supported" and "survives" in the manufacturer supplied Accessibility Result Declaration), the tester changes a corresponding setting for that feature which the application records if any corresponding notification is subsequently received (i.e. reception of correctly formed org.hbbtv.notify messages that correspond the modified setting). The comparison of the recorded notifications with the manufacturer supplied Accessibility Result Declaration is consistent. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.4.3: HbbTV terminals shall support the Subscribe Request API as defined in ATSC A/344 [95] clause 9.3.1.1, with the following modifications defined in this clause. ... HBBTV,section 15.2.2.4: In addition to the JSON-RPC Request message enabling HbbTV applications to query individual TV OS Accessibility Feature settings, terminals shall, under certain defined conditions, send feature specific notifications to the HbbTV application to reflect a change to the setting. Each individual accessibility feature defines its own user Setting Change notification message, specific to each accessibility feature. See clauses 15.3.2 to 15.3.9. HBBTV,section 15.3.1: This version of the HbbTV specification has support for managing the following Accessibility Features, depending on the TV OS support level of the feature. All the features below can be used with the Accessibility Framework defined in 15.2.2.1 – 15.2.2.4. Table 31 – List of Accessibility Features and their JSON Feature String Name HBBTV,section 15.3.2.3: This clause defines a message that may be sent from a terminal to an HbbTV application. This message shall be sent from a terminal to an HbbTV application if all the following conditions are true: - A user setting changes that affects the Subtitle or Captions settings has been made on the terminal - The application has registered for notifications of this type HBBTV,section 15.3.3.3: This clause defines a message that may be sent from a terminal to an HbbTV application. This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: - The application has registered for notifications of this type; and - One or more of the following events have occurred: - The user sets a new gain for Dialogue Enhancement on the terminal - The user enables/disables Dialogue Enhancement entirely HBBTV,section 15.3.4.3: This clause defines a message that may be sent from a terminal to an HbbTV application. This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: - A user setting change that affects the UI Magnification settings has been made on the terminal - The application has registered for notifications of this type HBBTV,section 15.3.5.3: This clause defines a message that may be sent from a terminal to an HbbTV application. This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: - A user setting change that affects the High Contrast UI settings has been made on the terminal - The application has registered for notifications of this type HBBTV,section 15.3.6.3: This clause defines a message that may be sent from a terminal to an HbbTV application. This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: - A user setting change that affects the Screen Reader settings has been made on the terminal - The application has registered for notifications of this type HBBTV,section 15.3.7.3: This clause defines a message that may be sent from a terminal to an HbbTV application. This message shall be sent from a terminal to an HbbTV application if all the following conditions are true: - A user setting change that affects the ‘Response to a User Action’ setting has been made on the terminal - The application has registered for notifications of this type HBBTV,section 15.3.8.3: This clause defines a message that may be sent from a terminal to an HbbTV application. This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: - The application has registered for notifications of this type - One or more of the following events have occurred: - The user enables/disables Audio Description entirely. - The user sets a new value for one of the following fields: “gainPreference”, or “panAzimuthPreference” HBBTV,section 15.3.9.3: This clause defines a message that may be sent from a terminal to an HbbTV application. This message shall be sent from a terminal to an HbbTV application if all the following conditions are true: - A user setting change that affects the In Vision Signing settings has been made on the terminal - The application has registered for notifications of this type | |||
| org.hbbtv_A11YAD0030 | 1 | Verifying the Audio Description Preference Change Message for enabling Audio Description | The application queries the org.hbbtv.af.featureSettingsQuery API with feature="audioDescription". The response message shall have the value set to '"enabled" : false' for the "audioDescription" feature. The application is subscribed to receive Audio Description Preference Change Messages. When enabling the Audio Description in the TV OS settings, the application shall receive an Audio Description Preference Change Message with the value set to '"enabled" : true' for the "audioDescriptionPrefChange" msgType. Each response message shall conform with the respective schema. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 15.3.8.1: The TV settings relating to the Audio Description feature that can be communicated to an HbbTV application using the response and notification messages are described in clauses 15.3.8.2 and 15.3.8.3. HBBTV,section 15.3.8.2: Table 40 below describes the variable parameters of value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "audioDescription". Parameter | Data Type | Mandatory (M) or Optional (O) | Valid Values | Description "enabled" | Boolean | M | true of false | If the user has enabled Audio Description in their TV OS settings, then this parameter shall be set to true. [...] HBBTV,section 15.3.8.3: This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: • The application has registered for notifications of this type • One or more of the following events have occurred: o The user enables/disables Audio Description entirely. • The user sets a new value for one of the following fields: “gainPreference”, or “panAzimuthPreference”. [...] HBBTV,section N: • response__org.hbbtv.af.featureSettingsQuery.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of audioDescription, as referred to in clause 15.3.8.2 of the present document. • notification__org.hbbtv.af.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC notification with method name org.hbbtv.notify and a msgType of audioDescriptionPrefChange, as referred to in clause 15.3.8.3 of the present document. | |||
| org.hbbtv_A11YAD0040 | 1 | Verifying the Audio Description Preference Change Message for disabling Audio Description | The application queries the org.hbbtv.af.featureSettingsQuery API with feature="audioDescription". The response message shall have the value set to '"enabled" : true' for the "audioDescription" feature. The application is subscribed to receive Audio Description Preference Change Messages. When disabling the Audio Description in the TV OS settings, the application shall receive an Audio Description Preference Change Message with the value set to '"enabled" : false' for the "audioDescriptionPrefChange" msgType. Each response message shall conform with the respective schema. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 15.3.8.1: The TV settings relating to the Audio Description feature that can be communicated to an HbbTV application using the response and notification messages are described in clauses 15.3.8.2 and 15.3.8.3. HBBTV,section 15.3.8.2: Table 40 below describes the variable parameters of value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "audioDescription". Parameter | Data Type | Mandatory (M) or Optional (O) | Valid Values | Description "enabled" | Boolean | M | true of false | If the user has enabled Audio Description in their TV OS settings, then this parameter shall be set to true. [...] HBBTV,section 15.3.8.3: This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: • The application has registered for notifications of this type • One or more of the following events have occurred: o The user enables/disables Audio Description entirely. • The user sets a new value for one of the following fields: “gainPreference”, or “panAzimuthPreference”. [...] HBBTV,section N: • response__org.hbbtv.af.featureSettingsQuery.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of audioDescription, as referred to in clause 15.3.8.2 of the present document. • notification__org.hbbtv.af.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC notification with method name org.hbbtv.notify and a msgType of audioDescriptionPrefChange, as referred to in clause 15.3.8.3 of the present document. | |||
| org.hbbtv_A11YAD0050 | 1 | Verifying the Audio Description Preference Change Message for the Gain Preference | The application queries the org.hbbtv.af.featureSettingsQuery API with feature="audioDescription". The response message shall also include the "gainPreference" field. The application is subscribed to receive Audio Description Preference Change Messages. When changing the "gainPreference" of the Audio Description in the TV OS settings to the minimal posible value, the application shall receive an Audio Description Preference Change Message. The "gainPreference" field of the "value" field shall be now set to a lower value compared to the previous recorded value. Each response message shall conform with the respective schema. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 15.3.8.1: The TV settings relating to the Audio Description feature that can be communicated to an HbbTV application using the response and notification messages are described in clauses 15.3.8.2 and 15.3.8.3. HBBTV,section 15.3.8.2: Table 40 below describes the variable parameters of value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "audioDescription". Parameter | Data Type | Mandatory (M) or Optional (O) | Valid Values | Description "enabled" | Boolean | M | true of false | If the user has enabled Audio Description in their TV OS settings, then this parameter shall be set to true. [...] “gainPreference” | Integer | O (see note) | The “gainPreference” value describes the Audio Description gain preference set by the user in dB. [...] HBBTV,section 15.3.8.3: This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: • The application has registered for notifications of this type • One or more of the following events have occurred: o The user enables/disables Audio Description entirely. • The user sets a new value for one of the following fields: “gainPreference”, or “panAzimuthPreference”. [...] HBBTV,section N: • response__org.hbbtv.af.featureSettingsQuery.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of audioDescription, as referred to in clause 15.3.8.2 of the present document. • notification__org.hbbtv.af.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC notification with method name org.hbbtv.notify and a msgType of audioDescriptionPrefChange, as referred to in clause 15.3.8.3 of the present document. | |||
| org.hbbtv_A11YAD0060 | 1 | Verifying the Audio Description Preference Change Message for the Pan Azimuth Preference | The application queries the org.hbbtv.af.featureSettingsQuery API with feature="audioDescription". The response message shall have the "panAzimuthPreference" field. The application is subscribed to receive Audio Description Preference Change Messages. When changing the "panAzimuthPreference" of the Audio Description in the TV OS settings to "right", the application shall receive an Audio Description Preference Change Message. The "panAzimuthPreference" field of the "value" field shall be now set to a lower value compared to the previous recorded value. Each response message shall conform with the respective schema. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 15.3.8.1: The TV settings relating to the Audio Description feature that can be communicated to an HbbTV application using the response and notification messages are described in clauses 15.3.8.2 and 15.3.8.3. HBBTV,section 15.3.8.2: Table 40 below describes the variable parameters of value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "audioDescription". Parameter | Data Type | Mandatory (M) or Optional (O) | Valid Values | Description "enabled" | Boolean | M | true of false | If the user has enabled Audio Description in their TV OS settings, then this parameter shall be set to true. [...] “panAzimuthPreference” | Integer | O (see note) | −180 to + 180 | The “panAzimuthPreference” value describes the Audio Description azimuth pan preference set by the user in degrees. [...] HBBTV,section 15.3.8.3: This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: • The application has registered for notifications of this type • One or more of the following events have occurred: o The user enables/disables Audio Description entirely. • The user sets a new value for one of the following fields: “gainPreference”, or “panAzimuthPreference”. [...] HBBTV,section N: • response__org.hbbtv.af.featureSettingsQuery.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of audioDescription, as referred to in clause 15.3.8.2 of the present document. • notification__org.hbbtv.af.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC notification with method name org.hbbtv.notify and a msgType of audioDescriptionPrefChange, as referred to in clause 15.3.8.3 of the present document. | |||
| org.hbbtv_A11YDE0010 | 1 | DE - negotiateMethods response message reflects dialogueEnhancement API support | A newly started application is connected to the JSON-RPC WSS server but has not yet negotiated any capabilities. The application sends a org.hbbtv.negotiateMethods JSON-RPC request to the terminal that includes "org.hbbtv.af.dialogueEnhancementOverride" in the "appToTerminal" array. A valid and correct org.hbbtv.negotiateMethods response message is received that also contains "org.hbbtv.af.dialogueEnhancementOverride" in the "appToTerminal" array. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list | |||
| org.hbbtv_A11YDE0011 | 1 | DE - negotiateMethods response message reflects non existant dialogueEnhancement API support | A newly started application is connected to the JSON-RPC WSS server but has not yet negotiated any capabilities. The application sends a org.hbbtv.negotiateMethods JSON-RPC request to the terminal that includes "org.hbbtv.af.dialogueEnhancementOverride" in the "appToTerminal" array. A valid and correct org.hbbtv.negotiateMethods response message is received that does not contain "org.hbbtv.af.dialogueEnhancementOverride" in the "appToTerminal" array. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list | -AC4_DE_OVERRIDE -MPEG_H_DE_OVERRIDE | ||
| org.hbbtv_A11YHCUI_0010 | 1 | Accessibility - High Contrast UI Settings Query (disabled) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. The High Contrast UI feature is successfully determined to be supported by sending an org.hbbtv.af.featureSupportInfo request message with feature field of the params object set to "highContrastUI" and confirming that the feature is supported by inspecting a valid and correct response message where the "value" field of the "result" object is set to "tvosSettingOnly", "tvosOnly" or "tvosAndHbbTV". Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "highContrastUI". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "false". | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. High Contrast UI | "highContrastUI" | N HBBTV,section 15.3.5.2: Table 36 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "highContrastUI". Table 36: High Contrast UI response message parameters ... | "enabled" | Boolean | M | true or false | If the user has enabled a high contrast UI in their TV OS settings then this parameter shall be set to true.| | "hcType" | String | O | "monochrome", "other" | ... It shall be present if the "enabled" parameter is set to "true" ... | | +HIGH_CONTRAST_UI | ||
| org.hbbtv_A11YHCUI_0020 | 1 | Accessibility - High Contrast UI Settings Query (enabled) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. The High Contrast UI feature is successfully determined to be supported by sending an org.hbbtv.af.featureSupportInfo request message with feature field of the params object set to "highContrastUI" and confirming that the feature is supported by inspecting a valid and correct response message where the "value" field of the "result" object is set to "tvosSettingOnly", "tvosOnly" or "tvosAndHbbTV". Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "highContrastUI". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "true" and an "hcType" field set to either "monochrome" or "other" depending on the High Contrast UI type described in the Accessibility Result Declaration | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. High Contrast UI | "highContrastUI" | N HBBTV,section 15.3.5.2: Table 36 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "highContrastUI". Table 36: High Contrast UI response message parameters ... | "enabled" | Boolean | M | true or false | If the user has enabled a high contrast UI in their TV OS settings then this parameter shall be set to true.| | "hcType" | String | O | "monochrome", "other" | ... It shall be present if the "enabled" parameter is set to "true" ... | | +HIGH_CONTRAST_UI | ||
| org.hbbtv_A11YIVSL_0010 | 1 | Accessibility - In-Vision Sign Language Settings Query (disabled) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. The In Vision Sign Language feature is successfully determined to be supported by sending an org.hbbtv.af.featureSupportInfo request message with feature field of the params object set to "inVisionSigning" and confirming that the feature is supported by inspecting a valid and correct response message where the "value" field of the "result" object is set to "tvosSettingOnly", "tvosOnly" or "tvosAndHbbTV". Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "inVisionSigning". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "false". | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. In Vision Sign Language | "inVisionSigning" | N HBBTV,section 15.3.9.2: Table 41 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "inVisionSigning". Table 41: In vision signing response message parameters ... | "enabled" | M | Boolean true or false | If the user has enabled an in-vision signing preference in their TV OS settings, then this parameter shall be set to true. | +IN_VISION_SIGN_LANGUAGE | ||
| org.hbbtv_A11YIVSL_0020 | 1 | Accessibility - In-Vision Sign Language Settings Query (enabled) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. The In Vision Sign Language feature is successfully determined to be supported by sending an org.hbbtv.af.featureSupportInfo request message with feature field of the params object set to "inVisionSigning" and confirming that the feature is supported by inspecting a valid and correct response message where the "value" field of the "result" object is set to "tvosSettingOnly", "tvosOnly" or "tvosAndHbbTV". Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "inVisionSigning". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "true". | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. In Vision Sign Language | "inVisionSigning" | N HBBTV,section 15.3.9.2: Table 41 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "inVisionSigning". Table 41: In vision signing response message parameters ... | "enabled" | M | Boolean true or false | If the user has enabled an in-vision signing preference in their TV OS settings, then this parameter shall be set to true. | +IN_VISION_SIGN_LANGUAGE | ||
| org.hbbtv_A11YMAG_0010 | 1 | Accessibility - Magnification Settings Query (disabled) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. The Magnification UI feature is successfully determined to be supported by sending an org.hbbtv.af.featureSupportInfo request message with feature field of the params object set to "uiMagnifier" and confirming that the feature is supported by inspecting a valid and correct response message where the "value" field of the "result" object is set to "tvosSettingOnly", "tvosOnly" or "tvosAndHbbTV". Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "uiMagnifier". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn only contains an "enabled" field set to "false" and no other fields. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. Magnification UI | "uiMagnifier" | N. HBBTV,section 15.3.4.2: Table 35 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "uiMagnifier". Table 35: UI magnification response message parameters ... | "enabled" | Boolean | M | true or falese| If the user has enabled a screen magnification UI setting in their TV OS then t his parameter shall be set to true.| | "magType" | String | O | "textMagnification", "magnifierGlass", "screenZoom", "largeLayout", "other" | ... It shall be present if the "enabled" parameter is set to true and shall not be present if the "enabled" parameter is set to false | +MAGNIFICATION_UI | ||
| org.hbbtv_A11YMAG_0020 | 1 | Accessibility - Magnification Settings Query (enabled) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. The Magnification UI feature is successfully determined to be supported by sending an org.hbbtv.af.featureSupportInfo request message with feature field of the params object set to "uiMagnifier" and confirming that the feature is supported by inspecting a valid and correct response message where the "value" field of the "result" object is set to "tvosSettingOnly", "tvosOnly" or "tvosAndHbbTV". Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "uiMagnifier". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "true" and a "magType" field set to either "textMagnification", "magnifierGlass", "screenZoom", "largeLayout" or "other" depending on the UI Magnification type described in the Accessibility Results Declaration | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. Magnification UI | "uiMagnifier" | N. HBBTV,section 15.3.4.2: Table 35 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "uiMagnifier". Table 35: UI magnification response message parameters ... | "enabled" | Boolean | M | true or falese| If the user has enabled a screen magnification UI setting in their TV OS then this parameter shall be set to true.| | "magType" | String | O | "textMagnification", "magnifierGlass", "screenZoom", "largeLayout", "other" | ... It shall be present if the "enabled" parameter is set to true and shall not be present if the "enabled" parameter is set to false ... | | +MAGNIFICATION_UI | ||
| org.hbbtv_A11YRESP2U_0010 | 1 | Accessibility - Response to User Action feature: Settings Query (disabled) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. The 'Response to a User Action' feature is successfully determined to be supported by sending an org.hbbtv.af.featureSupportInfo request message with feature field of the params object set to "responseToUserAction" and confirming that the feature is supported by inspecting a valid and correct response message where the "value" field of the "result" object is set to "tvosSettingOnly", "tvosOnly" or "tvosAndHbbTV". Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "responseToUserAction". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "false". | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. | Response to a User Action | "responseToUserAction" | Y - see 15.3.7.4 | HBBTV,section 15.3.7.2: Table 38 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "responseToUserAction". Table 38: Response to user action response message parameters ... | "enabled" | Boolean | M | Boolean true or false | If the user has enabled a "Response to a User Action" preference in their TV OS settings, then this parameter shall be set to "true". | | +RESP2USERACTION | ||
| org.hbbtv_A11YRESP2U_0020 | 1 | Accessibility - Response to User Action feature: Settings Query (enabled) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. The 'Response to a User Action' feature is successfully determined to be supported by sending an org.hbbtv.af.featureSupportInfo request message with feature field of the params object set to "responseToUserAction" and confirming that the feature is supported by inspecting a valid and correct response message where the "value" field of the "result" object is set to "tvosSettingOnly", "tvosOnly" or "tvosAndHbbTV". Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "responseToUserAction". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "true" and a "type" field set to either "audio", "visual", "haptic", "other" or "none" depending on the User Response type described in the Accessibility Results Declaration | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. | Response to a User Action | "responseToUserAction" | Y - see 15.3.7.4 | HBBTV,section 15.3.7.2: Table 38 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "responseToUserAction". Table 38: Response to user action response message parameters ... | "enabled" | Boolean | M | Boolean true or false | If the user has enabled a "Response to a User Action" preference in their TV OS settings, then this parameter shall be set to "true". | | "type" | String | O (see Note) | "audio", "visual", "haptic", "other" or "none" | This parameter describes ... | ... NOTE: If the "enabled" value is set to true, then the "type" field shall be present. | +RESP2USERACTION | ||
| org.hbbtv_A11YRESP2U_0050 | 1 | Accessibility Response to a User Action Behaviour | An application is connected to the JSON-RPC Websocket Server and successfully confirms that org.hbbtv.af.triggerResponseToUserAction and org.hbbtv.af.featureSettingsQuery request messages from appToTerminal are supported using the org.hbbtv.negotiateMethods API. The application sends an org.hbbtv.af.featureSettingsQuery for the 'responseToUserAction' feature and informs the tester of the value of the response 'type' parameter. The application sends a sequence of org.hbbtv.af.triggerResponseToUserAction request messages to the terminal for each of the three magnitude parameter values "triggerPrimary", "triggerSecondary" and "triggerException", with a 5 second interval between each response message and each new request. Correctly formed org.hbbtv.af.triggerResponseToUserAction response messages are received for each of the requests. The tester confirms that the responses from the terminal are 100% consistent with the indicated response type and magnitude against the descriptions provided in the Accessibility Result Declaration | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.3.7.2: Table 38 below describes the variable parameters of value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "responseToUserAction". - Valid Values for "type" parameter : "audio", "visual", "haptic", "other" or "none" - Description for "type" parameter : This parameter describes the type of mechanism the terminal uses to feedback to the user that the user action has occurred. A terminal should try to match to one of these values as closely as possible, but if it cannot, then the value "other" may be used. If a terminal is providing multiple types of feedback then a terminal shall select a value that matches one of them and should choose the most important to the user if that is known. The value "none" may be sent from the terminal in the case where a user has indicated in interest in getting a user response, but the TV terminal itself does not support any mechanism to realise the API defined in 15.3.7.4 HBBTV,section 15.3.7.4: The triggerResponseToUserAction request message should only be sent if the feature is required by the user i.e., if the terminal has indicated (by way of the most recent response defined in 15.3.7.2 or 15.3.7.3) that the enabled field of the value parameter is set to true. When the method parameter of a request message is set to a value of "org.hbbtv.af.triggerResponseToUserAction", the params field shall contain a magnitude field, which has a string value as described in the following table: Table 39: Response to user action magnitude parameter values ... | triggerPrimary | The most common type of response to the most common of user actions | ... | triggerSecondary | A second type of response that may be used for less common user actions | ... | triggerException | A user has attempted to navigate to a location that is not supported by the application or user interface | ... | NOTE: Terminals may not support multiple response magnitudes for one or more of the response types and may map them to a single value. | If the requested ‘response to a user action’ is successfully performed by the terminal, it shall reply with a non-error response message, where the following fields of the result parameter are: - the method field shall be set to org.hbbtv.af.triggerResponseToUserAction - the actioned field shall be set to true If the ‘response to a user action’ is not successfully performed by the terminal, then the terminal shall reply with a JSON-RPC error with a code value of -25 and a message value of "Response to User Action failed" | +RESP2USERACTION | ||
| org.hbbtv_A11YSCRE_0010 | 1 | Accessibility - Screen Reader Settings Query (disabled) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. The Screen Reader feature is successfully determined to be supported by sending an org.hbbtv.af.featureSupportInfo request message with feature field of the params object set to "screenReader" and confirming that the feature is supported by inspecting a valid and correct response message where the "value" field of the "result" object is set to "tvosSettingOnly", "tvosOnly" or "tvosAndHbbTV". Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "screenReader". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "false". | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. Screen Reader | "screenReader" | N HBBTV,section 15.3.6.2: Table 37 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "screenReader". Table 37: Screen reader response message parameters ... | "enabled" | Boolean | M | Boolean true or false | If the user has enabled a screen reader preference in thier TV OS settings, then this parameter shall be set to "true". | ... NOTE: The language value should only be present if the user has changed this from the default setting. The voice value should be present if the enabled value is set to true. | +SCREADER | ||
| org.hbbtv_A11YSCRE_0020 | 1 | Accessibility - Screen Reader Settings Query (enabled) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. The Screen Reader feature is successfully determined to be supported by sending an org.hbbtv.af.featureSupportInfo request message with feature field of the params object set to "screenReader" and confirming that the feature is supported by inspecting a valid and correct response message where the "value" field of the "result" object is set to "tvosSettingOnly", "tvosOnly" or "tvosAndHbbTV". Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "screenReader". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "true". | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. Screen Reader | "screenReader" | N HBBTV,section 15.3.6.2: Table 37 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "screenReader". Table 37: Screen reader response message parameters ... | "enabled" | Boolean | M | Boolean true or false | If the user has enabled a screen reader preference in thier TV OS settings, then this parameter shall be set to "true". | "speed" | Integer | O | 10-1000 | ... | "voice" | String | O | "male", "female" or "default" | ... | "language" | String | O(see Note) | ISO639-2 3-character code | ... | ... NOTE: The language value should only be present if the user has changed this from the default setting. The voice value should be present if the enabled value is set to true. | +SCREADER | ||
| org.hbbtv_A11YSUBS_0010 | 1 | Accessibility - Subtitles Settings Query (disabled) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "subtitles". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "false". | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. Subtitles | "subtitles" | N. HBBTV,section 15.3.2.2: Table 32 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "subtitles". Table 32: Subtitle response message parameters. ... | "enabled" | Boolean | M | Boolean true or false | If the user has enabled a screen reader preference in their TV OS settings, then this parameter shall be set to "true". | ... NOTE: Optional Parameters marked with a ‘*’ shall only be present if the user has explicitly modified the setting value to something other than the terminal default value. | |||
| org.hbbtv_A11YSUBS_0020 | 1 | Accessibility - Subtitles Settings Query (enabled - simple variant) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "subtitles". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "true". No fields (other than "language" or "enabled") are present in the "value" object. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. Subtitles | "subtitles" | N. HBBTV,section 15.3.2.2: Table 32 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "subtitles". Table 32: Subtitle response message parameters. ... | "enabled" | Boolean | M | Boolean true or false | If the user has enabled a screen reader preference in their TV OS settings, then this parameter shall be set to "true". | "size" | Integer | O* | 25 - 300 | ... | "fontFamily" | String | O* | | A string describing the chosen fontFamily. Note that the chosen fontFamily should be set to match a built-in font that is accessible by the HbbTV browser. | "textColour" | String | O* | RGB24 in #AABBCC form | ... | "textOpacity" | Integer | O* | 0 - 100 | ... | "edgeType" | String | O* |"outline", "dropShadow", "raised", "depressed" |... | "edgeColour" | String | O* | RGB24 in #AABBCC form | ... | "backgroundColour" | String | O* | RGB24 in #AABBCC | ... | "backgroundOpacity" | Integer | O* | 0-100 | ... | "windowColour" | String | O* | RGB24 in #AABBCC form | ... | "windowOpacity" | Integer | O* | 0-100 | ... | "language" | String | O | ISO639-2 3-character code | ... | NOTE: Optional Parameters marked with a ‘*’ shall only be present if the user has explicitly modified the setting value to something other than the terminal default value. | | |||
| org.hbbtv_A11YSUBS_0030 | 1 | Accessibility - Subtitles Settings Query (enabled - rich settings variant) | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSettingsQuery and org.hbbtv.af.featureSupportInfo methods. Then the application sends an org.hbbtv.af.featureSettingsQuery message to the terminal with the feature field of the params object set to "subtitles". The application receives a valid and correct response message where the "result" field contains a "value" object, which in turn contains an "enabled" field set to "true". At least one other fields in the value object other than "language" or "enabled" are present which shall (as closely as possible) relate to the 'rich' subtitle subsetting(s) that had been modified from the terminal default by the tester as part of the test preconditions. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.9.5: For both application and terminal to determine what JSON-RPC requests are supported by each other, the terminal shall support receiving JSON-RPC requests from the application with method name org.hbbtv.negotiateMethods. These requests shall conform to a schema whose normative definition is found in the electronic attachments HBBTV,section 9.9.5: The terminal shall respond to this request with a response conforming to the response schema whose normative definition is found in the electronic attachments – see annex N of the present document. In the response, the result property of the response shall be a JSON object containing: - a method property with the same value as the request, and - terminalToApp and appToTerminal properties containing the same list of method names as in the request, but with the messages that the terminal does not recognise or support removed from the list HBBTV,section 9.9.5: The terminal shall not send any JSON-RPC request to an application until the application has indicated support for that request, via the mechanism described above. Initially, when an HbbTV application is launched, the terminal shall assume that no JSON-RPC requests are supported by the application except this capability negotiation JSON-RPC request. Every subsequent time the HbbTV application sends this JSON-RPC request, it adds to the set of method names that the terminal shall consider that application supports. The terminal shall assume that all method names from all past instances of this request are supported for the remaining lifetime of the HbbTV application. HBBTV,section 15.2.1: Terminals shall: - support the org.hbbtv.af.featureSupportInfo API defined in clause 15.2.2.1.1 -support the org.hbbtv.af.featureSettingsQuery API defined in clause 15.2.2.3 HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. Only a single feature can be queried at any one time with this API. The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.2.2.3.2: Terminals may provide optional user setting parameters in responses, and terminals shall provide mandatory user setting parameters in responses. Terminals shall map provided parameters in any responses as accurately as possible to the corresponding terminal user setting. See the related sub-clauses of 15.3 for further clarifications on specific parameter mapping considerations. HBBTV,section 15.2.2.3.2: If an application requests user settings using org.hbbtv.af.featureSettingsQuery for a feature that is not supported by a TV OS (i.e. a response to a org.hbbtv.af.featureSupportInfo message would be a value of notSupported or supportedNoSetting) then a JSON-RPC error with a code value of -23 and a message value of "Invalid accessibility settings query" (as indicated in Table 10e in clause 9.9.7) shall be returned to the application. HBBTV,section 15.3.1: Table 31 - List of Accessibility Features and their JSON Feature String Name. Subtitles | "subtitles" | N. HBBTV,section 15.3.2.2: Table 32 below describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "subtitles". Table 32: Subtitle response message parameters. ... | "enabled" | Boolean | M | Boolean true or false | If the user has enabled a screen reader preference in their TV OS settings, then this parameter shall be set to "true". | "size" | Integer | O* | 25 - 300 | ... | "fontFamily" | String | O* | | A string describing the chosen fontFamily. Note that the chosen fontFamily should be set to match a built-in font that is accessible by the HbbTV browser. | "textColour" | String | O* | RGB24 in #AABBCC form | ... | "textOpacity" | Integer | O* | 0 - 100 | ... | "edgeType" | String | O* |"outline", "dropShadow", "raised", "depressed" |... | "edgeColour" | String | O* | RGB24 in #AABBCC form | ... | "backgroundColour" | String | O* | RGB24 in #AABBCC | ... | "backgroundOpacity" | Integer | O* | 0-100 | ... | "windowColour" | String | O* | RGB24 in #AABBCC form | ... | "windowOpacity" | Integer | O* | 0-100 | ... | "language" | String | O | ISO639-2 3-character code | ... | NOTE: Optional Parameters marked with a ‘*’ shall only be present if the user has explicitly modified the setting value to something other than the terminal default value. | | +SUBTITLE_SUB_SETTINGS | ||
| org.hbbtv_AC4-AD0030 | 1 | Verifying the Audio Description Preference Change Message for enabling Audio Description (AC-4 Audio) | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio including two Preselections. The first Preselection of the media contains an Audio Description while the second Preselection does not contain any Audio Description. While playing the content, the application queries the org.hbbtv.af.featureSettingsQuery API with feature="audioDescription". The response message shall have the value set to '"enabled" : false' for the "audioDescription" feature, and the terminal shall play the Preselection containing no Audio Description. The application is subscribed to receive Audio Description Preference Change Messages. When enabling the Audio Description in the TV OS settings, the application shall receive an Audio Description Preference Change Message with the value set to '"enabled" : true' for the "audioDescriptionPrefChange" msgType, and the Preselection with Audio Description shall be played back by the terminal. Each response message shall conform with the respective schema. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP HBBTV,section 10.2.7.2: If either or both of the subtitle components or the audio description components available in the content change and a previously selected component is no longer available, then the terminal should re-evaluate the subtitle or audio description component selection as applicable based on the user preferences. NOTE 2: "Use of the terminal's audio description selection mechanism by the user may change the selected audio track. Applications using an HTML5 media element should register a listener for 'change' events on the AudioTrackList object if they need to be aware of such changes."" The terminal shall present to the user the default selection of components unless the application overrides it (see clause 10.2.7.3). HBBTV,section 15.3.8.1: The TV settings relating to the Audio Description feature that can be communicated to an HbbTV application using the response and notification messages are described in clauses 15.3.8.2 and 15.3.8.3. HBBTV,section 15.3.8.2: Table 40 below describes the variable parameters of value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "audioDescription". Parameter | Data Type | Mandatory (M) or Optional (O) | Valid Values | Description "enabled" | Boolean | M | true of false | If the user has enabled Audio Description in their TV OS settings, then this parameter shall be set to true. [...] HBBTV,section 15.3.8.3: This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: • The application has registered for notifications of this type • One or more of the following events have occurred: o The user enables/disables Audio Description entirely. • The user sets a new value for one of the following fields: “gainPreference”, or “panAzimuthPreference”. [...] HBBTV,section A.2.12.1: The following shall apply when an HTML5 media element is presenting NGA content from a MediaSource object on terminals that support SRMP NGA with MPEG DASH according to clause 6.7 of ETSI TS 103 285 [45] and either or both of clauses 6.3.2 or 6.8 or ETSI TS 103 285 [45]: - When a SourceBuffer is initialized to contain NGA content, the present document is intentionally silent about whether any AudioTracks are created and if so, how many and what they correspond to in the NGA bitstream. - Terminals shall select exactly one Preselection to render initially. How this Preselection is chosen is implementation specific but shall take into account user preferences such as language preferences and accessibility settings. HBBTV,section N: • response__org.hbbtv.af.featureSettingsQuery.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of audioDescription, as referred to in clause 15.3.8.2 of the present document. • notification__org.hbbtv.af.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC notification with method name org.hbbtv.notify and a msgType of audioDescriptionPrefChange, as referred to in clause 15.3.8.3 of the present document. TS-101-154,section 6.7.4: Multiple audio programme components Multiple audio programme component use cases are a generalization of receiver-mix audio as defined in earlier versions of the present document: several audio components are decoded and mixed in the receiver. To implement these use cases, the IRD shall be capable of simultaneously decoding several different audio components and subsequently combining them into a complete programme. [...] The IRD shall support single-stream delivery as defined in clause 6.7.4.2. TS-103-190-1,section 4.3.3.3.4: presentation_config - presentation configuration This element indicates the presentation configuration as shown in table 85. [...] Table 85: presentation_config presentation_config | Presentation configuration 0 | music and effects (M+E) + dialogue 1 | Main + dialogue enhancement 2 | Main + associate 3 | Music and effects (M+E) + dialogue enhancement + associate 4 | Main + dialogue enhancement + associate 5 | HSF extended ≥ 6 | Reserved | +AC4 | ||
| org.hbbtv_AC4-AD0040 | 1 | Verifying the Audio Description Preference Change Message for disabling Audio Description (AC-4 Audio) | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio including two Preselections. The first Preselection of the media contains an Audio Description while the second Preselection does not contain any Audio Description. While playing the content, the application queries the org.hbbtv.af.featureSettingsQuery API with feature="audioDescription". The response message shall have the value set to '"enabled" : true' for the "audioDescription" feature, and the terminal shall play the Preselection containing Audio Description. The application is subscribed to receive Audio Description Preference Change Messages. When disabling the Audio Description in the TV OS settings, the application shall receive an Audio Description Preference Change Message with the value set to '"enabled" : false' for the "audioDescriptionPrefChange" msgType, and the Preselection with no Audio Description should be played back by the terminal. Each response message shall conform with the respective schema. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP HBBTV,section 10.2.7.2: If either or both of the subtitle components or the audio description components available in the content change and a previously selected component is no longer available, then the terminal should re-evaluate the subtitle or audio description component selection as applicable based on the user preferences. NOTE 2: "Use of the terminal's audio description selection mechanism by the user may change the selected audio track. Applications using an HTML5 media element should register a listener for 'change' events on the AudioTrackList object if they need to be aware of such changes."" The terminal shall present to the user the default selection of components unless the application overrides it (see clause 10.2.7.3). HBBTV,section 15.3.8.1: The TV settings relating to the Audio Description feature that can be communicated to an HbbTV application using the response and notification messages are described in clauses 15.3.8.2 and 15.3.8.3. HBBTV,section 15.3.8.2: Table 40 below describes the variable parameters of value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "audioDescription". Parameter | Data Type | Mandatory (M) or Optional (O) | Valid Values | Description "enabled" | Boolean | M | true of false | If the user has enabled Audio Description in their TV OS settings, then this parameter shall be set to true. [...] HBBTV,section 15.3.8.3: This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: • The application has registered for notifications of this type • One or more of the following events have occurred: o The user enables/disables Audio Description entirely. • The user sets a new value for one of the following fields: “gainPreference”, or “panAzimuthPreference”. [...] HBBTV,section A.2.12.1: The following shall apply when an HTML5 media element is presenting NGA content from a MediaSource object on terminals that support SRMP NGA with MPEG DASH according to clause 6.7 of ETSI TS 103 285 [45] and either or both of clauses 6.3.2 or 6.8 or ETSI TS 103 285 [45]: - When a SourceBuffer is initialized to contain NGA content, the present document is intentionally silent about whether any AudioTracks are created and if so, how many and what they correspond to in the NGA bitstream. - Terminals shall select exactly one Preselection to render initially. How this Preselection is chosen is implementation specific but shall take into account user preferences such as language preferences and accessibility settings. HBBTV,section N: • response__org.hbbtv.af.featureSettingsQuery.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of audioDescription, as referred to in clause 15.3.8.2 of the present document. • notification__org.hbbtv.af.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC notification with method name org.hbbtv.notify and a msgType of audioDescriptionPrefChange, as referred to in clause 15.3.8.3 of the present document. TS-101-154,section 6.7.4: Multiple audio programme components Multiple audio programme component use cases are a generalization of receiver-mix audio as defined in earlier versions of the present document: several audio components are decoded and mixed in the receiver. To implement these use cases, the IRD shall be capable of simultaneously decoding several different audio components and subsequently combining them into a complete programme. [...] The IRD shall support single-stream delivery as defined in clause 6.7.4.2. TS-103-190-1,section 4.3.3.3.4: presentation_config - presentation configuration This element indicates the presentation configuration as shown in table 85. [...] Table 85: presentation_config presentation_config | Presentation configuration 0 | music and effects (M+E) + dialogue 1 | Main + dialogue enhancement 2 | Main + associate 3 | Music and effects (M+E) + dialogue enhancement + associate 4 | Main + dialogue enhancement + associate 5 | HSF extended ≥ 6 | Reserved | +AC4 | ||
| org.hbbtv_AC4-AD0050 | 1 | Verifying the Audio Description Preference Change Message for the Gain Preference (AC-4 Audio) | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio including a preselection containing both an Audio Description dialogue and the main dialogue. The audio test material shall be constructed such that the Audio Description dialogue and the main dialogue will play back at roughly the same loudness when an Audio Description dialogue gain of 0 dB is used. The preselection is signalled in the AC-4 elementary stream table of contents by setting presentation_config=2 (“Main + associate”). The presentation references a substream with the associated dialog. The substream is signalled by setting the content_classifier=2 (“Associated service: visually impaired”) in the elementary stream and the content_classifier=2 (“Associated service: visually impaired”) in the DSI. In the DASH manifest, an Accessibility descriptor shall indicate "Audio description for the visually impaired" according to ETSI TS 103 285 clause 6.3.2.6. The Terminal shall select the preselection containing the Audio Description based on the procedural preconditions. While playing the content, the application queries the org.hbbtv.af.featureSettingsQuery API with feature="audioDescription". The response message shall also include the "gainPreference" field. If the "gainPreference" field holds a positive value, the Audio Description shall be played back louder than the main dialog. The application shall record the current "gainPreference" value for later comparison. The application is subscribed to receive Audio Description Preference Change Messages. When changing the gain preference setting of the Audio Description in the TV OS settings to the minimum possible value, the application shall receive an Audio Description Preference Change Message. The "gainPreference" field for the "audioDescriptionPrefChange" msgType shall now have a lower value compared to the previously recorded value. If the "gainPreference" field now holds a negative value for the "audioDescriptionPrefChange" msgType, the Audio Description shall be played back quieter than the main dialog. Each response message shall conform with the respective schema. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP HBBTV,section 10.2.7.2: If either or both of the subtitle components or the audio description components available in the content change and a previously selected component is no longer available, then the terminal should re-evaluate the subtitle or audio description component selection as applicable based on the user preferences. NOTE 2: "Use of the terminal's audio description selection mechanism by the user may change the selected audio track. Applications using an HTML5 media element should register a listener for 'change' events on the AudioTrackList object if they need to be aware of such changes."" The terminal shall present to the user the default selection of components unless the application overrides it (see clause 10.2.7.3). HBBTV,section 15.3.8.1: The TV settings relating to the Audio Description feature that can be communicated to an HbbTV application using the response and notification messages are described in clauses 15.3.8.2 and 15.3.8.3. HBBTV,section 15.3.8.2: Table 40 below describes the variable parameters of value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "audioDescription". Parameter | Data Type | Mandatory (M) or Optional (O) | Valid Values | Description "enabled" | Boolean | M | true of false | If the user has enabled Audio Description in their TV OS settings, then this parameter shall be set to true. [...] “gainPreference” | Integer | O (see note) | The “gainPreference” value describes the Audio Description gain preference set by the user in dB. [...] HBBTV,section 15.3.8.3: This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: • The application has registered for notifications of this type • One or more of the following events have occurred: o The user enables/disables Audio Description entirely. • The user sets a new value for one of the following fields: “gainPreference”, or “panAzimuthPreference”. [...] HBBTV,section A.2.12.1: The following shall apply when an HTML5 media element is presenting NGA content from a MediaSource object on terminals that support SRMP NGA with MPEG DASH according to clause 6.7 of ETSI TS 103 285 [45] and either or both of clauses 6.3.2 or 6.8 or ETSI TS 103 285 [45]: - When a SourceBuffer is initialized to contain NGA content, the present document is intentionally silent about whether any AudioTracks are created and if so, how many and what they correspond to in the NGA bitstream. - Terminals shall select exactly one Preselection to render initially. How this Preselection is chosen is implementation specific but shall take into account user preferences such as language preferences and accessibility settings. HBBTV,section N: • response__org.hbbtv.af.featureSettingsQuery.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of audioDescription, as referred to in clause 15.3.8.2 of the present document. • notification__org.hbbtv.af.audioDescription.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC notification with method name org.hbbtv.notify and a msgType of audioDescriptionPrefChange, as referred to in clause 15.3.8.3 of the present document. TS-101-154,section 6.7.4: Multiple audio programme components Multiple audio programme component use cases are a generalization of receiver-mix audio as defined in earlier versions of the present document: several audio components are decoded and mixed in the receiver. To implement these use cases, the IRD shall be capable of simultaneously decoding several different audio components and subsequently combining them into a complete programme. [...] The IRD shall support single-stream delivery as defined in clause 6.7.4.2. TS-103-285,section 6.3.2.6: DASH Element and attribute settings for AC-4 Table 9 provides the details on how AC-4 and related parameters are signalled with DASH elements and attributes that can be used on Adaptation Sets as well as on Preselection elements unless explicitly indicated. Table 9: AC-4 Elements and Attributes settings Element or Attribute Name | Description Accessibility | The content_classifier field in the DSI structure describes the type of audio conveyed by audio programme components. In case one or more audio programme components related to an AC-4 Preselection indicate "visually impaired" (i.e. content_classifier is 2), an Accessibility descriptor shall indicate "Audio description for the visually impaired" according to the scheme described by the schemeIdUri urn:tva:metadata:cs:AudioPurposeCS:2007 defined in ETSI TS 102 822-3-1 [41]. [...] TS-103-190-1,section 4.3.3.3.4: presentation_config - presentation configuration This element indicates the presentation configuration as shown in table 85. [...] Table 85: presentation_config presentation_config | Presentation configuration 0 | music and effects (M+E) + dialogue 1 | Main + dialogue enhancement 2 | Main + associate 3 | Music and effects (M+E) + dialogue enhancement + associate 4 | Main + dialogue enhancement + associate 5 | HSF extended ≥ 6 | Reserved TS-103-190-1,section 4.3.3.8.1: content_classifier - content classifier This element classifies the content of an audio program component as shown in table 91. Table 91: content_classifier Value of content_classifier | Content classification (audio program component type) 000 | Main audio service: complete main 001 | Main audio service: music and effects 010 | Associated service: visually impaired 011 | Any associated service: hearing impaired 100 | Associated service: dialogue 101 | Any associated service: commentary 110 | Associated service: emergency 111 | Associated service: voice over TS-103-190-1,section 6.2.16.2: Mixing main and associate While mixing the associate channels, a single user-agent provided gain g_assoc [-∞, 0] dB should be applied to all associate channels. This allows for a user-controlled adjustment of the relative associate level. [...] TS-103-190-2,section E.9.8: content_classifier This field shall contain the content classifier as described in ETSI TS 103 190-1 [1], clause 4.3.3.8.1. The value shall correspond to the value read from the respective content_type field in the ac4_substream_info element in ac4_presentation_info. | +AC4 +AC4_AD_STEERING | ||
| org.hbbtv_AC4-ADAPTATION-0010 | 2 | HTML5 DASH audio AC-4 Representation transition to lower bit rate within the same adaptation set | When the available bandwidth is restricted, the device shall seamlessly switch from an AC-4 192kbps audio representation to an AC-4 128kbps audio representation within the same adaptation set of the played HTML5 DASH content. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.4: [...] Players shall support seamless switching between audio Representations which differ only in any combination of the following properties: * Bit rate. For audio presentation to be considered seamless the following conditions shall be met: * There are no audible clicks, glitches or discontinuities. * Audio presentation is continuous, with no pauses, missing or extra audio. * Temporal alignment with other media streams (e.g. video, additional audio) is maintained. The requirements of clause 4.5.1 of ISO/IEC 23009-1 [1] for seamless switching shall also be supported. HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +AC4 | ||
| org.hbbtv_AC4-ADINS0001 | 2 | HTML5 mid-roll advert insertion, DASH AC-4/HEVC and DASH HE-AAC/HEVC | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with AC-4/HEVC is paused, and a second HTML5 media element with DASH HE-AAC/HEVC media is played in its entirety, and then the playing of the previous DASH media is resumed. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 6.3.2.1: [...] the decoder specific information (DSI), shall be used to set parameter that are relevant for indication of AC-4 in manifests. [...] * For AC-4 bitstream_version = 2 the DSI structure is described in ETSI TS 103 190-2, Annex E. [...] TS-103-285,section 6.3.2.7: Table 9 provides the details on how AC-4 and related parameters are signalled with DASH elements and attributes that can be used on Adaptation Sets as well as on Preselection elements [...] HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] Additional audio formats are defined by references from TS 103 285 [45] and TS 101 154 [14]. The labels that shall be used for these formats are defined in table 10. [...] For DVB DASH, the following shall apply; [...] The only system format required for MPEG DASH in the present document is ISOBMFF. [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [14] shall also support the related DASH requirement as shown. HBBTV,section 9.6.1: The video element from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met [...] When resuming the playback of an HTML5 media element that has previously been paused, the terminal shall start playback at or before the IDR following the pause position. When resuming the playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. When resuming the playback of an HTML5 media element that has previously been paused while presenting and references content containing both video and audio tracks, the terminal should start playback with video and audio as closely synchronized as possible. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-ADINS0002 | 2 | HTML5 mid-roll advert insertion, DASH AC-4/HEVC and MP4 HE-AAC/HEVC | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with AC-4/HEVC is paused, and a second HTML5 media element with preloaded MP4 with HE-AAC/HEVC media is played in its entirety, and then the playing of the previous DASH media is resumed. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 6.3.2.1: [...] the decoder specific information (DSI), shall be used to set parameter that are relevant for indication of AC-4 in manifests. [...] * For AC-4 bitstream_version = 2 the DSI structure is described in ETSI TS 103 190-2, Annex E. [...] TS-103-285,section 6.3.2.7: Table 9 provides the details on how AC-4 and related parameters are signalled with DASH elements and attributes that can be used on Adaptation Sets as well as on Preselection elements [...] HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For DVB DASH, the following shall apply; [...] The only system format required for MPEG DASH in the present document is ISOBMFF. [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. HBBTV,section 9.6.1: The video element from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met [...] When resuming the playback of an HTML5 media element that has previously been paused, the terminal shall start playback at or before the IDR following the pause position. When resuming the playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. When resuming the playback of an HTML5 media element that has previously been paused while presenting and references content containing both video and audio tracks, the terminal should start playback with video and audio as closely synchronized as possible. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-ADINS0010 | 3 | HTML5 post-roll advert insertion, DASH AC-4/HEVC and MP4 AAC/AVC | When content playback of a HTML5 media element referencing DASH with AC-4/HEVC is ended, a preloaded MP4 advertisement with AAC/AVC media is played in its entirety afterwards. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-2 2021-1 2020-3 2020-2 2019-3 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 6.3.2.1: [...] the decoder specific information (DSI), shall be used to set parameter that are relevant for indication of AC-4 in manifests. [...] * For AC-4 bitstream_version = 2 the DSI structure is described in ETSI TS 103 190-2, Annex E. [...] TS-103-285,section 6.3.2.7: Table 9 provides the details on how AC-4 and related parameters are signalled with DASH elements and attributes that can be used on Adaptation Sets as well as on Preselection elements [...] HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For DVB DASH, the following shall apply; [...] The only system format required for MPEG DASH in the present document is ISOBMFF. [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met: [...] HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-ADINS0020 | 3 | HTML5 pre-roll advert insertion, MP4 AAC/AVC and DASH AC-4/HEVC | When content of a preloaded MP4 advertisement with AAC/AVC media is played back in its entirety, an HTML5 media element referencing DASH AC-4/HEVC media is played back afterwards. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2019-3 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 6.3.2.1: [...] the decoder specific information (DSI), shall be used to set parameter that are relevant for indication of AC-4 in manifests. [...] * For AC-4 bitstream_version = 2 the DSI structure is described in ETSI TS 103 190-2, Annex E. [...] TS-103-285,section 6.3.2.7: Table 9 provides the details on how AC-4 and related parameters are signalled with DASH elements and attributes that can be used on Adaptation Sets as well as on Preselection elements [...] HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For DVB DASH, the following shall apply; [...] * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The only system format required for MPEG DASH in the present document is ISOBMFF. [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met: [...] HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-BROADBAND0010 | 1 | AC-4 broadband capability reported correctly and AC-4 media is presented | When an HbbTV application queries the xmlCapabilities a <video_profile> element is present in the document returned with name attribute of "MP4_HEVC_HD_25_8_AC4-CIP_EBUTTD", type attribute of "video/mp4", sync_tl attribute of "dash_pr", and a transport attribute containing the protocol name "dash". When play() is called on an HTMLVideoElement referencing an MPD containing HEVC_HD_25_8 video and AC-4 audio, the video and audio are presented without glitches or decoding artefacts. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 10.2.4: Terminals that support NGA according to clause 6.7 of TS 103 285 [] and either or both of clauses 6.3.2 or 6.8 of TS 103 285 [] shall include a video_profile element for each combination of video codec and frame rate, audio codec, HDR technology (if any) and transport protocol supported with HbbTV. Audio format labels for NGA codecs are defined in clause A.5.1 of the present document. [...] | +AC4 -HEVC_HD_10 +HEVC_HD_8 | ||
| org.hbbtv_AC4-BROADBAND0020 | 1 | AC-4 broadband capability reported correctly | When an HbbTV application queries the xmlCapabilities no <video_profile/> element with @name attribute containing the sub-string "AC4-C" is present in the document returned. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 10.2.4: Terminals that support NGA according to clause 6.7 of TS 103 285 [] and either or both of clauses 6.3.2 or 6.8 of TS 103 285 [] shall include a video_profile element for each combination of video codec and frame rate, audio codec, HDR technology (if any) and transport protocol supported with HbbTV. Audio format labels for NGA codecs are defined in clause A.5.1 of the present document. [...] | -AC4 | ||
| org.hbbtv_AC4-BROADCAST0010 | 1 | AC-4 broadcast capability reported correctly and AC-4 media presented | When an HbbTV application queries the xmlCapabilities object a <broadcast>urn:dvb:broadcast:ird:audio:AC-4_channel_based_immersive_personalized</broadcast> element is present in the document returned. When an MPEG-2 TS containing HEVC_HD_25_8 video and AC-4 audio is signalled to the terminal, audio and video from that stream are presented without glitches or decoding artefacts. | 2024-2 2024-1 2023-3 2023-1 2022-3 2020-2 2020-1 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 10.2.4: Terminals that support NGA according to clause 6.7 of TS 103 285 [] and either or both of clauses 6.3.2 or 6.8 of TS 103 285 [] shall include a video_profile element for each combination of video codec and frame rate, audio codec, HDR technology (if any) and transport protocol supported with HbbTV. Audio format labels for NGA codecs are defined in clause A.5.1 of the present document. [...] | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-BROADCAST0020 | 1 | AC-4 broadcast capability reported correctly | When an HbbTV application queries the xmlCapabilities a <broadcast>urn:dvb:broadcast:ird:audio:AC-4_channel_based_immersive_personalized</broadcast> element is not present in the document returned. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 10.2.4: Terminals that support NGA according to clause 6.7 of TS 103 285 [] and either or both of clauses 6.3.2 or 6.8 of TS 103 285 [] shall include a video_profile element for each combination of video codec and frame rate, audio codec, HDR technology (if any) and transport protocol supported with HbbTV. Audio format labels for NGA codecs are defined in clause A.5.1 of the present document. [...] | -AC4 | ||
| org.hbbtv_AC4-COMPONENTS0010 | 1 | AC-4 preferred-language audio component selection | When the terminal's preferred user language is set to German and an HTMLVideoElement plays an MPD referencing one MP4_HEVC_HD_25_10 video AdaptationSet, one AC-4 audio AdaptationSet with its @lang attribute set to 'en', and one AC-4 audio AdaptationSet with its @lang attribute set to 'de', the terminal presents the video and the German language audio AdaptationSet without artefacts or glitches. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 10.2.7.2: Component selection by the terminal — It is the responsibility of the terminal to choose for presentation to the user the most appropriate default components from those available in the media object(s), based on the user’s preferences (e.g. audio language). TS-103-285,section 6.1.2: If a programme has multiple audio Adaptation Sets with the same codec but with different original soundtracks in different languages, for example a sports game commentated by multiple commentators in multiple languages, then all language Adaptation Sets shall have the @value set to "main". Players should then evaluate the @lang attribute of the Adaptation Set in order to confirm the audio language which matches the language wanted by the user. | +AC4 +HEVC_HD_10 | ||
| org.hbbtv_AC4-COMPONENTS0020 | 1 | AC-4 Role-based audio component selection | When the terminal has enabled Audio Description and an HTMLVideoElement plays an MPD referencing one MP4_HEVC_HD_25_8 video AdaptationSet, one AC-4 audio AdaptationSet containing a Role element with its @schemeIdUri set to "urn:mpeg:dash:role:2011" and its @value set to "main", and one AC-4 audio AdaptationSet containing a Role element with its @schemeIdUri set to "urn:mpeg:dash:role:2011" and its @value set to "alternate" and with an Accessibility element with its @schemeIdUri set to "urn:tva:metadata:cs:AudioPurposeCS:2007" and its @value set to "1", the terminal presents the video and the audio description without artefacts or glitches. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.1.2: For ISO format files, signalling is only defined to identify audio description streams when these are delivered using DASH. In this case, the signalling is defined in clause 6.1.2 of the DVB DASH profile [45], "Role Releated Requirements". Presenting a broadcast-mix audio description stream is supported since this is no different from presenting any other alternative audio stream. Presenting receiver-mix audio description streams is not required by the present document. HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 10.2.7.2: Terminals shall support a method for the user to enable and disable audio description streams as defined in clause 7.1.2 of the present document. Terminals shall use this information when playing content to determine whether to present audio description streams instead of the normal audio (or in addition to the normal audio where receiver mix audio description is supported). TS-103-285,section 6.1.2: Except as defined below, every audio Adaptation Set shall include at least one Role element using the scheme "urn:mpeg:dash:role:2011" as defined in ISO/IEC 23009-1 [1]. The use of the @value attribute set to "main" for audio content indicates to the Player that the Adaptation Set is the preferred audio Adaptation Set by the Content Provider. If there is only one "main" then this Adaptation Set is then the default audio adaptation set. If there is more than one audio Adaptation Set in a DASH presentation then at least one of them shall be tagged with an @value set to "main". [...] As shown in Table 5, the combined use of Role and Accessibility Descriptors shall identify Adaptation Sets containing audio description and clean audio streams. | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-DASH-PRESELECTION0010 | 1 | Expose AC-4 DASH preselection to HTML5 AudioTrack in AudioTrackList | A DASH MPD contains multiple Preselection and Adaptation Set elements. Preselection elements reference one Adaptation Set. The same Period contains an Adaptation Set that is not referenced by any of the Preselections. The AudioTrackList shall contain one HTML5 AudioTrack for each Preselection and one for the Adaptation Set that is not referenced by any of the Preselections. The order of AudioTracks in the AudioTrackList shall be the same as the order of the corresponding elements in the MPD. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.12.1: An AudioTrack object shall be created for each Preselection element in the MPD. An AudioTrack object shall be created for each audio Adaptation Set in the MPD whose id is not used in any Preselection/@preselectionComponents attribute within the same Period. The order of AudioTrack objects in the AudioTrackList shall be the same as the order that the corresponding Adaptation Sets and preselection elements have in the MPD. | +AC4 | ||
| org.hbbtv_AC4-DASH-PRESELECTION0020 | 1 | AC-4 Preselection of preferred language | When the terminal's preferred language is set to French and an HTMLVideoElement is played, referencing a static MPD containing AC-4 audio, and the MPD comprises a single audio AdaptationSet, a Preselection with Role@value set to "main" and @lang set to "en", a second Preselection with Role@value set to "dub" and @lang set to "fr", and a third Preselection with Role@value set to "dub" and @lang set to "de", then the terminal shall present the Preselection with @lang set to "fr". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. HBBTV,section 10.2.7.2: It is the responsibility of the terminal to choose for presentation to the user the most appropriate default components from those available in the media object(s), based on the user's preferences (e.g. audio language). TS-103-285,section 10.18: Players shall support SRSP and SRMP use cases. TS-103-285,section 6.7.3: DASH clients supporting SRMP [...] audio shall support the signaling of Preselections by means of Preselection elements. TS-103-285,section 6.7.4: Every AC-4 or MPEG-H Audio Preselection element shall include at least one Role element using the scheme "urn:mpeg:dash:role:2011" as defined in ISO/IEC 23009-1 [1]. [...] If an audio bundle contains multiple audio Preselections including both the original language as well as translations into other languages, only the original language shall have the Role@value set to "main" while all other languages shall use an @value of "dub". The language contained in the Preselection element is given by the @lang attribute. | +AC4 | ||
| org.hbbtv_AC4-DE0001 | 1 | DE Query - dialogueEnhancementGainPreference reflects terminal preference setting | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio. The application sends a request to org.hbbtv.af.featureSettingsQuery with a request message where the "feature" field of the "params" object is set to "dialogueEnhancement" The response message has a value of dialogueEnhancementGainPreference field that is different from zero. Each response message shall conform with the respective schema. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. [...] The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.3.1: This version of the HbbTV specification has support for managing the following Accessibility Features, depending on the TV OS support level of the feature. All the features below can be used with the Accessibility Framework defined in 15.2.2.1 – 15.2.2.4. Table 31 – List of Accessibility Features and their JSON Feature String Name Accessibility Feature * JSON Feature String Name * Additional API usage? [...] Dialogue Enhancement * "dialogueEnhancement" * Y – see 15.3.3.4 [...] HBBTV,section 15.3.3.2: Table 33 describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". [...] Table 33 - variable parameters of the value field of a response message Parameter * Data Type * Mandatory (M) or Optional (O) dialogueEnhancementGainPreference * Integer * M [...] dialogueEnhancementGainPreference – The dialogue enhancement gain preference, in dB, for the dialogue enhancement processing to be applied as set by the user. HBBTV,section N: response__org.hbbtv.af.featureSettingsQuery.dialogueEnhancement.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of dialogueEnhancement, as referred to in clause 15.3.3.2 of the present document. | +AC4 +AC4_DE | ||
| org.hbbtv_AC4-DE0003 | 1 | DE Query - dialogueEnhancementGain reflects active gain value | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio signaling a maximum limit (carried in the audio stream) of 12dB for dialogue enhancement processing. The application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a gain override of 12dB. The application sends a request to org.hbbtv.af.featureSettingsQuery with a request message where the "feature" field of the "params" object is set to "dialogueEnhancement" and checks that the response message's dialogueEnhancementGain field is 12. The application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a gain override of 0dB. The application sends a request to org.hbbtv.af.featureSettingsQuery with a request message where the "feature" field of the "params" object is set to "dialogueEnhancement" and checks that the response message's dialogueEnhancementGain field is 0. Each response message shall conform with the respective schema. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. [...] The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.3.1: This version of the HbbTV specification has support for managing the following Accessibility Features, depending on the TV OS support level of the feature. All the features below can be used with the Accessibility Framework defined in 15.2.2.1 – 15.2.2.4. Table 31 – List of Accessibility Features and their JSON Feature String Name Accessibility Feature * JSON Feature String Name * Additional API usage? [...] Dialogue Enhancement * "dialogueEnhancement" * Y – see 15.3.3.4 [...] HBBTV,section 15.3.3.2: Table 33 describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". [...] Table 33 - variable parameters of the value field of a response message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementGain * Integer * M [...] dialogueEnhancementGain – The currently-active gain value in dB for the dialogue enhancement processing applied. If DE is switched off or is not supported natively by the terminal, this shall be set to 0. dialogueEnhancementLimit – The range of allowed gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. min – The current allowed minimum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. max – The current allowed maximum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. NOTE: Some NGA codecs allow for limits of dialogue enhancement processing to be carried in the audio stream and will modify the min and max values above. HBBTV,section 15.3.3.4: Dialogue Enhancement Override Request and Response Messages This clause defines a message that may be sent from an HbbTV application to a terminal, and its corresponding response. [...] When the HbbTV application sends this message to the terminal, the terminal shall process the request and change the amount of processing as per the further provisions of this clause. [...] Table 34 - parameters of the org.hbbtv.af.dialogueEnhancementOverride message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementGain * Integer * O [...] HBBTV,section N: response__org.hbbtv.af.featureSettingsQuery.dialogueEnhancement.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of dialogueEnhancement, as referred to in clause 15.3.3.2 of the present document. HBBTV,section N: response__org.hbbtv.af.dialogueEnhancementOverride.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.dialogueEnhancementOverride, and a feature value of dialogueEnhancement, as referred to in clause 15.3.3.4 of the present document. HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP TS-103-285,section 6.3.2.4: Dialogue Enhancement Requirements on Dialogue Enhancement apply as described in ETSI TS 101 154 [3], clause 6.7.6. TS-101-154,section 6.7.6: Dialogue Enhancement The AC-4 bitstream format features flexible and scalable dialogue enhancement capabilities, which are built into the codec. They are detailed in clause 5.7.8 of ETSI TS 103 190-1 [43] and clause 5.8 of ETSI TS 103 190-2 [46]. The following constraints apply: [...] Decoding: The IRD shall be capable of applying dialogue enhancement carried in the AC-4 elementary stream as described in ETSI TS 103 190-1 [43] and ETSI TS 103 190-2 [46]. TS-103-190-1,section 5.7.8.1: [Dialogue] Introduction The dialogue enhancement tool is a tool to increase intelligibility of the dialogue in an audio scene encoded in AC-4. The underlying algorithm uses metadata encoded in the bitstream to boost the dialogue in the scene. TS-103-190-1,section 4.3.14.1: b_de_data_present - dialogue enhancement data present flag If true, this Boolean indicates that dialogue enhancement data is present in the bitstream. TS-103-190-1,section 4.3.14.3.2: de_max_gain - maximum dialogue enhancement gain This 2-bit element defines the maximum gain (Gmax) allowed for boosting the dialogue: Gmax = (de_max_gain + 1) × 3 [dB] | +AC4 +AC4_DE +AC4_DE_OVERRIDE | ||
| org.hbbtv_AC4-DE0005 | 1 | DE Query - dialogueEnhancementLimit response reflects stream signaling | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio signaling a maximum limit (carried in the audio stream) of 12dB for dialogue enhancement processing. The application sends a request to org.hbbtv.af.featureSettingsQuery with a request message where the "feature" field of the "params" object is set to "dialogueEnhancement". The application checks that the response message carries the value zero in the min field and the value 12 in the max field of the dialogueEnhancementLimit field. Each response message shall conform with the respective schema. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 15.2.2.3.1: To determine the detailed TV OS settings of a particular accessibility feature, the org.hbbtv.af.featureSettingsQuery API can be used. [...] The JSON feature string names from table 31 in 15.3.1 can be used in the feature field of the params object. HBBTV,section 15.3.1: This version of the HbbTV specification has support for managing the following Accessibility Features, depending on the TV OS support level of the feature. All the features below can be used with the Accessibility Framework defined in 15.2.2.1 – 15.2.2.4. Table 31 – List of Accessibility Features and their JSON Feature String Name Accessibility Feature * JSON Feature String Name * Additional API usage? [...] Dialogue Enhancement * "dialogueEnhancement" * Y – see 15.3.3.4 [...] HBBTV,section 15.3.3.2: Table 33 describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". [...] Table 33 - variable parameters of the value field of a response message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementLimit * * min * Integer * M max * Integer * M dialogueEnhancementLimit – The range of allowed gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. min – The current allowed minimum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. max – The current allowed maximum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. NOTE: Some NGA codecs allow for limits of dialogue enhancement processing to be carried in the audio stream and will modify the min and max values above. HBBTV,section N: response__org.hbbtv.af.featureSettingsQuery.dialogueEnhancement.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of dialogueEnhancement, as referred to in clause 15.3.3.2 of the present document. HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP TS-103-285,section 6.3.2.4: Dialogue Enhancement Requirements on Dialogue Enhancement apply as described in ETSI TS 101 154 [3], clause 6.7.6. TS-101-154,section 6.7.6: Dialogue Enhancement The AC-4 bitstream format features flexible and scalable dialogue enhancement capabilities, which are built into the codec. They are detailed in clause 5.7.8 of ETSI TS 103 190-1 [43] and clause 5.8 of ETSI TS 103 190-2 [46]. The following constraints apply: [...] Decoding: The IRD shall be capable of applying dialogue enhancement carried in the AC-4 elementary stream as described in ETSI TS 103 190-1 [43] and ETSI TS 103 190-2 [46]. TS-103-190-1,section 5.7.8.1: [Dialogue] Introduction The dialogue enhancement tool is a tool to increase intelligibility of the dialogue in an audio scene encoded in AC-4. The underlying algorithm uses metadata encoded in the bitstream to boost the dialogue in the scene. TS-103-190-1,section 4.3.14.1: b_de_data_present - dialogue enhancement data present flag If true, this Boolean indicates that dialogue enhancement data is present in the bitstream. TS-103-190-1,section 4.3.14.3.2: de_max_gain - maximum dialogue enhancement gain This 2-bit element defines the maximum gain (Gmax) allowed for boosting the dialogue: Gmax = (de_max_gain + 1) × 3 [dB] | +AC4 +AC4_DE | ||
| org.hbbtv_AC4-DE0070 | 1 | DE gain override - clamping the gain to allowed range | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio signaling a maximum limit (carried in the audio stream) of 12dB for dialogue enhancement processing. When the application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a dialogueEnhancementGain parameter value of +15, the dialogueEnhancementGain field of the response message has a value of +12. When the application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a dialogueEnhancementGain parameter value of -15, the dialogueEnhancementGain field of the response message has a value of 0. Each response message shall conform with the respective schema. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 15.3.3.2: Table 33 describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". [...] NOTE: Some NGA codecs allow for limits of dialogue enhancement processing to be carried in the audio stream and will modify the min and max values above. HBBTV,section 15.3.3.4: Dialogue Enhancement Override Request and Response Messages This clause defines a message that may be sent from an HbbTV application to a terminal, and its corresponding response. [...] When the HbbTV application sends this message to the terminal, the terminal shall process the request and change the amount of processing as per the further provisions of this clause. [...] Table 34 - parameters of the org.hbbtv.af.dialogueEnhancementOverride message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementGain * Integer * O [...] HBBTV,section 15.3.3.4: A value of dialogueEnhancementGain that is outside the allowed value range of dialogue enhancement processing as indicated by metadata in the currently decoded audio stream shall be restricted by the terminal into the allowed range. HBBTV,section 15.3.3.4: If the override is successfully applied by the terminal it shall reply with a non-error response message[...] HBBTV,section N: response__org.hbbtv.af.dialogueEnhancementOverride.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.dialogueEnhancementOverride, and a feature value of dialogueEnhancement, as referred to in clause 15.3.3.4 of the present document. HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP TS-103-285,section 6.3.2.4: Dialogue Enhancement Requirements on Dialogue Enhancement apply as described in ETSI TS 101 154 [3], clause 6.7.6. TS-101-154,section 6.7.6: Dialogue Enhancement The AC-4 bitstream format features flexible and scalable dialogue enhancement capabilities, which are built into the codec. They are detailed in clause 5.7.8 of ETSI TS 103 190-1 [43] and clause 5.8 of ETSI TS 103 190-2 [46]. The following constraints apply: [...] Decoding: The IRD shall be capable of applying dialogue enhancement carried in the AC-4 elementary stream as described in ETSI TS 103 190-1 [43] and ETSI TS 103 190-2 [46]. TS-103-190-1,section 5.7.8.1: [Dialogue] Introduction The dialogue enhancement tool is a tool to increase intelligibility of the dialogue in an audio scene encoded in AC-4. The underlying algorithm uses metadata encoded in the bitstream to boost the dialogue in the scene. TS-103-190-1,section 4.3.14.1: b_de_data_present - dialogue enhancement data present flag If true, this Boolean indicates that dialogue enhancement data is present in the bitstream. TS-103-190-1,section 4.3.14.3.2: de_max_gain - maximum dialogue enhancement gain This 2-bit element defines the maximum gain (Gmax) allowed for boosting the dialogue: Gmax = (de_max_gain + 1) × 3 [dB] | +AC4 +AC4_DE +AC4_DE_OVERRIDE | ||
| org.hbbtv_AC4-DE0080 | 1 | DE gain override - resetting the gain to default | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio signaling a maximum limit (carried in the audio stream) of 12dB for dialogue enhancement processing. The application sends a org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". The value of the dialogueEnhancementGainPreference field of the response message is recorded. If dialogueEnhancementGainPreference is 0, the application calls the org.hbbtv.af.dialogueEnhancementOverride API method with the dialogueEnhancementGain parameter set to +12; else it calls the org.hbbtv.af.dialogueEnhancementOverride API method with the dialogueEnhancementGain parameter set to 0. The application then calls the org.hbbtv.af.dialogueEnhancementOverride API method again with no dialogueEnhancementGain parameter provided and checks that the dialogueEnhancementGain field of the response message has a value that is equal to the previously recorded dialogueEnhancementGainPreference value. Each response message shall conform with the respective schema. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 15.3.3.2: Table 33 describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". [...] Table 33 - variable parameters of the value field of a response message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementGain * Integer * M [...] dialogueEnhancementGain – The currently-active gain value in dB for the dialogue enhancement processing applied. If DE is switched off or is not supported natively by the terminal, this shall be set to 0. dialogueEnhancementLimit – The range of allowed gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. min – The current allowed minimum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. max – The current allowed maximum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. NOTE: Some NGA codecs allow for limits of dialogue enhancement processing to be carried in the audio stream and will modify the min and max values above. HBBTV,section 15.3.3.4: Dialogue Enhancement Override Request and Response Messages This clause defines a message that may be sent from an HbbTV application to a terminal, and its corresponding response. [...] When the HbbTV application sends this message to the terminal, the terminal shall process the request and change the amount of processing as per the further provisions of this clause. [...] Table 34 - parameters of the org.hbbtv.af.dialogueEnhancementOverride message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementGain * Integer * O [...] HBBTV,section 15.3.3.4: If this value is not specified in the request, the amount of processing shall be reset to the user preference set in the terminal. HBBTV,section 15.3.3.4: If the override is successfully applied by the terminal it shall reply with a non-error response message[...] HBBTV,section N: response__org.hbbtv.af.featureSettingsQuery.dialogueEnhancement.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of dialogueEnhancement, as referred to in clause 15.3.3.2 of the present document. HBBTV,section N: response__org.hbbtv.af.dialogueEnhancementOverride.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.dialogueEnhancementOverride, and a feature value of dialogueEnhancement, as referred to in clause 15.3.3.4 of the present document. HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP TS-103-285,section 6.3.2.4: Dialogue Enhancement Requirements on Dialogue Enhancement apply as described in ETSI TS 101 154 [3], clause 6.7.6. TS-101-154,section 6.7.6: Dialogue Enhancement The AC-4 bitstream format features flexible and scalable dialogue enhancement capabilities, which are built into the codec. They are detailed in clause 5.7.8 of ETSI TS 103 190-1 [43] and clause 5.8 of ETSI TS 103 190-2 [46]. The following constraints apply: [...] Decoding: The IRD shall be capable of applying dialogue enhancement carried in the AC-4 elementary stream as described in ETSI TS 103 190-1 [43] and ETSI TS 103 190-2 [46]. TS-103-190-1,section 5.7.8.1: [Dialogue] Introduction The dialogue enhancement tool is a tool to increase intelligibility of the dialogue in an audio scene encoded in AC-4. The underlying algorithm uses metadata encoded in the bitstream to boost the dialogue in the scene. TS-103-190-1,section 4.3.14.1: b_de_data_present - dialogue enhancement data present flag If true, this Boolean indicates that dialogue enhancement data is present in the bitstream. TS-103-190-1,section 4.3.14.3.2: de_max_gain - maximum dialogue enhancement gain This 2-bit element defines the maximum gain (Gmax) allowed for boosting the dialogue: Gmax = (de_max_gain + 1) × 3 [dB] | +AC4 +AC4_DE +AC4_DE_OVERRIDE | ||
| org.hbbtv_AC4-DE0100 | 1 | DE gain override - setting the amount of processing (AC4 audio) | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio containing noise and DE data to boost the noise. The audio has alternating segments where in one segment, the DE maximum gain limit is set to 12 dB and is set to 3 dB in the other. The segments are approximately 0.5 seconds each in duration and repeat over 10 seconds or more. The application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a gain override of 12 dB. The tester verifies aurally that the signal changes volume approximately twice every second. Then, the application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a gain override of zero. The tester verifies aurally that the signal is now at a constant audio volume. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 15.3.3.2: Table 33 describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". [...] NOTE: Some NGA codecs allow for limits of dialogue enhancement processing to be carried in the audio stream and will modify the min and max values above. HBBTV,section 15.3.3.4: Dialogue Enhancement Override Request and Response Messages This clause defines a message that may be sent from an HbbTV application to a terminal, and its corresponding response. [...] When the HbbTV application sends this message to the terminal, the terminal shall process the request and change the amount of processing as per the further provisions of this clause. [...] Table 34 - parameters of the org.hbbtv.af.dialogueEnhancementOverride message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementGain * Integer * O [...] HBBTV,section 15.3.3.4: A value of 0 shall disable the dialogue enhancement processing. HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP TS-103-285,section 6.3.2.4: Dialogue Enhancement Requirements on Dialogue Enhancement apply as described in ETSI TS 101 154 [3], clause 6.7.6. TS-101-154,section 6.7.6: Dialogue Enhancement The AC-4 bitstream format features flexible and scalable dialogue enhancement capabilities, which are built into the codec. They are detailed in clause 5.7.8 of ETSI TS 103 190-1 [43] and clause 5.8 of ETSI TS 103 190-2 [46]. The following constraints apply: [...] Decoding: The IRD shall be capable of applying dialogue enhancement carried in the AC-4 elementary stream as described in ETSI TS 103 190-1 [43] and ETSI TS 103 190-2 [46]. TS-103-190-1,section 5.7.8.1: [Dialogue] Introduction The dialogue enhancement tool is a tool to increase intelligibility of the dialogue in an audio scene encoded in AC-4. The underlying algorithm uses metadata encoded in the bitstream to boost the dialogue in the scene. TS-103-190-1,section 4.3.14.1: b_de_data_present - dialogue enhancement data present flag If true, this Boolean indicates that dialogue enhancement data is present in the bitstream. TS-103-190-1,section 4.3.14.3.2: de_max_gain - maximum dialogue enhancement gain This 2-bit element defines the maximum gain (Gmax) allowed for boosting the dialogue: Gmax = (de_max_gain + 1) × 3 [dB] | +AC4 +AC4_DE +AC4_DE_OVERRIDE | ||
| org.hbbtv_AC4-DE0110 | 1 | DE gain override - reset of gain at application exit | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio signaling a maximum limit (carried in the audio stream) of 12dB for dialogue enhancement processing. The application calls the org.hbbtv.af.featureSettingsQuery API method and stores the dialogueEnhancementGain field of the response message in persistent storage. If the dialogueEnhancementGain is zero, the application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a gain override of 12dB; else, the application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a gain override of 0dB. The application exits. A second application is started. The application calls the org.hbbtv.af.featureSettingsQuery API method and checks that the dialogueEnhancementGain field is identical to the previously saved persistent storage. Each response message shall conform with the respective schema. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 15.3.3.2: Table 33 describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". [...] Table 33 - variable parameters of the value field of a response message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementGain * Integer * M [...] dialogueEnhancementGain – The currently-active gain value in dB for the dialogue enhancement processing applied. If DE is switched off or is not supported natively by the terminal, this shall be set to 0. dialogueEnhancementLimit – The range of allowed gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. min – The current allowed minimum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. max – The current allowed maximum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. NOTE: Some NGA codecs allow for limits of dialogue enhancement processing to be carried in the audio stream and will modify the min and max values above. HBBTV,section 15.3.3.4: Dialogue Enhancement Override Request and Response Messages This clause defines a message that may be sent from an HbbTV application to a terminal, and its corresponding response. [...] When the HbbTV application sends this message to the terminal, the terminal shall process the request and change the amount of processing as per the further provisions of this clause. [...] Table 34 - parameters of the org.hbbtv.af.dialogueEnhancementOverride message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementGain * Integer * O [...] HBBTV,section 15.3.3.4: When the application exits, the amount of processing shall return to the levels previously set by the terminal preferences. HBBTV,section N: response__org.hbbtv.af.featureSettingsQuery.dialogueEnhancement.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of dialogueEnhancement, as referred to in clause 15.3.3.2 of the present document. HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP TS-103-285,section 6.3.2.4: Dialogue Enhancement Requirements on Dialogue Enhancement apply as described in ETSI TS 101 154 [3], clause 6.7.6. TS-101-154,section 6.7.6: Dialogue Enhancement The AC-4 bitstream format features flexible and scalable dialogue enhancement capabilities, which are built into the codec. They are detailed in clause 5.7.8 of ETSI TS 103 190-1 [43] and clause 5.8 of ETSI TS 103 190-2 [46]. The following constraints apply: [...] Decoding: The IRD shall be capable of applying dialogue enhancement carried in the AC-4 elementary stream as described in ETSI TS 103 190-1 [43] and ETSI TS 103 190-2 [46]. TS-103-190-1,section 5.7.8.1: [Dialogue] Introduction The dialogue enhancement tool is a tool to increase intelligibility of the dialogue in an audio scene encoded in AC-4. The underlying algorithm uses metadata encoded in the bitstream to boost the dialogue in the scene. TS-103-190-1,section 4.3.14.1: b_de_data_present - dialogue enhancement data present flag If true, this Boolean indicates that dialogue enhancement data is present in the bitstream. TS-103-190-1,section 4.3.14.3.2: de_max_gain - maximum dialogue enhancement gain This 2-bit element defines the maximum gain (Gmax) allowed for boosting the dialogue: Gmax = (de_max_gain + 1) × 3 [dB] | +AC4 +AC4_DE +AC4_DE_OVERRIDE | ||
| org.hbbtv_AC4-DE0120 | 1 | DE gain override - immutable user preferences | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio signaling a maximum limit (carried in the audio stream) of 12dB for dialogue enhancement processing. The application calls the org.hbbtv.af.featureSettingsQuery API method and makes a copy of the dialogueEnhancementGainPreference field. If the dialogueEnhancementGainPreference is zero, the application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a gain override of 12dB; else, the application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a gain override of 0dB. The application calls the org.hbbtv.af.featureSettingsQuery API method and checks that the dialogueEnhancementGainPreference field is identical to the previously saved value. Each response message shall conform with the respective schema. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 15.3.3.2: Table 33 describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". [...] Table 33 - variable parameters of the value field of a response message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementGain * Integer * M [...] dialogueEnhancementGain – The currently-active gain value in dB for the dialogue enhancement processing applied. If DE is switched off or is not supported natively by the terminal, this shall be set to 0. dialogueEnhancementLimit – The range of allowed gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. min – The current allowed minimum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. max – The current allowed maximum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. NOTE: Some NGA codecs allow for limits of dialogue enhancement processing to be carried in the audio stream and will modify the min and max values above. HBBTV,section 15.3.3.4: Dialogue Enhancement Override Request and Response Messages This clause defines a message that may be sent from an HbbTV application to a terminal, and its corresponding response. [...] When the HbbTV application sends this message to the terminal, the terminal shall process the request and change the amount of processing as per the further provisions of this clause. [...] Table 34 - parameters of the org.hbbtv.af.dialogueEnhancementOverride message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementGain * Integer * O [...] HBBTV,section 15.3.3.4: The settings in the user's preferences shall be unchanged. HBBTV,section 15.3.3.4: A value of 0 shall disable the dialogue enhancement processing. HBBTV,section N: response__org.hbbtv.af.featureSettingsQuery.dialogueEnhancement.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC response with method name org.hbbtv.af.featureSettingsQuery and a feature value of dialogueEnhancement, as referred to in clause 15.3.3.2 of the present document. HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP TS-103-285,section 6.3.2.4: Dialogue Enhancement Requirements on Dialogue Enhancement apply as described in ETSI TS 101 154 [3], clause 6.7.6. TS-101-154,section 6.7.6: Dialogue Enhancement The AC-4 bitstream format features flexible and scalable dialogue enhancement capabilities, which are built into the codec. They are detailed in clause 5.7.8 of ETSI TS 103 190-1 [43] and clause 5.8 of ETSI TS 103 190-2 [46]. The following constraints apply: [...] Decoding: The IRD shall be capable of applying dialogue enhancement carried in the AC-4 elementary stream as described in ETSI TS 103 190-1 [43] and ETSI TS 103 190-2 [46]. TS-103-190-1,section 5.7.8.1: [Dialogue] Introduction The dialogue enhancement tool is a tool to increase intelligibility of the dialogue in an audio scene encoded in AC-4. The underlying algorithm uses metadata encoded in the bitstream to boost the dialogue in the scene. TS-103-190-1,section 4.3.14.1: b_de_data_present - dialogue enhancement data present flag If true, this Boolean indicates that dialogue enhancement data is present in the bitstream. TS-103-190-1,section 4.3.14.3.2: de_max_gain - maximum dialogue enhancement gain This 2-bit element defines the maximum gain (Gmax) allowed for boosting the dialogue: Gmax = (de_max_gain + 1) × 3 [dB] | +AC4 +AC4_DE +AC4_DE_OVERRIDE | ||
| org.hbbtv_AC4-DE0130 | 1 | DE gain override - override error code | The application uses an HTML5 media element to play an A/V DASH stream with AC-4 audio. The application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a dialogueEnhancementGain parameter value of "NOTAVALUE" (that is, a string not a number). The application checks that the terminal replies with a valid JSON-RPC error response message with a code value of -24 and a message value of "Dialogue Enhancement override failed". The response message shall conform with the respective schema. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 | AC-4 part 2 as defined in clause 6.3.2 of TS 103 285 [45] | AC4-CIP HBBTV,section 15.3.3.4: Dialogue Enhancement Override Request and Response Messages This clause defines a message that may be sent from an HbbTV application to a terminal, and its corresponding response. [...] Table 34 - parameters of the org.hbbtv.af.dialogueEnhancementOverride message Parameter * Data Type * Mandatory (M) or Optional (O) [...] dialogueEnhancementGain * Integer * O [...] HBBTV,section 15.3.3.4: If the override is not actioned by the terminal, then the terminal shall reply with a JSON-RPC error with a code value of -24 and a message value of "Dialogue Enhancement override failed". | +AC4 +AC4_DE +AC4_DE_OVERRIDE | ||
| org.hbbtv_AC4-DE0150 | 1 | DE change notification - DE enabled/disabled in terminal preference settings | An application that is registered for JSON-RPC notifications from the terminal uses an HTML5 media element to play an A/V DASH stream with AC-4 audio signaling a maximum limit (carried in the audio stream) of 12dB for dialogue enhancement processing. The user enables the dialogue enhancement in the terminal settings. The application receives a dialogueEnhancementPrefChange notification with a value of dialogueEnhancementGainPreference field greater than 0. The user disables the dialogue enhancement in the terminal settings. The application receives a dialogueEnhancementPrefChange notification with value of dialogueEnhancementGainPreference field equal to 0. Each notification message shall conform with the notification__org.hbbtv.af.dialogueEnhancement.schema.json schema. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 15.3.3.3: Dialogue Enhancement Preference Change Message This clause defines a message that may be sent from a terminal to an HbbTV application. This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: The application has registered for notifications of this type; and [...] The user enables/disables Dialogue Enhancement entirely [...] This notification message follows the generic notification message format outlined in clause 9.9.4.1. The message parameters are defined in clause 15.3.3.2. HBBTV,section 9.9.4.1: The JSON-RPC Notifications Notifications messages from the terminal shall only be sent to the HbbTV Application after the specific notification messages have been subscribed for using the subscribe API defined in 9.9.4.2. [...] Subscriptions to notification messages shall apply only to the application that requested them and shall only apply for the lifetime of that application. Notifications using the "org.hbbtv.notify" method follow a generic format as shown here: { "jsonrpc" : "2.0", "method" : "org.hbbtv.notify", "params" : { "msgType" : message type – see below, "value" : { value parameters – see below } } } HBBTV,section 9.9.4.3: Subscribe API The HbbTV namespace for the message name being used, and the subscribe methods string value that terminals shall support is modified to be: "org.hbbtv.subscribe" [...] Table 10d: Notifications that an HbbTV terminal can sent to an HbbTV Application Notification API Section Reference (in this document) msgType [...] Dialogue Enhancement User Preference Change 15.3.3.3 dialogueEnhancementPrefChange HBBTV,section 15.3.3.2: Response Message Table 33 describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". [...] dialogueEnhancementGain – The currently-active gain value in dB for the dialogue enhancement processing applied. If DE is switched off or is not supported natively by the terminal, this shall be set to 0. This may differ from dialogueEnhancementGainPreference if an application has set the gain. The value of dialogueEnhancementGain shall be constrained to the allowed value range of dialogue enhancement processing as indicated by the dialogueEnhancementLimit field. dialogueEnhancementLimit – The range of allowed gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. min – The current allowed minimum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. max – The current allowed maximum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. NOTE: Some NGA codecs allow for limits of dialogue enhancement processing to be carried in the audio stream and will modify the min and max values above. HBBTV,section N: Electronic attachments notification__org.hbbtv.af.dialogueEnhancement.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC notification with method name org.hbbtv.notify and a msgType of dialogueEnhancementPrefChange, as referred to in clause 15.3.3.3 of the present document. HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP TS-103-285,section 6.3.2.4: Dialogue Enhancement Requirements on Dialogue Enhancement apply as described in ETSI TS 101 154 [3], clause 6.7.6. TS-101-154,section 6.7.6: Dialogue Enhancement The AC-4 bitstream format features flexible and scalable dialogue enhancement capabilities, which are built into the codec. They are detailed in clause 5.7.8 of ETSI TS 103 190-1 [43] and clause 5.8 of ETSI TS 103 190-2 [46]. The following constraints apply: [...] Decoding: The IRD shall be capable of applying dialogue enhancement carried in the AC-4 elementary stream as described in ETSI TS 103 190-1 [43] and ETSI TS 103 190-2 [46]. TS-103-190-1,section 5.7.8.1: [Dialogue] Introduction The dialogue enhancement tool is a tool to increase intelligibility of the dialogue in an audio scene encoded in AC-4. The underlying algorithm uses metadata encoded in the bitstream to boost the dialogue in the scene. TS-103-190-1,section 4.3.14.1: b_de_data_present - dialogue enhancement data present flag If true, this Boolean indicates that dialogue enhancement data is present in the bitstream. TS-103-190-1,section 4.3.14.3.2: de_max_gain - maximum dialogue enhancement gain This 2-bit element defines the maximum gain (Gmax) allowed for boosting the dialogue: Gmax = (de_max_gain + 1) × 3 [dB] | +AC4 +AC4_DE | ||
| org.hbbtv_AC4-DE0160 | 1 | DE change notification - gain change by an application | An application that is registered for JSON-RPC notifications from the terminal uses an HTML5 media element to play an A/V DASH stream with AC-4 audio signaling a maximum limit (carried in the audio stream) of 12dB for dialogue enhancement processing. Application requests org.hbbtv.af.featureSettingsQuery to store the returned current values of dialogueEnhancementGain, dialogueEnhancementLimit min attribute, and dialogueEnhancementLimit max attribute. The application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a dialogueEnhancementGain value that is different than zero and the stored current setting value, and which is within the min and max limits stored for current stream. Application receives a dialogueEnhancementPrefChange notification with the value of dialogueEnhancementGain field equal to value in dialogueEnhancementOverride request. Then the application calls the org.hbbtv.af.dialogueEnhancementOverride API method with a dialogueEnhancementGain value equal to zero to disable DE. Application receives a dialogueEnhancementPrefChange notification with the value of dialogueEnhancementGain field equal to zero. Each notification message shall conform with the notification__org.hbbtv.af.dialogueEnhancement.schema.json schema. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 15.3.3.3: Dialogue Enhancement Preference Change Message This clause defines a message that may be sent from a terminal to an HbbTV application. This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: The application has registered for notifications of this type; and [...] A temporary gain change is triggered by this application or by a concurrently running application [...] This notification message follows the generic notification message format outlined in clause 9.9.4.1. The message parameters are defined in clause 15.3.3.2. HBBTV,section 9.9.4.1: The JSON-RPC Notifications Notifications messages from the terminal shall only be sent to the HbbTV Application after the specific notification messages have been subscribed for using the subscribe API defined in 9.9.4.2. [...] Subscriptions to notification messages shall apply only to the application that requested them and shall only apply for the lifetime of that application. Notifications using the "org.hbbtv.notify" method follow a generic format as shown here: { "jsonrpc" : "2.0", "method" : "org.hbbtv.notify", "params" : { "msgType" : message type – see below, "value" : { value parameters – see below } } } HBBTV,section 9.9.4.3: Subscribe API The HbbTV namespace for the message name being used, and the subscribe methods string value that terminals shall support is modified to be: "org.hbbtv.subscribe" [...] Table 10d: Notifications that an HbbTV terminal can sent to an HbbTV Application Notification API Section Reference (in this document) msgType [...] Dialogue Enhancement User Preference Change 15.3.3.3 dialogueEnhancementPrefChange HBBTV,section 15.3.3.2: Response Message Table 33 describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". [...] dialogueEnhancementGain – The currently-active gain value in dB for the dialogue enhancement processing applied. If DE is switched off or is not supported natively by the terminal, this shall be set to 0. This may differ from dialogueEnhancementGainPreference if an application has set the gain. The value of dialogueEnhancementGain shall be constrained to the allowed value range of dialogue enhancement processing as indicated by the dialogueEnhancementLimit field. dialogueEnhancementLimit – The range of allowed gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. min – The current allowed minimum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. max – The current allowed maximum gain value in dB for the dialogue enhancement processing to be applied in the audio decoder. NOTE: Some NGA codecs allow for limits of dialogue enhancement processing to be carried in the audio stream and will modify the min and max values above. HBBTV,section N: Electronic attachments notification__org.hbbtv.af.dialogueEnhancement.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC notification with method name org.hbbtv.notify and a msgType of dialogueEnhancementPrefChange, as referred to in clause 15.3.3.3 of the present document. HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP TS-103-285,section 6.3.2.4: Dialogue Enhancement Requirements on Dialogue Enhancement apply as described in ETSI TS 101 154 [3], clause 6.7.6. TS-101-154,section 6.7.6: Dialogue Enhancement The AC-4 bitstream format features flexible and scalable dialogue enhancement capabilities, which are built into the codec. They are detailed in clause 5.7.8 of ETSI TS 103 190-1 [43] and clause 5.8 of ETSI TS 103 190-2 [46]. The following constraints apply: [...] Decoding: The IRD shall be capable of applying dialogue enhancement carried in the AC-4 elementary stream as described in ETSI TS 103 190-1 [43] and ETSI TS 103 190-2 [46]. TS-103-190-1,section 5.7.8.1: [Dialogue] Introduction The dialogue enhancement tool is a tool to increase intelligibility of the dialogue in an audio scene encoded in AC-4. The underlying algorithm uses metadata encoded in the bitstream to boost the dialogue in the scene. TS-103-190-1,section 4.3.14.1: b_de_data_present - dialogue enhancement data present flag If true, this Boolean indicates that dialogue enhancement data is present in the bitstream. TS-103-190-1,section 4.3.14.3.2: de_max_gain - maximum dialogue enhancement gain This 2-bit element defines the maximum gain (Gmax) allowed for boosting the dialogue: Gmax = (de_max_gain + 1) × 3 [dB] | +AC4 +AC4_DE +AC4_DE_OVERRIDE | ||
| org.hbbtv_AC4-DE0170 | 1 | DE change notification - DE limits change in played stream | An application that is registered for JSON-RPC notifications from the terminal uses an HTML5 media element to play an audio-only DASH stream with AC-4 audio. The AC-4 audio stream signals a maximum limit (carried in the audio stream) of 12dB for dialogue enhancement processing, changing to 3dB after 3 seconds. When the limit changes during the playback, the terminal sends a notification to the application. The notification message carries the new maximum limit in the dialogueEnhancementLimit.max field. Each notification message shall conform with the notification__org.hbbtv.af.dialogueEnhancement.schema.json schema. | 2024-2 | HBBTV 1.7.1 | HBBTV,section 15.3.3.3: Dialogue Enhancement Preference Change Message This clause defines a message that may be sent from a terminal to an HbbTV application. This message shall be sent from a terminal to an HbbTV application if all of the following conditions are true: The application has registered for notifications of this type; and [...] The user sets a new gain for Dialogue Enhancement on the terminal [...] This notification message follows the generic notification message format outlined in clause 9.9.4.1. The message parameters are defined in clause 15.3.3.2. HBBTV,section 9.9.4.1: The JSON-RPC Notifications Notifications messages from the terminal shall only be sent to the HbbTV Application after the specific notification messages have been subscribed for using the subscribe API defined in 9.9.4.2. [...] Subscriptions to notification messages shall apply only to the application that requested them and shall only apply for the lifetime of that application. Notifications using the "org.hbbtv.notify" method follow a generic format as shown here: { "jsonrpc" : "2.0", "method" : "org.hbbtv.notify", "params" : { "msgType" : message type – see below, "value" : { value parameters – see below } } } HBBTV,section 9.9.4.3: Subscribe API The HbbTV namespace for the message name being used, and the subscribe methods string value that terminals shall support is modified to be: "org.hbbtv.subscribe" [...] Table 10d: Notifications that an HbbTV terminal can sent to an HbbTV Application Notification API Section Reference (in this document) msgType [...] Dialogue Enhancement User Preference Change 15.3.3.3 dialogueEnhancementPrefChange HBBTV,section 15.3.3.2: Response Message Table 33 describes the variable parameters of the value field of a response message to an org.hbbtv.af.featureSettingsQuery request message where the "feature" field of the "params" object is set to "dialogueEnhancement". [...] NOTE: Some NGA codecs allow for limits of dialogue enhancement processing to be carried in the audio stream and will modify the min and max values above. HBBTV,section N: Electronic attachments notification__org.hbbtv.af.dialogueEnhancement.schema.json This is the normative JSON schema that will validate for a correctly formed JSON-RPC notification with method name org.hbbtv.notify and a msgType of dialogueEnhancementPrefChange, as referred to in clause 15.3.3.3 of the present document. HBBTV,section 7.3.1.1: General requirements [...] For MPEG DASH, the following shall apply: [...] * Terminals that support one or more NGA codecs as referenced in ETSI TS 103 285 [45] shall support those codec(s) for audio-only content and for audio/video content in combination with HEVC video. * For each of the technologies listed in Table 9a, terminals supporting the broadcast IRD from ETSI TS 101 154 [14] shall also support the related DASH requirement as shown. Table 9a: Mapping from broadcast requirements to DASH requirements Broadcast IRD requirement from ETSI TS 101 154 [14] * Related DASH Requirement * Labels in XML capabilities AC-4 channel-based, immersive and personalized audio as defined in clause 6.7 * AC-4 part 2 as defined in clause 6.3.2 of ETSI TS 103 285 [45] * AC4-CIP TS-103-285,section 6.3.2.4: Dialogue Enhancement Requirements on Dialogue Enhancement apply as described in ETSI TS 101 154 [3], clause 6.7.6. TS-101-154,section 6.7.6: Dialogue Enhancement The AC-4 bitstream format features flexible and scalable dialogue enhancement capabilities, which are built into the codec. They are detailed in clause 5.7.8 of ETSI TS 103 190-1 [43] and clause 5.8 of ETSI TS 103 190-2 [46]. The following constraints apply: [...] Decoding: The IRD shall be capable of applying dialogue enhancement carried in the AC-4 elementary stream as described in ETSI TS 103 190-1 [43] and ETSI TS 103 190-2 [46]. TS-103-190-1,section 5.7.8.1: [Dialogue] Introduction The dialogue enhancement tool is a tool to increase intelligibility of the dialogue in an audio scene encoded in AC-4. The underlying algorithm uses metadata encoded in the bitstream to boost the dialogue in the scene. TS-103-190-1,section 4.3.14.1: b_de_data_present - dialogue enhancement data present flag If true, this Boolean indicates that dialogue enhancement data is present in the bitstream. TS-103-190-1,section 4.3.14.3.2: de_max_gain - maximum dialogue enhancement gain This 2-bit element defines the maximum gain (Gmax) allowed for boosting the dialogue: Gmax = (de_max_gain + 1) × 3 [dB] | +AC4 +AC4_DE | ||
| org.hbbtv_AC4-FRAMERATES0010 | 1 | AC-4 frame rate transition native -> 25 fps at Period boundary transition: HEVC/AC-4 to HEVC/AC-4 | The terminal shall correctly decode and playback audio content from a stream defined by a static DASH MPD containing a period containing AC-4 media at the codec's native frame rate (48000/2048) fps followed by a period containing AC-4 media at a frame rate of 25 fps, both with HEVC video. Audio and video from both periods is played back in sync without glitches and the transition is successful. | 2024-2 2024-1 2023-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. [...] Terminals supporting delivery of HDR, HFR or NGA content via DASH shall also support the 2017 profile from the DVB DASH specification [45]. HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [45] and TS 101 154 [14]. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [14] shall also support the related DASH requirement as shown. HBBTV,section 9.7.4: Table 10c: Accuracy requirements for multi-stream synchronization | Ahead of video by no more than | Behind video by no more than Audio | Largest of A or 35 ms | Largest of A or 50 ms TS-103-285,section 10.5.3: Typically, at a Period boundary no continuity in terms of content offering is ensured. The content may be offered with different codecs, colour primaries, transfer characteristics, language attributes, content protection and so on. The Player should play the content continuously across Periods, but there may be implications in terms of implementation to provide fully continuous and seamless playout. [...] If the Media Presentation has the @type attribute set to "static", then any delay caused by re-initialization should not lead to "missed" content [...] | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-FRAMERATES0020 | 1 | AC-4 frame rate transition 25fps -> 50fps at Period boundary transition: HEVC/AC-4 to HEVC/AC-4 | The terminal shall correctly decode and playback audio content from a stream defined by a static DASH MPD containing a period containing AC-4 media at the frame rate of 25 fps followed by a period containing AC-4 media at a frame rate of 50 fps, both with HEVC video. Audio and video from both periods is played back in sync without glitches and the transition is successful. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. [...] Terminals supporting delivery of HDR, HFR or NGA content via DASH shall also support the 2017 profile from the DVB DASH specification [45]. HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [45] and TS 101 154 [14]. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [14] shall also support the related DASH requirement as shown. TS-103-285,section 10.5.3: Typically, at a Period boundary no continuity in terms of content offering is ensured. The content may be offered with different codecs, colour primaries, transfer characteristics, language attributes, content protection and so on. The Player should play the content continuously across Periods, but there may be implications in terms of implementation to provide fully continuous and seamless playout. ... If the Media Presentation has the @type attribute set to "static", then any delay caused by re-initialization should not lead to "missed" content ... | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-HTML5-ACTIONS-0010 | 2 | Pause AC-4 audio HTML5 media element | Pausing the playback of a HTML5 media element referencing AC-4 that is currently playing, shall cause the video to freeze and the audio to suspend. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.1.1.1: General streaming requirements In Unicast streaming: * Pausing playback shall cause the video to freeze and the audio to suspend. | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-HTML5-ACTIONS-0020 | 2 | Playback of paused AC-4 audio HTML5 media element from next AC-4 sync sample | When resuming the playback of a HTML5 media element referencing AC-4 that has previously been paused, the terminal shall start audio playback at or before the AC-4 sync sample following the pause position. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-1 2020-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused, the terminal shall start playback at or before the IDR following the pause position, [...] preferably from the next frame following the pause position. | +AC4 | ||
| org.hbbtv_AC4-MSTRSYNC0010 | 1 | Synchronised presentation of broadcast MP2TS HEVC (TEMI) video (master) with DASH AC-4 (DASH-PR) audio | When a MediaSynchroniser is initialised with a video/broadcast object in the presenting state with broadcast MPEG 2 TS HEVC video, a TEMI timeline that ticks with 50 ticks per second is selected and located in the adaptation field of TS packets carrying the video elementary stream. Once the DUT has started to present the broadcast video, a call is made to addMediaObject() with an HTML5 Video object referencing DASH AC-4 audio as its 'mediaObject', a valid DASH-PR 'timelineSpecification' string that ticks with 50 ticks per second and no correlation timestamp or tolerance values specified. When the synchronised presentation is started, and again 2 minutes later, the audio and video are observed to be synchronised to within a margin of plus 50ms to minus 35ms for a period of 15 seconds. | 2024-2 2024-1 2023-1 2022-3 2022-2 2022-1 2021-3 2020-1 | The challenge exists but not validated | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [45] and TS 101 154 [14]. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [14] shall also support the related DASH requirement as shown. HBBTV,section 8.2.3.2.2: void addMediaObject (Object mediaObject, String using a TEMI timelineSelector, CorrelationTimestamp correlationTimestamp, Number tolerance) [...] Adds a media object, i.e. video/broadcast object, AV Control object or HTML5 media object, to the MediaSynchroniser. If the MediaSynchroniser was initialised with the initMediaSynchroniser method, or if inter-device synchronisation has been enabled, then the terminal shall start to synchronise the media object to other media objects associated to this MediaSynchroniser as a result of this method call. HBBTV,section 10.2.8.3: Terminals shall at least support the combinations listed as mandatory in clause 10.2.8.4. [...] The terminal shall implement the MediaSynchroniser API defined in clause 8.2.3. HBBTV,section 10.2.8.4: HbbTV terminals shall support the presentation of at least the combinations of media type, systems layer, timeline and delivery protocol for multi-stream synchronisation, as shown in Table 14. [Row 1 of Table 14] HBBTV,section 13.3.2: MPEG DASH Period Relative | MPEG DASH streamed via broadband. HBBTV,section 9.7.4: The minimum accuracy for multi-stream and inter-device synchronisation for a given terminal is the largest of: * 10ms (being the duration of 1/2 a frame of video at 50fps); * the duration of 1/2 tick of any timeline selected (during the corresponding initMediaSynchroniser or addMediaObject method call) by the HbbTV application for any of the streams under the control of the MediaSynchroniser object; * the duration of 1/2 tick of the Synchronisation timeline (see clause 13.4.3.2) if inter-device synchronisation is being performed. | +AC4 +HEVC_HD_8 | |
| org.hbbtv_AC4-NOT-SUPPORTED | 1 | Play an alternative Representation if AC-4 is not supported. | The DASH MPD contains in the same Period an Adaptation Set signalling profile "urn:dvb:dash:profile:dvb-dash:2017" with AC-4 audio and Role@value set to "main", and a second Adaptation Set signalling profile "urn:dvb:dash:profile:dvb-dash:2014" with HE-AAC audio and Role@value not set to "main". A terminal that doesn't support AC-4 shall playback the HE-AAC audio Representation. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 6.1.2: If multiple Adaptation Sets have a @value set to "main" then the Player will choose which one of these Adaptation Sets is the most appropriate [...] TS-103-285,section 10.1: Players shall support the 2017 DVB profile if they support DASH playback of HDR, HFR or NGA content. [...] Players shall be able play the content described by the profile-specific MPD TS-103-285,section 10.10: Players shall be able to play the content described by the profile-specific MPD [...] Where there are multiple Adaptation Sets of the same component type [...] TS-103-285,section 10.17: Compatibility. Players shall ignore any AdaptationSet or Representation that has a @codecs [...] attribute that the player does not understand or cannot process. HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. | -AC4 | ||
| org.hbbtv_AC4-PERIOD-TRANS0010 | 1 | Period boundary transitions: HEVC/AC-4 to HEVC/AAC | The terminal shall correctly decode and playback audio content from a stream defined by a static DASH MPD containing a period containing AC-4 media followed by a period containing AAC media, both with HEVC video. Audio and video from both periods is played back in its entirety without artifacts or glitches and the transition is successful. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. [...] Terminals supporting delivery of HDR, HFR or NGA content via DASH shall also support the 2017 profile from the DVB DASH specification [45]. TS-103-285,section 10.5.3: Typically, at a Period boundary no continuity in terms of content offering is ensured. The content may be offered with different codecs, colour primaries, transfer characteristics, language attributes, content protection and so on. The Player should play the content continuously across Periods, but there may be implications in terms of implementation to provide fully continuous and seamless playout. [...] If the Media Presentation has the @type attribute set to "static", then any delay caused by re-initialization should not lead to "missed" content ... | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-PERIOD-TRANS0020 | 1 | Period boundary transitions: HEVC/AAC to HEVC/AC-4 | The terminal shall correctly decode and playback audio content from a stream defined by a static DASH MPD containing a period containing AAC media followed by a period containing AC-4 media, both with HEVC video. Audio and video from both periods is played back in its entirety without artifacts or glitches and the transition is successful. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. ... Terminals supporting delivery of HDR, HFR or NGA content via DASH shall also support the 2017 profile from the DVB DASH specification [45]. TS-103-285,section 10.5.3: Typically, at a Period boundary no continuity in terms of content offering is ensured. The content may be offered with different codecs, colour primaries, transfer characteristics, language attributes, content protection and so on. The Player should play the content continuously across Periods, but there may be implications in terms of implementation to provide fully continuous and seamless playout. [...] If the Media Presentation has the @type attribute set to "static", then any delay caused by re-initialization should not lead to "missed" content ... | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-PERIOD-TRANS0030 | 1 | Period boundary transitions: AC-4 continuous | The terminal shall correctly decode and play audio content from a stream defined by a static DASH MPD containing two Periods, each containing an AC-4 audio AdaptationSet with the same AdaptationSet@id value, each containing an HEVC video AdaptationSet with a second AdaptationSet@id value, and each of the AdaptationSets in the second Period carrying a SupplementalProperty descriptor with @schemeIdUri set to urn:dvb:dash:period_continuity:2014 and @value matching the Period@id attribute of the first Period, and the Periods meeting the signalling and content constraints for period continuity. Audio and video is played back seamlessly through the period boundary without artifacts or glitches. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. [...] Terminals supporting delivery of HDR, HFR or NGA content via DASH shall also support the 2017 profile from the DVB DASH specification [45]. TS-103-285,section 10.5.2: Content providers may explicitly signal that Adaptation Sets across Periods are period-continuous. It may do this by providing the following signalling ... TS-103-285,section 10.5.3: If furthermore the Adaptation Set is period-continuous (as defined in clause 10.5.2.2), i.e. the presentation times are continuous and this is signalled in the MPD, then the Player shall seamlessly play the content across the Period boundary under the constraints in clause 10.4. | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-PLAYBACK0002 | 1 | Playback of 2.0 Channel AC-4 audio only HbbTV ISOBMFF Live profile in a HTML5 video object | The terminal shall correctly decode and present 2.0 Channel AC-4 audio from an audio only DASH MPD with HbbTV ISOBMFF Live profile when played in a HTML5 video object. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Additional audio formats are defined by references from TS 103 285 [] and TS 101 154 []. The labels that shall be used for these formats are defined in table 10. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 10, terminals supporting the broadcast IRD from TS 101 154 [] shall also support the related DASH requirement as shown. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +AC4 | ||
| org.hbbtv_AC4-SEEKACCURACY0010 | 1 | Seek to start of video media segment in live period and playback in alignment with AC-4 audio | An application starts DASH content playback with AC-4 audio and then seeks to a position that is in a live period and is identifiable from the MPD as being the start of a media segment. The seek shall be frame accurate. The position reported by the media player API reports the true media position after the seek. | 2024-2 2024-1 2023-1 2022-3 2020-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.1.3: MPEG DASH / ISO BMFF Seeks to a position shall be performed precisely if: 1) the position is within a live Period and is identifiable from the MPD as being the start of a media segment, or [...] In all cases, the position on the media timeline reported by the appropriate APIs shall meet the requirements specified for those APIs and shall reflect the true media position. This may mean that the position reported following a seek is different to the position requested in the seek call. | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-SEEKACCURACY0030 | 1 | seek to other positions in AC-4 DASH content - live period - nearest position before target | An application starts DASH content playback with AC-4 audio and then seeks to a position that is in a live Period but not identifiable from the MPD as being the start of a media segment and where the nearest position that is identifiable as random access point is before the target position but after the current position. The seek shall be either frame accurate or the seek shall navigate the media position to that nearest position. The position reported by the media player API reports the true media position after the seek. | 2024-2 2024-1 2023-3 2023-1 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 | The challenge exists but not validated | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.1.3: MPEG DASH / ISO BMFF [...] Seeks to other positions should position the media object precisely at the requested position. If they do not, the new media position shall be at the nearest position for which precise seeking is required that moves the media position in the direction implied by the seek request. [...] In all cases, the position on the media timeline reported by the appropriate APIs shall meet the requirements specified for those APIs and shall reflect the true media position. This may mean that the position reported following a seek is different to the position requested in the seek call. | +AC4 | |
| org.hbbtv_AC4-WEBAUDIO0010 | 2 | PCM audio from memory played in combination with broadcasted AC-4 | A broadcast-related HbbTV application that is connected to the broadcast of the current channel which includes HEVC video and AC4 audio. The application loads 16-bit PCM audio via XMLHttpRequest and then plays that through the Web Audio API. The PCM audio is heard and the broadcast video playback is not interrupted. The audio from the Web Audio API shall be either mixed with AC-4 broadcast audio or temporarily replace it, i.e after the audio from the Web Audio Api ends, the AC-4 broadcast audio plays or continues playing. | 2024-2 2024-1 2023-3 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: The audio formats are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.4 with the addition of non-interleaved IEEE 32-bit linear PCM as defined in clause 2.9 of Web Audio [65]. HBBTV,section 10.2.11: Terminals shall support playing audio from memory via the Web Audio API simultaneously with playing Audio delivered via broadcast (either with or without video). ... The following shall apply regardless of whether the two audio sources are mixed properly or if either or both of the approximations are followed. - The playback of the audio from memory shall not disturb the playback of the video from the main A/V, e.g. the video shall not be paused, no frames shall be dropped and no black frames shall be inserted. - Where an HbbTV terminal supports bitstream output(s) (e.g. S/PDIF), the terminal shall not change the number of channels in a bitstream output at the start or end of outputting audio from memory. | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_AC4-WEBAUDIO0020 | 2 | MP3 Audio from memory mixed with broadcasted AC-4 | A broadcast-related HbbTV application that is connected to the broadcast of the current channel which includes HEVC video and AC4 audio. The application loads MP3 audio via XMLHttpRequest, decodes it via AudioContext.decodeAudioData and then plays that through the Web Audio API. The MP3 audio is heard and the broadcast video playback is not interrupted. The audio shall be either mixed with AC-4 broadcast audio or temporarily replace it, i.e after the audio from the Web Audio Api ends, the AC-4 broadcast audio plays or continues playing. | 2024-2 2024-1 2023-3 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: The audio formats are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.4 with the addition of non-interleaved IEEE 32-bit linear PCM as defined in clause 2.9 of Web Audio [65]. HBBTV,section 10.2.11: Terminals shall support playing audio from memory via the Web Audio API simultaneously with playing Audio delivered via broadcast (either with or without video). ... The following shall apply regardless of whether the two audio sources are mixed properly or if either or both of the approximations are followed. - The playback of the audio from memory shall not disturb the playback of the video from the main A/V, e.g. the video shall not be paused, no frames shall be dropped and no black frames shall be inserted. - Where an HbbTV terminal supports bitstream output(s) (e.g. S/PDIF), the terminal shall not change the number of channels in a bitstream output at the start or end of outputting audio from memory. HBBTV,section 10.2.1: For audio played by the Web Audio API [65], the following shall apply; - Non-interleaved IEEE 32-bit linear PCM shall be supported as defined in clause 2.9 of Web Audio [65]. - MPEG1_L3 (as defined in clause 8.1 of the OIPF Media Formats specification [2]) shall be supported for the AudioContext.decodeAudioData() method. | +AC4 +HEVC_HD_8 | ||
| org.hbbtv_ACCESSIBILITY0010 | 1 | audio description enabled | When the user has enabled audio description streams, the audioDescriptionEnabled property of the Configuration class returns true. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.20.3: readonly Boolean audioDescriptionEnabled Shall be set to false if audio description is disabled by the terminal, otherwise shall be set to true. If set false applications should not enable audio description using the component selection API of the supported media objects i.e. AV Control object, video/broadcast object and HTML5 media elements. HBBTV,section 10.2.7.2: Terminals shall support a method for the user to enable and disable audio description streams as defined in clause 7.1.2 of the present document. Terminals shall use this information when playing content to determine whether to present audio description streams instead of the normal audio (or in addition to the normal audio where receiver mix audio description is supported). | |||
| org.hbbtv_ACCESSIBILITY0020 | 1 | audio description disabled | When the user has disabled audio description streams, the audioDescriptionEnabled property of the Configuration class returns false. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.20.3: readonly Boolean audioDescriptionEnabled Shall be set to false if audio description is disabled by the terminal, otherwise shall be set to true. If set false applications should not enable audio description using the component selection API of the supported media objects i.e. AV Control object, video/broadcast object and HTML5 media elements. HBBTV,section 10.2.7.2: Terminals shall support a method for the user to enable and disable audio description streams as defined in clause 7.1.2 of the present document. Terminals shall use this information when playing content to determine whether to present audio description streams instead of the normal audio (or in addition to the normal audio where receiver mix audio description is supported). | |||
| org.hbbtv_ADD00010 | 1 | AV Object Toggle Whole screen (MP4 640x720i HP@L4) | Terminals shall be able to resize the A/V Control object from the top-left quarter of the screen to whole-screen. For both sizes, 640x720i video shall not be cropped, it shall be positioned in the centre of A/V Control object and its aspect ratio shall be preserved. Under these conditions the video shall be scaled to fill as much of the A/V Control object as possible. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum Terminal Capabilities: Terminals shall be able to scale video down to 1/4 by 1/4 | |||
| org.hbbtv_ADD00020 | 1 | AV Object Toggle Whole screen (MP4 720x576i MP@L3) | Terminals shall be able to resize the A/V Control object from the top-left quarter of the screen to whole-screen. For both sizes, 720x576i video shall not be cropped, it shall be positioned in the centre of A/V Control object and its aspect ratio shall be preserved. Under these conditions the video shall be scaled to fill as much of the A/V Control object as possible. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum Terminal Capabilities: Terminals shall be able to scale video down to 1/4 by 1/4 | |||
| org.hbbtv_ADD00030 | 1 | AV Object Toggle Whole screen (MP4 352x288i MP@L3) | Terminals shall be able to resize the A/V Control object from the top-left quarter of the screen to whole-screen. For both sizes, 352x288i video shall not be cropped, it shall be positioned in the centre of A/V Control object and its aspect ratio shall be preserved. Under these conditions the video shall be scaled to fill as much of the A/V Control object as possible. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Minimum Terminal Capabilities: Terminals shall be able to scale video down to 1/4 by 1/4 | |||
| org.hbbtv_ADINS001 | 1 | HTML5 mid-roll advert insertion, DASH E-AC-3/HEVC and HEAAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with E-AC-3/HEVC is paused, and preloaded DASH with HE-AAC/AVC_HD_25 media is played in its entirety, and then the playing of the DASH media is resumed. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 2021-3 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The video element from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] HBBTV,section 9.6.12: The end of presentation of an HTML5 media element is notified to the application by means of an 'ended' event. This event shall not arrive before the last frame of video or the last audio sample is guaranteed to be presented (e.g. because it has entered a display processing pipeline). It should arrive within 80 ms of the last frame of video or the last audio sample being presented (whichever is the later) and shall be received within 250 ms of that time. NOTE: When considered with the requirements in clause 9.6.3, this means that the transition at the end of an advert, either to another advert or back to the content, should be possible within 330ms but may be up to 500 ms. | +EAC3 +HEVC_HD_8 | ||
| org.hbbtv_ADINS002 | 1 | HTML5 mid-roll advert insertion, DASH E-AC-3 audio only and HE-AAC audio only | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH E-AC-3 audio only is paused, and preloaded DASH with HE-AAC audio only media is played in its entirety, and then the playing of the DASH media is resumed. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 2021-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The video element from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references only audio content, the terminal shall start playback at or before the audio RAP following the pause position. When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section E.1: Annex E (normative): Profiles of MPEG DASH [...] Unlike the previous version of this annex, this version also supports adaptive delivery of radio services. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] HBBTV,section 9.6.12: The end of presentation of an HTML5 media element is notified to the application by means of an 'ended' event. This event shall not arrive before the last frame of video or the last audio sample is guaranteed to be presented (e.g. because it has entered a display processing pipeline). It should arrive within 80 ms of the last frame of video or the last audio sample being presented (whichever is the later) and shall be received within 250 ms of that time. NOTE: When considered with the requirements in clause 9.6.3, this means that the transition at the end of an advert, either to another advert or back to the content, should be possible within 330ms but may be up to 500 ms. | +EAC3 | ||
| org.hbbtv_ADINS003 | 1 | HTML5 mid-roll advert insertion, DASH E-AC-3/AVC_HD_25 and MP4 HE-AAC/AVC_SD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with E-AC-3/AVC_HD_25 is paused, and preloaded MP4 with HE-AAC/AVC_SD_25 media is played in its entirety, and then the playing of the DASH media is resumed. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 2021-3 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The video element from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] HBBTV,section 9.6.12: The end of presentation of an HTML5 media element is notified to the application by means of an 'ended' event. This event shall not arrive before the last frame of video or the last audio sample is guaranteed to be presented (e.g. because it has entered a display processing pipeline). It should arrive within 80 ms of the last frame of video or the last audio sample being presented (whichever is the later) and shall be received within 250 ms of that time. NOTE: When considered with the requirements in clause 9.6.3, this means that the transition at the end of an advert, either to another advert or back to the content, should be possible within 330ms but may be up to 500 ms. | +EAC3 +HEVC_HD_8 | ||
| org.hbbtv_ADINS004 | 1 | HTML5 post-roll advert insertion, DASH E-AC-3/HEVC and MP4 HE-AAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with E-AC-3/HEVC has ended, and preloaded MP4 with HE-AAC/AVC_HD_25 media is played in its entirety. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-2 2021-1 2020-3 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The video element from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | +EAC3 +HEVC_HD_8 | ||
| org.hbbtv_ADINS005 | 1 | HTML5 pre-roll advert insertion, DASH E-AC-3/HEVC and MP4 HE-AAC/AVC_HD_25 | Content is presented without artefacts or glitches when a preloaded MP4 with HE-AAC/AVC_HD_25 media is played in its entirety, and then a HTML5 media element referencing DASH with E-AC-3/HEVC is played. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The video element from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | +EAC3 +HEVC_HD_8 | ||
| org.hbbtv_ADINS006 | 1 | HTML5 mid-roll advert insertion with 3 media elements, DASH E-AC-3/HEVC, MP4 HE-AAC/AVC_HD_25 and DASH HE-AAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with E-AC-3/HEVC is paused, and preloaded MP4 with HE-AAC/AVC_SD_25 media is played and then paused, and then a preloaded HTML5 media element referencing DASH with HE-AAC/AVC_HD_25 is played. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The video element from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] HBBTV,section 9.6.12: The end of presentation of an HTML5 media element is notified to the application by means of an 'ended' event. This event shall not arrive before the last frame of video or the last audio sample is guaranteed to be presented (e.g. because it has entered a display processing pipeline). It should arrive within 80 ms of the last frame of video or the last audio sample being presented (whichever is the later) and shall be received within 250 ms of that time. NOTE: When considered with the requirements in clause 9.6.3, this means that the transition at the end of an advert, either to another advert or back to the content, should be possible within 330ms but may be up to 500 ms. | +EAC3 +HEVC_HD_8 | ||
| org.hbbtv_ADINS007 | 1 | HTML5 mid-roll advert insertion, MP4 E-AC-3/HEVC and MP4 HE-AAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing MP4 content with E-AC3/HEVC is paused, and preloaded MP4 with HEAAC/AVC_HD_25 media is played in its entirety, and then the playing of the E-AC3/HEVC media is resumed. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 2021-3 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The video element from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] HBBTV,section 9.6.12: The end of presentation of an HTML5 media element is notified to the application by means of an 'ended' event. This event shall not arrive before the last frame of video or the last audio sample is guaranteed to be presented (e.g. because it has entered a display processing pipeline). It should arrive within 80 ms of the last frame of video or the last audio sample being presented (whichever is the later) and shall be received within 250 ms of that time. NOTE: When considered with the requirements in clause 9.6.3, this means that the transition at the end of an advert, either to another advert or back to the content, should be possible within 330ms but may be up to 500 ms. | +EAC3 +HEVC_HD_8 | ||
| org.hbbtv_ADINS008 | 1 | HTML5 mid-roll advert insertion with 3 media elements, DASH E-AC-3/HEVC, MP4 HE-AAC/AVC_SD_25 and MP4 HE-AAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with E-AC-3/HEVC is paused, and preloaded MP4 with HE-AAC/AVC_SD_25 media is played and then paused, and then a preloaded HTML5 media element referencing MP4 with HE-AAC/AVC_HD_25 is played. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The video element from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] HBBTV,section 9.6.12: The end of presentation of an HTML5 media element is notified to the application by means of an 'ended' event. This event shall not arrive before the last frame of video or the last audio sample is guaranteed to be presented (e.g. because it has entered a display processing pipeline). It should arrive within 80 ms of the last frame of video or the last audio sample being presented (whichever is the later) and shall be received within 250 ms of that time. NOTE: When considered with the requirements in clause 9.6.3, this means that the transition at the end of an advert, either to another advert or back to the content, should be possible within 330ms but may be up to 500 ms. | +EAC3 +HEVC_HD_8 | ||
| org.hbbtv_ADINS009 | 1 | HTML5 mid-roll advert insertion, MP4 E-AC-3 audio only and DASH HE-AAC audio only | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing MP4 with E-AC-3 audio only is paused, and preloaded DASH with HE-AAC audio only media is played in its entirety, and then the playing of the E-AC-3 media is resumed. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The video element from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references only audio content, the terminal shall start playback at or before the audio RAP following the pause position. When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section E.1: Annex E (normative): Profiles of MPEG DASH [...] Unlike the previous version of this annex, this version also supports adaptive delivery of radio services. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] HBBTV,section 9.6.12: The end of presentation of an HTML5 media element is notified to the application by means of an 'ended' event. This event shall not arrive before the last frame of video or the last audio sample is guaranteed to be presented (e.g. because it has entered a display processing pipeline). It should arrive within 80 ms of the last frame of video or the last audio sample being presented (whichever is the later) and shall be received within 250 ms of that time. NOTE: When considered with the requirements in clause 9.6.3, this means that the transition at the end of an advert, either to another advert or back to the content, should be possible within 330ms but may be up to 500 ms. | +EAC3 | ||
| org.hbbtv_ADINS010 | 1 | HTML5 mid-roll advert insertion, DASH E-AC-3/HEVC with in-band EBU-TT-D subtitles and MP4 HE-AAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with E-AC3/HEVC is paused, and preloaded MP4 with HEAAC/AVC_HD_25 media is played in its entirety, and then the playing of the DASH media is resumed. In-band EBU-TT-D subtitles are displayed without artefacts and continue to be presented in sync with content. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2019-1 2018-3 2018-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 7.3.1.5.1: EBU-TT-D subtitles shall be supported in-band: * with MPEG DASH content as defined in annex E and the DVB DASH profile [45]. * with non-adaptive ISOBMFF content as defined by [44] streamed via HTTP. * (if the download option is supported) with ISOBMFF content as defined by [44] that has been downloaded by the terminal. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] HBBTV,section 9.6.12: The end of presentation of an HTML5 media element is notified to the application by means of an 'ended' event. This event shall not arrive before the last frame of video or the last audio sample is guaranteed to be presented (e.g. because it has entered a display processing pipeline). It should arrive within 80 ms of the last frame of video or the last audio sample being presented (whichever is the later) and shall be received within 250 ms of that time. NOTE: When considered with the requirements in clause 9.6.3, this means that the transition at the end of an advert, either to another advert or back to the content, should be possible within 330ms but may be up to 500 ms. | +EAC3 | ||
| org.hbbtv_ADINS011 | 1 | HTML5 mid-roll advert insertion, DASH E-AC-3/HEVC with out-of-band EBU-TT-D subtitles and MP4 HE-AAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with E-AC-3/HEVC is paused, and preloaded MP4 with HE-AAC/AVC_HD_25 media is played in its entirety, and then the playing of the DASH media is resumed. Out-of-band EBU-TT-D subtitles are displayed without artefacts and continue to be presented in sync with content. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-2 2021-1 2020-3 2020-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 7.3.1.5.1: EBU-TT-D subtitles shall be supported out of band irrespective of how the A/V content is being or has been delivered. In this case terminals shall support EBU-TT-D subtitles contained in a single XML document delivered via HTTP [...] [...] Terminals shall support the API extensions for controlling subtitles in either the EBU-TT-D format or in the same format as that used in broadcast services. These are [SM1] defined in clause A.2.5 for the AV Control object and in clause A.2.12 for use with the HTML5 media objects. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] HBBTV,section 9.6.12: The end of presentation of an HTML5 media element is notified to the application by means of an 'ended' event. This event shall not arrive before the last frame of video or the last audio sample is guaranteed to be presented (e.g. because it has entered a display processing pipeline). It should arrive within 80 ms of the last frame of video or the last audio sample being presented (whichever is the later) and shall be received within 250 ms of that time. NOTE: When considered with the requirements in clause 9.6.3, this means that the transition at the end of an advert, either to another advert or back to the content, should be possible within 330ms but may be up to 500 ms. | +EAC3 | ||
| org.hbbtv_ADINS012 | 1 | HTML5 mid-roll advert insertion, DASH HEAAC/AVC_HD_25 and MP4 HEAAC/AVC_SD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with HEAAC/AVC_HD_25 media is paused, and preloaded MP4 with HEAAC/AVC_SD_25 media is played in its entirety, and then the playing of the DASH media is resumed. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | |||
| org.hbbtv_ADINS013 | 1 | HTML5 post-roll advert insertion, DASH HEAAC/AVC_HD_25 and MP4 HEAAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with HEAAC/AVC_HD_25 media is ended, and preloaded MP4 with HEAAC/AVC_HD_25 media is played in its entirety. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-2 2020-3 2020-2 2020-1 2019-3 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met: [...] * the second media element has not been played HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | |||
| org.hbbtv_ADINS014 | 1 | HTML5 pre-roll advert insertion, DASH HEAAC/AVC_HD_25 and MP4 HEAAC/AVC_HD_25 | Content is presented without artefacts or glitches when an MP4 with HEAAC/AVC_HD_25 media is played in its entirety, and then an HTML5 media element referencing DASH with HEAAC/AVC_HD_25 media is played. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-3 2020-2 2020-1 2019-3 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met: [...] * the second media element has not been played HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | |||
| org.hbbtv_ADINS024 | 1 | HTML5 pre-roll advert insertion, DASH HEAAC/AVC_HD_25 and DASH HEAAC/AVC_HD_25 | Content is presented without artefacts or glitches when a DASH stream with HEAAC/AVC_HD_25 media is played in its entirety and then an HTML5 media element referencing DASH with HEAAC/AVC_HD_25 media is played. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met: [...] * the second media element has not been played HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | |||
| org.hbbtv_ADINS025 | 1 | HTML5 mid-roll advert insertion with 3 video elements, DASH HEAAC/AVC_HD_25, MP4 HEAAC/AVC_HD_25, DASH HEAAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with HEAAC/AVC_HD_25 media is paused, and preloaded MP4 with HEAAC/AVC_HD_25 media is played in its entirety, and then a preloaded HTML5 media element referencing DASH with HEAAC/AVC_HD_25 media is played. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | |||
| org.hbbtv_ADINS027 | 1 | HTML5 mid-roll advert insertion with 3 video elements, DASH HEAAC/AVC_HD_25, MP4 HEAAC/AVC_SD_25, MP4 HEAAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with HEAAC/AVC_HD_25 is paused, and preloaded MP4 with HEAAC/AVC_SD_25 media is played in its entirety, and then a preloaded HTML5 media element referencing MP4 with HEAAC/AVC_HD_25 is played. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | |||
| org.hbbtv_ADINS030 | 1 | HTML5 mid-roll advert insertion, DASH HEAAC/AVC_HD_25 and DASH HEAAC/AVC_SD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with HEAAC/AVC_HD_25 media is paused, and preloaded DASH with HEAAC/AVC_SD_25 media is played in its entirety, and then the playing of the first DASH media is resumed. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused and references video content, the terminal shall start video playback at or before the IDR following the pause position. [...] When resuming playback, the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | |||
| org.hbbtv_ADINS101 | 1 | HTML5 transition from MP4 with HEAAC/AVC_HD_25 to preloaded DASH HEAAC/AVC_HD_25 media in less than 250ms | When a currently playing HTMLMediaElement referencing MP4 content with HEAAC/AVC_HD_25 media is paused and play is called on a preloaded HTMLMediaElement referencing DASH content with HEAAC/AVC_HD_25 media (beginning with a random access point) in the same spin of the event loop, the terminal shall transition to presenting the second HTMLMediaElement in less than 250ms | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.1: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] For MPEG DASH, the following shall apply; * AVC_SD_25 and AVC_HD_25 shall be supported. The conditions on support for HEVC_HD_25_8, HEVC_HD_25_10, and HEVC_UHD_25 in clause 7.3.1.3 shall apply. * HE-AAC shall be supported. The conditions on support for E-AC3 in table 9 shall apply. The only system format required for MPEG DASH in the present document is ISOBMFF. HBBTV,section 9.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Non-adaptively streamed video and/or audio as defined in clause 7.3.2.1 of the present document shall be supported with the content identified by an HTTP URL [...] * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section 9.6.2: The terminal shall support the existence within the same DOM of at least one HTML5 media element that is playing together with at least two HTML5 media elements in a paused state, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section 9.6.3: The delay between the end of presentation of an HTML5 media element and starting presentation of another HTML5 media element shall be less than 250ms if all of the following conditions are met [...] the pause() function on the first HTML5 media element and the play() function on the second HTML5 media element are called within the same spin of the event loop HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML media elements [...] | |||
| org.hbbtv_ANALYTICS0010 | 1 | Beacon is sent on application termination due to service change | When a running broadcast-related service-bound application has added an event listener for the visibilitychange event that calls sendBeacon when the document.visibilityState attribute becomes 'hidden', then, when the user changes the selected channel, the requested Beacon is sent within 5 seconds. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.25: It shall be possible for an HbbTV application to cause beacon data to be transmitted when the application is terminated or hidden by calling sendBeacon in the handler of a visibilitychange event when document.visibilityState has become ‘hidden’. The data should be transmitted as soon as possible and shall be transmitted within 5 seconds in each of the following cases: - termination of an HbbTV application due a change in the selected broadcast service (see clause 6.2.2.2) HBBTV,section 6.2.2.11: During the process of stopping an application, terminals shall ensure that a visibilitychange event is sent with document.visibilityState set to 'hidden' such that the requirements of clause A.3.25 are satisfied. TS-102-809,section 5.3.5.3: service_bound_flag: If this flag is set to "1", the application is only associated with the current service and so the process of killing the application shall start at the beginning of the service change regardless of the contents of the destination AIT. Beacon,section 3.1: The sendBeacon method transmits data provided by the data parameter to the URL provided by the url parameter: | |||
| org.hbbtv_ANALYTICS0020 | 1 | Beacon is sent on application termination due to AIT change | When a running broadcast-related application has added an event listener for the visibilitychange event that calls sendBeacon when the document.visibilityState attribute becomes 'hidden', then, when the AIT changes to set the application control code to KILL, the requested Beacon is sent within 5 seconds. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.25: It shall be possible for an HbbTV application to cause beacon data to be transmitted when the application is terminated or hidden by calling sendBeacon in the handler of a visibilitychange event when document.visibilityState has become ‘hidden’. The data should be transmitted as soon as possible and shall be transmitted within 5 seconds in each of the following cases: ... - termination of an HbbTV application due to a change in AIT signalling (see clause 6.2.2.3) HBBTV,section 6.2.2.3: Figure 14 shows the rules that shall apply if the AIT changes or a broadcast-related application exits while a broadcast service is selected. ... Is it signalled with the control code KILL? Yes: Kill currently running application HBBTV,section 6.2.2.11: During the process of stopping an application, terminals shall ensure that a visibilitychange event is sent with document.visibilityState set to 'hidden' such that the requirements of clause A.3.25 are satisfied. Beacon,section 3.1: The sendBeacon method transmits data provided by the data parameter to the URL provided by the url parameter: | |||
| org.hbbtv_ANALYTICS0040 | 1 | Beacon is sent on application termination due to application exit | When a running application has added an event listener for the visibilitychange event that calls sendBeacon when the document.visibilityState attribute becomes 'hidden', then, when the application calls Application.destroyApplication(), the requested Beacon is sent within 5 seconds. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.25: It shall be possible for an HbbTV application to cause beacon data to be transmitted when the application is terminated or hidden by calling sendBeacon in the handler of a visibilitychange event when document.visibilityState has become ‘hidden’. The data should be transmitted as soon as possible and shall be transmitted within 5 seconds in each of the following cases: ... - termination of an HbbTV application due to the application exiting HBBTV,section 6.2.2.11: Any application shall be stopped under the following circumstances: - The application itself exits using the Application.destroyApplication() method (as defined in clause 7.2.2 of the OIPF DAE specification [1]). HBBTV,section 6.2.2.11: During the process of stopping an application, terminals shall ensure that a visibilitychange event is sent with document.visibilityState set to 'hidden' such that the requirements of clause A.3.25 are satisfied. Beacon,section 3.1: The sendBeacon method transmits data provided by the data parameter to the URL provided by the url parameter: | |||
| org.hbbtv_ANALYTICS0050 | 1 | Beacon is sent on application termination due to user EXIT function | When a running application has added an event listener for the visibilitychange event that calls sendBeacon when the document.visibilityState attribute becomes 'hidden', then, when the user presses the "EXIT or comparable button", the requested Beacon is sent within 5 seconds. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.25: It shall be possible for an HbbTV application to cause beacon data to be transmitted when the application is terminated or hidden by calling sendBeacon in the handler of a visibilitychange event when document.visibilityState has become ‘hidden’. The data should be transmitted as soon as possible and shall be transmitted within 5 seconds in each of the following cases: ... - termination of an HbbTV application by the user using the “EXIT or comparable button” mechanism as defined in clause 10.2.2.1 HBBTV,section 6.2.2.11: Any application shall be stopped under the following circumstances: ... The user manually terminates the application using the "EXIT or comparable button" mechanism as defined in clause 10.2.2.1. HBBTV,section 6.2.2.11: During the process of stopping an application, terminals shall ensure that a visibilitychange event is sent with document.visibilityState set to 'hidden' such that the requirements of clause A.3.25 are satisfied. Beacon,section 3.1: The sendBeacon method transmits data provided by the data parameter to the URL provided by the url parameter: | |||
| org.hbbtv_ANALYTICS0060 | 1 | Beacon is sent on application termination due to source selection | When a running broadcast-independent application has added an event listener for the visibilitychange event that calls sendBeacon when the document.visibilityState attribute becomes 'hidden', then, when the user selects one of the terminal's external video inputs or other sources, the requested Beacon is sent within 5 seconds. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.25: It shall be possible for an HbbTV application to cause beacon data to be transmitted when the application is terminated or hidden by calling sendBeacon in the handler of a visibilitychange event when document.visibilityState has become ‘hidden’. The data should be transmitted as soon as possible and shall be transmitted within 5 seconds in each of the following cases: ... - termination of an HbbTV application due to selection of a different "source" (e.g. an HDMI input being selected on a television) HBBTV,section 6.2.2.11: During the process of stopping an application, terminals shall ensure that a visibilitychange event is sent with document.visibilityState set to 'hidden' such that the requirements of clause A.3.25 are satisfied. Beacon,section 3.1: The sendBeacon method transmits data provided by the data parameter to the URL provided by the url parameter: | +HAS_DISPLAY | ||
| org.hbbtv_ANALYTICS0080 | 1 | Beacon is sent on standby | When a running application has added an event listener for the visibilitychange event that calls sendBeacon when the document.visibilityState attribute becomes 'hidden', then, when the user puts the terminal into standby, the requested Beacon is sent within 5 seconds. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.25: It shall be possible for an HbbTV application to cause beacon data to be transmitted when the application is terminated or hidden by calling sendBeacon in the handler of a visibilitychange event when document.visibilityState has become ‘hidden’. The data should be transmitted as soon as possible and shall be transmitted within 5 seconds in each of the following cases: ... - termination of an HbbTV application due to the terminal going into any standby mode NOTE: Terminals that go into a deep low-power standby state immediately may need to send the beacon prior to going into that standby state. HBBTV,section 6.2.4: A visibilitychange event shall be sent when an HbbTV application is hidden but not terminated for any of the following reasons: ... - the terminal enters a standby mode in which the application state is preserved and from which the application may later become visible again (e.g. an active standby mode where the display is disabled but the terminal otherwise continues to run, or a standby mode where the application state is retained in non-volatile storage during the standby mode) HBBTV,section 6.2.2.11: During the process of stopping an application, terminals shall ensure that a visibilitychange event is sent with document.visibilityState set to 'hidden' such that the requirements of clause A.3.25 are satisfied. Beacon,section 3.1: The sendBeacon method transmits data provided by the data parameter to the URL provided by the url parameter: | |||
| org.hbbtv_ANALYTICS0090 | 1 | Beacon is sent on starting other app or feature | A broadcast-related application is running. It has added an event listener for the visibilitychange event that calls sendBeacon when the document.visibilityState attribute becomes 'hidden'. The terminal native UI is used to start a feature outside the scope of HbbTV that takes over the whole of the screen, for example an application from a global VOD provider. When the HbbTV application is no longer visible to the user, the Beacon is sent within 5 seconds. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.25: It shall be possible for an HbbTV application to cause beacon data to be transmitted when the application is terminated or hidden by calling sendBeacon in the handler of a visibilitychange event when document.visibilityState has become ‘hidden’. The data should be transmitted as soon as possible and shall be transmitted within 5 seconds in each of the following cases: ... - termination of an HbbTV application due to another application or terminal feature being started (whether or not that other application or feature is an HbbTV application) - hiding of an application with or without freezing, where this is supported by the terminal (see clause 6.2.4) HBBTV,section 6.2.4: A visibilitychange event shall be sent when an HbbTV application is hidden but not terminated for any of the following reasons: • a terminal user interface or application has fully covered the HbbTV application such that no part of the HbbTV application is visible to the user • the HbbTV application has been removed from the screen while another user interface or application is being displayed ... HBBTV,section 6.2.2.11: During the process of stopping an application, terminals shall ensure that a visibilitychange event is sent with document.visibilityState set to 'hidden' such that the requirements of clause A.3.25 are satisfied. Beacon,section 3.1: The sendBeacon method transmits data provided by the data parameter to the URL provided by the url parameter: | |||
| org.hbbtv_ANALYTICS0100 | 1 | Beacon is sent on selecting external input | A broadcast-related application is running. It has added an event listener for the visibilitychange event that calls sendBeacon when the document.visibilityState attribute becomes 'hidden'. The terminal native UI is used to select an external input, for example HDMI. When the HbbTV application is no longer visible to the user, the Beacon is sent within 5 seconds. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.25: It shall be possible for an HbbTV application to cause beacon data to be transmitted when the application is terminated or hidden by calling sendBeacon in the handler of a visibilitychange event when document.visibilityState has become ‘hidden’. The data should be transmitted as soon as possible and shall be transmitted within 5 seconds in each of the following cases: ... - termination of an HbbTV application due to another application or terminal feature being started (whether or not that other application or feature is an HbbTV application) - hiding of an application with or without freezing, where this is supported by the terminal (see clause 6.2.4) HBBTV,section 6.2.4: A visibilitychange event shall be sent when an HbbTV application is hidden but not terminated for any of the following reasons: • a terminal user interface or application has fully covered the HbbTV application such that no part of the HbbTV application is visible to the user • the HbbTV application has been removed from the screen while another user interface or application is being displayed ... HBBTV,section 6.2.2.11: During the process of stopping an application, terminals shall ensure that a visibilitychange event is sent with document.visibilityState set to 'hidden' such that the requirements of clause A.3.25 are satisfied. Beacon,section 3.1: The sendBeacon method transmits data provided by the data parameter to the URL provided by the url parameter: | +HAS_DISPLAY | ||
| org.hbbtv_ANALYTICS0110 | 1 | Beacon is sent on starting native terminal feature | A broadcast-related application is running. It has added an event listener for the visibilitychange event that calls sendBeacon when the document.visibilityState attribute becomes 'hidden'. The terminal native UI is used to invoke a native terminal feature that causes the HbbTV application to stop being visible to the user (if there is such), for example a guide or configuration menu. Either the HbbTV application remains visible to the user, or when it is no longer visible to the user, the Beacon is sent within 5 seconds. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.25: It shall be possible for an HbbTV application to cause beacon data to be transmitted when the application is terminated or hidden by calling sendBeacon in the handler of a visibilitychange event when document.visibilityState has become ‘hidden’. The data should be transmitted as soon as possible and shall be transmitted within 5 seconds in each of the following cases: ... - termination of an HbbTV application due to another application or terminal feature being started (whether or not that other application or feature is an HbbTV application) - hiding of an application with or without freezing, where this is supported by the terminal (see clause 6.2.4) HBBTV,section 6.2.4: A visibilitychange event shall be sent when an HbbTV application is hidden but not terminated for any of the following reasons: • a terminal user interface or application has fully covered the HbbTV application such that no part of the HbbTV application is visible to the user • the HbbTV application has been removed from the screen while another user interface or application is being displayed ... HBBTV,section 6.2.2.11: During the process of stopping an application, terminals shall ensure that a visibilitychange event is sent with document.visibilityState set to 'hidden' such that the requirements of clause A.3.25 are satisfied. Beacon,section 3.1: The sendBeacon method transmits data provided by the data parameter to the URL provided by the url parameter: | |||
| org.hbbtv_APP2APP0010 | 1 | App2App - HbbTV app connects to local end-point | An application successfully opens a WebSocket connection to the URL consisting of the URL of the local endpoint of the app2app service endpoint it has discovered via Java Script API suffixed with the application specific suffix string "myapp.mychannel.org". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.1: The terminal shall implement a server providing end-points, described in clause 14.5.2, that implement the server-side of the WebSocket protocol version 13 as defined in RFC 6455 [40]. HbbTV Applications determine the location of the service end-points using Javascript APIs defined in clause 8.2.6. HBBTV,section 14.5.2: The terminal shall provide two service endpoints implementing the server-side of the WebSocket protocol specification [40]: The local endpoint is for connecting to by clients that are HbbTV applications on the terminal. HBBTV,section 14.5.4: The WebSocket URL that a client connects to when using either service end-point is formed by concatenating the base WebSocket URL for that service end-point with an application specific suffix. | |||
| org.hbbtv_APP2APP0020 | 1 | App2App - CS app connects to a remote end-point | A companion screen application successfully opens a WebSocket connection to the URL consisting of the URL of the remote endpoint of the app2app service endpoint it has discovered via the HbbTV terminal discovery suffixed with the application specific suffix string "myapp.mychannel.org". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.1: The terminal shall implement a server providing end-points, described in clause 14.5.2, that implement the server-side of the WebSocket protocol version 13 as defined in RFC 6455 [40]. [...] Companion Screen Applications connect to the service end-points using the WebSocket protocol in the role of a client of the WebSocket protocol. HBBTV,section 14.5.2: The terminal shall provide two service endpoints implementing the server-side of the WebSocket protocol specification [40]: [...] The remote endpoint is for connecting to by clients that are applications on other devices on the home network, including remote Companion Screen Applications or Applications running on other HbbTV terminal devices. [...] Companion Screen Applications and applications on other HbbTV terminals only connect to the remote service endpoint of any terminal. HBBTV,section 14.5.4: The WebSocket URL that a client connects to when using either service end-point is formed by concatenating the base WebSocket URL for that service end-point with an application specific suffix. | |||
| org.hbbtv_APP2APP0070 | 1 | App2App - Pairing clients with maximum app end-point | When an application connects to the local app2app service endpoint with an app endpoint that contains all allowed characters for a resource-name as defined in RFC 6455, that has a query component and that is exactly 1000 characters in length, and a companion screen application connects to the remote app2app service end-point with the same app endpoint, the terminal shall open a Web Socket connection for both clients, and once both connections are open the terminal shall send them both a 'pairingcompleted' message encoded in UTF-8. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.4: The terminal shall support an app-endpoint that is least 1000 characters in length and which contains any characters permitted in a resource-name by RFC 6455 [40]. The terminal shall pair two waiting connections according to the following rules: * One waiting connection shall be on the local service endpoint (and therefore be inferred to have come from the HbbTV application client). * One other waiting connection shall be on the remote service endpoint (and therefore be inferred to have come from a remote client, such as a Companion Screen Application). * The app-endpoint portion of the resource name used in the client handshake request shall match between both waiting connections. HBBTV,section 14.5.5: When connections from two clients enter into a state of being paired to each other, the terminal shall immediately inform both clients by sending them a Data frame of type Text (as defined by the WebSocket protocol specification clause 5.6 [40]) with as Payload data the UTF-8 encoded text 'pairingcompleted'. The connections are now both considered to be open, and the clients to be paired. RFC6455,section 3: The "resource-name" [...] can be constructed by concatenating the following: * "/" if the path component is empty * the path component * "?" if the query component is non-empty * the query component RFC3986,section 3.3: path = path-abempty ; begins with "/" or is empty / path-absolute ; begins with "/" but not "//" / path-noscheme ; begins with a non-colon segment / path-rootless ; begins with a segment / path-empty ; zero characters path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> segment = *pchar segment-nz = 1*pchar segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; non-zero-length segment without any colon ":" pchar = unreserved / pct-encoded / sub-delims / ":" / "@" RFC3986,section A: pchar = unreserved / pct-encoded / sub-delims / ":" / "@" query = *( pchar / "/" / "?" ) [...] pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" [...] sub-delims = "!" / "$" / "&" / "'" / "(" / ")"/ "*" / "+" / "," / ";" / "=" RFC2234,section 6.1: ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39; 0-9 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" | |||
| org.hbbtv_APP2APP0071 | 1 | App2App - Do not pair clients with different maximum app end-points | When an application connects to the local app2app service endpoint with an app endpoint that contains all allowed characters for a resource-name as defined in RFC 6455, that has a query component and that is exactly 1000 characters in length, and a companion screen application connects to the remote app2app service end-point with the app endpoint that only differs in the last character, the terminal shall open a Web Socket connection for both clients, but does not send any message to the clients after both connections are opened. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.4: The terminal shall support an app-endpoint that is least 1000 characters in length which contains any characters permitted in a resource-name by RFC 6455 [40]. The terminal shall pair two waiting connections according to the following rules: * One waiting connection shall be on the local service endpoint (and therefore be inferred to have come from the HbbTV application client). * One other waiting connection shall be on the remote service endpoint (and therefore be inferred to have come from a remote client, such as a Companion Screen Application). * The app-endpoint portion of the resource name used in the client handshake request shall match between both waiting connections. HBBTV,section 14.5.5: When connections from two clients enter into a state of being paired to each other, the terminal shall immediately inform both clients by sending them a Data frame of type Text (as defined by the WebSocket protocol specification clause 5.6 [40]) with as Payload data the UTF-8 encoded text 'pairingcompleted'. The connections are now both considered to be open, and the clients to be paired. RFC6455,section 3: The "resource-name" [...] can be constructed by concatenating the following: * "/" if the path component is empty * the path component * "?" if the query component is non-empty * the query component RFC3986,section 3.3: path = path-abempty ; begins with "/" or is empty / path-absolute ; begins with "/" but not "//" / path-noscheme ; begins with a non-colon segment / path-rootless ; begins with a segment / path-empty ; zero characters path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> segment = *pchar segment-nz = 1*pchar segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; non-zero-length segment without any colon ":" pchar = unreserved / pct-encoded / sub-delims / ":" / "@" RFC3986,section A: pchar = unreserved / pct-encoded / sub-delims / ":" / "@" query = *( pchar / "/" / "?" ) [...] pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" [...] sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" RFC2234,section 6.1: ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39; 0-9 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" | |||
| org.hbbtv_APP2APP0130 | 1 | App2App - Max concurrent connections | When 10 companion screen applications running on 10 different terminals connect to the remote endpoint of the app2app service with the app-endpoint "myapp.mychannel.org/?pairing" and subsequently an HbbTV application opens 10 connections to the local app2app service end-point using the same app-endpoint, the terminal shall pair each connection from the local client with one of the waiting remote connections and it shall send a UTF-8 encoded message 'pairingcompleted' to each client connection. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.3: The terminal shall support a minimum of 10 concurrent WebSocket connections from clients to the local service endpoint from local HbbTV applications and, simultaneously, a minimum of 10 concurrent WebSocket connections from clients to the remote service endpoint from other terminals or companion screen applications. HBBTV,section 14.5.4: The WebSocket URL that a client connects to when using either service end-point is formed by concatenating the base WebSocket URL for that service end-point with an application specific suffix. This suffix is referred to in the present document as the app-endpoint. HBBTV,section 14.5.5: When connections from two clients enter into a state of being paired to each other, the terminal shall immediately inform both clients by sending them a Data frame of type Text (as defined by the WebSocket protocol specification clause 5.6 [40]) with as Payload data the UTF-8 encoded text 'pairingcompleted'. | |||
| org.hbbtv_APP2APP0170 | 1 | App2App - Ignore origin header | When a companion screen application connects to the URL consisting of the URL of the app2app service endpoint suffixed with the application specific suffix string "myapp.mychannel.org" and includes an Origin header in the request handshake, the terminal accepts the request and establishes a WebSocket connection with the client. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.3: The terminal shall Ignore any Origin header in the request handshake sent by the client. HBBTV,section 14.5.4: The WebSocket URL that a client connects to when using either service end-point is formed by concatenating the base WebSocket URL for that service end-point with an application specific suffix. | |||
| org.hbbtv_APP2APP0180 | 1 | App2App - ignoring Sec-WebSocket-Extensions | If a companion screen application connects to the URL consisting of the URL of the remote app2app service endpoint suffixed with the application specific suffix string "myapp.mychannel.org" and including the Sec-WebSocket-Extensions header in the request handshake, then the terminal ignores Sec-WebSocket-Extensions and connection is established, without sending Sec-WebSocket-Extensions reply header. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.3: Terminals shall not use any WebSocket extensions. Terminals shall ignore any Sec-WebSocket-Extensions header in the request handshake sent by the client. Terminals shall not send a Sec-WebSocket-Extensions reply header. HBBTV,section 14.5.4: The WebSocket URL that a client connects to when using either service end-point is formed by concatenating the base WebSocket URL for that service end-point with an application specific suffix. | |||
| org.hbbtv_APP2APP0220 | 1 | App2App - Waiting connection | If a HbbTV application connects to the local endpoint of the app2app service with the app endpoint "myapp.mychannel.org/?pairing_1" and then a companion screen application connects to the remote endpoint with the app endpoint "myapp.mychannel.org/?pairing_2", the terminal will open a Web Socket connection for both, the terminal will not pair them, i.e. no message "pairingcompleted" is sent, but keep them in a waiting state and if after some time a second companion screen application connects with the app-endpoint "myapp.mychannel.org/?pairing_1" the terminal will pair this connection with the waiting connection from the HbbTV application and send a "pairingcompleted" message to both ends of the newly paired clients. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.4: The terminal shall pair two waiting connections according to the following rules: [...] The app-endpoint portion of the resource name used in the client handshake request shall match between both waiting connections. [...] The WebSocket URL that a client connects to when using either service end-point is formed by concatenating the base WebSocket URL for that service end-point with an application specific suffix. This suffix is referred to in the present document as the app-endpoint. HBBTV,section 14.5.5: When connections from two clients enter into a state of being paired to each other, the terminal shall immediately inform both clients by sending them a Data frame of type Text (as defined by the WebSocket protocol specification clause 5.6 [40]) with as Payload data the UTF-8 encoded text 'pairingcompleted'. The connections are now both considered to be open, and the clients to be paired. | |||
| org.hbbtv_APP2APP0315 | 1 | App2App - Discard data frames of local client in waiting state | When an HbbTV application connects to the local app2app service endpoint and immediately sends a message after the connection has been established and after the application has sent the message a companion screen application connects to the remote endpoint using the same app-endpoint as the HbbTV application, the terminal shall pair the two connections and send the "pairingcompleted" message to the both clients but shall not relay the message initially sent by the HbbTV application to the companion screen application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: When connections from two clients enter into a state of being paired to each other, the terminal shall immediately inform both clients by sending them a Data frame of type Text (as defined by the WebSocket protocol specification clause 5.6 [40]) with as Payload data the UTF-8 encoded text 'pairingcompleted'. The connections are now both considered to be open, and the clients to be paired. Once paired and connections to both clients are open, the terminal shall act as a relay to pass messages between them, providing, in effect, a full-duplex bi-directional communication stream. When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frames, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. The terminal shall discard any data frames received from a client before it has informed that client of successful pairing and shall relay all data frames thereafter. Additionally the terminal shall inform a client of successful pairing before sending it relayed data frames. | |||
| org.hbbtv_APP2APP0316 | 1 | App2App - Discard data frames of remote client in waiting state | When a companion screen application connects to the remote app2app service endpoint and immediately sends a message after the connection has been established and after the companion screen application has sent the message an HbbTV application connects to the local endpoint using the same app-endpoint as the companion screen application, the terminal shall pair the two connections and send the "pairingcompleted" message to the both clients but shall not relay the message initially sent by the companion screen application to the HbbTV application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: When connections from two clients enter into a state of being paired to each other, the terminal shall immediately inform both clients by sending them a Data frame of type Text (as defined by the WebSocket protocol specification clause 5.6 [40]) with as Payload data the UTF-8 encoded text 'pairingcompleted'. The connections are now both considered to be open, and the clients to be paired. Once paired and connections to both clients are open, the terminal shall act as a relay to pass messages between them, providing, in effect, a full-duplex bi-directional communication stream. When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frame, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. The terminal shall discard any data frames received from a client before it has informed that client of successful pairing and shall relay all data frames thereafter. Additionally the terminal shall inform a client of successful pairing before sending it relayed data frames. | |||
| org.hbbtv_APP2APP0360 | 1 | App2App - Unfragmented data frame with maximum size. | After the connections to the app2app service end-point of an HbbTV application and a companion screen application have been paired, and the companion screen application sends an unfragmented frame containing a binary message with a size of 131 072 bytes using an unfragmented data frame to the app2app service, the terminal delivers the binary message properly to the application on the local client. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: Once paired and connections to both clients are open, the terminal shall act as a relay to pass messages between them, providing, in effect, a full-duplex bi-directional communication stream. When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frame, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. The terminal shall support all data frame types and both unfragmented and fragmented frames as required by RFC 6455 [40]. When relaying a payload received from a client, the terminal is not required to fragment the payload across frames in the same way as the frames it received. The terminal shall be able to relay messages with a payload size of up to and including 131 072 bytes. For messages sent from the remote client, the terminal shall be able to relay the message, and have it received by the local application (client), if it is fragmented where each frame may carry any number of bytes up to the size of the message. | |||
| org.hbbtv_APP2APP0365 | 1 | App2App - maximum message size from local client. | After the connections to the app2app service end-point of an HbbTV application and a companion screen application have been paired, and the HbbTV application on the local client sends a text message with a size of 131 072 bytes to the app2app service, the terminal delivers the message either in fragmented or unfragmented frames properly to the companion screen application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: Once paired and connections to both clients are open, the terminal shall act as a relay to pass messages between them, providing, in effect, a full-duplex bi-directional communication stream. When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frame, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. The terminal shall support all data frame types and both unfragmented and fragmented frames as required by RFC 6455 [40]. When relaying a payload received from a client, the terminal is not required to fragment the payload across frames in the same way as the frames it received. The terminal shall be able to relay messages with a payload size of up to and including 131 072 bytes. | |||
| org.hbbtv_APP2APP0370 | 1 | App2App - Fragmented data frames with maximum size. | After the connections to the app2app service end-point of an HbbTV application and a companion screen application have been paired, and the companion screen application sends a fragmented frame containing a text message with a size of 131 072 bytes where 127 fragments have a size of 1024 bytes and 1 fragment has a size of 1 byte and one fragment has a size of 1023 bytes to the app2app service, the terminal delivers the text message properly to the application on the local client. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: Once paired and connections to both clients are open, the terminal shall act as a relay to pass messages between them, providing, in effect, a full-duplex bi-directional communication stream. When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of those frames, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. The terminal shall support all data frame types and both unfragmented and fragmented frames as required by RFC 6455 [40]. When relaying a payload received from a client, the terminal is not required to fragment the payload across frames in the same way as the frames it received. The terminal shall be able to relay messages with a payload size of up to and including 131 072 bytes. For messages sent from the remote client, the terminal shall be able to relay the message, and have it received by the local application (client), if it is fragmented where each frame may carry any number of bytes up to the size of the message. | |||
| org.hbbtv_APP2APP0371 | 1 | App2App - Single Pairing - 10 large messages in 10 sec sent to local end-point | After the connections to the app2app service end-point of an HbbTV application and a companion screen application have been paired, and the HbbTV application sends a text message with a size of 131 072 bytes every second for a duration of at least 60 seconds to just one connected companion, the terminal relays each message immediately either in fragmented or unfragmented frames to that companion screen application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frame, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. [...] Over a 10 second period, during which any other paired connections have no traffic, the terminal shall be able to relay any of the following rates of traffic across a single paired connection: • 10 messages with a payload size of up to and including 131 072 bytes sent by the application (client) connected to the local service end-point. | |||
| org.hbbtv_APP2APP0372 | 1 | App2App - Single Pairing - 10 large messages in 10 sec to remote end-point | After the connections to the app2app service end-point of an HbbTV application and a companion screen application have been paired, the companion screen application sends a binary message with a size of 131 072 bytes using unfragmented frames every second for a duration of at least 60 seconds and the terminal shall immediately relay the frames and deliver all contained messages to the HbbTV application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frame, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. [...] Over a 10 second period, during which any other paired connections have no traffic, the terminal shall be able to relay any of the following rates of traffic across a single paired connection: [...] * 10 unfragmented messages with a payload size of up to and including 131 072 bytes sent by the client connected to the remote service end-point. | |||
| org.hbbtv_APP2APP0373 | 1 | App2App - Single Pairing - 200 small messages in 10sec to local end-point | After the connections to the app2app service end-points of an HbbTV application and a companion screen application have been paired, and the HbbTV application sends a text messages with a payload size of 512 bytes every 50ms for a duration of 60 seconds the terminal shall immediately relay the messages as either fragmented or unfragmented text frames to the companion screen application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frame, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. [...] Over a 10 second period, during which any other paired connections have no traffic, the terminal shall be able to relay any of the following rates of traffic across a single paired connection: [...] • 200 frames with a payload size of up to and including 512 bytes sent by the client connected to the local service end-point. | |||
| org.hbbtv_APP2APP0374 | 1 | App2App - Single Pairing - 200 small messages in 10sec to remote end-point | After the connections to the app2app service end-points of an HbbTV application and a companion screen application have been paired, and the companion screen application sends a binary message in a frame with a payload size of 512 bytes every 50ms for a duration of 60 seconds the terminal shall immediately relay them as binary messages to the HbbTV application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frame, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. [...] Over a 10 second period, during which any other paired connections have no traffic, the terminal shall be able to relay any of the following rates of traffic across a single paired connection: [...] * 200 unfragmented messages with a payload size of up to and including 512 bytes sent by the client connected to the remote service end-point. | |||
| org.hbbtv_APP2APP0375 | 1 | App2App - 10 pairings - 5 large messages per pairing in 10 sec to local end-point | When a HbbTV application has 10 paired connections with 10 companion screen applications, and the HbbTV application sends one binary message with a size of 131 072 bytes every 2 seconds to each single connection over a period of 60 seconds the terminal shall immediately relay every binary message either as fragmented or unfragmented frames to the corresponding companion screen application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frame, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. [...] When messages sent by all clients across all currently paired connections are considered in aggregate then, during a 10 second period, the terminal shall be able to relay any of the following rates of traffic when spread evenly across up to 10 paired connections: • 50 messages with a payload size of up to and including 131 072 bytes sent by the application connected to the local service end-point (5 frames via each paired connection). | |||
| org.hbbtv_APP2APP0376 | 1 | App2App - 10 pairings - 5 large messages per pairing in 10 sec to remote end-point | When a HbbTV application has 10 paired connections with 10 companion screen applications, and each companion screen application sends a text message with a size of 131 072 bytes every 2 seconds over a period of 60 seconds the terminal immediately relays the text message to the HbbTV application via the corresponding connection. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frame, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. [...] When messages sent by all clients across all currently paired connections are considered in aggregate then, during a 10 second period, the terminal shall be able to relay any of the following rates of traffic when spread evenly across up to 10 paired connections: [...] * 50 unfragmented messages with a payload size of up to and including 131 072 bytes sent by the client connected to the remote service end-point (5 frames via each paired connection). | ||
| org.hbbtv_APP2APP0377 | 1 | App2App - 10 pairings - 25 small messages per pairing in 10 sec to local end-point | When a HbbTV application has 10 paired connections with 10 companion screen applications, and the HbbTV application sends one text message with a size of 512 bytes every 400ms to each single connection over a period of 60 seconds the terminal shall immediately relay every text message either as fragmented or unfragmented frames to the corresponding companion screen application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frame, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. [...] When messages sent by all clients across all currently paired connections are considered in aggregate then, during a 10 second period, the terminal shall be able to relay any of the following rates of traffic when spread evenly across up to 10 paired connections: [...] * 250 messages with a payload size of up to and including 512 bytes sent by the client connected to the local service end-point (25 frames via each paired connection) | |||
| org.hbbtv_APP2APP0378 | 1 | App2App - 10 pairings - 25 small messages per pairing in 10 sec to remote end-point | When a HbbTV application has 10 paired connections with 10 companion screen applications, and each companion screen application sends a binary message with a size of 512 bytes every 400 ms over a period of 60 seconds the terminal immediately relays the binary message to the HbbTV application via the corresponding connection. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: When either client sends a WebSocket message, consisting of one or more protocol frames, the terminal, upon receipt of each frame, shall immediately relay its contents to the other client via the corresponding WebSocket connection and maintaining the same payload type. [...] When messages sent by all clients across all currently paired connections are considered in aggregate then, during a 10 second period, the terminal shall be able to relay any of the following rates of traffic when spread evenly across up to 10 paired connections: [...] * 250 unfragmented messages with a payload size of up to and including 512 bytes sent by the client connected to the remote service end-point (25 frames via each paired connection). | |||
| org.hbbtv_APP2APP0380 | 1 | App2App - Answering client's ping request | After the connections to the app2app service end-points of an HbbTV application and a companion screen application have been paired, the client connected to the remote end-point sends a Ping frame, the terminal responds with a Pong frame. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: If the client connected to the remote service endpoint sends a Ping frame (as defined in RFC 6455 [40]) then the terminal shall respond with a Pong frame. | |||
| org.hbbtv_APP2APP0385 | 1 | App2App - Application disconnects paired connection | When an application closes a paired connection to the local app2app service end-point, the terminal closes the connection to the client connected to the remote end-point by sending a Close frame. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: If the application closes the WebSocket connection to the local service endpoint then the terminal shall commence the process of disconnecting the corresponding paired connection from the remote other client by sending a corresponding Close frame as defined in RFC 6455 [40]. | |||
| org.hbbtv_APP2APP0386 | 1 | App2App - Application disconnects paired connection: Application stopped by terminal | When an application that has a paired connection to the local app2app service end-point is stopped by the terminal due to a channel change, the terminal closes the connection to the client connected to the remote end-point. | 2024-2 2024-1 2023-3 2022-2 2022-1 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: If the application closes the WebSocket connection to the local service endpoint then the terminal shall commence the process of disconnecting the corresponding paired connection from the remote other client by sending a corresponding Close frame as defined in RFC 6455 [40]. If the application is stopped and WebSocket connections are still open, then any WebSocket connections to the WebSocket server shall be closed in an undefined manner. | |||
| org.hbbtv_APP2APP0390 | 1 | App2App - Initiating disconnection of clients (sending a close frame) | After a local and a remote client have been paired and subsequently the remote client sends a WebSocket data message with a close frame to the app2app service, the terminal disconnects both of the clients. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: If the remote client sends a Close frame (as defined in RFC 6455 [40]) [...], the terminal shall commence the process of disconnecting the client. In addition, it shall close the corresponding paired WebSocket connection that was made by the application to the local service endpoint. In normal operation the terminal should indefinitely maintain the pair of connections and relay messages as described above. However, if the terminal has initiated the closure of the connection to either client for whatever reason, then it shall close both connections in the pair. | |||
| org.hbbtv_APP2APP0395 | 1 | App2App - Initiating disconnection of clients (disconnect) | After a local and a remote client have been paired and subsequently the remote client disconnects without sending a close frame to the app2app service, the terminal disconnects both of the clients by sending a corresponding close frame. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.5.5: If the remote client [...] disconnects without sending a Close frame, the terminal shall commence the process of disconnecting the client. In addition, it shall close the corresponding paired WebSocket connection that was made by the application to the local service endpoint. In normal operation the terminal should indefinitely maintain the pair of connections and relay messages as described above. However, if the terminal has initiated the closure of the connection to either client for whatever reason, then it shall close both connections in the pair. | |||
| org.hbbtv_APP2APP0500 | 1 | App2App - HbbTV app from HTTPS connects to local endpoint | An application that was started via HTTPS successfully opens a WebSocket connection to the URL consisting of the URL of the local endpoint of the app2app service endpoint it has discovered via Java Script API suffixed with the application specific suffix string "myapp.mychannel.org". | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 14.5.1: The terminal shall implement a server providing end-points, described in clause 14.5.2, that implement the server-side of the WebSocket protocol version 13 as defined in RFC 6455 [40]. HbbTV Applications determine the location of the service end-points using Javascript APIs defined in clause 8.2.6. HBBTV,section 14.5.2: The terminal shall provide two service endpoints implementing the server-side of the WebSocket protocol specification [40]: The local endpoint is for connecting to by clients that are HbbTV applications on the terminal. HBBTV,section 14.5.4: Note 1: [...] See also clause A.3.13 "Mixed Content". The WebSocket URL that a client connects to when using either service end-point is formed by concatenating the base WebSocket URL for that service end-point with an application specific suffix. HBBTV,section A.3.13: Regardless of how an HbbTV application was delivered (HTTP, HTTP over TLS ("https:"), object carousel), terminals shall permit them to successfully make WebSocket connections to WebSocket endpoints that have been requested and returned to the application via one of the following APIs from clause 14.5.2: * getApp2AppLocalBaseURL | |||
| org.hbbtv_APP2AV0010 | 1 | APP2AV: HTML5 currentTime is accurate | The playback position returned by an HTML5 media object is the time of the current video frame composed with the application graphics and accurate within 100ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.2: Each [media object] provides a property that enables an application to read the current media playback position. [...] For the HTML5 media elements, the currentTime property [...] the value returned shall be the time of the last video frame that was composed with graphics before the method was called and shall be accurate to within 100 ms | ||
| org.hbbtv_APP2AV0020 | 1 | APP2AV: AVO playPosition is accurate | The playback position returned by an A/V control object is the time of the current video frame composed with the application graphics and accurate within 100ms. | 2024-2 2024-1 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.2: Each [media object] provides a property that enables an application to read the current media playback position. [...] For the AV Control object , the playPosition property [...] the value returned shall be the time of the last video frame that was composed with graphics before the method was called and shall be accurate to within 100 ms | |||
| org.hbbtv_APP2AV0030 | 1 | APP2AV: AVO playPosition correlates with 25fps | The playback position returned by the A/V control object for a service with a 25 fps video component, is updated at least every 40ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.2: For [...] the A/V control object, the value returned shall be updated each time the property is read. The precision of the playback position shall at least correlate with the frame rate of the video component of the media stream. | |||
| org.hbbtv_APP2AV0040 | 1 | APP2AV: AVO playPosition correlates with 50fps | The playback position returned by the A/V control object for a service with a 50 fps video component, is updated at least every 20ms. | 2024-2 2024-1 2023-3 2023-2 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.2: For [...] the A/V control object, the value returned shall be updated each time the property is read. The precision of the playback position shall at least correlate with the frame rate of the video component of the media stream. | |||
| org.hbbtv_APP2AV0050 | 1 | APP2AV: AVO playPosition correlates with the audio frame of MPEG1 audio track | The playback position returned by the A/V control object for an audio-only stream encoded with MPEG1L3@48kHz, is updated at least every 24ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.2: For the AV Control object, the value returned shall be updated each time the property is read. The precision of the playback position shall at least correlate with either: [...] or the length of an access unit of the audio component presented by the media object, e.g. is at least 24ms for MPEG 1 Layer 2 at 48kHz sample rate [...] | |||
| org.hbbtv_APP2AV0060 | 1 | APP2AV: AVO playPosition correlates with audio frame of AAC audio track | The playback position returned by the A/V control object for a audio only stream encoded with HE-AAC@48kHz, is updated at least every 42.67ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.2: For the AV Control object, the value returned shall be updated each time the property is read. The precision of the playback position shall at least correlate with either: [...] or the length of an access unit of the audio component presented by the media object, e.g. is at least [...] 42.67ms for HE-AAC at 48kHz sample rate. | |||
| org.hbbtv_APP2AV0070 | 1 | APP2AV: AVO value of playPosition for on-demand | The value of the playPosition property of the A/V control object that is in the playing state presenting on-demand but not MPEG DASH content shall be the play position of that content in milliseconds. | 2024-2 2024-1 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.2: For the AV Control object:For on-demand content the value returned when the property is read shall be as defined in clause 8.2.5.1 of the OIPF DAE specification [1]. OIPF-DAE,section 8.2.5.1: The property holds the current play position in milliseconds of the media referenced by the data property. | |||
| org.hbbtv_APP2AV0080 | 1 | APP2AV: AVO value of playPosition for DASH | An application is presenting in an A/V control object MPEG DASH content with a dynamic MPD. While playing the content, the MPD is updated and the first Period that was present initially disappeared, then the value returned by the playPosition property of the A/V control object shall be a value in milliseconds assuming time 0 is the start time of the first Period that was present in the MPD when the MPD was first loaded. | 2024-2 2024-1 2023-3 2023-2 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.2: For the AV Control object:For MPEG-DASH the value returned when the property is read shall be as defined in 9.4.3. HBBTV,section 9.4.3: The origin of the media timeline used for the playPosition property shall be the start time of the first Period that was defined in the MPD when the MPD was first loaded. The origin of the media timeline shall not change unless the A/V control object returns to the stopped state. | |||
| org.hbbtv_APP2AV0110 | 1 | APP2AV: accuracy of MediaSynchroniser.currentTime with broadcast TS and MPEG TEMI | When an application reads the currentTime from a MediaSynchroniser that was initialized with a DVB TV service and a reference to a MPEG TEMI timeline carried on the audio component in that service and there are multiple timelines with different timeline IDs present on the video and audio component, the terminal shall return the current value of the referenced TEMI timeline corresponding to the last frame that was composed with graphics before the currentTime property was queried with an accuracy of at least 100ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.3: When an application reads the currentTime property of a MediaSynchroniser object (see clause 8.2.3.2.1) the returned value shall correspond to the current position of the timeline used by the MediaSynchroniser object[...]For a MediaSynchroniser object that has been initialised by calling the initMediaSynchroniser method, the returned value shall correspond to the current playback position of the media object that was passed as an argument to the initMediaSynchroniser method (the master media). The value returned shall be the time of the last video frame that was composed with graphics before the property was queried and shall be accurate to within 100ms. HBBTV,section 13.4.2: Table 18: [[row 3] Type of timeline: MPEG-TS Timed External Media Information (TEMI). Supported for: MPEG Transport Stream delivered via broadcast.][...]The terminal shall derive the timeline described by a Timeline Selector for a media stream if the Timeline Selector and media object representing that media stream are passed as arguments to the initMediaSynchroniser [...] methods of a MediaSynchroniser object. TS-103-286-2,section 11.3.2: The format for a timeline selector for a temi_timeline is shown by the following Augmented BNF (as defined in RFC 5234 [4]) rule definition for temi-timeline-selector: temi-timeline-selector = "urn:dvb:css:timeline:temi:" component-tag ":" timeline-id component-tag is the base-ten integer representation of the value of the component_tag (declared by a stream identifier descriptor as defined in EN 300 468 [13]) associated with stream of TS packets that carry the temi _timeline_descriptor. timeline-id is the base-ten integer representation of the value of the timeline_id field in the temi_timeline_descriptor. The timeline to be selected shall be determined from the most recently received temi_timeline_descriptor whose timeline_id matches that specified in the Timeline Selector and which is carried in the af_descriptor() in the adaptation_field for TS packets identified by the component tag specified in the Timeline Selector. | |||
| org.hbbtv_APP2AV0111 | 1 | APP2AV: accuracy of MediaSynchroniser.currentTime with broadcast TS using PTS timeline | When an application reads the currentTime from a MediaSynchroniser that was initialized with a DVB TV service and a reference to a MPEG PTS timeline, the terminal shall return the current value of the referenced PTS timeline corresponding to the last frame that was composed with graphics before the currentTime property was queried with an accuracy of at least 100ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.3: When an application reads the currentTime property of a MediaSynchroniser object (see clause 8.2.3.2.1) the returned value shall correspond to the current position of the timeline used by the MediaSynchroniser object[...]For a MediaSynchroniser object that has been initialised by calling the initMediaSynchroniser method, the returned value shall correspond to the current playback position of the media object that was passed as an argument to the initMediaSynchroniser method (the master media). The value returned shall be the time of the last video frame that was composed with graphics before the property was queried and shall be accurate to within 100ms. HBBTV,section 13.4.2: Table 19: Type of timeline MPEG-TS Presentation Timestamps (PTS)(see note 1) Supported for MPEG Transport Stream delivered via broadcast (see note 2). Single program MPEG Transport Stream streamed via broadband. TS-103-286-2,section 5.3.3: Name MPEG-TS PTS: Presentation Time Stamp Timeline Selector value "urn:dvb:css:timeline:pts" Intrinsic TS-103-286-2,section 11.3.2: If PTS is to be used as a Timeline, then the Time Value is the value of PTS (as defined in [6]) of the media stream being presented to the user. The unitsPerTick of the timeline shall be 1 and the unitsPerSecond shall be 90 000, corresponding to the tick rate of clock underpinning PTS. When PTS values wrap then the Time Value shall also wrap and shall never equal or exceed 2^33 | ||
| org.hbbtv_APP2AV0120 | 1 | APP2AV: accuracy of MediaSynchroniser.currentTime with DASH | When an application reads the currentTime from a MediaSynchroniser that was initialized with an HTML5 media object presenting an MPEG-DASH stream, the terminal shall return the current value of the DASH-PR timeline corresponding to the last frame that was composed with graphics before the currentTime property was queried with an accuracy of at least 100ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.3: When an application reads the currentTime property of a MediaSynchroniser object (see clause 8.2.3.2.1) the returned value shall correspond to the current position of the timeline used by the MediaSynchroniser object[...]For a MediaSynchroniser object that has been initialised by calling the initMediaSynchroniser method, the returned value shall correspond to the current playback position of the media object that was passed as an argument to the initMediaSynchroniser method (the master media). The value returned shall be the time of the last video frame that was composed with graphics before the property was queried and shall be accurate to within 100ms. HBBTV,section 13.4.2: Table 18: [[row 4] Type of timeline: MPEG DASH Period Relative. Supported for: MPEG DASH streamed via broadband.][...]The terminal shall derive the timeline described by a Timeline Selector for a media stream if the Timeline Selector and media object representing that media stream are passed as arguments to the initMediaSynchroniser [...] methods of a MediaSynchroniser object. | ||
| org.hbbtv_APP2AV0130 | 1 | APP2AV: Precision of MediaSynchroniser.currentTime for 25fps video | When an application repeatedly reads the currentTime property of a MediaSynchroniser intialised with an HD broadcast carrying a TEMI timeline and encoded at 1080i25, the terminal updates the returned value at least every 40ms. | 2024-2 2024-1 2023-3 2023-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.3: When an application reads the currentTime property of a MediaSynchroniser object (see clause 8.2.3.2.1) the returned value shall correspond to the current position of the timeline used by the MediaSynchroniser object[...]For a MediaSynchroniser object that has been initialised by calling the initMediaSynchroniser method, the returned value shall correspond to the current playback position of the media object that was passed as an argument to the initMediaSynchroniser method (the master media). [...]The precision of the playback position shall at least correlate with either:- the highest frame rate of any video being presented on the terminal where that video is a component of a media object attached to the MediaSynchroniser, e.g. it is at least 40ms for 25 fps video and 20ms for 50 fps, HBBTV,section 13.4.2: Table 18: [[row 3] MPEG-TS Timed External Media Information (TEMI). Supported for: MPEG Transport Stream delivered via broadcast.][...]The terminal shall derive the timeline described by a Timeline Selector for a media stream if the Timeline Selector and media object representing that media stream are passed as arguments to the initMediaSynchroniser [...] methods of a MediaSynchroniser object. | |||
| org.hbbtv_APP2AV0140 | 1 | APP2AV: Precision of MediaSynchroniser.currentTime for 50fps video | When an application repeatedly reads the currentTime property of a MediaSynchroniser intialised with an HTML5 media object presenting an MPEG DASH stream that is encoded at 720p50, the terminal returns the value of the DASH-PR timeline updated at least every 20ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.3: For a MediaSynchroniser object that has been initialised by calling the initMediaSynchroniser method, the returned value shall correspond to the current playback position of the media object that was passed as an argument to the initMediaSynchroniser method (the master media). [...]The precision of the playback position shall be at least correlate with either:- the highest frame rate of any video being presented on the terminal where that video is a component of a media object attached to the MediaSynchroniser, e.g. it is at least 40ms for 25 fps video and 20ms for 50 fps, HBBTV,section 13.4.2: Table 18: [[row 4] Type of timeline: MPEG DASH Period Relative. Supported for: MPEG DASH streamed via broadband.][...]The terminal shall derive the timeline described by a Timeline Selector for a media stream if the Timeline Selector and media object representing that media stream are passed as arguments to the initMediaSynchroniser [...] methods of a MediaSynchroniser object. | |||
| org.hbbtv_APP2AV0150 | 1 | APP2AV: Precision of MediaSynchroniser.currentTime for MPEG1L2 audio | When an application repeatedly reads the currentTime property of a MediaSynchroniser intialised with a broadcast audio-only service encoded with MPEG1L2 audio and a reference to an MPEG TEMI timeline carried in the adaptation field of the TS header of a separate component that carries PES packets with PTS timestamps but with no data carried in the PES packet payload, in that service, the terminal returns the value of that TEMI timeline updated at least every 24ms. | 2024-2 2024-1 2023-3 2023-2 2022-3 2022-2 2022-1 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.3: For a MediaSynchroniser object that has been initialised by calling the initMediaSynchroniser method, the returned value shall correspond to the current playback position of the media object that was passed as an argument to the initMediaSynchroniser method (the master media). [...]The precision of the playback position shall be at least correlate with either:- or if there is no applicable video component the shortest length of an access unit of any audio being presented on the terminal where that audio is a component of a media object attached to the MediaSynchroniser, e.g. is at least 24ms for MPEG 1 Layer 2 at 48kHz sample rate or 42.67ms for HE- AAC at 48kHz sample rate. HBBTV,section 13.4.2: Table 18: [[row 3] Type of timeline: MPEG-TS Timed External Media Information (TEMI). Supported for: MPEG Transport Stream delivered via broadcast.][...]The terminal shall derive the timeline described by a Timeline Selector for a media stream if the Timeline Selector and media object representing that media stream are passed as arguments to the initMediaSynchroniser [...] methods of a MediaSynchroniser object. TS-103-286-2,section 11.3.2: The format for a timeline selector for a temi_timeline is shown by the following Augmented BNF (as defined in RFC 5234 [4]) rule definition for temi-timeline-selector: temi-timeline-selector = "urn:dvb:css:timeline:temi:" component-tag ":" timeline-id component-tag is the base-ten integer representation of the value of the component_tag (declared by a stream identifier descriptor as defined in EN 300 468 [13]) associated with stream of TS packets that carry the temi _timeline_descriptor. timeline-id is the base-ten integer representation of the value of the timeline_id field in the temi_timeline_descriptor. The timeline to be selected shall be determined from the most recently received temi_timeline_descriptor whose timeline_id matches that specified in the Timeline Selector and which is carried in the af_descriptor() in the adaptation_field for TS packets identified by the component tag specified in the Timeline Selector. | |||
| org.hbbtv_APP2AV0160 | 1 | APP2AV: Precision of MediaSynchroniser.currentTime for HEAAC audio | When an application repeatedly reads the currentTime property of a MediaSynchroniser intialised with a DASH audio-only stream encoded with HE-AAC, the terminal returns the value of the DASH-PR timeline updated at least every 42.67ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.3: For a MediaSynchroniser object that has been initialised by calling the initMediaSynchroniser method, the returned value shall correspond to the current playback position of the media object that was passed as an argument to the initMediaSynchroniser method (the master media). [...]The precision of the playback position shall be at least correlate with either:- or if there is no applicable video component the shortest length of an access unit of any audio being presented on the terminal where that audio is a component of a media object attached to the MediaSynchroniser, e.g. is at least 24ms for MPEG 1 Layer 2 at 48kHz sample rate or 42.67ms for HE- AAC at 48kHz sample rate. HBBTV,section 13.4.2: Table 18: [[row 4] Type of timeline: MPEG DASH Period Relative. Supported for: MPEG DASH streamed via broadband.][...]The terminal shall derive the timeline described by a Timeline Selector for a media stream if the Timeline Selector and media object representing that media stream are passed as arguments to the initMediaSynchroniser [...] methods of a MediaSynchroniser object. | |||
| org.hbbtv_APP2AV0170 | 1 | APP2AV: Value of MediaSynchroniser.currentTime on slave terminal | When an application reads the currentTime property from a MediaSynchroniser that has been successfully initialised for inter-device synchronisation on a slave terminal and on the master terminal the master media is broadcast TS with TEMI timeline, the currentTime property of the slave terminal MediaSynchroniser returns the value of the TEMI timeline of the current playback position on the master terminal (within uncertainty bounds quantified by the value of the interDeviceSyncDispersion property at the slave terminal) | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 13.11.3: For a MediaSynchroniser object that has been initialised by calling the initSlaveMediaSynchroniser method, the value returned shall correspond to the current playback position of the media object on the master terminal that was passed as an argument to the initMediaSynchroniser method on the master terminal (the master media). HBBTV,section 8.2.3.2.1: readonly Number interDeviceSyncDispersion Description The dispersion of clock synchronisation between the slave terminal and the master terminal in milliseconds. This value quantifies the limit on the accuracy of synchronisation currently achievable. If the terminal has the capability to act as a slave terminal but the MediaSynchroniser object is not a slave MediaSynchroniser then this shall be zero. If the terminal does not have the capability to act as a slave terminal then the value of this property shall be undefined. If the MediaSynchroniser object is a slave MediaSynchroniser then the initial value shall be Number.POSITIVE_INFINITY and shall then be updated at between 250ms and 1000ms intervals with the limit on synchronisation accuracy achievable, measured in milliseconds, as estimated by the WC-Client function of the terminal (see clause 13.7.4) in the period since the last time this property was updated. When this property is updated, an InterDevSyncDispersionUpdate event shall be triggered. | +SYNC_SLAVE | ||
| org.hbbtv_APP2AV0180 | 1 | APP2AV: Precision of MediaSynchroniser.currentTime on slave for 50fps video as other media | When an application repeatedly reads the currentTime property from a MediaSynchroniser that has been successfully initialised for inter-device synchronisation on a slave terminal using the initSlaveMediaSynchroniser method and an MPEG DASH stream with 50fps video is added as other media to this slave MediaSynchroniser, the currentTime property of the slave terminal MediaSynchroniser returns the value of the synchronisation timeline of the current playback position on the master terminal (within uncertainty bounds quantified by the value of the interDeviceSyncDispersion property at the slave terminal) updated at least every 20ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-1 2019-3 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 13.11.3: For a MediaSynchroniser object that has been initialised by calling the initSlaveMediaSynchroniser method, the value returned shall correspond to the current playback position of the media object on the master terminal that was passed as an argument to the initMediaSynchroniser method on the master terminal (the master media).The precision of the playback position shall at least correlate with either:- the highest frame rate of any video being presented on the slave terminal where that video is a component of a media object attached to the MediaSynchroniser, e.g. it is at least 40ms for 25 fps video and 20ms for 50 fps, | +SYNC_SLAVE | ||
| org.hbbtv_APP2AV0190 | 1 | APP2AV: Precision of MediaSynchroniser.currentTime on slave for MPEG1L2 audio as other media | When an application repeatedly reads the currentTime property from a MediaSynchroniser that has been successfully initialised for inter-device synchronisation on a slave terminal using the initSlaveMediaSynchroniser method and a broadcast audio-only service encoded with MPEG1-L2 is added as other media to this slave MediaSynchroniser, the currentTime property of the slave terminal MediaSynchroniser returns the value of the playback position of the MediaSynchroniser on the master terminal (within uncertainty bounds quantified by the value of the interDevSyncAccuracy property at the slave terminal) updated at least every 24ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 13.11.3: For a MediaSynchroniser object that has been initialised by calling the initSlaveMediaSynchroniser method, the value returned shall correspond to the current playback position of the media object on the master terminal that was passed as an argument to the initMediaSynchroniser method on the master terminal (the master media).The precision of the playback position shall at least correlate with either:- or if there is no applicable video component the shortest length of an access unit of any audio being presented on the slave terminal where that audio is a component of a media object attached to the MediaSynchroniser, e.g. is at least 24ms for MPEG 1 Layer 2 at 48kHz sample rate or 42.67ms for HE- AAC at 48kHz sample rate, | +SYNC_SLAVE | ||
| org.hbbtv_APP2AV0200 | 1 | APP2AV: Precision of MediaSynchroniser.currentTime on slave with no other media | When an application repeatedly reads the currentTime property from a MediaSynchroniser that has been successfully initialised for inter-device synchronisation on a slave terminal using the initSlaveMediaSynchroniser method and no other media is attached to this slave MediaSynchroniser, the currentTime property of the slave terminal MediaSynchroniser returns the value of the playback position of the MediaSynchroniser on the master terminal (within uncertainty bounds quantified by the value of the interDeviceSyncDispersion property at the slave terminal) updated at least every 100ms. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 13.11.3: For a MediaSynchroniser object that has been initialised by calling the initSlaveMediaSynchroniser method, the value returned shall correspond to the current playback position of the media object on the master terminal that was passed as an argument to the initMediaSynchroniser method on the master terminal (the master media). The precision of the playback position shall at least correlate with either: [...] or if there are no applicable video or audio components then it shall be at least 100ms. | +SYNC_SLAVE | ||
| org.hbbtv_APP2AV0300 | 1 | APP2AV: accuracy of MediaSynchroniser.currentTime with broadcast TS and MPEG TEMI (large TEMI values) | When an application reads the currentTime from a MediaSynchroniser that was initialized with a DVB TV service and a reference to a MPEG TEMI timeline, those tickrate is 48000, that is using the 64 bit timestamp format and those current values are larger than 4133977199468, carried on the audio component in that service and there are multiple timelines with different timeline IDs present on the video and audio component, the terminal shall return the current value of the referenced TEMI timeline corresponding to the last frame that was composed with graphics before the currentTime property was queried with an accuracy of at least 100ms. | 2024-2 2023-2 2023-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.11.3: When an application reads the currentTime property of a MediaSynchroniser object (see clause 8.2.3.2.1) the returned value shall correspond to the current position of the timeline used by the MediaSynchroniser object[...]For a MediaSynchroniser object that has been initialised by calling the initMediaSynchroniser method, the returned value shall correspond to the current playback position of the media object that was passed as an argument to the initMediaSynchroniser method (the master media). The value returned shall be the time of the last video frame that was composed with graphics before the property was queried and shall be accurate to within 100ms. HBBTV,section 13.4.2: Table 18: [[row 3] Type of timeline: MPEG-TS Timed External Media Information (TEMI). Supported for: MPEG Transport Stream delivered via broadcast.][...]The terminal shall derive the timeline described by a Timeline Selector for a media stream if the Timeline Selector and media object representing that media stream are passed as arguments to the initMediaSynchroniser [...] methods of a MediaSynchroniser object. TS-103-286-2,section 11.3.2: The format for a timeline selector for a temi_timeline is shown by the following Augmented BNF (as defined in RFC 5234 [4]) rule definition for temi-timeline-selector: temi-timeline-selector = "urn:dvb:css:timeline:temi:" component-tag ":" timeline-id component-tag is the base-ten integer representation of the value of the component_tag (declared by a stream identifier descriptor as defined in EN 300 468 [13]) associated with stream of TS packets that carry the temi _timeline_descriptor. timeline-id is the base-ten integer representation of the value of the timeline_id field in the temi_timeline_descriptor. The timeline to be selected shall be determined from the most recently received temi_timeline_descriptor whose timeline_id matches that specified in the Timeline Selector and which is carried in the af_descriptor() in the adaptation_field for TS packets identified by the component tag specified in the Timeline Selector. TS-103-286-2,section 11.3.3: If the has_timestamp field of a temi_timeline_descriptor is 1 or 2 then the timeline tick value is taken from the media_timestamp field and the tick rate is determined from the timescale field. The unitsPerTick of the timeline shall be 1 and the unitsPerSecond of the timeline shall be equal to the value of the timescale field. ISO/IEC-13818-1,section U.3.6: has_timestamp: Indicates a media timestamp will be carried in this descriptor, and indicates its type. Value 0 means no media timestamp is present, value 1 means a 32 bit media timestamp is present, value 2 means a 64 bit media timestamp is present, value 3 is reserved. [...] media_timestamp: Indicates the media time in timescale units ... | ||
| org.hbbtv_APPSIG0031 | 1 | Autostart app with micro version greater than supported (v2.0.1) | The terminal shall not launch autostart applications where the micro version needed by the application is greater than the micro version of the specification version supported by the terminal (1.4.1). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 | HBBTV 1.4.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | |||
| org.hbbtv_APPSIG0032 | 1 | Autostart app with micro version greater than supported (v2.0.2) | The terminal shall not launch autostart applications where the micro version needed by the application is greater than the micro version of the specification version supported by the terminal (1.5.1). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 | HBBTV 1.5.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | |||
| org.hbbtv_APPSIG0033 | 1 | Autostart app with micro version greater than supported (v2.0.3) | The terminal shall not launch autostart applications where the micro version needed by the application is greater than the micro version of the specification version supported by the terminal (1.6.1). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.6.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M TS-102-809,section 5.2.5.1: The receiver shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | |||
| org.hbbtv_APPSIG0041 | 1 | Autostart app with minor version greater than supported (v2.0.1) | The terminal shall not launch autostart applications where the minor version of the application is greater than the minor version of the specification version supported by the terminal (1.4.1). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 | HBBTV 1.4.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | |||
| org.hbbtv_APPSIG0042 | 1 | Autostart app with minor version greater than supported (v2.0.2) | The terminal shall not launch autostart applications where the minor version of the application is greater than the minor version of the specification version supported by the terminal (1.5.1). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 | HBBTV 1.5.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | |||
| org.hbbtv_APPSIG0043 | 1 | Autostart app with minor version greater than supported (v2.0.3) | The terminal shall not launch autostart applications where the minor version of the application is greater than the minor version of the specification version supported by the terminal (1.6.1). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M TS-102-809,section 5.2.5.1: The receiver shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | |||
| org.hbbtv_APPSIG0070 | 1 | Autostart app with major version greater than supported | The terminal shall not launch autostart applications where the major version of the application is greater than the major version of the specification version supported by the terminal. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | |||
| org.hbbtv_APPSIG0080 | 1 | apps requiring A/V content download feature | Terminals not supporting the DL option shall not launch autostart applications signalled as requiring the A/V content download feature | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: The following bits can be combined to express profiles corresponding to additional features that applications may require:0x0001 A/V content download feature:0x0002 PVR feature HBBTV,section 7.2.3.1: The following bits can be combined to express profiles corresponding to additional features that applications may require:0x0001 A/V content download feature:0x0002 PVR feature HBBTV,section 7.2.3.1: The following bits can be combined for applications that require additional features: 0x0001 download feature 0x0002 PVR feature 0x0004 RTSP feature HBBTV,section 5.6.1: In clause 7.2.3.1, in table 5 “Supported application signalling features” [....] in the row for 5.2.5 “Platform profiles”, “Content download” shall be changed to “A/V content download”, [....] The sentence “The following bits can be combined for applications that require additional features:” shall be replaced with “The following bits can be combined to express profiles corresponding to additional features that applications may require:” TS-102-809,section 5.2.5.1: "The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" TS-102-809,section 5.2.5.1: "The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | -DL | ||
| org.hbbtv_APPSIG0090 | 1 | apps requiring PVR feature | Terminals not supporting the PVR option shall not launch autostart applications signalled as requiring the PVR feature | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: The following bits can be combined to express profiles corresponding to additional features that applications may require:0x0001 A/V content download feature:0x0002 PVR feature HBBTV,section 7.2.3.1: The following bits can be combined to express profiles corresponding to additional features that applications may require:0x0001 A/V content download feature:0x0002 PVR feature HBBTV,section 7.2.3.1: The following bits can be combined for applications that require additional features: 0x0001 download feature 0x0002 PVR feature 0x0004 RTSP feature HBBTV,section 5.6.1: In clause 7.2.3.1, in table 5 “Supported application signalling features” [....] in the row for 5.2.5 “Platform profiles”, “Content download” shall be changed to “A/V content download”, [....] The sentence “The following bits can be combined for applications that require additional features:” shall be replaced with “The following bits can be combined to express profiles corresponding to additional features that applications may require:” TS-102-809,section 5.2.5.1: "The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" TS-102-809,section 5.2.5.1: "The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | -PVR | ||
| org.hbbtv_APPSIG0100 | 1 | Non-supported application types are ignored | Terminals not supporting an arbitrary other application type shall launch an HbbTV application when autostart apps of both types are signalled | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: The application type shall be 0x0010. HBBTV,section 7.2.3.1: Terminals shall ignore AIT sub-tables within the selected service which have an application_type that the terminal cannot decode. HBBTV,section 7.2.3.1: The application type shall be 0x0010. HBBTV,section 4.4.5: In Table 5: “Supported application signalling features”, in the row "5.3.4 Application Information Table", the following text shall be added to the “Notes” column; Terminals shall ignore AIT sub-tables within the selected service which have an application_type that the terminal cannot decode. HBBTV,section 7.2.3.1: The application type shall be 0x0010. TS-102-809,section 5.3.4: The AIT comprises the set of AIT sub-tables (see clause 5.3.4.5) within the selected service which have an application_type that the receiver can decode TS-102-809,section 5.3.4.5: All sections on the same PID with the AIT table_id and the same value of application_type are members of the same sub-table. TS-102-809,section 5.3.4: The AIT comprises the set of AIT sub-tables (see clause 5.3.4.5) within the selected service which have an application_type that the receiver can decode TS-102-809,section 5.3.4.5: All sections on the same PID with the AIT table_id and the same value of application_type are members of the same sub-table. | |||
| org.hbbtv_APPSIG0110 | 1 | AIT application priority between application types | Terminals also supporting MHP shall launch an HbbTV app when autostart apps of both types are signalled and the HbbTV app has a higher priority | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.7 Application priority | 18 | M HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.7 Application priority | 18 | M HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.7 Application priority | 18 | M TS-102-809,section 5.2.7.1: The application priority identifies a relative priority between the applications signalled in a service:[....] Where there is more than one application with the same application identification in a service, this priority shall be used to determine which application is started. TS-102-809,section 5.2.7.1: The application priority identifies a relative priority between the applications signalled in a service:[....] Where there is more than one application with the same application identification in a service, this priority shall be used to determine which application is started. | +MHP | ||
| org.hbbtv_APPSIG0120 | 1 | MHP application type is ignored when not supported | Terminals not supporting MHP shall launch an HbbTV application when both autostart MHP and HbbTV apps are signalled | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: The application type shall be 0x0010. HBBTV,section 7.2.3.1: Terminals shall ignore AIT sub-tables within the selected service which have an application_type that the terminal cannot decode. HBBTV,section 7.2.3.1: The application type shall be 0x0010. HBBTV,section 4.4.5: In Table 5: “Supported application signalling features”, in the row "5.3.4 Application Information Table", the following text shall be added to the “Notes” column; Terminals shall ignore AIT sub-tables within the selected service which have an application_type that the terminal cannot decode. HBBTV,section 7.2.3.1: The application type shall be 0x0010. TS-102-809,section 5.3.4: The AIT comprises the set of AIT sub-tables (see clause 5.3.4.5) within the selected service which have an application_type that the receiver can decode TS-102-809,section 5.3.4.5: All sections on the same PID with the AIT table_id and the same value of application_type are members of the same sub-table. TS-102-809,section 5.3.4: The AIT comprises the set of AIT sub-tables (see clause 5.3.4.5) within the selected service which have an application_type that the receiver can decode TS-102-809,section 5.3.4.5: All sections on the same PID with the AIT table_id and the same value of application_type are members of the same sub-table. | -MHP | ||
| org.hbbtv_APPSIG0130 | 1 | HbbTV v1 apps shall be supported | Terminals shall launch applications whose application profile version is major=1, minor=1 and micro=1 | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | |||
| org.hbbtv_APPSIG0140 | 1 | HbbTV v1.5 apps shall be supported | Terminals shall launch applications whose application profile version is major=1, minor=2 and micro=1 | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | |||
| org.hbbtv_APPSIG0141 | 1 | HbbTV v2 apps shall be supported | Terminals shall launch applications whose application profile version is major=1, minor=3 and micro=1 | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | |||
| org.hbbtv_APPSIG0142 | 1 | HbbTV v2.0.1 apps shall be supported | Terminals shall launch applications whose application profile version is major=1, minor=4 and micro=1 | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. [...] 5.2.5 Platform profiles | 17 | M TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" TS-102-809,section 5.2.5.1: The terminal shall only launch applications if the following expression is true for at least one of the signalled profiles: (application_profile ? terminal_profiles_set) ^ {(application_version.major < terminal_version.major(application_profile)) | [(application_version.major = terminal_version.major(application_profile)) ^ ({application_version.minor < terminal_version.minor(application_profile)} | {[application_version.minor = terminal_version.minor(application_profile)] ^ [application_version.micro <= terminal_version.micro(application_profile)]})]} Where : ? represents "belongs to the set of" ^ represents "logical AND" | represents "logical OR" | |||
| org.hbbtv_APPSIG0500 | 1 | Support for AITs with two sections. | Terminals shall launch an autostart application whose signalling is contained in the last section of an AIT sub-table which has two sections. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.1: The application lifecycle is determined by the following four factors: 4) The signalled application control code (as defined in clause 7.2.3.1 of the present document and clause 5.2.4 of TS 102 809 [3]). HBBTV,section 6.2.1: The application lifecycle is determined by the following four factors: 4) The signalled application control code (as defined in clause 7.2.3.1 of the present document and clause 5.2.4 of TS 102 809 [3]). HBBTV,section 6.2.1: The application lifecycle is determined by the following four factors: 4) The signalled application control code (as defined in clause 7.2.3.1 of the present document and clause 5.2.4 of TS 102 809 [3]). HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. TS-102-809,section 5.3.4.6: section_number: This 8-bit field gives the number of the section. The section_number of the first section in the sub_table shall be "0x00". The section_number shall be incremented by 1 with each additional section with the same table_id, and application_type. last_section_number: This 8-bit field specifies the number of the last section (that is, the section with the highest section_number) of the sub_table of which this section is part. | |||
| org.hbbtv_APPSIG0510 | 1 | Support for AITs with eight sections. | If the HbbTV AIT sub-table has 8 sections and there is only one autostart application in the first section of that sub-table and there is a second application in the last section of that sub-table with control code 2 (present) and the autostart application launches the second application via the createApplication method, the terminal shall on channel tuning first launch the autostart application and then the second application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.1: The application lifecycle is determined by the following four factors: 4) The signalled application control code (as defined in clause 7.2.3.1 of the present document and clause 5.2.4 of TS 102 809 [3]). HBBTV,section 6.2.1: The application lifecycle is determined by the following four factors: 4) The signalled application control code (as defined in clause 7.2.3.1 of the present document and clause 5.2.4 of TS 102 809 [3]). HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. HBBTV,section 7.2.3.1: Table 5 identifies the descriptors and other signalling entities whose MPEG-2 encoding shall be supported. TS-102-809,section 5.3.4.6: section_number: This 8-bit field gives the number of the section. The section_number of the first section in the sub_table shall be "0x00". The section_number shall be incremented by 1 with each additional section with the same table_id, and application_type. last_section_number: This 8-bit field specifies the number of the last section (that is, the section with the highest section_number) of the sub_table of which this section is part. HBBTV,section 10.2.1: Terminals shall support AIT sub-tables for HbbTV applications, i.e. that have an application type 0x10, with at least 8 sections. HBBTV,section 10.2.1: Terminals shall support AIT sub-tables for HbbTV applications, i.e. that have an application type 0x10, with at least 8 sections. | |||
| org.hbbtv_AUDIO_COMMUTING0010 | 1 | AV Components: Selecting audio components from an HTTP MP4 stream with Spanish and English languages | Using the AV Control object functions getComponents and selectComponent, the terminal shall correctly switch to presenting the unplayed audio component from a HTTP MP4 stream containing Spanish and English language components that is currently being presented. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-1 2020-3 2020-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Where constants are defined in in the OIPF DAE specification [1] as input parameters and/or return values for methods or as values for properties, these constants shall be supported if any method or property is supported that uses them and if the constant is not explicitly excluded by name below. [...] OIPF-DAE,section 7.16.5: void selectComponent( AVComponent component ) [...] Select the component that will be subsequently rendered when A/V playback starts or select the component for rendering if A/V playback has already started. If playback has started, this SHALL replace any other components of the same type that are currently playing. TDT-Hibrida,section E.4.5: Commuting audio adaptation set in a single manifest should be seamless and avoiding audio glitches. Video adaptation set, if present, should not be affected with freezes or black screens during audio adaptation set switching. Example: switching audio languages for same video contents. | |||
| org.hbbtv_AUDIO_COMMUTING0020 | 1 | AV Components: Selecting audio components from an HbbTV ISOBMFF DASH Live stream with Spanish and English languages | Using the A/V Control object functions getComponents and selectComponent, the terminal shall correctly switch to presenting the unplayed audio component from a HbbTV ISOBMFF DASH Live stream containing Spanish and English language adaptation sets. | 2024-2 2024-1 2023-3 2023-2 2023-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Where constants are defined in in the OIPF DAE specification [1] as input parameters and/or return values for methods or as values for properties, these constants shall be supported if any method or property is supported that uses them and if the constant is not explicitly excluded by name below. [...] OIPF-DAE,section 7.16.5: void selectComponent( AVComponent component ) [...] Select the component that will be subsequently rendered when A/V playback starts or select the component for rendering if A/V playback has already started. If playback has started, this SHALL replace any other components of the same type that are currently playing. TDT-Hibrida,section E.4.5: Commuting audio adaptation set in a single manifest should be seamless and avoiding audio glitches. Video adaptation set, if present, should not be affected with freezes or black screens during audio adaptation set switching. Example: switching audio languages for same video contents. | |||
| org.hbbtv_AUDIOMIX0010 | 1 | video/broadcast object volume control | A service has two audio tracks A and B and is being presented using the video/broadcast object. The audio level in A is 12dB higher than in B. The application selects audio track A. When setVolume(70) is called on the v/b object, the audio becomes quieter without any audible glitches within 20 milliseconds. getVolume() returns 70. When setVolume(88) is called, the audio gets louder in volume without any audible glitches within 20 milliseconds. When audio track B is selected and setVolume(100) is immediately called, then after a possible brief transient, the audible volume remains the same. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 10.2.12: Terminals shall implement volume changes as a fade over an interval sufficient to avoid audible clicks (e.g. 5ms) but should not prolong changes to the point that the listener perceives a gradual fade. Any changes shall fully take effect within 20ms. ... The volume parameter of the setVolume method of the video/broadcast object takes an integer value between 0 and 100. ... In the present document, the volume scale is defined more precisely by the following formula: attenuation_db = { 100-vb_volume, vb_volume > 0; inf, vb_volume = 0 }; amplitude_scale = 10 ^ (attenuation_db / 20) where attenuation_dB is the attenuation to be applied in dB, vb_volume is the value of the volume parameter passed to the setVolume method of the video/broadcast object, and amplitude_scale is the factor to be applied to the amplitude of the audio. ... These volume controls may have no effect if the user has explicitly enabled an audio pass-through mode on the terminal. HBBTV,section A.1: video/broadcast embedded object ... The setVolume() and getVolume() methods shall be supported and shall comply with the requirements of clause 10.2.12. | |||
| org.hbbtv_AUDIOMIX0020 | 1 | HTMLMediaElement volume control | A DASH stream has two audio tracks A and B and is being presented using an HTML video element. The audio level in A is 12dB higher than in B. The application enables audio track A and disables B. When the media element volume is set to 0.03, the audio becomes quieter without any audible glitches within 20 milliseconds. When the media element volume is set to 0.25, the audio gets louder in volume without any audible glitches within 20 milliseconds. When audio track A is disabled, B enabled and the media element volume is immediately set to 1.0, then after a possible brief transient, the audible volume remains the same. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 10.2.12: Terminals shall implement volume changes as a fade over an interval sufficient to avoid audible clicks (e.g. 5ms) but should not prolong changes to the point that the listener perceives a gradual fade. Any changes shall fully take effect within 20ms. ... The volume attribute of the HTMLMediaElement takes a floating point value between 0.0 and 1.0 with 0.0 meaning “silent” and 1.0 meaning “loudest”. In the present document, the volume scale shall be linear in amplitude. ... These volume controls may have no effect if the user has explicitly enabled an audio pass-through mode on the terminal. HBBTV,section A.3.6: * The volume attribute of the HTMLMediaElement shall comply with the requirements of clause 10.2.12. | |||
| org.hbbtv_AUDIOMIX0030 | 1 | WebAudio GainNode | There are two WAV files A and B. The audio level in A is 12dB higher than in B. The application plays A using the WebAudio API. The application then plays A again with a GainNode with gain set to 0.03. The audio is quieter. The application then plays A again with gain set to 0.25. The audio is louder. Finally, the application then plays B with gain set to 1.0. The audible volume remains the same. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.10: The following interfaces from the Web Audio API [65] shall be supported with the properties and methods listed for each: ... * AudioParam: value, defaultValue, minValue, maxValue, setValueAtTime, cancelScheduledValues * GainNode: gain WEBAUDIO,section 1.20: 1.20. The GainNode Interface Changing the gain of an audio signal is a fundamental operation in audio applications. This interface is an AudioNode with a single input and single output ... Each sample of each channel of the input data of the GainNode MUST be multiplied by the computedValue of the gain AudioParam. | |||
| org.hbbtv_AUDIOMIX0040 | 1 | Audio pass-through status | The XML configuration contains an audio_system element that has a pass_through attribute. The terminal's pass-through mode is enabled. The XML configuration audio_system element pass_though attribute has the value "true". The terminal's pass-through mode is disabled. The XML configuration audio_system element pass_through attribute has the value "false". | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 10.2.4.7: Terminals that can output multi-channel audio or support any audio pass-through mode shall include an element of the following form to describe current audio output capabilities of the terminal: <audio_system audio_output_format="audio-type" pass_through="passthrough-status"/> ... passthrough-status is one of the following: • “true” – the terminal’s audio outputs are operating in a pass-through mode in which broadcast or broadband audio bitstreams are output directly by the terminal without modification. In this mode, the effects of playing audio from the WebAudio API or using the audio volume APIs are not expected to be heard. • “false” – the terminal is not operating in a pass-through mode. Audio playback using the WebAudio API and application control of audio volume will function normally. NOTE 7: The XML configuration is only indicative for the time that it is read. System state such as “passthrough” can change at any time. | |||
| org.hbbtv_AUDIOMIX0100 | 1 | Audio mixing - stereo broadcast, stereo WebAudio | A broadcast-related HbbTV application that is connected to the broadcast of the current channel which has unencrypted stereo audio loads a stereo 48 kHz WAV file with XMLHttpRequest and AudioContext.decodeAudioData and then plays that through the Web Audio API. The WAV file's audio is heard and the broadcast audio and video playback are not interrupted. The audio is mixed together. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 10.2.11: Subject to the constraints defined in this clause, terminals shall support playing audio from memory via the Web Audio API (referred to in this clause as “mixed-in audio”) simultaneously with playing audio delivered via broadcast or broadband (referred to in this clause as the “programme audio”). Specifically, this shall be supported in all of the following cases, either with or without video: • The programme audio delivered via broadcast ... subject to the following constraints: • The mixed-in audio is mono or stereo; and • The mixed-in audio is sampled at 48 kHz ... Terminals shall seamlessly mix the mixed-in audio with the programme audio and output the results on all outputs from the terminal with the following exceptions: ... • If the user has explicitly enabled an audio pass-through mode on the terminal then the mixed-in audio may not be heard through outputs that receive the original programme audio bitstream. • Where the programme audio is encrypted, depending on the level of security required, the mixed-in audio may not be heard ... In all cases, the following shall apply: • The playback of the mixed-in audio shall not disturb the playback of the video from the programme A/V, e.g. the video shall not be paused, no frames shall be dropped and no black frames shall be inserted. HBBTV,section 10.2.1: The following formats shall be supported as input to the AudioContext.decodeAudioData method of the Web Audio API [65]; • MPEG1_L3 (as defined in clause 8.1 of the OIPF Media Formats specification [1]) • Mono or stereo 16-bit linear PCM audio samples in a RIFF WAVE container (i.e. a "WAV" file [89] with wFormatTag=WAVE_FORMAT_PCM (0x0001), wChannels=1 or 2 and wBitsPerSample=16) | |||
| org.hbbtv_AUDIOMIX0110 | 1 | Audio mixing - stereo DASH, stereo WebAudio | An HbbTV application is playing a DASH stream that has unencrypted stereo audio and loads a stereo 48 kHz WAV file with XMLHttpRequest and AudioContext.decodeAudioData and then plays that through the Web Audio API. The WAV file's audio is heard and the DASH audio and video playback are not interrupted. The audio is mixed together. | 2024-2 2024-1 | HBBTV 1.7.1 | HBBTV,section 10.2.11: Subject to the constraints defined in this clause, terminals shall support playing audio from memory via the Web Audio API (referred to in this clause as “mixed-in audio”) simultaneously with playing audio delivered via broadcast or broadband (referred to in this clause as the “programme audio”). Specifically, this shall be supported in all of the following cases, either with or without video: • The programme audio delivered via broadband ... subject to the following constraints: • The mixed-in audio is mono or stereo; and • The mixed-in audio is sampled at 48 kHz ... Terminals shall seamlessly mix the mixed-in audio with the programme audio and output the results on all outputs from the terminal with the following exceptions: ... • If the user has explicitly enabled an audio pass-through mode on the terminal then the mixed-in audio may not be heard through outputs that receive the original programme audio bitstream. • Where the programme audio is encrypted, depending on the level of security required, the mixed-in audio may not be heard ... In all cases, the following shall apply: • The playback of the mixed-in audio shall not disturb the playback of the video from the programme A/V, e.g. the video shall not be paused, no frames shall be dropped and no black frames shall be inserted. HBBTV,section 10.2.1: The following formats shall be supported as input to the AudioContext.decodeAudioData method of the Web Audio API [65]; • MPEG1_L3 (as defined in clause 8.1 of the OIPF Media Formats specification [1]) • Mono or stereo 16-bit linear PCM audio samples in a RIFF WAVE container (i.e. a "WAV" file [89] with wFormatTag=WAVE_FORMAT_PCM (0x0001), wChannels=1 or 2 and wBitsPerSample=16) | |||
| org.hbbtv_AVC00010 | 1 | video/broadcast object supports media playback extensions API. | Video/broadcast object shall support: constants - COMPONENT_TYPE_VIDEO, COMPONENT_TYPE_AUDIO, COMPONENT_TYPE_SUBTITLE, methods - getComponents, getCurrentActiveComponents, selectComponent and unselectComponent. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5.1: Media playback extensions. OIPF-DAE,section 8.4.2: AVComponent OIPF-DAE,section 7.13.4.1: Media playback extensions to video/broadcast | |||
| org.hbbtv_AVC00020 | 1 | Correct collection of AVcomponents is returned by getComponents(null) method of video/broadcast. | getComponents method shall return collection of components with length = 8, all 8 items contain valid AVcomponents. Array notation to access AVcomponents is supported. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5.1: Media playback extensions. OIPF-DAE,section 7.16.5.6: The AVComponentCollection class. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00030 | 1 | video/broadcast object correctly converts component_tag field in the stream_identifier_descriptor in PMT into componentTag property of AVComponent. | getComponents(null) method of video/broadcast object shall return collection of AVcomponents where componentTag property of items is respectively 1, 2, 3, 4, 5, 6, 7, 8. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5.2: The AVComponent class. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00040 | 1 | video/broadcast object correctly converts elementary_pid field in the stream_identifier_descriptor in PMT into pid property of AVComponent. | getComponents(null) method of video/broadcast object shall return collection of AVcomponents where pid field of items are respectively 0x62, 0x65, 0x66, 0x74, 0x75, 0x76, 0x67, 0x68 | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5.2: The AVComponent class. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00045 | 1 | Terminal correctly recognizes type of AVComponent. | getComponents(null) method of video/broadcast object shall return following collection of AVcomponents: type=COMPONENT_TYPE_VIDEO, pid = 0x62, pid = 0x65, type=COMPONENT_TYPE_AUDIO, pid = 0x66, pid = 0x74, pid = 0x75, pid = 0x76, type=COMPONENT_TYPE_SUBTITLE, pid = 0x67, pid = 0x68. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00050 | 1 | getComponents(COMPONENT_TYPE_VIDEO) method of video/broadcast object returns correct collection of video AVcomponents. | getComponents method shall return collection of video components with length = 2, one component has pid=0x62, componentTag=1, other pid=0x65, componentTag=2 | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5.1: Media playback extensions. OIPF-DAE,section 7.16.5.6: The AVComponentCollection class. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00060 | 1 | getComponents(COMPONENT_TYPE_AUDIO) method of video/broadcast object returns correct collection of audio AVcomponents. | getComponents method shall return collection of audio components with length = 4, components have parameters: pid=0x66, componentTag=3, pid=0x74, componentTag=4. pid=0x75, componentTag=5. pid=0x76, componentTag=6 | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5.1: Media playback extensions. OIPF-DAE,section 7.16.5.6: The AVComponentCollection class. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00070 | 1 | getComponents(COMPONENT_TYPE_SUBTITLE) method of video/broadcast object returns correct collection of subtitle AVcomponents. | getComponents method shall return collection of subtitle components with length = 2, components have parameters: pid=0x67, componentTag=7, pid=0x68, componentTag=8 | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5.1: Media playback extensions. OIPF-DAE,section 7.16.5.6: The AVComponentCollection class. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00085 | 1 | Terminal correctly recognizes scrambling of AVComponent. | getComponents method of video/broadcast object shall return collection of AVcomponents where: audio component with componentTag=5 has property encrypted=true. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00090 | 1 | Terminal correctly calculates 'aspectRatio' property of AVVideoComponents | When the video/broadcast object is bound to an MPEG-2 TS stream containing one 4:3 aspect ratio and one 16:9 aspect ratio elementary video stream, getComponents() shall return an AVComponentCollection containing two AVVideoComponents with 'aspectRatio' properties of 1.33 and 1.78, respectively | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 7.16.5.3: The AVVideoComponent class OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00100 | 1 | Terminal correctly recognizes language of audio AVComponents. | getComponents method of video/broadcast object shall return collection of AVcomponents where: audio component with componentTag=3 has language='eng', audio component with componentTag=4 has language='pol', audio component with componentTag=5 has language='kor', audio component with componentTag=6 has language='ita', | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 7.16.5.4: The AVAudioComponent class OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00110 | 1 | Terminal correctly sets audioDescription of audio AVComponent. | getComponents method of video/broadcast object shall return collection of AVcomponents where: one audio component has audioDescription=true. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition. ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 7.16.5.4: The AVAudioComponent class OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00130 | 1 | Terminal correctly recognizes language of subtitle AVComponent. | getComponents method of video/broadcast object shall return collection of AVcomponents where subtitle components have languages 'pol' and 'eng'. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 7.16.5.5: The AVSubtitleComponent class OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00140 | 1 | Terminal correctly recognizes hearing impaired of subtitle AVComponent. | getComponents method of video/broadcast object shall return collection of AVcomponents where 1 subtitle component have hearingImpaired=true. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 7.16.5.5: The AVSubtitleComponent class OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00145 | 1 | Terminal correctly returns active AVComponents using getCurrentActiveComponents( componentType ) method of video/broadcast object. | When the video/broadcast object is playing a stream containing multiple video, audio and subtitle components, a call to getCurrentActiveComponents() with a componentType of COMPONENT_TYPE_VIDEO, COMPONENT_TYPE_AUDIO or COMPONENT_TYPE_SUBTITLE, shall return the currently active AVComponent for the video, audio or subtitle component, respectively | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent OIPF-Media-Formats,section 3: A/V Media Formats | ||
| org.hbbtv_AVC00150 | 1 | Terminal correctly switches AVComponents using selectComponent( AVComponent component ) method of video/broadcast object. | Terminal shall read current active components (video, audio and subtitle), next it selects from all components non-active audio and subtitle. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition HBBTV,section 10.2.7: Subtitles OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00155 | 1 | Terminal correctly updates active AVComponents collection. | Terminal shall read collection of current active components (video, audio and subtitle) using getCurrentActiveComponents( Integer componentType ) method, and compares it with active AVcomponents after switching. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition. ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00160 | 1 | SelectedComponentChange callback is called when selectComponent switches AVComponents. | Terminal shall read current active audio and subtitle components, next it selects from all components non-active audio and subtitle. After each switching, callback SelectedComponentChange with appropriate argument is called. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | ||
| org.hbbtv_AVC00170 | 1 | Unselecting COMPONENT_TYPE_VIDEO stops rendering video AVComponent. | When unselectComponent(COMPONENT_TYPE_VIDEO) is called video/broadcast object shall stop to render video. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00180 | 1 | Terminal stops presenting audio AV component when unselectComponent(COMPONENT_TYPE_AUDIO)of video/broadcast object is called. | When unselectComponent(COMPONENT_TYPE_AUDIO) is called video/broadcast object shall stop to render audio. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | ||
| org.hbbtv_AVC00190 | 1 | Unselecting COMPONENT_TYPE_SUBTITLE stops rendering subtitle AVComponent. | When unselectComponent(COMPONENT_TYPE_SUBTITLE) is called video/broadcast object shall stop to render subtitle. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00200 | 1 | Terminal restore rendering video AVComponents after selectComponent(COMPONENT_TYPE_VIDEO) calling. | Terminal shall restore rendering video component, when selectComponent(COMPONENT_TYPE_VIDEO) is called. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent. | |||
| org.hbbtv_AVC00201 | 1 | Terminal restores rendering audio AVComponents after selectComponent(COMPONENT_TYPE_AUDIO) calling. | Terminal shall restore rendering audio component, when selectComponent(COMPONENT_TYPE_AUDIO) is called. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent. | |||
| org.hbbtv_AVC00210 | 1 | Terminal selects by default audio AV component with language equal preferredAudioLanguage property of Configuration object. | Language of current active audio component and preferredAudioLanguage in Configuration object ('eng') shall be the same. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.3.2: The Configuration class. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent. | |||
| org.hbbtv_AVC00220 | 1 | Terminal selects by default subtitle AVcomponent with language equal preferredSubtitleLanguage property of Configuration object. | Language of current active subtitle component and preferredSubtitleLanguage in Configuration object ('eng') shall be the same. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition HBBTV,section 10.2.7: Subtitles ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.3.2: The Configuration class. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00230 | 1 | video/broadcast object updates component collection, if broadcasted data related to AV components changes. | 7 components: 1 video, 4 audio and 2 subtitle is broadcasted in the current channel. getComponents method shall return correct number and type of components. Next 4 components are broadcasted: 1 video, 2 audio and 1 subtitle. Terminal shall update number and type of components. Next 5 components are broadcasted: 1 video, 3 audio and 1 subtitle. Terminal shall update number and type of components. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC00235 | 1 | SelectedComponentChange is called, if AVcomponent being presented is no longer available. | 1 video, 4 audio and 2 subtitle components are broadcasted, sequently video, audio and subtitle selected components are no longer broadcasted. Each time selected components is no longer available SelectedComponentChange shall be called. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition ISO/IEC-13818-1,section 2.6: Program and program element descriptors. OIPF-DAE,section 7.13.4: Extensions to video/broadcast for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01010 | 1 | A/V Control object supports media playback extensions API. | A/V Control object shall support: constants - COMPONENT_TYPE_VIDEO, COMPONENT_TYPE_AUDIO, COMPONENT_TYPE_SUBTITLE, methods - getComponents, getCurrentActiveComponents, selectComponent and unselectComponent. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.14.4: Extensions to A/V object for playback of selected components. OIPF-DAE,section 7.16.5.1: Media playback extensions. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01030 | 1 | getComponents(null) method of A/V control object returns correct collection of AVcomponents defined mp4 file. | getComponents method shall return collection of components with length = 5, items contains AV components which corresponds to tracks in mp4 file. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.14.4: Extensions to A/V object for playback of selected components. OIPF-DAE,section 7.16.5.1: Media playback extensions. OIPF-DAE,section 7.16.5.6: The AVComponentCollection class. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01040 | 1 | A/V Control object correctly converts trackID of mp4 file into pid property of AVComponent. | getComponents(null) method of A/V Control object shall return collection of AVComponents where pid field of items are respectively 1, 2, 3, 4, 5. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.14.4: Extensions to A/V object for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01050 | 1 | getComponents(COMPONENT_TYPE_VIDEO) method of A/V control object returns correct collection of video AVcomponents from mp4 file. | getComponents method shall return collection of components with length = 2, items contain AV video components which corresponds to tracks with sample description type 'avc1'. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.14.4: Extensions to A/V object for playback of selected components. OIPF-DAE,section 7.16.5.1: Media playback extensions. OIPF-DAE,section 7.16.5.6: The AVComponentCollection class. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01060 | 1 | getComponents(COMPONENT_TYPE_AUDIO) method of A/V control object returns correct collection of audio AVcomponents from mp4 file. | getComponents method returns collection of components with length = 3, items shall contain AV audio components which corresponds to tracks with sample description type 'mp4a'. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.14.4: Extensions to A/V object for playback of selected components. OIPF-DAE,section 7.16.5.1: Media playback extensions. OIPF-DAE,section 7.16.5.6: The AVComponentCollection class. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01070 | 1 | A/V Control object correctly sets language of audio AVComponents. | A/V control object shall play mp4 file, in which media header 'mdhd' contains language code 'pol' for track 3, 'eng' for track 4 and 'kor' for track 5. getComponents method of A/V control object returns collection of AVComponents which contains components with: pid=3 and language='pol', pid=4 have language='eng', pid=5 have language='kor'. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.14.4: Extensions to A/V object for playback of selected components. OIPF-DAE,section 7.16.5.1: Media playback extensions. OIPF-DAE,section 7.16.5.6: The AVComponentCollection class. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01080 | 1 | Terminal correctly reads active AVComponents using getCurrentActiveComponents( componentType ) method of A/V Control object. | Terminal shall read current active components (video and audio) from mp4 file using getCurrentActiveComponents( Integer componentType ) method, and compares it with output. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.14.4: Extensions to A/V object for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01099 | 1 | onSelectedComponentChanged callback is called when terminal switches AVComponents using unselectComponent( AVComponent component ) method of A/V Control object. | Terminal unselects AVcomponents (video and audio). After each unselecting, callback onSelectedComponentChanged with valid argument shall be called. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.14.4: Extensions to A/V object for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01101 | 1 | Terminal correctly switches AVComponents using selectComponent(AVComponent) method of A/V control object | When a playing A/V Control object's selectComponent() method is called with an AVComponent representing an inactive video or audio from an mp4 file, the currently active video or audio component shall be changed to that of the inactive AVComponent and a SelectedComponentChange event shall be dispatched | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.14.4: Extensions to A/V object for playback of selected components. OIPF-DAE,section 7.16.5.1: Media playback extensions. OIPF-DAE,section 7.16.5.6: The AVComponentCollection class. OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01110 | 1 | Terminal stops presenting video AV component when unselectComponent(COMPONENT_TYPE_VIDEO) of A/V Control object is called. | When unselectComponent(COMPONENT_TYPE_VIDEO) is called A/V Control object shall stop to render video from mp4 file. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.14.4: Extensions to A/V object for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01120 | 1 | Terminal stops presenting audio AVcomponent when unselectComponent(COMPONENT_TYPE_AUDIO) of A/V Control object is called. | When unselectComponent(COMPONENT_TYPE_AUDIO) is called A/V Control object shall stop to render audio from mp4 file. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.14.4: Extensions to A/V Control for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC01140 | 2 | A/V control object updates component collection after start of playing different mp4 file. | Terminal shall update information of A/V Components when next mp4 file is played. When second mp4 file is played A/V Control shall contain information of 5 A/V components: 2 video (pid=1 and pid=2) and 3 audio : pid=3, language='pol', pid=4, language = 'eng', pid=5, language='kor'. When third mp4 file is played A/V Control shall contain information of 2 A/V components, 1 video (pid=1) and 1 audio(pid=2) with language 'rus'. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition HBBTV,section A.2.5: Extensions to the AV Control Object OIPF-DAE,section 7.13.4: Extensions to A/V Control for playback of selected components. OIPF-DAE,section 7.16.5: Extensions for playback of selected media components OIPF-DAE,section 8.4.2: AVComponent | |||
| org.hbbtv_AVC-HD-009-009 | 1 | Fragmented MP4 - HD - H.264/AVC - HP 3.1 - 1280 x 720 px @ 25i - 16:9 - 8 Mbps | The terminal shall correctly decode and present video from a fragmented MP4 file encoded with the AVC_HD_25 video format, High 3.1 profile, 16:9 aspect ratio, 1280 x 720 px resolution, 25i frame rate, 8 Mbps bandwidth | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 4.2: The carriage of A/V content and related information (e.g. subtitles) in file-based formats (systems layer format: MP4) SHALL use the MP4 File Format [MP4FF] and ISO Base Media File Format [ISOFF] standards with the constraints defined in section 9.4.4.3 of [DLNAMEDIA], except for 9.4.4.3.3 and 9.4.4.3.10. This is the preferred format for MP4-based unprotected content. Moreover, the following additional constraints apply: The largesize defined in 4.2 of [ISOFF] SHALL NOT be used. Note that larger MP4 files are still able to be generated and used in IPTV services by means of movie fragments. The stco box defined in 8.19 of [ISOFF] SHALL be used. i.e. the co64 box defined in 8.19 of [ISOFF] SHALL NOT be used. For services that allow the real-time playback of downloaded content before the download has been completed (e.g. Progressive Download), the following additional constraints apply: The moov and moof boxes SHALL be used according to section 9.4.4.3.11 of [DLNAMEDIA]. Use of the pdin box, defined in 8.43 of [ISOFF], is RECOMMENDED. In addition, carriage of H.264/AVC content in the MP4 systems layer SHALL be conformant to the AVC File Format standard [AVCFF]. OIPF-Media-Formats,section 5: H.264/AVC [H264] (video format label: AVC) is the preferred video codec for both standard definition and high definition content. OIPF-Media-Formats,section 5.1.3: All AVC format content provided in IPTV services SHALL conform to the following constraints in GOP structure: All slices in the same picture SHALL be of the same type. I picture: A picture with slice_type=7 or slice_type=2 for all the slices composing that picture or IDR picture. P picture: A picture with slice_type=5 or slice_type=0 for all the slices composing that picture. B picture: A picture with slice_type=6 or slice_type=1 for all the slices composing that picture. Decoding order among I or P pictures SHALL be kept in their display order. P picture SHALL NOT refer to B pictures. Complementary reference field pair that includes I/P field SHALL NOT include B field. Reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. Non-reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. A reference B frame or a complementary reference field pair of reference B pictures that immediately precedes/follows in display order and is present between "pic1" and "pic2" in display order. Here, "pic1" is immediately preceding I or P picture and "pic2" is immediately following I or P picture. OIPF-Media-Formats,section 5.1.1.1: H.264/AVC HD video content SHALL comply with [TS101154] clauses 5.5 and 5.7. This format corresponds to video format label AVC_HD_25 in 25Hz systems. OIPF-Protocol,section 5.2.2.2: The use of the HTTP protocol on this reference point SHALL comply with [HTTP]. The Content Delivery Function SHALL support the Range HTTP header in a GET request from the OITF to reduce unnecessary network usage by allowing partial retrieval for use in cases such as trick play. The OITF MAY pre-buffer the content in order to sustain play-out even when the HTTP transfer is stalled. HBBTV,section 7.3.1.2: For non-adaptive unicast streaming, terminals shall support content whose average total bitrate when measured over a 10 second window does not exceed 12 Mbit/s, inclusive of multiplexing and packaging overheads but excluding network protocol overheads. | |||
| org.hbbtv_AVC-HD-009-017 | 1 | Fragmented MP4 - HD - H.264/AVC - HP 3.2 - 1920 x 1080 px @ 25i - 16:9 - 8 Mbps | The terminal shall correctly decode and present video from a fragmented MP4 file encoded with the AVC_HD_25 video format, High 3.2 profile, 16:9 aspect ratio, 1920 x 1080 px resolution, 25i frame rate, 8 Mbps bandwidth | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 4.2: The carriage of A/V content and related information (e.g. subtitles) in file-based formats (systems layer format: MP4) SHALL use the MP4 File Format [MP4FF] and ISO Base Media File Format [ISOFF] standards with the constraints defined in section 9.4.4.3 of [DLNAMEDIA], except for 9.4.4.3.3 and 9.4.4.3.10. This is the preferred format for MP4-based unprotected content. Moreover, the following additional constraints apply: The largesize defined in 4.2 of [ISOFF] SHALL NOT be used. Note that larger MP4 files are still able to be generated and used in IPTV services by means of movie fragments. The stco box defined in 8.19 of [ISOFF] SHALL be used. i.e. the co64 box defined in 8.19 of [ISOFF] SHALL NOT be used. For services that allow the real-time playback of downloaded content before the download has been completed (e.g. Progressive Download), the following additional constraints apply: The moov and moof boxes SHALL be used according to section 9.4.4.3.11 of [DLNAMEDIA]. Use of the pdin box, defined in 8.43 of [ISOFF], is RECOMMENDED. In addition, carriage of H.264/AVC content in the MP4 systems layer SHALL be conformant to the AVC File Format standard [AVCFF]. OIPF-Media-Formats,section 5: H.264/AVC [H264] (video format label: AVC) is the preferred video codec for both standard definition and high definition content. OIPF-Media-Formats,section 5.1.3: All AVC format content provided in IPTV services SHALL conform to the following constraints in GOP structure: All slices in the same picture SHALL be of the same type. I picture: A picture with slice_type=7 or slice_type=2 for all the slices composing that picture or IDR picture. P picture: A picture with slice_type=5 or slice_type=0 for all the slices composing that picture. B picture: A picture with slice_type=6 or slice_type=1 for all the slices composing that picture. Decoding order among I or P pictures SHALL be kept in their display order. P picture SHALL NOT refer to B pictures. Complementary reference field pair that includes I/P field SHALL NOT include B field. Reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. Non-reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. A reference B frame or a complementary reference field pair of reference B pictures that immediately precedes/follows in display order and is present between "pic1" and "pic2" in display order. Here, "pic1" is immediately preceding I or P picture and "pic2" is immediately following I or P picture. OIPF-Media-Formats,section 5.1.1.1: H.264/AVC HD video content SHALL comply with [TS101154] clauses 5.5 and 5.7. This format corresponds to video format label AVC_HD_25 in 25Hz systems. OIPF-Protocol,section 5.2.2.2: The use of the HTTP protocol on this reference point SHALL comply with [HTTP]. The Content Delivery Function SHALL support the Range HTTP header in a GET request from the OITF to reduce unnecessary network usage by allowing partial retrieval for use in cases such as trick play. The OITF MAY pre-buffer the content in order to sustain play-out even when the HTTP transfer is stalled. HBBTV,section 7.3.1.2: For non-adaptive unicast streaming, terminals shall support content whose average total bitrate when measured over a 10 second window does not exceed 12 Mbit/s, inclusive of multiplexing and packaging overheads but excluding network protocol overheads. | |||
| org.hbbtv_AVC-HD-009-025 | 1 | Fragmented MP4 - HD - H.264/AVC - HP 3.2 - 1280 x 720 px @ 50p - 16:9 - 8 Mbps | The terminal shall correctly decode and present video from a fragmented MP4 file encoded with the AVC_HD_25 video format, High 3.2 profile, 16:9 aspect ratio, 1280 x 720 px resolution, 50p frame rate, 8 Mbps bandwidth | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 4.2: The carriage of A/V content and related information (e.g. subtitles) in file-based formats (systems layer format: MP4) SHALL use the MP4 File Format [MP4FF] and ISO Base Media File Format [ISOFF] standards with the constraints defined in section 9.4.4.3 of [DLNAMEDIA], except for 9.4.4.3.3 and 9.4.4.3.10. This is the preferred format for MP4-based unprotected content. Moreover, the following additional constraints apply: The largesize defined in 4.2 of [ISOFF] SHALL NOT be used. Note that larger MP4 files are still able to be generated and used in IPTV services by means of movie fragments. The stco box defined in 8.19 of [ISOFF] SHALL be used. i.e. the co64 box defined in 8.19 of [ISOFF] SHALL NOT be used. For services that allow the real-time playback of downloaded content before the download has been completed (e.g. Progressive Download), the following additional constraints apply: The moov and moof boxes SHALL be used according to section 9.4.4.3.11 of [DLNAMEDIA]. Use of the pdin box, defined in 8.43 of [ISOFF], is RECOMMENDED. In addition, carriage of H.264/AVC content in the MP4 systems layer SHALL be conformant to the AVC File Format standard [AVCFF]. OIPF-Media-Formats,section 5: H.264/AVC [H264] (video format label: AVC) is the preferred video codec for both standard definition and high definition content. OIPF-Media-Formats,section 5.1.3: All AVC format content provided in IPTV services SHALL conform to the following constraints in GOP structure: All slices in the same picture SHALL be of the same type. I picture: A picture with slice_type=7 or slice_type=2 for all the slices composing that picture or IDR picture. P picture: A picture with slice_type=5 or slice_type=0 for all the slices composing that picture. B picture: A picture with slice_type=6 or slice_type=1 for all the slices composing that picture. Decoding order among I or P pictures SHALL be kept in their display order. P picture SHALL NOT refer to B pictures. Complementary reference field pair that includes I/P field SHALL NOT include B field. Reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. Non-reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. A reference B frame or a complementary reference field pair of reference B pictures that immediately precedes/follows in display order and is present between "pic1" and "pic2" in display order. Here, "pic1" is immediately preceding I or P picture and "pic2" is immediately following I or P picture. OIPF-Media-Formats,section 5.1.1.1: H.264/AVC HD video content SHALL comply with [TS101154] clauses 5.5 and 5.7. This format corresponds to video format label AVC_HD_25 in 25Hz systems. OIPF-Protocol,section 5.2.2.2: The use of the HTTP protocol on this reference point SHALL comply with [HTTP]. The Content Delivery Function SHALL support the Range HTTP header in a GET request from the OITF to reduce unnecessary network usage by allowing partial retrieval for use in cases such as trick play. The OITF MAY pre-buffer the content in order to sustain play-out even when the HTTP transfer is stalled. HBBTV,section 7.3.1.2: For non-adaptive unicast streaming, terminals shall support content whose average total bitrate when measured over a 10 second window does not exceed 12 Mbit/s, inclusive of multiplexing and packaging overheads but excluding network protocol overheads. | |||
| org.hbbtv_AVC-HD-009-028 | 1 | Fragmented MP4 - HD - H.264/AVC - HP 4.0 - 1920 x 1080 px @ 25p - 16:9 - 8 Mbps | The terminal shall correctly decode and present video from a fragmented MP4 file encoded with the AVC_HD_25 video format, High 4.0 profile, 16:9 aspect ratio, 1920 x 1080 px resolution, 25p frame rate, 8 Mbps bandwidth | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 4.2: The carriage of A/V content and related information (e.g. subtitles) in file-based formats (systems layer format: MP4) SHALL use the MP4 File Format [MP4FF] and ISO Base Media File Format [ISOFF] standards with the constraints defined in section 9.4.4.3 of [DLNAMEDIA], except for 9.4.4.3.3 and 9.4.4.3.10. This is the preferred format for MP4-based unprotected content. Moreover, the following additional constraints apply: The largesize defined in 4.2 of [ISOFF] SHALL NOT be used. Note that larger MP4 files are still able to be generated and used in IPTV services by means of movie fragments. The stco box defined in 8.19 of [ISOFF] SHALL be used. i.e. the co64 box defined in 8.19 of [ISOFF] SHALL NOT be used. For services that allow the real-time playback of downloaded content before the download has been completed (e.g. Progressive Download), the following additional constraints apply: The moov and moof boxes SHALL be used according to section 9.4.4.3.11 of [DLNAMEDIA]. Use of the pdin box, defined in 8.43 of [ISOFF], is RECOMMENDED. In addition, carriage of H.264/AVC content in the MP4 systems layer SHALL be conformant to the AVC File Format standard [AVCFF]. OIPF-Media-Formats,section 5: H.264/AVC [H264] (video format label: AVC) is the preferred video codec for both standard definition and high definition content. OIPF-Media-Formats,section 5.1.3: All AVC format content provided in IPTV services SHALL conform to the following constraints in GOP structure: All slices in the same picture SHALL be of the same type. I picture: A picture with slice_type=7 or slice_type=2 for all the slices composing that picture or IDR picture. P picture: A picture with slice_type=5 or slice_type=0 for all the slices composing that picture. B picture: A picture with slice_type=6 or slice_type=1 for all the slices composing that picture. Decoding order among I or P pictures SHALL be kept in their display order. P picture SHALL NOT refer to B pictures. Complementary reference field pair that includes I/P field SHALL NOT include B field. Reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. Non-reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. A reference B frame or a complementary reference field pair of reference B pictures that immediately precedes/follows in display order and is present between "pic1" and "pic2" in display order. Here, "pic1" is immediately preceding I or P picture and "pic2" is immediately following I or P picture. OIPF-Media-Formats,section 5.1.1.1: H.264/AVC HD video content SHALL comply with [TS101154] clauses 5.5 and 5.7. This format corresponds to video format label AVC_HD_25 in 25Hz systems. OIPF-Protocol,section 5.2.2.2: The use of the HTTP protocol on this reference point SHALL comply with [HTTP]. The Content Delivery Function SHALL support the Range HTTP header in a GET request from the OITF to reduce unnecessary network usage by allowing partial retrieval for use in cases such as trick play. The OITF MAY pre-buffer the content in order to sustain play-out even when the HTTP transfer is stalled. HBBTV,section 7.3.1.2: For non-adaptive unicast streaming, terminals shall support content whose average total bitrate when measured over a 10 second window does not exceed 12 Mbit/s, inclusive of multiplexing and packaging overheads but excluding network protocol overheads. | |||
| org.hbbtv_AVC-HD-009-032 | 1 | Fragmented MP4 - HD - H.264/AVC - HP 4.0 - 1280 x 720 px @ 25p - 16:9 - 8 Mbps | The terminal shall correctly decode and present video from a fragmented MP4 file encoded with the AVC_HD_25 video format, High 4.0 profile, 16:9 aspect ratio, 1280 x 720 px resolution, 25p frame rate, 8 Mbps bandwidth | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 4.2: The carriage of A/V content and related information (e.g. subtitles) in file-based formats (systems layer format: MP4) SHALL use the MP4 File Format [MP4FF] and ISO Base Media File Format [ISOFF] standards with the constraints defined in section 9.4.4.3 of [DLNAMEDIA], except for 9.4.4.3.3 and 9.4.4.3.10. This is the preferred format for MP4-based unprotected content. Moreover, the following additional constraints apply: The largesize defined in 4.2 of [ISOFF] SHALL NOT be used. Note that larger MP4 files are still able to be generated and used in IPTV services by means of movie fragments. The stco box defined in 8.19 of [ISOFF] SHALL be used. i.e. the co64 box defined in 8.19 of [ISOFF] SHALL NOT be used. For services that allow the real-time playback of downloaded content before the download has been completed (e.g. Progressive Download), the following additional constraints apply: The moov and moof boxes SHALL be used according to section 9.4.4.3.11 of [DLNAMEDIA]. Use of the pdin box, defined in 8.43 of [ISOFF], is RECOMMENDED. In addition, carriage of H.264/AVC content in the MP4 systems layer SHALL be conformant to the AVC File Format standard [AVCFF]. OIPF-Media-Formats,section 5: H.264/AVC [H264] (video format label: AVC) is the preferred video codec for both standard definition and high definition content. OIPF-Media-Formats,section 5.1.3: All AVC format content provided in IPTV services SHALL conform to the following constraints in GOP structure: All slices in the same picture SHALL be of the same type. I picture: A picture with slice_type=7 or slice_type=2 for all the slices composing that picture or IDR picture. P picture: A picture with slice_type=5 or slice_type=0 for all the slices composing that picture. B picture: A picture with slice_type=6 or slice_type=1 for all the slices composing that picture. Decoding order among I or P pictures SHALL be kept in their display order. P picture SHALL NOT refer to B pictures. Complementary reference field pair that includes I/P field SHALL NOT include B field. Reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. Non-reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. A reference B frame or a complementary reference field pair of reference B pictures that immediately precedes/follows in display order and is present between "pic1" and "pic2" in display order. Here, "pic1" is immediately preceding I or P picture and "pic2" is immediately following I or P picture. OIPF-Media-Formats,section 5.1.1.1: H.264/AVC HD video content SHALL comply with [TS101154] clauses 5.5 and 5.7. This format corresponds to video format label AVC_HD_25 in 25Hz systems. OIPF-Protocol,section 5.2.2.2: The use of the HTTP protocol on this reference point SHALL comply with [HTTP]. The Content Delivery Function SHALL support the Range HTTP header in a GET request from the OITF to reduce unnecessary network usage by allowing partial retrieval for use in cases such as trick play. The OITF MAY pre-buffer the content in order to sustain play-out even when the HTTP transfer is stalled. HBBTV,section 7.3.1.2: For non-adaptive unicast streaming, terminals shall support content whose average total bitrate when measured over a 10 second window does not exceed 12 Mbit/s, inclusive of multiplexing and packaging overheads but excluding network protocol overheads. | |||
| org.hbbtv_AVC-HD-009-035 | 1 | Fragmented MP4 - HD - H.264/AVC - HP 4.0 - 1920 x 1080 px @ 25i - 16:9 - 8 Mbps | The terminal shall correctly decode and present video from a fragmented MP4 file encoded with the AVC_HD_25 video format, High 4.0 profile, 16:9 aspect ratio, 1920 x 1080 px resolution, 25i frame rate, 8 Mbps bandwidth | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 4.2: The carriage of A/V content and related information (e.g. subtitles) in file-based formats (systems layer format: MP4) SHALL use the MP4 File Format [MP4FF] and ISO Base Media File Format [ISOFF] standards with the constraints defined in section 9.4.4.3 of [DLNAMEDIA], except for 9.4.4.3.3 and 9.4.4.3.10. This is the preferred format for MP4-based unprotected content. Moreover, the following additional constraints apply: The largesize defined in 4.2 of [ISOFF] SHALL NOT be used. Note that larger MP4 files are still able to be generated and used in IPTV services by means of movie fragments. The stco box defined in 8.19 of [ISOFF] SHALL be used. i.e. the co64 box defined in 8.19 of [ISOFF] SHALL NOT be used. For services that allow the real-time playback of downloaded content before the download has been completed (e.g. Progressive Download), the following additional constraints apply: The moov and moof boxes SHALL be used according to section 9.4.4.3.11 of [DLNAMEDIA]. Use of the pdin box, defined in 8.43 of [ISOFF], is RECOMMENDED. In addition, carriage of H.264/AVC content in the MP4 systems layer SHALL be conformant to the AVC File Format standard [AVCFF]. OIPF-Media-Formats,section 5: H.264/AVC [H264] (video format label: AVC) is the preferred video codec for both standard definition and high definition content. OIPF-Media-Formats,section 5.1.3: All AVC format content provided in IPTV services SHALL conform to the following constraints in GOP structure: All slices in the same picture SHALL be of the same type. I picture: A picture with slice_type=7 or slice_type=2 for all the slices composing that picture or IDR picture. P picture: A picture with slice_type=5 or slice_type=0 for all the slices composing that picture. B picture: A picture with slice_type=6 or slice_type=1 for all the slices composing that picture. Decoding order among I or P pictures SHALL be kept in their display order. P picture SHALL NOT refer to B pictures. Complementary reference field pair that includes I/P field SHALL NOT include B field. Reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. Non-reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. A reference B frame or a complementary reference field pair of reference B pictures that immediately precedes/follows in display order and is present between "pic1" and "pic2" in display order. Here, "pic1" is immediately preceding I or P picture and "pic2" is immediately following I or P picture. OIPF-Media-Formats,section 5.1.1.1: H.264/AVC HD video content SHALL comply with [TS101154] clauses 5.5 and 5.7. This format corresponds to video format label AVC_HD_25 in 25Hz systems. OIPF-Protocol,section 5.2.2.2: The use of the HTTP protocol on this reference point SHALL comply with [HTTP]. The Content Delivery Function SHALL support the Range HTTP header in a GET request from the OITF to reduce unnecessary network usage by allowing partial retrieval for use in cases such as trick play. The OITF MAY pre-buffer the content in order to sustain play-out even when the HTTP transfer is stalled. HBBTV,section 7.3.1.2: For non-adaptive unicast streaming, terminals shall support content whose average total bitrate when measured over a 10 second window does not exceed 12 Mbit/s, inclusive of multiplexing and packaging overheads but excluding network protocol overheads. | |||
| org.hbbtv_AVC-HD-009-039 | 1 | Fragmented MP4 - HD - H.264/AVC - HP 4.0 - 1280 x 720 px @ 25i - 16:9 - 8 Mbps | The terminal shall correctly decode and present video from a fragmented MP4 file encoded with the AVC_HD_25 video format, High 4.0 profile, 16:9 aspect ratio, 1280 x 720 px resolution, 25i frame rate, 8 Mbps bandwidth | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 4.2: The carriage of A/V content and related information (e.g. subtitles) in file-based formats (systems layer format: MP4) SHALL use the MP4 File Format [MP4FF] and ISO Base Media File Format [ISOFF] standards with the constraints defined in section 9.4.4.3 of [DLNAMEDIA], except for 9.4.4.3.3 and 9.4.4.3.10. This is the preferred format for MP4-based unprotected content. Moreover, the following additional constraints apply: The largesize defined in 4.2 of [ISOFF] SHALL NOT be used. Note that larger MP4 files are still able to be generated and used in IPTV services by means of movie fragments. The stco box defined in 8.19 of [ISOFF] SHALL be used. i.e. the co64 box defined in 8.19 of [ISOFF] SHALL NOT be used. For services that allow the real-time playback of downloaded content before the download has been completed (e.g. Progressive Download), the following additional constraints apply: The moov and moof boxes SHALL be used according to section 9.4.4.3.11 of [DLNAMEDIA]. Use of the pdin box, defined in 8.43 of [ISOFF], is RECOMMENDED. In addition, carriage of H.264/AVC content in the MP4 systems layer SHALL be conformant to the AVC File Format standard [AVCFF]. OIPF-Media-Formats,section 5: H.264/AVC [H264] (video format label: AVC) is the preferred video codec for both standard definition and high definition content. OIPF-Media-Formats,section 5.1.3: All AVC format content provided in IPTV services SHALL conform to the following constraints in GOP structure: All slices in the same picture SHALL be of the same type. I picture: A picture with slice_type=7 or slice_type=2 for all the slices composing that picture or IDR picture. P picture: A picture with slice_type=5 or slice_type=0 for all the slices composing that picture. B picture: A picture with slice_type=6 or slice_type=1 for all the slices composing that picture. Decoding order among I or P pictures SHALL be kept in their display order. P picture SHALL NOT refer to B pictures. Complementary reference field pair that includes I/P field SHALL NOT include B field. Reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. Non-reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. A reference B frame or a complementary reference field pair of reference B pictures that immediately precedes/follows in display order and is present between "pic1" and "pic2" in display order. Here, "pic1" is immediately preceding I or P picture and "pic2" is immediately following I or P picture. OIPF-Media-Formats,section 5.1.1.1: H.264/AVC HD video content SHALL comply with [TS101154] clauses 5.5 and 5.7. This format corresponds to video format label AVC_HD_25 in 25Hz systems. OIPF-Protocol,section 5.2.2.2: The use of the HTTP protocol on this reference point SHALL comply with [HTTP]. The Content Delivery Function SHALL support the Range HTTP header in a GET request from the OITF to reduce unnecessary network usage by allowing partial retrieval for use in cases such as trick play. The OITF MAY pre-buffer the content in order to sustain play-out even when the HTTP transfer is stalled. HBBTV,section 7.3.1.2: For non-adaptive unicast streaming, terminals shall support content whose average total bitrate when measured over a 10 second window does not exceed 12 Mbit/s, inclusive of multiplexing and packaging overheads but excluding network protocol overheads. | |||
| org.hbbtv_AVC-HD-009-043 | 1 | Fragmented MP4 - HD - H.264/AVC - HP 4.0 - 1280 x 720 px @ 50p - 16:9 - 8 Mbps | The terminal shall correctly decode and present video from a fragmented MP4 file encoded with the AVC_HD_25 video format, High 4.0 profile, 16:9 aspect ratio, 1280 x 720 px resolution, 50p frame rate, 8 Mbps bandwidth | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 4.2: The carriage of A/V content and related information (e.g. subtitles) in file-based formats (systems layer format: MP4) SHALL use the MP4 File Format [MP4FF] and ISO Base Media File Format [ISOFF] standards with the constraints defined in section 9.4.4.3 of [DLNAMEDIA], except for 9.4.4.3.3 and 9.4.4.3.10. This is the preferred format for MP4-based unprotected content. Moreover, the following additional constraints apply: The largesize defined in 4.2 of [ISOFF] SHALL NOT be used. Note that larger MP4 files are still able to be generated and used in IPTV services by means of movie fragments. The stco box defined in 8.19 of [ISOFF] SHALL be used. i.e. the co64 box defined in 8.19 of [ISOFF] SHALL NOT be used. For services that allow the real-time playback of downloaded content before the download has been completed (e.g. Progressive Download), the following additional constraints apply: The moov and moof boxes SHALL be used according to section 9.4.4.3.11 of [DLNAMEDIA]. Use of the pdin box, defined in 8.43 of [ISOFF], is RECOMMENDED. In addition, carriage of H.264/AVC content in the MP4 systems layer SHALL be conformant to the AVC File Format standard [AVCFF]. OIPF-Media-Formats,section 5: H.264/AVC [H264] (video format label: AVC) is the preferred video codec for both standard definition and high definition content. OIPF-Media-Formats,section 5.1.3: All AVC format content provided in IPTV services SHALL conform to the following constraints in GOP structure: All slices in the same picture SHALL be of the same type. I picture: A picture with slice_type=7 or slice_type=2 for all the slices composing that picture or IDR picture. P picture: A picture with slice_type=5 or slice_type=0 for all the slices composing that picture. B picture: A picture with slice_type=6 or slice_type=1 for all the slices composing that picture. Decoding order among I or P pictures SHALL be kept in their display order. P picture SHALL NOT refer to B pictures. Complementary reference field pair that includes I/P field SHALL NOT include B field. Reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. Non-reference B picture SHALL refer to the following. I or P frames or complementary reference field pairs of I or P pictures that immediately precedes/follows in display order. A reference B frame or a complementary reference field pair of reference B pictures that immediately precedes/follows in display order and is present between "pic1" and "pic2" in display order. Here, "pic1" is immediately preceding I or P picture and "pic2" is immediately following I or P picture. OIPF-Media-Formats,section 5.1.1.1: H.264/AVC HD video content SHALL comply with [TS101154] clauses 5.5 and 5.7. This format corresponds to video format label AVC_HD_25 in 25Hz systems. OIPF-Protocol,section 5.2.2.2: The use of the HTTP protocol on this reference point SHALL comply with [HTTP]. The Content Delivery Function SHALL support the Range HTTP header in a GET request from the OITF to reduce unnecessary network usage by allowing partial retrieval for use in cases such as trick play. The OITF MAY pre-buffer the content in order to sustain play-out even when the HTTP transfer is stalled. HBBTV,section 7.3.1.2: For non-adaptive unicast streaming, terminals shall support content whose average total bitrate when measured over a 10 second window does not exceed 12 Mbit/s, inclusive of multiplexing and packaging overheads but excluding network protocol overheads. | |||
| org.hbbtv_BR_APPLAUNCH0010 | 1 | Broadcast-related application launching another from same service - URL with triplet | A broadcast-related application requests to launch another broadcast related application signalled in the current service using the dvb: URL for the other application with the current service referred to using its dvb triplet. The second application is launched. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild) [....] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild)[...] uri The URI of the first page of the application to be created. TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_BR_APPLAUNCH0020 | 1 | Broadcast-related application launching another from same service - URL with current.ait | A broadcast-related application requests to launch another broadcast related application signalled in the current service using the dvb: URL for the other application with the current service referred to using 'current.ait'. The second application is launched. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild )[...] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild )[...] uri The URI of the first page of the application to be created. TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_BR_APPLAUNCH0030 | 1 | Broadcast-related application launching another from different service - failure by DOM0 event | A broadcast-related application requests to launch another broadcast related application signalled in a different service using the dvb: URL for the other application. The second application fails as if the initial page could not be loaded. The onApplicationLoadError handler of the first application is called. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [..] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.1.2: function onApplicationLoadError( Application appl ) The function that is called when the OITF fails to load either the file containing the initial HTML document of an application or an XML AIT file (e.g. due to an HTTP 404 error, an HTTP timeout, being unable to load the file from a DSM-CC object carousel or due to the file not being either an HTML file or a XML AIT file as appropriate), OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [[.]] uri The URI of the first page of the application to be created. OIPF-DAE,section 7.2.1.2: function onApplicationLoadError( Application appl ) The function that is called when the OITF fails to load the file containing the initial HTML document of an application (e.g. due to an HTTP 404 error, an HTTP timeout, being unable to load the file from a DSM-CC object carousel or due to the file not being either an HTML file). OIPF-DAE,section 7.55: Add the following to section 7.2.1.2; function onApplicationLoadError( Application appl ) The function that is called when the OITF fails to load the file containing the initial HTML document of an application (e.g. due to an HTTP 404 error, an HTTP timeout, being unable to load the file from a DSM-CC object carousel or due to the file not being either an HTML file). All properties of the Application object referred to by appl SHALL have the value undefined and calling any methods on that object SHALL fail. In section 7.2.1.4, add a new row to the table of events as follows; Intrinsic event | Corresponding DOM 2 event | DOM 2 Event properties onApplicationLoadError | ApplicationLoadError | Bubbles: No, Cancelable: No, Context Info: appl TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_BR_APPLAUNCH0035 | 1 | Broadcast-related application launching another from different service - failure by DOM2 event | A broadcast-related application that registered a callback for the DOM2 Event ApplicationLoadError requests to launch another broadcast related application signalled in a different service using the dvb: URL for the other application. The second application fails as if the initial page could not be loaded. The terminal calls the function registered as callback for the ApplicationLoadError. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [..] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.1.2: function onApplicationLoadError( Application appl ) The function that is called when the OITF fails to load either the file containing the initial HTML document of an application or an XML AIT file (e.g. due to an HTTP 404 error, an HTTP timeout, being unable to load the file from a DSM-CC object carousel or due to the file not being either an HTML file or a XML AIT file as appropriate), OIPF-DAE,section 7.2.1.4: For the intrinsic events listed in the table below a corresponding DOM event SHALL be generated in the following manner: [...] onApplicationLoadError | ApplicationLoadError | Bubbles: No, Cancellable: No, Context Info: appl OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [[.]] uri The URI of the first page of the application to be created. OIPF-DAE,section 7.2.1.2: function onApplicationLoadError( Application appl ) The function that is called when the OITF fails to load the file containing the initial HTML document of an application (e.g. due to an HTTP 404 error, an HTTP timeout, being unable to load the file from a DSM-CC object carousel or due to the file not being either an HTML file). OIPF-DAE,section 7.2.1.4: onApplicationLoadError | ApplicationLoadError | Bubbles: No, Cancelable: No, Context Info: appl OIPF-DAE,section 7.55: Add the following to section 7.2.1.2; function onApplicationLoadError( Application appl ) The function that is called when the OITF fails to load the file containing the initial HTML document of an application (e.g. due to an HTTP 404 error, an HTTP timeout, being unable to load the file from a DSM-CC object carousel or due to the file not being either an HTML file). All properties of the Application object referred to by appl SHALL have the value undefined and calling any methods on that object SHALL fail. In section 7.2.1.4, add a new row to the table of events as follows; Intrinsic event | Corresponding DOM 2 event | DOM 2 Event properties onApplicationLoadError | ApplicationLoadError | Bubbles: No, Cancelable: No, Context Info: appl TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_BR_APPLAUNCH0040 | 1 | Broadcast-related application changing channel and then launching - DVB triplet | A broadcast-related application (not service bound) starts in one service, changes channel to a second service where it is allowed to run by the signalling and then requests to launch another broadcast related application signalled in the second service (but not signalled in the first) using the dvb: URL for the other application using the DVB triplet for the second service. The second application is launched as defined in the second service. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [..] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild )[...] uri The URI of the first page of the application to be created. TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_BR_APPLAUNCH0050 | 1 | Broadcast-related application changing channel and then launching - current.ait | A broadcast-related application (not service bound) starts in one service, changes channel to a second service where it is allowed to run by the signalling and then requests to launch another broadcast related application signalled in the second service (but not signalled in the first) using the dvb: URL for the other application using 'current.ait' to refer to the second service. The second application is launched as defined in the second service. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild )[..] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) uri The URI of the first page of the application to be created. TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_BR_APPLAUNCH0060 | 1 | Broadcast-independent application becomes broadcast-related and then launches app on current service - DVB triplet | A broadcast-independent application selects a broadcast service where it meets the conditions for becoming broadcast-related and survives. It then requests to launch another application signalled in the newly selected service using the dvb: URL for the other application referring to the service using its DVB triplet. The second application is launched. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: - The broadcast-independent application has an organisation_id and application_id (whether obtained through a broadcast AIT or an XML AIT). - An application of the same organisation_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. - The application signalled in the broadcast channel with the same organisation_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. - The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organisation_id and application_id. - The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. These conditions shall apply regardless of whether an application was originally launched as broadcast-related or as broadcast-independent and regardless of how many times an application may have previously transitioned from broadcast-related to broadcast-independent or vice-versa HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). • An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. • The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application was initially referenced through an XML AIT (and hence has an org_id and an app_id). • An application of the same org_id and app_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same org_id and app_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application exactly matches the URL in the broadcast signalling for that org_id and app_id up to the beginning of any query or fragment string signalled. • The page currently loaded in the broadcast-independent application is inside the application domain of the broadcast application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild )[...] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [...] uri The URI of the first page of the application to be created. TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_BR_APPLAUNCH0070 | 1 | Broadcast-independent application becomes broadcast-related and then launches app on current service - current.ait | A broadcast-independent application selects a broadcast service where it meets the conditions for becoming broadcast-related and survives. It then requests to launch another application signalled in the newly selected service using the dvb: URL for the other application referring to the service using 'current.ait'. The second application is launched. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: - The broadcast-independent application has an organisation_id and application_id (whether obtained through a broadcast AIT or an XML AIT). - An application of the same organisation_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. - The application signalled in the broadcast channel with the same organisation_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. - The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organisation_id and application_id. - The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. These conditions shall apply regardless of whether an application was originally launched as broadcast-related or as broadcast-independent and regardless of how many times an application may have previously transitioned from broadcast-related to broadcast-independent or vice-versa HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). • An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. • The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application was initially referenced through an XML AIT (and hence has an org_id and an app_id). • An application of the same org_id and app_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same org_id and app_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application exactly matches the URL in the broadcast signalling for that org_id and app_id up to the beginning of any query or fragment string signalled. • The page currently loaded in the broadcast-independent application is inside the application domain of the broadcast application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [...] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [...] uri The URI of the first page of the application to be created. TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_BR_APPLAUNCH0080 | 1 | Broadcast-independent application becomes broadcast-related , changes channel and then launches app on current service - DVB triplet | A broadcast-independent application selects a broadcast service where it meets the conditions for becoming broadcast-related and survives. It then changes to a second channel and requests to launch another application signalled in that second channel (but not the first) using a dvb: URL for the other application where the reference to the service is in the form of its DVB triplet. The second application is launched. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: - The broadcast-independent application has an organisation_id and application_id (whether obtained through a broadcast AIT or an XML AIT). - An application of the same organisation_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. - The application signalled in the broadcast channel with the same organisation_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. - The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organisation_id and application_id. - The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. These conditions shall apply regardless of whether an application was originally launched as broadcast-related or as broadcast-independent and regardless of how many times an application may have previously transitioned from broadcast-related to broadcast-independent or vice-versa HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). • An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. • The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application was initially referenced through an XML AIT (and hence has an org_id and an app_id). • An application of the same org_id and app_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same org_id and app_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application exactly matches the URL in the broadcast signalling for that org_id and app_id up to the beginning of any query or fragment string signalled. • The page currently loaded in the broadcast-independent application is inside the application domain of the broadcast application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [....] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [...] uri The URI of the first page of the application to be created. TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_BR_APPLAUNCH0090 | 1 | Broadcast-independent application becomes broadcast-related, changes channel and then launches app on current service - current.ait | A broadcast-independent application selects a broadcast service where it meets the conditions for becoming broadcast-related and survives. It then changes to a second channel and requests to launch another application signalled in that second channel (but not the first) using a dvb: URL for the other application where the reference to the service is 'current.ait'. The second application is launched. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: - The broadcast-independent application has an organisation_id and application_id (whether obtained through a broadcast AIT or an XML AIT). - An application of the same organisation_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. - The application signalled in the broadcast channel with the same organisation_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. - The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organisation_id and application_id. - The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. These conditions shall apply regardless of whether an application was originally launched as broadcast-related or as broadcast-independent and regardless of how many times an application may have previously transitioned from broadcast-related to broadcast-independent or vice-versa HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). • An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. • The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application was initially referenced through an XML AIT (and hence has an org_id and an app_id). • An application of the same org_id and app_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same org_id and app_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application exactly matches the URL in the broadcast signalling for that org_id and app_id up to the beginning of any query or fragment string signalled. • The page currently loaded in the broadcast-independent application is inside the application domain of the broadcast application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [...] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [...] uri The URI of the first page of the application to be created. TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_BR_APPLAUNCH0100 | 1 | Broadcast-related application becomes broadcast-independent , back to broadcast-related on a different channel and then launches app on current service - DVB triplet | A broadcast-related application running as part of one service becomes broadcast-independent and then selects a different broadcast service where it meets the conditions for becoming broadcast-related and survives. It then requests to launch another application signalled in that second service (but not the first) using a dvb: URL for the other application where the reference to the service is in the form of its DVB triplet. The second application is launched. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: A broadcast-related application can transition to a broadcast-independent application by calling the setChannel() method on the video/broadcast object with a value of null for its channel argument. Access to broadcast resources shall be lost and the object shall transition to the unrealized state. A ChannelChangeSucceededEvent shall be dispatched to the video/broadcast object that caused the transition with a value of null for the channel property.[...] When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: - The broadcast-independent application has an organisation_id and application_id (whether obtained through a broadcast AIT or an XML AIT). - An application of the same organisation_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. - The application signalled in the broadcast channel with the same organisation_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. - The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organisation_id and application_id. - The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. These conditions shall apply regardless of whether an application was originally launched as broadcast-related or as broadcast-independent and regardless of how many times an application may have previously transitioned from broadcast-related to broadcast-independent or vice-versa HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: A broadcast-related application can transition to a broadcast-independent application by calling the setChannel() method on the video/broadcast object with a value of null for its channel argument. Access to broadcast resources shall be lost and the object shall transition to the unrealized state. A ChannelChangeSucceededEvent shall be dispatched to the video/broadcast object that caused the transition with a value of null for the channel property. [...] When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). • An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. • The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: A broadcast-related application can transition to a broadcast-independent application by calling the setChannel() method on the video/broadcast object with a value of null for its channel argument. Access to broadcast resources shall be lost, as described in clause 6.2.2.7. A ChannelChangeSucceededEvent shall be dispatched to the video/broadcast object that caused the transition with a value of null for the channel property. [...] When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application was initially referenced through an XML AIT (and hence has an org_id and an app_id). • An application of the same org_id and app_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same org_id and app_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application exactly matches the URL in the broadcast signalling for that org_id and app_id up to the beginning of any query or fragment string signalled. • The page currently loaded in the broadcast-independent application is inside the application domain of the broadcast application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [...] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [...] uri The URI of the first page of the application to be created. TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_BR_APPLAUNCH0110 | 1 | Broadcast-related application becomes broadcast-independent , back to broadcast-related on a different channel and then launches app on current service - current.ait | A broadcast-related application running as part of one service becomes broadcast-independent and then selects a different broadcast service where it meets the conditions for becoming broadcast-related and survives. It then requests to launch another application signalled in that second service (but not the first) using a dvb: URL for the other application where the reference to the service is 'current.ait'. The second application is launched. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [..] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 6.2.2.1: Starting an application may be initiated in the following ways: [...] By an already running application (via the JavaScript method createApplication()). HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: A broadcast-related application can transition to a broadcast-independent application by calling the setChannel() method on the video/broadcast object with a value of null for its channel argument. Access to broadcast resources shall be lost and the object shall transition to the unrealized state. A ChannelChangeSucceededEvent shall be dispatched to the video/broadcast object that caused the transition with a value of null for the channel property.[...] When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: - The broadcast-independent application has an organisation_id and application_id (whether obtained through a broadcast AIT or an XML AIT). - An application of the same organisation_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. - The application signalled in the broadcast channel with the same organisation_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. - The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organisation_id and application_id. - The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. These conditions shall apply regardless of whether an application was originally launched as broadcast-related or as broadcast-independent and regardless of how many times an application may have previously transitioned from broadcast-related to broadcast-independent or vice-versa HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [10] and optionally appended fragment component with theApplication.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: A broadcast-related application can transition to a broadcast-independent application by calling the setChannel() method on the video/broadcast object with a value of null for its channel argument. Access to broadcast resources shall be lost and the object shall transition to the unrealized state. A ChannelChangeSucceededEvent shall be dispatched to the video/broadcast object that caused the transition with a value of null for the channel property. [...] When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application has an organization_id and application_id (whether obtained through a broadcast AIT or an XML AIT). • An application of the same organization_id and application_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same organization_id and application_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application has the same origin as at least one of the URLs signalled in the broadcast for that organization_id and application_id. • The URL of the page currently loaded in the broadcast-independent application is inside the application boundary of the application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. HBBTV,section 9.2: It shall be possible to use dvb: URLs referring to applications signalled in the current service as defined in table 4 of TS 102 851 [11] with the Application.createApplication() method. Use of dvb: URLs referring to applications from another service will cause createApplication() to fail as if the initial page could not be loaded. HBBTV,section 6.2.2.6: A broadcast-related application can transition to a broadcast-independent application by calling the setChannel() method on the video/broadcast object with a value of null for its channel argument. Access to broadcast resources shall be lost, as described in clause 6.2.2.7. A ChannelChangeSucceededEvent shall be dispatched to the video/broadcast object that caused the transition with a value of null for the channel property. [...] When a broadcast-independent application successfully selects a broadcast service using a video/broadcast object, that application shall be killed unless all the following conditions are met: • The broadcast-independent application was initially referenced through an XML AIT (and hence has an org_id and an app_id). • An application of the same org_id and app_id is signalled in the broadcast channel to be selected with control code AUTOSTART or PRESENT. • The application signalled in the broadcast channel with the same org_id and app_id includes a transport_protocol_descriptor with protocol_id equal to 3. • The URL of the entry point document of the broadcast-independent application exactly matches the URL in the broadcast signalling for that org_id and app_id up to the beginning of any query or fragment string signalled. • The page currently loaded in the broadcast-independent application is inside the application domain of the broadcast application as defined in clause 6.3. If these conditions are met, the application shall transition to be a broadcast-related application as defined in clause 6.2.2.2. The application should be authored to follow the behaviour defined in clause 5.3.3. OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [...] uri The URI of the first page of the application to be created OIPF-DAE,section 7.2.2.2: Application createApplication( String uri, Boolean createChild ) [...] uri The URI of the first page of the application to be created. TS-102-851,section 6.3.1: ait_specifier = ait_filter "." "ait" ait_abs_path ait_filter = "current" OR dvb_service_without_event ait_abs_path = "/" ait_entity ait_entity = ait_root_directory OR ait_application ait_root_directory = "app_root" ait_application (note 2) = org_id_part "." app_id_part [ "?" ait_params ] ait_params (note 3) = "arg_" 1*digit "=" *uric [ "&" ait_params ] | |||
| org.hbbtv_CS000001 | 1 | Test to verify HbbTVCSManager embedded object support with correct MIME type | The terminal shall support HbbTVCSManager embedded object with MIME type “application/hbbtvCSManager”. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: HbbTVCSManager embedded object. This embedded object shall have the MIME type “application/hbbtvCSManager”. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000002 | 1 | Discovering a Companion Screen Launcher Application with a valid enum_id | When a Companion Screen Launcher Application is discovered, the terminal shall respond to discoverCSLaunchers() by calling onCSDiscovery() callback function with an Array containing a single DiscoveredCSLauncher object with a 'enum_id' property of type Number | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: The onCSDiscovery callback shall be supported and called once for each call to discoverCSLaunchers() that returns true: function onCSDiscovery( Array csLaunchers ) csLaunchers | A JavaScript Array object containing zero or more DiscoveredCSLauncher objects (see clause 8.2.6.3) where each object in the array represents a CS Launcher application that is Connected (as defined in clause 14.3.2) The protocol for determining the CS Launchers to be included in this array is out of scope, and not defined by the present document. HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: readonly Number enum_id | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000003 | 1 | Responding to the second discoverCSLaunchers() call with the same enum_id for a connected (associated) Companion Screen Launcher Application | When a Companion Screen Launcher Application is discovered with a valid enum_id and the HbbTV application calls discoverCSLaunchers() function again while the Companion Screen Launcher Application is connected (associated), the terminal shall call onCSDiscovery() callback function with an Array containing a single DiscoveredCSLauncher with an 'enum_id' property with the same value as the previous callback. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: Boolean discoverCSLaunchers(function onCSDiscovery) [...] This returns with either the value true to indicate that the function has completed with no errors (and that a callback is expected), false otherwise. HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: readonly Number enum_id | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000004 | 2 | Responding to the second discoverCSLaunchers() call with different enum_id for a disconnected (dis-associated) Companion Screen Launcher Application | When a connected (associated) Companion Screen Launcher Application is disconnected (dis-associated) and the HbbTV application calls discoverCSLaunchers() function again, the CS Launcher Application shall cause the terminal to call the onCSDiscovery() callback function with an array of csLaunchers consisting of a single DiscoveredCSLauncher object having a different enum_id. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: The onCSDiscovery callback shall be supported and called once for each call to discoverCSLaunchers() that returns true function onCSDiscovery( Array csLaunchers ): csLaunchers A JavaScript Array object containing zero or more DiscoveredCSLauncher objects (see clause 8.2.6.3) where each object in the array represents a CS Launcher application HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: enum_id A unique ID of an instance of a CS Launcher application. The enum_id is expected to be quasi-static. Repeated calls to discoverCSLaunchers() shall respond with the same enum_id unless any of the HbbTV® terminal, the Companion Screen, or the CS Launcher application have been restarted or re-connected. Newly started and connected Launcher applications on Companion Screens shall generate new enum_ids. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000005 | 2 | Discovering two Companion Screen Launcher Applications with unique enum_ids | When two Companion Screen Launcher Applications are discovered, the terminal shall respond to discoverCSLaunchers() by calling onCSDiscovery() callback function once with an array of csLaunchers consisting of two DiscoveredCSLauncher objects each having a unique enum_id. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: The onCSDiscovery callback shall be supported and called once for each call to discoverCSLaunchers() that returns true function onCSDiscovery( Array csLaunchers ): csLaunchers A JavaScript Array object containing zero or more DiscoveredCSLauncher objects (see clause 8.2.6.3) where each object in the array represents a CS Launcher application HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: enum_id A unique ID of an instance of a CS Launcher application. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000006 | 2 | Discovering a Companion Screen Launcher Application with an empty friendly_name string | When a Companion Screen Launcher Application is discovered, the terminal shall respond to discoverCSLaunchers() by calling onCSDiscovery() callback function with an array of csLaunchers consisting of a single DiscoveredCSLauncher object having an empty friendly_name string in case of Companion Screen Launcher Application not providing one. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: The onCSDiscovery callback shall be supported and called once for each call to discoverCSLaunchers() that returns true function onCSDiscovery( Array csLaunchers ): csLaunchers A JavaScript Array object containing zero or more DiscoveredCSLauncher objects (see clause 8.2.6.3) where each object in the array represents a CS Launcher application HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: friendly_name A CS Launcher application may provide a friendly name, e.g. "Muttleys Tablet", for an HbbTV® application to make use of. It is optional that this parameter is returned. If it is not returned, it shall be set to the empty string "". | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000007 | 2 | Discovering a Companion Screen Launcher Application with a valid CS_OS_id | When a Companion Screen Launcher Application is discovered, the terminal shall respond to discoverCSLaunchers() by calling onCSDiscovery() callback function with an array of csLaunchers consisting of a single DiscoveredCSLauncher object having a valid CS_OS_id. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: The onCSDiscovery callback shall be supported and called once for each call to discoverCSLaunchers() that returns true function onCSDiscovery( Array csLaunchers ): csLaunchers A JavaScript Array object containing zero or more DiscoveredCSLauncher objects (see clause 8.2.6.3) where each object in the array represents a CS Launcher application HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: CS_OS_id The CS OS identifier string, as described in clause 14.4.1. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000008 | 1 | Test to check return value of bool discoverCSLaunchers() in case of no errors | When the HbbTV application calls HbbTVCSManager.discoverCSLaunchers() function with a 'onCSDiscovery' argument, the terminal shall return true in the case of no errors. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: Boolean discoverCSLaunchers(function onCSDiscovery) Triggers a callback reporting CS launcher applications on the home network, along with their enumeration ID, a friendly name and their CS OS information. This returns with either the value true to indicate that the function has completed with no errors (and that a callback is expected), false otherwise. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000010 | 1 | onCSDiscovery() callback fired within 1 sec for a currently connected Companion Screen | When there is a Companion Screen Launcher Application currently running and the Companion Screen Device is connected to the same network as the HbbTV terminal at the time of the call to HbbTVCSManager.discoverCSLaunchers(), the CS Launcher Application shall cause the terminal to call the 'onCSDiscovery' callback function within 1 second of the function returning true. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: When true is returned, the terminal shall determine a set of CS Launcher Applications that are Connected (as defined in clause 14.3.2) and report these by scheduling the onCSDiscovery() callback to fire within 1 second. There shall be no callback scheduled if false is returned. In determining the set of Connected CS Launcher Applications, the terminal performs any discovery and/or association steps that are needed. The details of what is done during this function call or after this function call depends on the protocol between the HbbTV® terminal and the CS launcher application and is implementation specific | +CS_APP_LAUNCH | |
| org.hbbtv_CS000012 | 1 | Launching a Native Application (Android) | When the Launch Native instruction is supplied in the payload field of the launchCSApp() method, the Companion Screen Launcher Application shall cause the terminal to attempt to launch the native application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a Companion Screen the launchCSApp() method needs to be called for the Companion Screen identified by the Companion Screen enumeration ID (enum_id). The action that the CS Launcher Application on the Companion Screen will undertake is described by the payload string. The semantics of the instruction and the payload format are described in clause 14.4.2. HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: readonly Number enum_id HBBTV,section 14.4.2.1: If the Launch Native or Launch HTML instruction is supplied, then the Launcher Application shall attempt to launch the application. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000012_IOS | 1 | Launching a Native Application (iOS) | When the Launch Native instruction is supplied in the payload field of the launchCSApp() method, the iOS Companion Screen Launcher Application shall cause the terminal to attempt to launch the native application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a Companion Screen the launchCSApp() method needs to be called for the Companion Screen identified by the Companion Screen enumeration ID (enum_id). The action that the CS Launcher Application on the Companion Screen will undertake is described by the payload string. The semantics of the instruction and the payload format are described in clause 14.4.2. HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: readonly Number enum_id HBBTV,section 14.4.2.1: If the Launch Native or Launch HTML instruction is supplied, then the Launcher Application shall attempt to launch the application. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000013 | 1 | Launching an HTML Application (Android) | When the Launch HTML instruction is supplied in the payload field of the launchCSApp() method, the Companion Screen Launcher Application shall cause the terminal to attempt to launch the HTML application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a Companion Screen the launchCSApp() method needs to be called for the Companion Screen identified by the Companion Screen enumeration ID (enum_id). The action that the CS Launcher Application on the Companion Screen will undertake is described by the payload string. The semantics of the instruction and the payload format are described in clause 14.4.2. HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: readonly Number enum_id HBBTV,section 14.4.2.1: If the Launch Native or Launch HTML instruction is supplied, then the Launcher Application shall attempt to launch the application. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000013_IOS | 1 | Launching an HTML Application (iOS) | When the Launch HTML instruction is supplied in the payload field of the launchCSApp() method, the iOS Companion Screen Launcher Application shall cause the terminal to attempt to launch the HTML application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a Companion Screen the launchCSApp() method needs to be called for the Companion Screen identified by the Companion Screen enumeration ID (enum_id). The action that the CS Launcher Application on the Companion Screen will undertake is described by the payload string. The semantics of the instruction and the payload format are described in clause 14.4.2. HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: readonly Number enum_id HBBTV,section 14.4.2.1: If the Launch Native or Launch HTML instruction is supplied, then the Launcher Application shall attempt to launch the application. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000016 | 1 | Launching both Native and HTML Applications where the Native Application is available (Android) | When both launch native and launch HTML instructions are supplied in the payload field of the launchCSApp() method, the Companion Screen Launcher Application shall cause the terminal to attempt to launch the native application first. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a Companion Screen the launchCSApp() method needs to be called for the Companion Screen identified by the Companion Screen enumeration ID (enum_id). The action that the CS Launcher Application on the Companion Screen will undertake is described by the payload string. The semantics of the instruction and the payload format are described in clause 14.4.2. HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: readonly Number enum_id HBBTV,section 14.4.2.1: If both a Launch Native and a Launch HTML instruction are supplied the Launch Native application instruction shall be actioned first. If this is successful, then the launch of the HTML application shall not be executed. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000016_IOS | 1 | Launching both Native and HTML Applications where the Native Application is available (iOS) | When both launch native and launch HTML instructions are supplied in the payload field of the launchCSApp() method, the iOS Companion Screen Launcher Application shall cause the terminal to attempt to launch the native application first. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. HBBTV,section 14.4.2.1: If both a launch native and a launch HTML instruction are supplied the Launch native application instruction shall be actioned first. If this is successful, then the launch of the HTML application shall not be executed. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000017 | 1 | Launching both Native and HTML Applications where the Native Application is not available (Android) | When both launch native and launch HTML instructions are supplied in the payload field of the launchCSApp() method, If the launch Native application is not successful, then the Companion Screen Launcher Application shall cause the terminal to attempt to launch the HTML application | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a Companion Screen the launchCSApp() method needs to be called for the Companion Screen identified by the Companion Screen enumeration ID (enum_id). The action that the CS Launcher Application on the Companion Screen will undertake is described by the payload string. HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: readonly Number enum_id HBBTV,section 14.4.2.1: If both a Launch Native and a Launch HTML instruction are supplied the Launch Native application instruction shall be actioned first. If this is successful, then the launch of the HTML application shall not be executed. If the launch Native application is not successful, then the launch of the HTML application shall be actioned. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000017_IOS | 1 | Launching both Native and HTML Applications where the Native Application is not available (iOS) | When both launch native and launch HTML instructions are supplied in the payload field of the launchCSApp() method, If the launch Native application is not successful, then the iOS Companion Screen Launcher Application shall cause the terminal to attempt to launch the HTML application | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. HBBTV,section 14.4.2.1: If both a launch native and a launch HTML instruction are supplied the Launch native application instruction shall be actioned first. If this is successful, then the launch of the HTML application shall not be executed. If the launch Native application is not successful, then the launch of the HTML application shall be actioned. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000018 | 1 | Launching a Native Application with invalid JSON data | When the launch native application instruction is supplied in the payload field of the launchCSApp() method with invalid JSON data, the CS Launcher Application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with error code 4 (general_error). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. HBBTV,section 14.4.2.2: The payload data for the install and launch operations are carried as Strings which contain JSON formatted data. The exact format of the JSON payload is described here. JSON not conforming to these rules (including empty strings) are invalid and shall cause the onCSLaunch callback to return with an error code of 4 (general_error). | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000019 | 1 | Launching an HTML Application with invalid JSON data | When the launch HTML application instruction is supplied in the payload field of the launchCSApp() method with invalid JSON data, the CS Launcher Application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with error code 4 (general_error). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. HBBTV,section 14.4.2.2: The payload data for the install and launch operations are carried as Strings which contain JSON formatted data. The exact format of the JSON payload is described here. JSON not conforming to these rules (including empty strings) are invalid and shall cause the onCSLaunch callback to return with an error code of 4 (general_error). | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000020 | 1 | Installing a (Native) Application with invalid JSON data (Android) | When the install (Native) application instruction is supplied in the payload field of the launchCSApp() method with invalid JSON data, the CS Launcher Application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with error code 4 (general_error). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. HBBTV,section 14.4.2.2: The payload data for the install and launch operations are carried as Strings which contain JSON formatted data. The exact format of the JSON payload is described here. JSON not conforming to these rules (including empty strings) are invalid and shall cause the onCSLaunch callback to return with an error code of 4 (general_error). | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000020_IOS | 1 | Installing a (Native) Application with invalid JSON data (iOS) | When the install (Native) application instruction is supplied in the payload field of the launchCSApp() method with invalid JSON data, the iOS CS Launcher Application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with error code 4 (general_error). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. HBBTV,section 14.4.2.2: The payload data for the install and launch operations are carried as Strings which contain JSON formatted data. The exact format of the JSON payload is described here. JSON not conforming to these rules (including empty strings) are invalid and shall cause the onCSLaunch callback to return with an error code of 4 (general_error). | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000021 | 1 | Launching both Native and HTML Applications with invalid JSON data (Android) | When both launch native and launch HTML instructions are supplied in the payload field of the launchCSApp() method with invalid JSON data, the CS Launcher Application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with error code 4 (general_error). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. HBBTV,section 14.4.2.2: The payload data for the install and launch operations are carried as Strings which contain JSON formatted data. The exact format of the JSON payload is described here. JSON not conforming to these rules (including empty strings) are invalid and shall cause the onCSLaunch callback to return with an error code of 4 (general_error). | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000021_IOS | 1 | Launching both Native and HTML Applications with invalid JSON data (iOS) | When both launch native and launch HTML instructions are supplied in the payload field of the launchCSApp() method with invalid JSON data, the iOS CS Launcher Application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with error code 4 (general_error). | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. HBBTV,section 14.4.2.2: The payload data for the install and launch operations are carried as Strings which contain JSON formatted data. The exact format of the JSON payload is described here. JSON not conforming to these rules (including empty strings) are invalid and shall cause the onCSLaunch callback to return with an error code of 4 (general_error). | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000022 | 1 | Launching an application with JSON data of 65536 bytes (Android) | When the launch application instruction is supplied in the payload field of the launchCSApp() method with JSON formatted data of 65536 bytes, the Companion Screen Launcher Application shall cause the terminal to attempt to launch the application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 14.4.2.2: The terminal and launcher shall support a maximum size for the String containing the JSON formatted data of 65536 bytes. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000022_IOS | 1 | Launching an application with JSON data of 65536 bytes (iOS) | When the launch application instruction is supplied in the payload field of the launchCSApp() method with JSON formatted data of 65536 bytes, the iOS Companion Screen Launcher Application shall cause the terminal to attempt to launch the application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 14.4.2.2: The terminal and launcher shall support a maximum size for the String containing the JSON formatted data of 65536 bytes. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000023 | 1 | Installing a (Native) application from a single source with store name (Android) | When the install (Native) application instruction is supplied with single source information having store name in the payload field of the launchCSApp() method, the Companion Screen Launcher Application shall cause the terminal to attempt to install the native application using the provided store information. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 14.4.2.2.1: This Installation Operation may contain multiple sources for a installation to be sourced from, but shall include at least one source. If there is a single source, then it may contain a store name. The store names (appStoreId) are defined as the app_store_id string as defined in table 15 in section 14.4.1.2. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000024 | 1 | Installing a (Native) application from a single source without store name (Android) | When the install (Native) application instruction is supplied with single source information not having store name in the payload field of the launchCSApp() method, the Companion Screen Launcher Application shall cause the terminal to attempt to install the native application using the default store information. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 14.4.2.2.2: This Installation Operation may contain multiple sources for a installation to be sourced from, but shall include at least one source. If there are multiple sources, then each source shall contain a store name, except for the last one in the list, which may optionally contain a store name. If the last one in the list does not contain a store name, the platform default store shall be assumed. HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: readonly Number enum_id | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000025 | 1 | Installing a (Native) application from the first store of multiple sources (Android) | When the install (Native) application instruction is supplied with multiple source information in the payload field of the launchCSApp() method, the Companion Screen Launcher Application shall cause the terminal to attempt to install the native application using the first store information. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 14.4.2.2.1: This Installation Operation may contain multiple sources for a installation to be sourced from, but shall include at least one source. If there are multiple sources, then each source shall contain a store name, except for the last one in the list, which may optionally contain a store name. If the last one in the list does not contain a store name, the platform default store shall be assumed. If there are multiple sources then the launcher should attempt to install from the first store in the list that the platform recognises. The store names (appStoreId) are defined as the app_store_id string as defined in table 15 in section 14.4.1.2. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000026 | 1 | Installing a (Native) application from the last store of multiple sources with store name (Android) | When the install (Native) application instruction is supplied with multiple source information all having store names in the payload field of the launchCSApp() method, and only the last one is valid, the Companion Screen Launcher Application shall cause the terminal to attempt to install the native application using the last store information. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 14.4.2.2.1: This Installation Operation may contain multiple sources for a installation to be sourced from, but shall include at least one source. If there are multiple sources, then each source shall contain a store name, except for the last one in the list, which may optionally contain a store name. If the last one in the list does not contain a store name, the platform default store shall be assumed. If there are multiple sources then the launcher should attempt to install from the first store in the list that the platform recognises. The store names (appStoreId) are defined as the app_store_id string as defined in table 15 in section 14.4.1.2. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000027 | 1 | Installing a (Native) application from the default store of multiple sources (Android) | When the install (Native) application instruction is supplied with multiple source information all having store names but the last one in the payload field of the launchCSApp() method, and all of them are invalid, the Companion Screen Launcher Application shall cause the terminal to attempt to install the native application using the default store information. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 14.4.2.2.1: This Installation Operation may contain multiple sources for a installation to be sourced from, but shall include at least one source. If there are multiple sources, then each source shall contain a store name, except for the last one in the list, which may optionally contain a store name. If the last one in the list does not contain a store name, the platform default store shall be assumed. If there are multiple sources then the launcher should attempt to install from the first store in the list that the platform recognises. The store names (appStoreId) are defined as the app_store_id string as defined in table 15 in section 14.4.1.2. | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000028 | 1 | Installing a Native Companion Screen application with the correct enum_id returned (Android) | When a Native Companion Screen application is installed, the CS Launcher application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with the same enum_id | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. When the result of the the Launch operation is known, the HbbTV browser calls the onCSLaunch callback enum_id A unique ID for a CS launcher application | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000028_IOS | 1 | Installing a Native Companion Screen application with the correct enum_id returned (iOS) | When a Native Companion Screen application is installed, the iOS CS Launcher application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with the same enum_id | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. When the result of the the Launch operation is known, the HbbTV browser calls the onCSLaunch callback enum_id A unique ID for a CS launcher application | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000029 | 1 | Launching a Native Companion Screen application with the correct enum_id returned (Android) | When a Native Companion Screen application is launched, the CS Launcher application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with the same enum_id. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. When the result of the the Launch operation is known, the HbbTV browser calls the onCSLaunch callback enum_id A unique ID for a CS launcher application | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000029_IOS | 1 | Launching a Native Companion Screen application with the correct enum_id returned (iOS) | When a Native Companion Screen application is launched, the iOS CS Launcher application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with the same enum_id. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. When the result of the the Launch operation is known, the HbbTV browser calls the onCSLaunch callback enum_id A unique ID for a CS launcher application | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000030 | 1 | Launching an HTML Companion Screen application with the correct enum_id returned (Android) | When an HTML Companion Screen application is launched, the CS Launcher application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with the same enum_id.. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. When the result of the the Launch operation is known, the HbbTV browser calls the onCSLaunch callback enum_id A unique ID for a CS launcher application | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000030_IOS | 1 | Launching an HTML Companion Screen application with the correct enum_id returned (iOS) | When an HTML Companion Screen application is launched, the iOS CS Launcher application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with the same enum_id. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. When the result of the the Launch operation is known, the HbbTV browser calls the onCSLaunch callback enum_id A unique ID for a CS launcher application | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000031 | 1 | Launching a Native and an HTML Companion Screen application with the correct enum_id returned (Android) | When a Native and an HTML Companion Screen application is launched, the CS Launcher application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with the same enum_id." | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. When the result of the the Launch operation is known, the HbbTV browser calls the onCSLaunch callback enum_id A unique ID for a CS launcher application | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000031_IOS | 1 | Launching a Native and an HTML Companion Screen application with the correct enum_id returned (iOS) | When a Native and an HTML Companion Screen application is launched, the iOS CS Launcher application shall cause the terminal to respond to launchCSApp() by calling onCSLaunch() callback function with the same enum_id." | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.6.1: To launch or install a CS application on a CS device the launchCSApp() method needs to be called for the CS device identified by the CS device enumeration ID (enum_id). The action that the CS launcher application on the CS device will undertake is described by the payload string. The semantics of the instruction and the payload format are described in section 14.4.2. When the result of the the Launch operation is known, the HbbTV browser calls the onCSLaunch callback enum_id A unique ID for a CS launcher application | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000032 | 1 | Test to check return value of bool launchCSApp() in case of no errors | When the HbbTV application calls the launchCSApp() function, the terminal shall return true to the HbbTV application when the enum_id refers to a launcher application. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: Boolean launchCSApp(int enum_id, String payload, function onCSLaunch). [...] The function returns false if the enum_id does not refer to a launcher application, otherwise it returns true. HBBTV,section 8.2.6.3: A DiscoveredCSLauncher object shall have the following properties: readonly Number enum_id | +CS_APP_LAUNCH | ||
| org.hbbtv_CS000033 | 1 | Test to check return value of bool launchCSApp() in case of any error | When the HbbTV application calls launchCSApp() function, the terminal shall return false to the HbbTV application in case of any error. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.6.1: bool launchCSApp(int enum_id, String payload, function onCSLaunch). This returns true to indicate that the function has completed with no errors (and that callbacks are expected), false otherwise. | +CS_APP_LAUNCH | ||
| org.hbbtv_D00007050 | 1 | DASH: finished state of A/V Control object | The A/V control is transitioned to finished state due to reaching end of video content. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: In order to play the content, the terminal shall fetch the MPD from the URL, interpret the MPD and select an initial set of representations. OIPF-DAE,section 7.14.1.1: Figure 18: State diagram for embedded A/V Control objects OIPF-DAE,section B.5: 5 - finished; the playback of the current media has reached the end of the media. | |||
| org.hbbtv_D00007060 | 1 | DASH: error state reporting when mpd contains invalid xml. | A/V Control object shall go to error state 6 with error value 'content corrupt or invalid', when it tries to play mpd file containing invalid xml. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: If at any time the MPD is found to be not valid according to the XML schema or semantics defined in DASH [29], the A/V control object shall go to play state 6 ('error') with error value 4 ('content corrupt or invalid'). OIPF-DAE,section 7.14.1.1: Figure 18: State diagram for embedded A/V Control objects | |||
| org.hbbtv_D1000020 | 1 | Update of BaseURL at the Period level. | When an MPD contains one Period with a BaseURL on the Period level, and the BaseURL is updated during playback, the terminal shall request the segments from the new location. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. DASH,section 5.3.2.2: BaseURL - specifies a base URL that can be used for reference resolution and alternative URL selection. For more details refer to the description in 5.6 DASH,section 5.4: If MPD@type is set to 'dynamic', the MPD may be updated during the Media Presentation. DASH,section 5.6: The BaseURL element may be used to specify one or more common locations for Segments and other resources. | |||
| org.hbbtv_D1000030 | 1 | Update of BaseURL at the Adaptation Set level. | When an MPD contains one Period with a BaseURL on the Adaptation Set level, and the BaseURL is updated during playback, the terminal shall request the segments from the new location. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. DASH,section 5.3.3.2: BaseURL - specifies a base URL that can be used for reference resolution and alternative URL selection. For more details refer to the description in 5.6 DASH,section 5.4: If MPD@type is set to 'dynamic', the MPD may be updated during the Media Presentation. DASH,section 5.6: The BaseURL element may be used to specify one or more common locations for Segments and other resources. | |||
| org.hbbtv_D1000040 | 1 | Update of BaseURL at the Representation level. | When an MPD contains one Period with a BaseURL on the Representation level, and the BaseURL is updated during playback, the terminal shall request the segments from the new location. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. DASH,section 5.3.5.2: BaseURL - specifies a base URL that can be used for reference resolution and alternative URL selection. For more details refer to the description in 5.6 DASH,section 5.4: If MPD@type is set to 'dynamic', the MPD may be updated during the Media Presentation. DASH,section 5.6: The BaseURL element may be used to specify one or more common locations for Segments and other resources. | |||
| org.hbbtv_D1000110 | 3 | DASH: Increasing @availabilityEndTime | When the @availabilityEndTime attribute of a dynamic, single-Period MPD is extended, the A/V control object shall continue playing segments past the original @availabilityEndTime | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] DASH,section 5.3.1.2: @availabilityEndTime - specifies the latest Segment availability end time for any Segment in the Media Presentation. DASH,section 5.4: If MPD@type is set to 'dynamic', the MPD may be updated during the Media Presentation. | |||
| org.hbbtv_D1000200 | 1 | DASH: update of playPosition. | playPosition property of A/V Control object shall be correctly updated due to normal playout. MPD type is static. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] OIPF-DAE,section 8.2.3: readonly Number playPosition: The property holds the current play positon in milliseconds of the media referenced by the data property. | |||
| org.hbbtv_D1000230 | 1 | Request for segments shall respect format tag when $Number$ identifier is used. | When $Number$ identifier is used and number of digits is less than [width], the result shall be padded with zeros. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] DASH,section 5.3.9.4.4: The width parameter is an unsigned integer that provides the minimum number of characters to be printed. If the value to be printed is shorter than this number, the result shall be padded with zeros. The value is not truncated even if the result is larger. | |||
| org.hbbtv_D1000231 | 1 | Request for segments shall respect format tag when $Bandwidth$ identifier is used. | When $Bandwidth$ identifier is used and number of digits is less than [width], the result shall be padded with zeros. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Presentation of adaptive bitrate content HBBTV,section E: Profiles of MPEG DASH DASH,section 5.3.9.4.4: The width parameter is an unsigned integer that provides the minimum number of characters to be printed. If the value to be printed is shorter than this number, the result shall be padded with zeros. The value is not truncated even if the result is larger. | |||
| org.hbbtv_D1000232 | 1 | Request for segments shall respect format tag when $Time$ identifier is used. | When $Time$ identifier is used and number of digits is less than [width], the result shall be padded with zeros. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Presentation of adaptive bitrate content HBBTV,section E: Profiles of MPEG DASH DASH,section 5.3.9.4.4: The width parameter is an unsigned integer that provides the minimum number of characters to be printed. If the value to be printed is shorter than this number, the result shall be padded with zeros. The value is not truncated even if the result is larger. | |||
| org.hbbtv_D1000233 | 1 | Request for segments shall contain not truncated number, even if $Number$ value have more digits than format tag. | When $Number$ identifier is used and number of digits is bigger than [width], the result shall not be truncated. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Presentation of adaptive bitrate content HBBTV,section E: Profiles of MPEG DASH DASH,section 5.3.9.4.4: The width parameter is an unsigned integer that provides the minimum number of characters to be printed. If the value to be printed is shorter than this number, the result shall be padded with zeros. The value is not truncated even if the result is larger. | |||
| org.hbbtv_D1000234 | 1 | Request for segments shall contain not truncated number, even if $Bandwidth$ value have more digits than format tag. | When $Bandwidth$ identifier is used and number of digits is bigger than [width], the result shall not be truncated. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Presentation of adaptive bitrate content HBBTV,section E: Profiles of MPEG DASH DASH,section 5.3.9.4.4: The width parameter is an unsigned integer that provides the minimum number of characters to be printed. If the value to be printed is shorter than this number, the result shall be padded with zeros. The value is not truncated even if the result is larger. | |||
| org.hbbtv_D1000400 | 1 | DASH: SegmentTemplate@startNumber | The first url of media segment request send by terminal shall contain value of @startNumber parameter of segmentTemplate. | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] DASH,section 5.3.9.5.3: if SegmentTemplate element is present the Template-based Segment URL construction in 5.3.9.4.4 shall be applied with the number of the Media Segment in the Media Segment list. The first number in the list is determined by the value of the SegmentTemplate@startNumber attribute, if present, or is 1 in case this attribute is not present. | |||
| org.hbbtv_D1000410 | 1 | DASH: absence of SegmentTemplate@startNumber. | If the @startNumber attribute is not present in the corresponding SegmentTemplate element at Period level, the $Number$ identifier shall be replaced with 1 in the URL when the terminal requests the first segment | 2024-2 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4: Terminals shall support applications setting the data attribute of a CEA-2014 A/V control object to a URL referencing an MPD as defined in DASH [29] DASH,section 5.3.9.5.3: if SegmentTemplate element is present the Template-based Segment URL construction in 5.3.9.4.4 shall be applied with the number of the Media Segment in the Media Segment list. The first number in the list is determined by the value of the SegmentTemplate@startNumber attribute, if presen |