List of Approved Test Assertions applicable to HbbTV Specifications ≥ v1.4.1 from test suite 2024-1 generated on 19 May 24 at 04:28:20.
| 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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-1 2023-3 2023-2 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-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 | 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-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-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-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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_00000130 | 2 | Service selection with AUTOSTART application from broadband, part 1 (success) | Terminal is tuned to a service with no application running. The terminal is then tuned to a service with an AIT which signals one AUTOSTART application carried via HTTP. The terminal has an operational broadband connection. The application is available from this connection. The terminal shall start the application. | 2024-1 2023-3 2023-2 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 | The challenge exists but not validated | 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 - no App running - Does terminal have operational broadband connection? Yes - Is an App signalled as AUTOSTART? Yes - Load application via HTTP - Did it load successfully? Yes - 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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,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_00000640 | 2 | User input - VK_RED | When user press the red button, there should be a key event of VK_RED dispatched | 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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-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,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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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. | |||
| 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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. | |||
| 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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. | |||
| 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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. | |||
| 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-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-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-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-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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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.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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-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-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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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: 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_00002430 | 2 | Terminal stores cookies with an expiry date in persistent memory | The terminal shall store cookies with expiry dates in persistent memory. | 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 | The challenge exists but not validated | 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. | ||
| 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.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-1 2023-3 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,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-1 2023-3 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,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-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,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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_00003560 | 3 | AV Object Seeking Outside Buffer (MP4 Forward) | The terminal shall correctly seek forward to a new position outside buffer for a video contained in a MP4 format. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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 | The challenge exists but not validated | 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_00003851 | 1 | OIPF Configuration: preferredAudioLanguage | The configuration.preferredAudioLanguage property of the application/oipfConfiguration object contains a list of comma separated ISO 639.2 language codes. | 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 preferredAudioLanguage: A comma-separated set of languages to be used for audio playback, in order of preference. Each language SHALL be indicated by its ISO 639.2 language code as defined in [ISO 639.2]. | |||
| org.hbbtv_00003861 | 1 | OIPF Configuration: preferredSubtitleLanguage | The configuration.preferredSubtitleLanguage property of the application/oipfConfiguration object contains a list of comma separated ISO 639.2 language codes. | 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 preferredAudioLanguage: A comma-separated set of languages to be used for audio playback, in order of preference. Each language SHALL be indicated by its ISO 639.2 language code as defined in [ISO 639.2]. | |||
| 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-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_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-1 2023-3 2023-2 2023-1 2022-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-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-1 2023-3 2023-2 2023-1 2022-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-1 2023-3 2023-2 2023-1 2022-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_00007110 | 1 | DASH: connecting state of A/V Control object. | The A/V Control has transitioned to the connecting state (3) due to call play() method on DASH content. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 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: 3 - connecting; connect to media server, i.e. waiting for connection to media server to be established, upon first connection or after the connection was lost. | ||
| 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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-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 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.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-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,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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-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-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_A11Y_0040 | 1 | Accessibility Feature Suppression | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.af.featureSuppress and org.hbbtv.af.featureSupportInfo methods and requests suppression (using the org.hbbtv.af.featureSuppress method) of all features where the terminal responds to org.hbbtv.af.featureSupportInfo request with a response of tvosAndHbbTV or supportedNoSetting. The application records the responses and informs the tester which features responded with suppressing or notSuppressing, and which features the application did not attempt to suppress. The tester then manually needs to confirm that the features are suppressed or not suppressed accordingly. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 15.2.2.2.2: If a terminal responds that it has agreed to suppress the feature ("suppressing"), it shall suppress its implementation of the feature (in as far as the feature affects the HbbTV application environment) while the HbbTV application remains running. If a terminal responds that it has refused to suppress the feature ("notSuppressing"), it shall not suppress the feature. | |||
| 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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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_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-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-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-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-1 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 | 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-1 2023-3 2023-2 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-1 2023-3 2023-2 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-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 | 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-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-1 2023-3 2023-2 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-1 2023-3 2023-2 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-1 2023-3 2023-1 2022-3 2020-2 2020-1 2019-2 | HBBTV 1.5.1 HBBTV 1.6.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-1 2023-3 2023-2 2023-1 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-CLEARKEY-0010 | 2 | HTML5 static video element to display DASH HEVC and AC-4 content with EME CLEARKEY description | 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 AC-4 audio and HEVC video content 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-1 2020-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 [...] 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.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using the video element as follows; * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] HBBTV,section B.3: The "Clear Key" key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH. | +AC4 +HEVC_HD_8 | ||
| 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-1 2023-3 2023-2 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-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-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-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-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-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-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-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-1 2023-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 2020-1 | The challenge exists but not validated | HBBTV 1.5.1 HBBTV 1.6.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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | The challenge exists but not validated | 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-1 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-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-1 2023-1 2022-3 2022-2 2022-1 2021-3 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 [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-1 2023-3 2023-2 2023-1 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-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-1 2023-3 2023-2 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-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-1 2023-3 2023-2 2023-1 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-1 2023-1 2022-3 2020-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.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-1 2023-3 2023-1 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 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-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,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-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,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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-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-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-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-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-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-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,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-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-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-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-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-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-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 | 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.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-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 | 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.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-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-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,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-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-1 2023-3 2023-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-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-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-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-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,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-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-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-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-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-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_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-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-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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2022-2 2022-1 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: 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 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-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,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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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 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-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,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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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 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-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,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-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,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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 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-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,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-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-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,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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 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-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 | The challenge exists but not validated | 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-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 | The challenge exists but not validated | 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-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,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_APP2AV1111 | 1 | APP2AV:MediaSynchroniser.currentTime with broadcast TS and PTS values larger than 2^32 | 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 with large PTS values close to 2^33, then the terminal shall return the current value of the referenced PTS timeline. | 2024-1 2023-3 2023-2 2023-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.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" 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_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-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-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-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-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-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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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,section A1: 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-1 2023-3 2023-2 2023-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section A1: 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_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-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-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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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_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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_AVC00202 | 1 | Terminal restore rendering subtitle AVComponents after selectComponent(COMPONENT_TYPE_SUBTITLE) calling. | Terminal shall restore rendering subtitle component, when selectComponent(COMPONENT_TYPE_SUBTITLE) is called. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-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_AVC01130 | 1 | Terminal starts to render AVComponents using selectComponent( componentType ) method of A/V Control object. | First, terminal shall stop rendering AVComponent using unselectComponent() method, next terminal starts to render video and audio components from mp4 file, when selectComponent() is called. | 2024-1 2023-3 2023-2 2023-1 2022-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: Detailed section by section definition 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_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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 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-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-1 2023-3 2023-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-1 2023-3 2023-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-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-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-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-1 2023-3 2023-2 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-1 2023-3 2023-2 2023-1 2022-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_DA540290 | 3 | Simple DASH A/V stream | The terminal shall correctly decode and display video content from a stream defined by a static MPD containing one audio adaptation set with one representation, and one video adaptation set with one representation. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.5: Representation HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.2: There shall be no more than N_rep Representations per Adaptation Set in an MPD. [...] Maximum numeric requirements on HbbTV ISOBMFF Live MPD: N_rep 16 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540300 | 3 | Simple DASH A/V stream (Audio check) DASH Audio stream with one representation | The terminal shall correctly decode and display audio content from a stream defined by a static MPD containing one audio adaptation set with one representation, and one video adaptation set with one representation. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.5: Representation HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.2: There shall be no more than N_rep Representations per Adaptation Set in an MPD. [...] Table E.1 Maximum numeric requirements on HbbTV ISOBMFF Live MPD Parameter: N_rep Value: 16 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540310 | 3 | DASH A/V stream with two video representations | The terminal shall correctly decode and display AV content from a stream defined by a static MPD containing one audio adaptation set with one representation and one video adaptation set with two representations. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.5: Representation HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.2: There shall be no more than N_rep Representations per Adaptation Set in an MPD. [...] Maximum numeric requirements on HbbTV ISOBMFF Live MPD: N_rep 16 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540320 | 3 | DASH A/V stream with 16 video representations | The terminal shall correctly decode and display AV content from a stream defined by a static MPD containing one audio adaptation set with one representation and one video adaptation set with 16 representations. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.5: Representation HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.2: There shall be no more than N_rep Representations per Adaptation Set in an MPD. [...] Table E.1 Maximum numeric requirements on HbbTV ISOBMFF Live MPD Parameter: N_rep Value: 16 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540340 | 3 | DASH streams with HE-AAC Broadcast-mix Audio Description (main audio only) | Terminal correctly presents main broadcast audio from a DASH stream containing 1 video and 2 HE-AAC audio AdaptationSets, where 1 audio AdaptationSet is signalled as containing broadcast mix Audio Description using the AudioPurpose classification scheme | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.3.2: [...] Accessibility 0 ... N specifies information about accessibility scheme [...] Role 0 ... N specifies information on role annotation scheme [...] HBBTV,section 9.4: When an instance of the AVComponent class refers to a DASH audio media content component: If the audio media component is identified as being audio description (as defined in clause E.2.4 Role Related Requirements below), the audioDescription property of the AVComponent shall be set to true. HBBTV,section E.2.4: The MPD shall identify audio description streams using the Role and Accessibility descriptors HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. OIPF-DAE,section 8.4.5: Audio streams [...] with broadcast mix audio description SHALL be exposed to the application using one AVAudioComponent object per audio stream. Broadcast mix audio description streams SHALL have the audioDescription property set to true. | |||
| org.hbbtv_DA540341 | 4 | DASH streams with HE-AAC Broadcast-mix Audio Description (audio description only) | Terminal correctly presents broadcast mix Audio Description from a DASH stream containing 1 video and 2 HE-AAC audio AdaptationSets, where 1 audio AdaptationSet is signalled as containing broadcast mix Audio Description using the AudioPurpose classification scheme | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.3.2: [...] Accessibility 0 ... N specifies information about accessibility scheme [...] Role 0 … N specifies information on role annotation scheme [...] HBBTV,section 9.4: When an instance of the AVComponent class refers to a DASH audio media content component; If the audio media component is identified as being audio description (as defined in clause E.2.4 Role Related Requirements below), the audioDescription property of the AVComponent shall be set to true. HBBTV,section E.2.4: The MPD shall identify audio description streams using the Role and Accessibility descriptors HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. OIPF-DAE,section 8.4.5: Audio streams [...] with broadcast mix audio description SHALL be exposed to the application using one AVAudioComponent object per audio stream. Broadcast mix audio description streams SHALL have the audioDescription property set to true. | |||
| org.hbbtv_DA540360 | 3 | DASH streaming with one period, without a start or duration attribute | The terminal shall correctly decode and display AV content from a stream defined by a static MPD containing one period, the period not having a start or duration attribute defined. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.2: If (i) @start attribute is absent, and (ii) the Period element is the first in the MPD, and (iii) the MPD@type is 'static', then the PeriodStart time shall be set to zero. [...] The Period extends until the PeriodStart of the next Period, or until the end of the Media Presentation in the case of the last Period. HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.2: There shall be no more than "Nper" Periods in an MPD that shall be temporarily sequential. The behaviour of a terminal is undefined for MPDs containing more than "Nper" Periods. [...] Table E.1 Maximum numeric requirements on HbbTV ISOBMFF Live MPD Parameter: N_per Value: 32 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540370 | 3 | DASH streaming with one period with start attribute and no duration attribute | The terminal shall correctly decode and display AV content from a stream defined by a static MPD containing one period with a start attribute and no duration attribute. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.2: If the attribute @start is present in the Period, then the Period is a regular Period and the PeriodStart is equal to the value of this attribute. [...] The Period extends until the PeriodStart of the next Period, or until the end of the Media Presentation in the case of the last Period. HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.2: There shall be no more than "Nper" Periods in an MPD that shall be temporarily sequential. The behaviour of a terminal is undefined for MPDs containing more than "Nper" Periods. [...] Table E.1 Maximum numeric requirements on HbbTV ISOBMFF Live MPD Parameter: N_per Value: 32 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540380 | 3 | DASH streaming with one period with duration attribute and no start attribute | The terminal shall correctly decode and display AV content from a stream defined by a static MPD containing one period with a duration attribute and no start attribute. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.2: If (i) @start attribute is absent, and (ii) the Period element is the first in the MPD, and (iii) the MPD@type is 'static', then the PeriodStart time shall be set to zero. [...] @duration [...] if present specifies the duration of the Period to determine the PeriodStart time of the next Period. HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.2: There shall be no more than "Nper" Periods in an MPD that shall be temporarily sequential. The behaviour of a terminal is undefined for MPDs containing more than "Nper" Periods. [...] Table E.1 Maximum numeric requirements on HbbTV ISOBMFF Live MPD Parameter: N_per Value: 32 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540390 | 3 | DASH streaming with one period with start and duration attributes | The terminal shall correctly decode and display AV content from a stream defined by a static MPD containing one period with a start attribute and a duration attribute. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.2: If the attribute @start is present in the Period, then the Period is a regular Period and the PeriodStart is equal to the value of this attribute. [...] @duration [...] if present specifies the duration of the Period to determine the PeriodStart time of the next Period. HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.2: There shall be no more than "Nper" Periods in an MPD that shall be temporarily sequential. The behaviour of a terminal is undefined for MPDs containing more than "Nper" Periods. [...] Table E.1 Maximum numeric requirements on HbbTV ISOBMFF Live MPD Parameter: N_per Value: 32 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540400 | 3 | DASH streaming with two contiguous periods, both with start and duration attributes | The terminal shall correctly decode and display video content from a stream defined by a static MPD containing two contiguous periods, each having a start and a duration attribute defined. The terminal shall be able to transition between the two periods | 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 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.2: @start [...] if present, specifies the PeriodStart time of the Period.The PeriodStart time is used as an anchor to determine the MPD start time of each Media Segment as well as to determine the presentation time of each each access unit in the Media Presentation timeline. [...] @duration [...] if present specifies the duration of the Period to determine the PeriodStart time of the next Period. HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.2: There shall be no more than "Nper" Periods in an MPD that shall be temporarily sequential. The behaviour of a terminal is undefined for MPDs containing more than "Nper" Periods. [...] Table E.1 Maximum numeric requirements on HbbTV ISOBMFF Live MPD Parameter: N_per Value: 32 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | ||
| org.hbbtv_DA540405 | 3 | DASH streaming with two contiguous periods, both with start and duration attributes (audio check) | The terminal shall correctly decode and play audio content from a stream defined by a static MPD containing two contiguous periods, each having a start and a duration attribute defined. The terminal shall correctly transition between the two periods. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.2: @start [...] if present, specifies the PeriodStart time of the Period.The PeriodStart time is used as an anchor to determine the MPD start time of each Media Segment as well as to determine the presentation time of each each access unit in the Media Presentation timeline. [...] @duration [...] if present specifies the duration of the Period to determine the PeriodStart time of the next Period. HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.2: There shall be no more than "Nper" Periods in an MPD that shall be temporarily sequential. The behaviour of a terminal is undefined for MPDs containing more than "Nper" Periods. [...] Table E.1 Maximum numeric requirements on HbbTV ISOBMFF Live MPD Parameter: N_per Value: 32 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540410 | 3 | DASH streaming with two contiguous periods, one with start and duration attributes, the other with start attribute and a SegmentTimeline | The terminal shall correctly decode and display AV content from a stream defined by a static MPD containing two contiguous periods, the first period having a start and a duration attribute defined, the second having a start attribute defined and containing a SegmentTimeline element. The terminal shall be able to transition between the two periods | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-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 | DASH,section 5.3.2: Period DASH,section 5.3.9.6: Segment timeline HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.2: There shall be no more than "Nper" Periods in an MPD that shall be temporarily sequential. The behaviour of a terminal is undefined for MPDs containing more than "Nper" Periods. [...] Table E.1 Maximum numeric requirements on HbbTV ISOBMFF Live MPD Parameter: N_per Value: 32 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540420 | 3 | DASH streaming with three contiguous periods, one with start and duration attributes, the others with start attribute and SegmentTimeline | The terminal shall correctly decode and display AV content from a stream defined by a static MPD containing three contiguous periods, the first period having a start and a duration attribute defined, the second and third having a start attribute defined and containing a SegmentTimeline element. | 2024-1 2023-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 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.2: Period DASH,section 5.3.9.6: Segment timeline HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.2: There shall be no more than "Nper" Periods in an MPD that shall be temporarily sequential. The behaviour of a terminal is undefined for MPDs containing more than "Nper" Periods. [...] Table E.1 Maximum numeric requirements on HbbTV ISOBMFF Live MPD Parameter: N_per Value: 32 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | ||
| org.hbbtv_DA540430 | 3 | DASH streaming with 32 contiguous periods, each with start and duration attributes | The terminal shall correctly decode and display AV content from a stream defined by a static MPD containing 32 contiguous periods, the first having a start attribute defined, and others having a duration attribute defined. The terminal shall correctly and smoothly transition between periods. | 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 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.2: @start [...] if present, specifies the PeriodStart time of the Period.The PeriodStart time is used as an anchor to determine the MPD start time of each Media Segment as well as to determine the presentation time of each each access unit in the Media Presentation timeline. [...] @duration [...] if present specifies the duration of the Period to determine the PeriodStart time of the next Period. HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.2: There shall be no more than "Nper" Periods in an MPD that shall be temporarily sequential. The behaviour of a terminal is undefined for MPDs containing more than "Nper" Periods. [...] Table E.1 Maximum numeric requirements on HbbTV ISOBMFF Live MPD Parameter: N_per Value: 32 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | ||
| org.hbbtv_DA540440 | 3 | DASH stream with 'lmsg' compatibility brand in last segment of one period | The terminal shall correctly play a DASH stream described by a static MPD containing three periods, where the last media segment of the second period carries the 'lmsg' compatibility brand | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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. DASH,section 7.3.1: If the Media Segment is the last Media Segment in the Representation, this Media Segment may carry the 'lmsg' compatibility brand. If the Media Segment is not the last Media Segment in the Representation, the 'lmsg' compatibility brand shall not be present. | |||
| org.hbbtv_DA540460 | 3 | DASH streaming with segments described per Representation by SegmentTemplates defined using $Number$ | The terminal shall correctly decode and display AV content from a stream defined by a static MPD in which segments are described by SegmentTemplates at the Representation level using the $Number$ identifier | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3: Hierarchical data model HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540470 | 4 | DASH streaming with segments described per Representation by SegmentTemplates defined using $Time$ and SegmentTimeline | The terminal shall correctly decode and display AV content from a stream defined by a static MPD in which segments are described by SegmentTemplates at the Representation level using the $Time$ identifier and the SegmentTimeline element | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3: Hierarchical data model HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540480 | 3 | DASH streaming with segments described per AdaptationSet by SegmentTemplates defined using $Number$ and $Bandwidth$ | The terminal shall correctly decode and display AV content from a stream defined by a static MPD in which segments are described by SegmentTemplates at the AdaptationSet level using the $Number$ and $Bandwidth$ identifiers | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3: Hierarchical data model HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540490 | 4 | DASH streaming with segments described per AdaptationSet by SegmentTemplates defined using $Time$, $Bandwidth$ and SegmentTimeline | The terminal shall correctly decode and display AV content from a stream defined by a static MPD in which segments are described by SegmentTemplates at the AdaptationSet level using the $Time$ and $Bandwidth$ identifiers and the SegmentTimeline element | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3: Hierarchical data model HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540500 | 3 | DASH streaming with segments described per AdaptationSet by SegmentTemplates defined using $Number$ and $RepresentationID$ | The terminal shall correctly decode and display AV content from a stream defined by a static MPD in which segments are described by SegmentTemplates at the AdaptationSet level using the $Number$ and $RepresentationID$ identifiers | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3: Hierarchical data model HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540510 | 4 | DASH streaming with segments described per AdaptationSet by SegmentTemplates defined using $Time$ and $RepresentationID$ | The terminal shall correctly decode and display AV content from a stream defined by a static MPD in which segments are described by SegmentTemplates at the AdaptationSet level using the $Time$ and $RepresentationID$ identifiers and the SegmentTimeline element | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3: Hierarchical data model HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540520 | 3 | DASH streaming with BaseURL defined at top level of MPD and segments described per Representation by SegmentTemplates | The terminal shall correctly decode and display AV content from a stream defined by a static MPD in which a BaseURL is defined at the top level of the MPD, and segments are described by SegmentTemplates at the Representation level | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3: Hierarchical data model HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540530 | 3 | DASH streaming with BaseURL defined per Period and segments described per Representation by SegmentTemplates | The terminal shall correctly decode and display AV content from a stream defined by a static MPD in which BaseURL is defined in each Period, and segments are described by SegmentTemplates at the Representation level | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3: Hierarchical data model HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540540 | 3 | DASH streaming with BaseURL defined per Representation and segments described per AdaptationSet by SegmentTemplates | The terminal shall correctly decode and display AV content from a stream defined by a static MPD in which BaseURL is defined in each Representation, and segments are described by SegmentTemplates at the AdaptationSet level | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3: Hierarchical data model HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540550 | 4 | Test that dynamic MPD updates are requested | When playing content described by an MPD which has @type="dynamic" the terminal shall make requests for an updated MPD according to the @minimumUpdatePeriod attribute of the MPD element. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") @minimumUpdatePeriod -- If this attribute is present, it specifies the smallest period between potential changes to the MPD DASH,section 5.4: If MPD@type is set to 'dynamic', the MPD may be updated during the Media Presentation. [...] If the attribute MPD@minimumUpdatePeriod is present updates to the MPD are expected and restricted in a sense that at the location where the MPD is available at a certain time, the MPD is also valid for the duration of the value of the MPD@minimumUpdatePeriod attribute. | |||
| org.hbbtv_DA540560 | 4 | Test dynamic MPD with @mediaPresentationDuration attribute | When playing content described by an MPD which has @type="dynamic" and @mediaPresentationDuration set to the full length of the video, the terminal shall play the video to the end. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") @mediaPresentationDuration -- [...] specifies the duration of the entire Media Presentation DASH,section 5.4: If MPD@type is set to 'dynamic', the MPD may be updated during the Media Presentation. [...] If the attribute MPD@minimumUpdatePeriod is not present, no update to the MPD is expected, the attribute MPD@mediaPresentationDuration shall be present and the MPD shall remain valid until the Media Presentation end time. | |||
| org.hbbtv_DA540570 | 1 | Early available period - Test dynamic MPDs with the addition of content to an empty Period. | The terminal shall play a stream defined by an MPD which has @type="dynamic". The MPD shall initially be served to the terminal containing a single empty Period element. The MPD shall then be updated so that the Period contains accessible segments. The terminal shall then start playing content. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") @minimumUpdatePeriod -- If this attribute is present, it specifies the smallest period between potential changes to the MPD DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation. DASH,section 5.3.2.1: Early Available Periods may be used to advertise initialization of other non-media data before the media data itself is available. | ||
| org.hbbtv_DA540580 | 4 | Addition of a Period to a dynamic MPD with 1 Period. | When playing content described by an MPD which has @type="dynamic" and has one Period element when initially served to the terminal, the terminal shall correctly play content described in a Period element which is dynamically added to the MPD. | 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") @minimumUpdatePeriod -- If this attribute is present, it specifies the smallest period between potential changes to the MPD DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation. | |||
| org.hbbtv_DA540590 | 4 | Added Period in a Dynamic MPD - Low to High | The terminal shall play a stream defined by an MPD which has @type="dynamic" and contains a single Period, which shall have @start=0. The MPD shall then be updated to change the segments described by the video Representation to a higher bitrate Representation with a different @id. Playback of video on the terminal shall continue without interruption using the segments described in the new Representation. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") @minimumUpdatePeriod -- If this attribute is present, it specifies the smallest period between potential changes to the MPD DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation. | |||
| org.hbbtv_DA540595 | 4 | Added Period in a Dynamic MPD - High to Low | The terminal shall play a stream defined by an MPD which has @type="dynamic" and contains a single Period, which shall have @start=0. The MPD shall then be updated to change the segments described by the video Representation to a lower bitrate Representation with a different @id. Playback of video on the terminal shall continue without interruption using the segments described in the new Representation. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2020-2 2020-1 2019-3 2019-2 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 E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation. | |||
| org.hbbtv_DA540600 | 4 | Removal of a completed period from a dynamic MPD | The terminal shall play a stream defined by an MPD which has @type="dynamic" and which contains two Periods. Once playback of the first Period has completed, the MPD shall be updated to remove it. The terminal shall continue to correctly play content without interruption. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation. | |||
| org.hbbtv_DA540605 | 4 | Removal of a completed period from a dynamic MPD (Audio check) | The terminal shall play a stream defined by an MPD which has @type="dynamic" and which contains two Periods. Once playback of the first Period has completed, the MPD shall be updated to remove it. The terminal shall continue to correctly play audio content without interruption. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation. | |||
| org.hbbtv_DA540610 | 4 | Addition of a new representation to a dynamic MPD | The terminal shall play a stream defined by an MPD which has @type="dynamic". Once playback has commenced the MPD shall be updated to add a Representation. The terminal shall continue to correctly play video content without interruption and shall use the added Representation when the bandwidth to use other Representations is not available. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 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 E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply HBBTV,section E.4.2.1: During playback of adaptively streamed content encoded using AVC, terminals shall support transitions between video Representations DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation. | ||
| org.hbbtv_DA540615 | 4 | Addition of a new representation to a dynamic MPD (audio check) | The terminal shall play a stream defined by an MPD which has @type="dynamic". Once playback has commenced the MPD shall be updated to add a Representation. The terminal shall continue to correctly play audio content without interruption and shall use the added Representation when the bandwidth to use other Representations is not available. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation. | ||
| org.hbbtv_DA540620 | 4 | Change to the SegmentTemplate of a dynamic MPD | The terminal shall play a stream defined by an MPD which has @type="dynamic". Once playback has commenced the MPD shall be updated with a modified SegmentTemplate. The terminal shall continue to correctly play content without interruption. | 2024-1 2023-3 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation. | |||
| org.hbbtv_DA540630 | 4 | Change to the BaseURL of a dynamic MPD | The terminal shall play a stream defined by an MPD which has @type="dynamic". Once playback has commenced the MPD shall be updated with a modified BaseURL element. The terminal shall continue to correctly play content without interruption. | 2024-1 2023-3 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: BaseURL -- specifies a Base URL that can be used for reference resolution and alternative URL selection. [...] @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation. | |||
| org.hbbtv_DA540640 | 4 | Termination of MPD updates when @mediaPresentationDuration is set | The terminal shall play a stream defined by an MPD which has @type="dynamic" and which specifies a value for @minimumUpdatePeriod. Once playback has commenced the MPD shall be updated to replace the @minimumUpdatePeriod attribute with the @mediaPresentationDuration. The terminal shall make no further requests for the MPD. | 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: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.1.2: @type -- specifies whether the Media Presentation Description may be updated (@type="dynamic") or not (@type="static") @minimumUpdatePeriod -- If this attribute is present, it specifies the smallest period between potential changes to the MPD DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation. [...] If the attribute MPD@minimumUpdatePeriod is not present, no update to the MPD is expected, the attribute MPD@mediaPresentationDuration shall be present and the MPD shall remain valid until the Media Presentation end time. | |||
| org.hbbtv_DA540655 | 4 | Correct handling of a decrease in @minimumUpdatePeriod in a dynamic MPD | The terminal shall play a stream defined by an MPD which has @type="dynamic". The MPD shall initially be served to the terminal containing a single Period and the @minimumUpdatePeriod set to 30 seconds. After 1 minute the MPD shall be replaced by one with the @minimumUpdatePeriod reduced to 10 seconds. The terminal shall increase the frequency at which it updates the MPD to 10 seconds. | 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.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.2.1: If the attribute @start is present in the Period, then the Period is a regular Period and the PeriodStart is equal to the value of this attribute. DASH,section 5.4: Updates typically extend the accessible Segment list for each Representation, introduce a new Period or terminate the Media Presentation | |||
| org.hbbtv_DA540660 | 5 | DASH stream transitioning from high to low bitrate interlaced video content | During playout of a stream defined in a static MPD the terminal shall transition seamlessly from a video representation with a high bit rate (1.5Mbps) and interlaced content to a representation with a low bit rate (256kbps) and interlaced content. | 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH 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_DA540670 | 5 | DASH stream transitioning from low to high bitrate interlaced video content | During playout of a stream defined in a static MPD the terminal shall transition seamlessly from a video representation with a low bit rate (256kbps) and interlaced content to a representation with a high bit rate (1.5Mbps) and interlaced content. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-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 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 HBBTV,section E.4.6: When the terminal is presenting a DASH video AdaptationSet in which there is a higher bitrate video representation than the one currently being presented, the terminal shall adapt to a higher representation if all of the following conditions are met: 1) the higher representation has parameters which are supported by the terminal and the display; 2) use of the higher representation is not precluded by user preferences; 3) given a series of consecutive video segments whose indicated duration totals 30 seconds or more, the time taken for the terminal to actively download those segments is less than 1/K times the total duration of the segments, where K is given by 2 * higher_bandwidth / lower_bandwidth, where higher_bandwidth and lower_bandwidth are taken from the Representation@bandwidth attribute from the DASH MPD. | |||
| org.hbbtv_DA540680 | 5 | DASH stream transitioning from high to low bitrate progressive video content | During playout of a stream defined in a static MPD the terminal shall transition seamlessly from a video representation with a high bit rate (1.5Mbps) and progressive content to a representation with a low bit rate (256kbps) and progressive content. | 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH 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_DA540690 | 5 | DASH stream transitioning from low to high bitrate progressive video content | During playout of a stream defined in a static MPD the terminal shall transition seamlessly from a video representation with a low bit rate (256kbps) and progressive content to a representation with a high bit rate (1.5Mbps) and progressive content. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-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 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 HBBTV,section E.4.6: When the terminal is presenting a DASH video AdaptationSet in which there is a higher bitrate video representation than the one currently being presented, the terminal shall adapt to a higher representation if all of the following conditions are met: 1) the higher representation has parameters which are supported by the terminal and the display; 2) use of the higher representation is not precluded by user preferences; 3) given a series of consecutive video segments whose indicated duration totals 30 seconds or more, the time taken for the terminal to actively download those segments is less than 1/K times the total duration of the segments, where K is given by 2 * higher_bandwidth / lower_bandwidth, where higher_bandwidth and lower_bandwidth are taken from the Representation@bandwidth attribute from the DASH MPD. | |||
| org.hbbtv_DA540700 | 4 | DASH stream transitioning from 576i to 1080i video content | During playout of a stream defined in a static MPD the terminal shall transition across a period boundary, from a 576i video representation to a 1080i video representation without decoding artefacts or picture corruption | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.4.2.1: During playback of adaptively streamed content encoded using AVC, terminals shall support transitions between video Representations as follows: [...] 3) Between Representations which differ by full-screen resolution (e.g. 1920x1080 and 720x576) | |||
| org.hbbtv_DA540710 | 4 | DASH stream transitioning from 1080i to 576i video content | During playout of a stream defined in a static MPD the terminal shall transition across a period boundary, from a 1080i video representation to a 576i video representation without decoding artefacts or picture corruption | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 | |||
| org.hbbtv_DA540720 | 4 | DASH stream transitioning video content from luminance resolution 480x576 to luminance resolution 720x576 | During playout of a stream defined in a static MPD the terminal shall transition across a period boundary, from a video representation with a luminance resolution of 480x576 to a video representation with a luminance resolution of 720x576 without decoding artefacts or picture corruption | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 | |||
| org.hbbtv_DA540730 | 4 | DASH stream transitioning video content from luminance resolution 720x576 to luminance resolution 480x576 | During playout of a stream defined in a static MPD the terminal shall transition across a period boundary, from a video representation with a luminance resolution of 720x576 to a video representation with a luminance resolution of 480x576 without decoding artefacts or picture corruption | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.4.2.1: During playback of adaptively streamed content encoded using AVC, terminals shall support transitions between video Representations as follows: 4) Between Representations with the same full-screen resolution but different luminance resolutions as defined in table 9 "Table 9: Resolutions for Full-screen Display from 25 Hz H.264/AVC SDTV IRD and supported by 25 Hz H.264/AVC HDTV IRD, 50 Hz H.264/AVC HDTV IRD, 25 Hz SVC HDTV IRD and 50 Hz SVC HDTV IRD" and table 12 "Resolutions for Full-screen Display from H.264/AVC HDTV IRD and SVC HDTV IRD" of TS 101 154 [7] (e.g. 1920x1080 and 1440x1080) | |||
| org.hbbtv_DA540740 | 4 | DASH stream transitioning from interlaced to progressive video content | During playout of a stream defined in a static MPD the terminal shall transition across a period boundary, from a video representation with interlaced frames to a video representation with progressive frames without decoding artefacts or picture corruption | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.4.2.1: Some examples of transitions between Representations which terminals may support but which are not required to support include: 9) Between Representations where one is interlaced and the other is progressive | |||
| org.hbbtv_DA540750 | 4 | DASH stream transitioning from progressive to interlaced video content | During playout of a stream defined in a static MPD the terminal shall transition across a period boundary, from a video representation with progressive frames to a video representation with interlaced frames without decoding artefacts or picture corruption | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.4.2.1: Some examples of transitions between Representations which terminals may support but which are not required to support include: 9) Between Representations where one is interlaced and the other is progressive | |||
| org.hbbtv_DA540760 | 4 | DASH stream transitioning from 25fps video to 50fps video content | During playout of a stream defined in a static MPD the terminal shall transition across a period boundary, from a 25fps video representation to a 50fps video representation without decoding artefacts or picture corruption | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.4.2.1: Some examples of transitions between Representations which terminals may support but which are not required to support include: 10) Between Representations which differ in framerate, e.g. 25 and 50 fps | |||
| org.hbbtv_DA540770 | 4 | DASH stream transitioning from 50fps video to 25fps video content | During playout of a stream defined in a static MPD the terminal shall transition across a period boundary, from a 50fps video representation to a 25fps video representation without decoding artefacts or picture corruption | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.4.2.1: Some examples of transitions between Representations which terminals may support but which are not required to support include: 10) Between Representations which differ in framerate, e.g. 25 and 50 fps | |||
| org.hbbtv_DA540780 | 5 | DASH stream transitioning HEAAC audio content from low to high bitrate Representations | During playout of a stream defined in a static MPD in response to increased bandwidth availability the terminal shall seamlessly transition from an audio representation with a bitrate of 56kbps to an audio representation with a bitrate of 384kbps, both representations being encoded using HEAAC. | 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.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.4.2.2: During playback of adaptively streamed content encoded using HE-AAC or E-AC3, terminals shall support transitions between audio Representations as follows: 1) Between Representations which differ by bit-rate. Transitions shall be seamless unless combined with other changes which do not have that requirement. | |||
| org.hbbtv_DA540790 | 5 | DASH stream transitioning HEAAC audio content from high to low bitrate Representations | During playout of a stream defined in a static MPD in response to decreased bandwidth availability the terminal shall seamlessly transition from an audio representation with a bitrate of 384kbps to an audio representation with a bitrate of 54kbps, both representations being encoded using HEAAC. | 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.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.4.2.2: During playback of adaptively streamed content encoded using HE-AAC or E-AC3, terminals shall support transitions between audio Representations as follows: 1) Between Representations which differ by bit-rate. Transitions shall be seamless unless combined with other changes which do not have that requirement. | |||
| org.hbbtv_DA540820 | 4 | DASH stream transitioning from HE-AAC audio content to E-AC3 audio content | During playout of a stream defined in a static MPD, the terminal shall transition from an audio representation using HE-AAC encoding to one using E-AC3 encoding | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 | +EAC3 | ||
| org.hbbtv_DA540830 | 4 | DASH stream transitioning from EAC-3 audio content to HE-AAC audio content | During playout of a stream defined in a static MPD, the terminal shall transition from an audio representation using E-AC3 encoding to one using HE-AAC encoding | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 | +EAC3 | ||
| org.hbbtv_DA540840 | 4 | DASH stream transitioning from an audio representation with 2 channels to one with 5.1 channels | During playout of a stream defined in a static MPD the terminal shall transition from an audio representation with 2 channels to one with 5.1 channels | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.2.5: In order for the terminals to know the number of audio channels in a representation the MPD should include the Audio Channel Configuration to correctly represent the audio channel configuration | |||
| org.hbbtv_DA540850 | 4 | DASH stream transitioning from an audio representation with 5.1 channels to one with 2 channels | During playout of a stream defined in a static MPD, the terminal shall transition from an audio representation with 5.1 channels to one with 2 channels | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.2.5: In order for the terminals to know the number of audio channels in a representation the MPD should include the Audio Channel Configuration to correctly represent the audio channel configuration | |||
| org.hbbtv_DA540860 | 4 | DASH stream transitioning from an audio representation with a high sample rate to one with a low sample rate | During playout of a stream defined in a static MPD, the terminal shall transition from an audio representation with a high sample rate to one with a low sample rate | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 | |||
| org.hbbtv_DA540870 | 4 | DASH stream transitioning from an audio representation with a low sample rate to one with a high sample rate | During playout of a stream defined in a static MPD, the terminal shall transition from an audio representation with a low sample rate to one with a high sample rate | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 | |||
| org.hbbtv_DA540880 | 4 | MPEG DASH - Redirect to an MPD - HTTP 302 (Found) | When a HTTP 302 (Found) status code is received as a response to a request for an MPD, the terminal shall request the MPD from the URI provided in the Location field of the HTTP response | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section A.7: If the DASH access client receives an HTTP client or server error (i.e. messages with 4xx or 5xx error code), the client should respond appropriately (e.g. as indicated in RFC 2616) to the error code. In particular, clients should handle redirections (such as 301 and 307) as these may be used as part of normal operation. 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" and "307 Temporary Redirect" by using the temporary URL given in the Location field. 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. | |||
| org.hbbtv_DA540890 | 4 | MPEG DASH - Redirect to an MPD - HTTP 307 (Temporary Redirect) | When a HTTP 307 (Temporary Redirect) status code is received as a response to a request for an MPD, the terminal shall request the MPD from the URI provided in the Location field of the HTTP response | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section A.7: If the DASH access client receives an HTTP client or server error (i.e. messages with 4xx or 5xx error code), the client should respond appropriately (e.g. as indicated in RFC 2616) to the error code. In particular, clients should handle redirections (such as 301 and 307) as these may be used as part of normal operation. 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" and "307 Temporary Redirect" by using the temporary URL given in the Location field. 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. | |||
| org.hbbtv_DA540900 | 4 | HTTP 400 error when trying to load a DASH MPD | When an HTTP 400 (bad request) status code is received as a response to a request for an MPD, the AV object shall generate an onPlayStateChange event and transition to state 6 (error) | 2024-1 2023-3 2023-2 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 | 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. DASH,section A.7: If the DASH access client receives an HTTP client or server error (i.e. messages with 4xx or 5xx error code), the client should respond appropriately (e.g. as indicated in RFC 2616) to the error code. In particular, clients should handle redirections (such as 301 and 307) as these may be used as part of normal operation. RFC2616,section 10.4.1: The client SHOULD NOT repeat the request without modifications OIPF-DAE,section B: Changes to Section 5.7: Number playState [R] - indication of the current play state as follows: [...] 6 - error; an error occurred during media playback, preventing the current media to start/continue playing. | |||
| org.hbbtv_DA540910 | 3 | HTTP 502 error when trying to load a DASH MPD | When a HTTP 502 (bad gateway) status code is received as a response to a request for an MPD, the AV object shall generate an onPlayStateChange event and transition to state 6 (error) | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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. DASH,section A.7: If the DASH access client receives an HTTP client or server error (i.e. messages with 4xx or 5xx error code), the client should respond appropriately (e.g. as indicated in RFC 2616) to the error code. In particular, clients should handle redirections (such as 301 and 307) as these may be used as part of normal operation. OIPF-DAE,section B: Changes to Section 5.7: Number playState [R] - indication of the current play state as follows: [...] 6 - error; an error occurred during media playback, preventing the current media to start/continue playing. | |||
| org.hbbtv_DA540920 | 3 | HTTP 401 error when trying to load a DASH MPD | When a HTTP 401 (unauthorised) status code is received as a response to requests for an MPD, the AV object shall generate an onPlayStateChange event and transition to state 6 (error) | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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. DASH,section A.7: If the DASH access client receives a repeated HTTP error for the request of an MPD, the appropriate response may involve terminating the streaming service. OIPF-DAE,section B: Changes to Section 5.7: Number playState [R] - indication of the current play state as follows: [...] 6 - error; an error occurred during media playback, preventing the current media to start/continue playing. | |||
| org.hbbtv_DA540930 | 4 | HTTP 404 error when trying to load a DASH initialization segment | When a HTTP 404 (not found) status code is received as a response to a request for an Initialization Segment, the AV object shall generate an onPlayStateChange event and transition to playState 6 ('error') | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1.1.1: [...] When not presenting video, The AV Control object shall be rendered as an opaque black rectangle. 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. DASH,section A.7: If the DASH access client receives an HTTP client error (i.e. messages with 4xx error code) for the request of an Initialisation Segment, the Period containing the Initialisation Segment may not be available anymore or may not be available yet. OIPF-DAE,section B: Changes to Section 5.7: Number playState [R] - indication of the current play state as follows: [...] 6 - error; an error occurred during media playback, preventing the current media to start/continue playing. | |||
| org.hbbtv_DA540940 | 4 | HTTP 404 errors when trying to load a DASH segment | When a HTTP 404 (not found) status code is received as a response to requests for a DASH media segment, the AV object shall generate a onPlayStateChange event and transition to state 6 (error), and the terminal shall stop presenting DASH media and blank the display. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-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.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.1.1.1: When not presenting video, The AV Control object shall be rendered as an opaque black rectangle. 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. DASH,section A.7: Similarly, if the DASH access client receives an HTTP client error (i.e. messages with 4xx error code) for the request of a Media Segment, the requested Media Segment may not be available anymore or may not be available yet. In both these case the client should check if the precision of the time synchronization to a globally accurate time standard is sufficiently accurate. If the clock is believed accurate, or the error re-occurs after any correction, the client should check for an update of the MPD. OIPF-DAE,section 7.14.1.1: 10. When not presenting video, the AV Control object SHALL be rendered as an opaque black rectangle. OIPF-DAE,section B: Changes to Section 5.7: Number playState [R] - indication of the current play state as follows: [...] 6 - error; an error occurred during media playback, preventing the current media to start/continue playing. | |||
| org.hbbtv_DA540950 | 4 | MPEG DASH - Redirect to a Video Segment - HTTP 302 (Found) | When a HTTP 302 (found) status code is received as a response to a request for a media segment, the terminal shall request the segment from the URI provided in the Location field of the HTTP response | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section A.7: If the DASH access client receives an HTTP client or server error (i.e. messages with 4xx or 5xx error code), the client should respond appropriately (e.g. as indicated in RFC 2616) to the error code. In particular, clients should handle redirections (such as 301 and 307) as these may be used as part of normal operation. 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" and "307 Temporary Redirect" by using the temporary URL given in the Location field. | |||
| org.hbbtv_DA540960 | 4 | MPEG DASH - Redirect to a Video Segment - HTTP 307 (Temporary Redirect) | When a HTTP 307 (temporary redirect) status code is received as a response to a request for a media segment, the terminal shall request the segment from the URI provided in the Location field of the HTTP response and successfully play the DASH stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section A.7: If the DASH access client receives an HTTP client or server error (i.e. messages with 4xx or 5xx error code), the client should respond appropriately (e.g. as indicated in RFC 2616) to the error code. In particular, clients should handle redirections (such as 301 and 307) as these may be used as part of normal operation. 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" and "307 Temporary Redirect" by using the temporary URL given in the Location field. | |||
| org.hbbtv_DA540980 | 3 | DASH stream with 1 video AdaptationSet and 15 audio AdaptationSets | The terminal shall play a DASH stream described by an MPD containing 1 video and 15 audio AdaptationSets, with each audio AdaptationSet having a different @lang attribute. When the stream is played the terminal shall select an appropriate language AdaptationSet, and correctly play both audio and video content. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.3: AdaptationSet HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.2: There shall be no more than N_adset AdaptationSets per Period in an MPD. [...] Maximum numeric requirements on HbbTV ISOBMFF Live MPD: N_adset 16 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA540990 | 3 | DASH stream with 1 video representation and 16 audio representations | The terminal shall play a DASH stream described by an MPD containing 1 video and 1 audio AdaptationSet, with the audio AdaptationSet containing 16 Representations. When the stream is played the terminal shall select an audio Representation, and correctly play both audio and video content. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.5: Representation HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.2: There shall be no more than N_rep Representations per Adaptation Set in an MPD. [...] Maximum numeric requirements on HbbTV ISOBMFF Live MPD: N_rep 16 HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA541000 | 3 | Playback of DASH stream with 1 second segments | The terminal shall correctly play back video in a stream defined in a static MPD in which audio and video are encoded in segments 1 second in duration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.3.2: Segments shall be at least 1s long, except for the last segment in an MPD which may be shorter. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.9: Segments and Segment information | |||
| org.hbbtv_DA541005 | 3 | Playback of DASH stream with 1 second segments (audio check) | The terminal shall correctly play back audio a stream defined in a static MPD in which audio and video are encoded in segments 1 second in duration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.3.2: Segments shall be at least 1s long, except for the last segment in an MPD which may be shorter. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.9: Segments and Segment information | |||
| org.hbbtv_DA541010 | 3 | Playback of DASH stream with 15 second segments | The terminal shall correctly play back video in a stream defined in a static MPD in which audio and video are encoded in segments 15 seconds in duration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.3.2: Each video Segment shall have a duration of not more than fifteen seconds. Each audio Segment shall have a duration of not more than fifteen seconds. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.9: Segments and Segment information | |||
| org.hbbtv_DA541015 | 3 | Playback of DASH stream with 15 second segments (audio check) | The terminal shall correctly play back audio in a stream defined in a static MPD in which audio and video are encoded in segments 15 seconds in duration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.3.2: Each video Segment shall have a duration of not more than fifteen seconds. Each audio Segment shall have a duration of not more than fifteen seconds. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.9: Segments and Segment information | |||
| org.hbbtv_DA541020 | 3 | Playback of DASH stream with 3 second video segments and 15 second audio segments (video check) | The terminal shall correctly play back video in a stream defined in a static MPD in which video is encoded in segments 3 seconds duration, and audio is encoded in segments 15 seconds in duration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.3.2: Segments shall be at least 1s long, except for the last segment in an MPD which may be shorter. Each video Segment shall have a duration of not more than fifteen seconds. Each audio Segment shall have a duration of not more than fifteen seconds. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.9: Segments and Segment information | |||
| org.hbbtv_DA541025 | 3 | Playback of DASH stream with 3 second video segments and 15 second audio segments (audio check) | The terminal shall correctly play back audio in a stream defined in a static MPD in which video is encoded in segments 3 seconds duration, and audio is encoded in segments 15 seconds in duration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.3.2: Segments shall be at least 1s long, except for the last segment in an MPD which may be shorter. Each video Segment shall have a duration of not more than fifteen seconds. Each audio Segment shall have a duration of not more than fifteen seconds. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.9: Segments and Segment information | |||
| org.hbbtv_DA541030 | 3 | Playback of DASH stream with 15 second video segments and 3 second audio segments (video check) | The terminal shall correctly play back video in a stream defined in a static MPD in which video is encoded in segments 15 seconds in duration and audio is encoded in segments 3 seconds in duration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.3.2: Segments shall be at least 1s long, except for the last segment in an MPD which may be shorter. Each video Segment shall have a duration of not more than fifteen seconds. Each audio Segment shall have a duration of not more than fifteen seconds. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.9: Segments and Segment information | |||
| org.hbbtv_DA541035 | 3 | Playback of DASH stream with 15 second video segments and 3 second audio segments (audio check) | The terminal shall correctly play back audio in a stream defined in a static MPD in which video is encoded in segments 15 seconds in duration and audio is encoded in segments 3 seconds in duration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.3.2: Segments shall be at least 1s long, except for the last segment in an MPD which may be shorter. Each video Segment shall have a duration of not more than fifteen seconds. Each audio Segment shall have a duration of not more than fifteen seconds. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. DASH,section 5.3.9: Segments and Segment information | |||
| org.hbbtv_DA541040 | 3 | Playback of DASH stream with audio segments described by a SegmentTemplate containing a SegmentTimeline at the Period level of the associated MPD. | The terminal shall correctly play a stream defined by a static MPD in which the segments for the audio Representation are described by a SegmentTemplate containing a SegmentTimeline at the Period level. The video segments shall be described by a SegmentTemplate within the Representation which overrides the higher level SegmentTemplate and SegmentTimeline. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.3: Adaptation Sets DASH,section 5.3.9: Segments and Segment information HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA541050 | 3 | Playback of DASH stream with audio segments described by a SegmentTemplate at the Representation level inheriting a SegmentTimeline from the Period Level. | The terminal shall correctly play a stream defined by a static MPD in which the audio segments are described by a SegmentTemplate containing a SegmentTimeline at the Period level and a second SegmentTemplate containing @media and @initialization at the Representation level. The video segments shall be described by a SegmentTemplate within the Representation which overrides the higher level SegmentTemplate and SegmentTimeline. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.2: Period DASH,section 5.3.9: The elements SegmentBase, SegmentTemplate and SegmentList may be present in the Representation element itself HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA541060 | 3 | Playback of DASH stream with segments described by a SegmentTemplate containing a SegmentTimeline at the AdaptationSet level of the associated MPD. | The terminal shall correctly play a stream defined by a static MPD in which the segments are described by a SegmentTemplate containing a SegmentTimeline at the AdaptationSet level. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.3: Adaptation Sets DASH,section 5.3.9: Segments and Segment information HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA541070 | 3 | Playback of DASH stream with segments described by a SegmentTemplate with SegmentTimeline at the AdaptationSet level inheriting attributes from a SegmentTemplate at the Period Level. | The terminal shall correctly play a stream defined by a static MPD in which the segments are described by a SegmentTemplate containing a SegmentTimeline at the AdaptationSet level and a second SegmentTemplate containing @media and @initialization at the Period level. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.3: Adaptation Sets DASH,section 5.3.9: Segments and Segment information HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA541080 | 3 | Playback of DASH stream with segments described by a SegmentTemplate containing a SegmentTimeline at the Representation level of the associated MPD. | The terminal shall correctly play a stream defined by a static MPD in which the segments are described by a SegmentTemplate containing a SegmentTimeline at the Representation level. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.3: Adaptation Sets DASH,section 5.3.9: Segments and Segment information HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA541090 | 3 | Playback of DASH stream with segments described by a SegmentTemplate with SegmentTimeline at the Representation level inheriting attributes from a SegmentTemplate at the Period Level. | The terminal shall correctly play a stream defined by a static MPD in which the segments are described by a SegmentTemplate containing a SegmentTimeline at the Representation level and a second SegmentTemplate containing @media and @initialization at the Period level. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.3: Adaptation Sets DASH,section 5.3.9: Segments and Segment information HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.2.1: All of the requirements and restrictions for the MPEG DASH ISO Base media file format live profile shall apply. HBBTV,section E.4.1: Terminals shall support the HbbTV ISOBMFF Live profile. | |||
| org.hbbtv_DA541150 | 2 | Play with speed specified as 4x for DASH encoded clear content | The terminal shall play a DASH stream. In response to a request to play back at 4x normal speed, the terminal shall select and use an appropriate playback speed (greater than or equal to 1) and the terminal shall dispatch a PlaySpeedChanged event, correctly reporting the actual playback speed. | 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-3 2019-2 2019-1 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 HBBTV,section A.1: An onPlaySpeedChanged event shall be generated for all calls to the play() method regardless of the value returned by the method call and whether the play speed changes or not. OIPF-DAE,section 7.14.10.2: Following methods SHALL be supported: play() and stop(), as defined in Req. 5.7.1.f of [CEA-2014-A]. OIPF-DAE,section B: Boolean play(Number speed) - plays the media referenced by data, starting at the current play position denoted by playPosition, at the supported speed closest to the value of attribute speed. Negative speeds reverse playback. | |||
| org.hbbtv_DA541160 | 2 | Play with speed specified as -4x for DASH encoded clear content | The terminal shall play a DASH stream. In response to a request to play back at -4x normal speed, the terminal shall select and use an appropriate playback speed (less than or equal to -1) and the terminal shall dispatch a PlaySpeedChanged event, correctly reporting the actual playback speed. | 2024-1 2023-3 2023-2 2023-1 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,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section A.1: An onPlaySpeedChanged event shall be generated for all calls to the play() method regardless of the value returned by the method call and whether the play speed changes or not. OIPF-DAE,section 7.14.10.2: Following methods SHALL be supported: play() and stop(), as defined in Req. 5.7.1.f of [CEA-2014-A]. OIPF-DAE,section B: Boolean play(Number speed) - plays the media referenced by data, starting at the current play position denoted by playPosition, at the supported speed closest to the value of attribute speed. Negative speeds reverse playback. | |||
| org.hbbtv_DA541170 | 1 | Play with speed specified as 0.5x for DASH encoded clear content | The terminal shall play a DASH stream. In response to a request to play back at 0.5x normal speed, the terminal shall select and use an appropriate playback speed (less than or equal to 1, and greater than 0) and the terminal shall dispatch a PlaySpeedChanged event, correctly reporting the actual playback speed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2020-2 2020-1 2019-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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section A.1: An onPlaySpeedChanged event shall be generated for all calls to the play() method regardless of the value returned by the method call and whether the play speed changes or not. OIPF-DAE,section 7.14.10.2: Following methods SHALL be supported: play() and stop(), as defined in Req. 5.7.1.f of [CEA-2014-A]. OIPF-DAE,section B: Boolean play(Number speed) - plays the media referenced by data [...] at the supported speed closest to the value of attribute speed. Negative speeds reverse playback. [...] This method SHALL always return true. [...] A play speed event (see section 7.14.3.2 of the DAE specification) SHALL be generated when the operation has completed, regardless of the new play speed. If the play speed is not changed, the argument of the event SHALL be set to the previous play speed. | |||
| org.hbbtv_DA541180 | 1 | Play with speed specified as -0.5x for DASH encoded clear content | The terminal shall play a DASH stream. In response to a request to play back at -0.5x normal speed, the terminal shall select and use an appropriate playback speed (greater than or equal to -1, and less than 0) and the terminal shall dispatch a PlaySpeedChanged event, correctly reporting the actual playback speed. | 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-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section A.1: An onPlaySpeedChanged event shall be generated for all calls to the play() method regardless of the value returned by the method call and whether the play speed changes or not. OIPF-DAE,section 7.14.10.2: Following methods SHALL be supported: play() and stop(), as defined in Req. 5.7.1.f of [CEA-2014-A]. OIPF-DAE,section B: Boolean play(Number speed) - plays the media referenced by data [...] at the supported speed closest to the value of attribute speed. Negative speeds reverse playback. [...] This method SHALL always return true. [...] A play speed event (see section 7.14.3.2 of the DAE specification) SHALL be generated when the operation has completed, regardless of the new play speed. If the play speed is not changed, the argument of the event SHALL be set to the previous play speed. | |||
| org.hbbtv_DA541190 | 3 | Support for normal playback of DASH encoded clear content streamed over HTTP | Terminal shall correctly decode and display AV content from DASH stream delivered over HTTP | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 | |||
| org.hbbtv_DA541200 | 3 | Support for pausing DASH encoded clear content streamed over HTTP. | Terminal shall correctly pause playback of DASH video content streamed over HTTP when the "play" method of the A/V control object is called with 0 passed as the "speed" parameter. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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. OIPF-DAE,section 8.2.3.1: Method: play(0) [...] HTTP: The OITF SHALL pause playback. | |||
| org.hbbtv_DA541220 | 4 | AV Object Seeking (Forward 5s) in DASH encoded clear content streamed over HTTP | The terminal shall correctly seek to 5 seconds ahead of the current position in a DASH stream delivered over HTTP using the seek() method of the A/V control object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 8.2.3.1: seek( Integer pos ) HBBTV,section E.4.3: The terminal should not buffer more than data equivalent to approximately 300 seconds of normal play in advance of the current play position. | |||
| org.hbbtv_DA541230 | 4 | AV Object Seeking Outside Buffer (Forward 6 minutes) in DASH encoded clear content streamed over HTTP. | The terminal shall correctly seek to 6 minutes ahead of the current position in a DASH stream delivered over HTTP using the seek() method of the A/V control object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 8.2.3.1: seek( Integer pos ) HBBTV,section E.4.3: The terminal should not buffer more than data equivalent to approximately 300 seconds of normal play in advance of the current play position. | |||
| org.hbbtv_DA541240 | 4 | AV Object Seeking Within Buffer (Backward 5s) in DASH encoded clear content streamed over HTTP | The terminal shall correctly seek to 5 seconds before the current position in a DASH stream delivered over HTTP using the seek() method of the A/V control object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 8.2.3.1: seek( Integer pos ) HBBTV,section E.4.3: The terminal should not buffer more than data equivalent to approximately 300 seconds of normal play in advance of the current play position. | |||
| org.hbbtv_DA541250 | 5 | AV Object Seeking Outside Buffer (Backwards 60s) in DASH content streamed over HTTP. | The terminal shall correctly seek to 60 seconds before the current position in a DASH stream delivered over HTTP using the seek() method of the A/V control object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 8.2.3.1: seek( Integer pos ) HBBTV,section E.4.3: The terminal should not buffer more than data equivalent to approximately 300 seconds of normal play in advance of the current play position. | |||
| org.hbbtv_DA541500 | 1 | Support for trick mode Fast Forward for DASH encoded clear content with multiple representations | The terminal shall play a DASH stream defined by a static MPD which defines a single AdaptationSet for video, and a single AdaptationSet for audio. The audio AdaptationSet shall define one Representation, and the video AdaptationSet shall define three Representations, with bandwidths of 256000, 1500000 and 7500000 and @maxPlayoutRate elements set to 5, 3 and 2 respectively. In response to a request to play back at 4x normal speed the terminal shall select and use an appropriate playback speed (greater than or equal to 1) and the terminal shall dispatch a PlaySpeedChanged event correctly reporting the actual playback speed. | 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.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section A.1: An onPlaySpeedChanged event shall be generated for all calls to the play() method regardless of the value returned by the method call and whether the play speed changes or not. OIPF-DAE,section 7.14.10.2: Following methods SHALL be supported: play() and stop(), as defined in Req. 5.7.1.f of [CEA-2014-A]. OIPF-DAE,section B: Boolean play(Number speed) - plays the media referenced by data, starting at the current play position denoted by playPosition, at the supported speed closest to the value of attribute speed. Negative speeds reverse playback. | |||
| org.hbbtv_DA541510 | 1 | Support for trick mode Fast Rewind for DASH encoded clear content with multiple representations | The terminal shall play a DASH stream defined by a static MPD which defines a single AdaptationSet for video, and a single AdaptationSet for audio. The audio AdaptationSet shall define one Representation, and the video AdaptationSet shall define three Representations, with three different bandwidths and @maxPlayoutRate elements set to 5, 3 and 2 respectively. In response to a request to play back at -4x normal speed the terminal shall select and use an appropriate playback speed (less than or equal to -1) and the terminal shall dispatch a PlaySpeedChanged event correctly reporting the actual playback speed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2019-1 2018-2 2018-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section A.1: An onPlaySpeedChanged event shall be generated for all calls to the play() method regardless of the value returned by the method call and whether the play speed changes or not. OIPF-DAE,section 7.14.10.2: Following methods SHALL be supported: play() and stop(), as defined in Req. 5.7.1.f of [CEA-2014-A]. OIPF-DAE,section B: Boolean play(Number speed) - plays the media referenced by data, starting at the current play position denoted by playPosition, at the supported speed closest to the value of attribute speed. Negative speeds reverse playback. | ||
| org.hbbtv_DA541800 | 1 | 'language' property of the AVAudioComponent is 'und' if the audio component's 'lang' attribute in the MPD is not primary language subtag | If the MPD contains one video component and one audio component, and the audio component's 'lang' attribute is absent, then the value of the 'language' property of the corresponding AVComponent object shall be 'und' | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-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: The language property shall be set to the contents of the lang attribute in the MPD - even when this is not a valid ISO 639-2 language code. The contents of the language field in the media header "mdhd" of the track shall be ignored. NOTE: MPEG DASH requires the lang attribute to comply with RFC5646 which gives preference to ISO 639-1 2-character language codes above ISO 639-2 3-character language codes where both are defined for a language HBBTV,section A1: 7.16.5 | M(*) | ... The value of the language property shall be either an ISO 639-1 [60] 2-character language code or an ISO 639-2 [61] 3-character language code as defined by clause 8.4.2 of the OIPF DAE specification1 as modified in the present document. | |||
| org.hbbtv_DA541820 | 1 | MPD schema validation error | If the A/V Control object's 'data' attribute is set to an MPD containing one <Representation> element, and the MPD / associated A/V content are otherwise valid except that the <Representation> element does not have a @bandwidth attribute, after the play() method is called on the A/V Control object the A/V Control object shall go to play state 6 (error) with an error code of 4 (content corrupt or invalid) | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_DA541830 | 1 | AVComponent's componentTag property is equal to the adaptation sets @id property | If the A/V Control object's 'data' attribute is set to an MPD containing both video and audio adaptation sets and the corresponding <AdaptationSet> element has an @id attribute with the value '123' for audio and '11' for video, then the 'componentTag' property of the associated AVComponent instance shall be a number of the given value. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The componentTag shall be the value of the id attribute on the Adaptation Set (if provided). | |||
| org.hbbtv_DA541840 | 1 | AVAudioComponent 'language' property on the 'mdhd' of the audio track is ignored | If the MPD contains one video component and one audio component where the audio component's 'lang' attribute contains a valid language code - 'eng' according to ISO 639-2 -- and the 'mdhd' of the audio track contains the ISO-639-2 language code 'deu', then the value of the 'language' property of the corresponding AVComponent object shall be 'eng'. | 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.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 9.4: The value of the language property shall be either an ISO 639-1 [60] 2-character language code or an ISO 639-2 [61] 3-character language code as defined by clause 8.4.2 of the OIPF DAE specification [1] as modified in the present document. OIPF-DAE,section 7.16.5.1.3: AVComponentCollection getComponents( Integer componentType ) [...] For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state and MAY be known if the object is in other states. OIPF-DAE,section 8.4.2: Defined by the value of the ‘@lang’ attribute in the MPD, whether set explicitly or inherited. The contents of the language field in the ‘mdhd” of the track SHALL be ignored. | |||
| org.hbbtv_DA541850 | 1 | <AdaptationSet> element with Role@value of 'main' - Lower element position | If an MPD contains 1 period containing 2 video adaptation sets, and each adaptation set has a corresponding <AdaptationSet> element, namely [1] and [2]. If [1] appears above [2] in the XML document, but [2] contains a <Role> element where its @value attribute has a value of 'main', then the video referenced by [2] shall be presented | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 E.2.2: Similarly if there is more than one audio Adaptation Set, exactly one shall be labelled with a Role@value of "main" to allow the terminal to identify the default adaptation set. There shall be at least one video Adaptation Set per Period in an MPD. | |||
| org.hbbtv_DA541860 | 1 | <AdaptationSet> element with Role@value of 'main' - Higher @id attribute | If an MPD contains 1 period containing 2 video adaptation sets, and each adaptation set has a corresponding <AdaptationSet> element, namely [1] and [2]. If [1] has an @id attribute with a value of '2' and a <Role> element where its @value attribute has a value of 'main', and [2] has an @id attribute with a value of '1' but no <Role> element, then the video referenced by [1] shall be presented | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 E.2.2: Similarly if there is more than one audio Adaptation Set, exactly one shall be labelled with a Role@value of "main" to allow the terminal to identify the default adaptation set. There shall be at least one video Adaptation Set per Period in an MPD. | |||
| org.hbbtv_DA541870 | 1 | DASH MPD with Multiple Profiles | The terminal shall be able to present a DASH stream where the MPD contains 2 valid adaptation sets in which the 1st adaptation set uses a profile mandated by the DASH specification but not the HbbTV specification and the 2nd adaptation set uses the 'urn:hbbtv:dash:profile:isoff-live:2012' profile | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 E.2.1: Terminals shall be able to play the content described by the profile-specific MPD (as defined in section 8.1 of DASH [29]) (but not necessarily other Adaptation Sets or Representations in the MPD discarded as part of the process of deriving the profile-specific MPD). | |||
| org.hbbtv_DA541880 | 1 | DASH - AVC_SD_25 | The terminal shall be able to present DASH content from an MPD containing one video component that uses AVC_SD_25 encoded segments | 2024-1 2023-3 2023-2 2023-1 2022-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.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section E.2.1: Terminals shall be able to play the content described by the profile-specific MPD (as defined in section 8.1 of DASH [29]) (but not necessarily other Adaptation Sets or Representations in the MPD discarded as part of the process of deriving the profile-specific MPD). | |||
| org.hbbtv_DA541890 | 1 | DASH - AVC_HD_25 | The terminal shall be able to present DASH content from an MPD containing one video component that uses AVC_HD_25 encoded segments | 2024-1 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 E.2.1: Terminals shall be able to play the content described by the profile-specific MPD (as defined in section 8.1 of DASH [29]) (but not necessarily other Adaptation Sets or Representations in the MPD discarded as part of the process of deriving the profile-specific MPD). | |||
| org.hbbtv_DASH_PROFILES0010 | 1 | MPD: DASH-IF not supported | The src of an HTML5 video element points to a DASH MPD where the @profiles indicates only "http://dashif.org/guidelines/dash264". The MPD is rejected and a MEDIA_ERR_SRC_NOT_SUPPORTED error is generated. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: The following rules apply for MPDs that do not list either or both of "urn:hbbtv:dash:profile:isoff-live:2012" or "urn:dvb:dash:profile:dvb-dash:2014" in their MPD @profiles attribute; .... • MPDs specified with the URNs defined for the interoperability points defined in the DASH-IF guidelines [i. 19] shall be rejected by HbbTV terminals that do not support the specified inter-operability point. | -DASHIF | ||
| org.hbbtv_DASH_PROFILES0020 | 1 | MPD: Non-standard HbbTV profile not supported | The src of an HTML5 video element points to a DASH MPD where the @profiles indicates only "urn:hbbtv:dash:profile:isoff-live:2013". The MPD is rejected and a MEDIA_ERR_SRC_NOT_SUPPORTED error is generated. | 2024-1 2023-3 2023-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-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: The following rules apply for MPDs that do not list either or both of "urn:hbbtv:dash:profile:isoff-live:2012" or "urn:dvb:dash:profile:dvb-dash:2014" in their MPD @profiles atttribute; .... • MPDs specified with profiles beginning "urn:hbbtv:dash:profile" shall be rejected unless that profile is defined in a later version of the present document and the HbbTV terminal supports the specified profile. TS-103-285,section 4.1: The URN for the profile (MPEG Interoperability Point) shall be "urn:dvb:dash:profile:dvb-dash:2014". | |||
| org.hbbtv_DASH_PROFILES0030 | 1 | MPD: Non-standard DVB profile not supported | The src of an HTML5 video element points to a DASH MPD where the @profiles indicates only "urn:dvb:dash:profile:dvb-dash:2015". The MPD is rejected and a MEDIA_ERR_SRC_NOT_SUPPORTED error is generated. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: The following rules apply for MPDs that do not list either or both of "urn:hbbtv:dash:profile:isoff-live:2012" or "urn:dvb:dash:profile:dvb-dash:2014" in their MPD @profiles atttribute; .... • MPDs specified with profiles beginning "urn:dvb:dash:profile” shall be rejected unless that profile is defined in a later version of the DVB-DASH specification than V1.1.1.[ 45] and the HbbTV terminal supports the specified profile. | |||
| org.hbbtv_DASH_PROFILES0050 | 1 | AdaptationSet: DASH-IF not supported | The src of an HTML5 video element points to a DASH MPD where the @profiles indicates "http://dashif.org/guidelines/dash264", "urn:dvb:dash:profile:dvb-dash:2014" and "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014". The MPD includes Video, Audio and subtitle Adaptation Sets with @profiles "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014", Video, Audio and subtitle Adaptation Sets with @profiles "http://dashif.org/guidelines/dash264" and Video, Audio and subtitle Adaptation Sets with both of these. When the load() method is called, no VideoTrack, AudioTrack or TextTrack objects are created for the Adaptation Sets where @profiles only contains "http://dashif.org/guidelines/dash264". | 2024-1 2023-3 2023-2 2023-1 2022-3 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 E.4.1: The following rules apply for Adaptation Sets and/or Representations that are not indicated as conforming to at least one of the "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" or "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" profiles: • Adaptation Sets or Representations indicated as being compliant with one or more of the interoperability points in the DASH-IF interoperability guidelines [i.19] shall be ignored by HbbTV terminals that do not support that inter-operability point. | -DASHIF | ||
| org.hbbtv_DASH_PROFILES0060 | 1 | Adaptation Set: Non-standard HbbTV not supported | The src of an HTML5 video element points to a DASH MPD where the @profiles indicates "urn:hbbtv:dash:profile:isoff-live:2013", "urn:dvb:dash:profile:dvb-dash:2014" and "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014". The MPD includes Video, Audio and subtitle Adaptation Sets with @profiles "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014", Video, Audio and subtitle Adaptation Sets with @profiles "urn:hbbtv:dash:profile:isoff-live:2013" and Video, Audio and subtitle Adaptation Sets with both of these. When the load() method is called, no VideoTrack, AudioTrack or TextTrack objects are created for the Adaptation Sets where @profiles only contains "urn:hbbtv:dash:profile:isoff-live:2013". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 E.4.1: The following rules apply for Adaptation Sets and/or Representations that are not indicated as conforming to at least one of the "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" or "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" profiles: ....... • Adaptation Sets or Representations indicated as being compliant with profiles beginning "urn:hbbtv:dash:profile" shall be ignored unless the indicated profile is defined in a later version of the present document and the HbbTV terminal supports that profile. | |||
| org.hbbtv_DASH_PROFILES0070 | 1 | Adaptation Set: Non-standard DVB not supported | The src of an HTML5 video element points to a DASH MPD where the @profiles indicates "urn:dvb:dash:profile:dvb-dash:2015", "urn:dvb:dash:profile:dvb-dash:2014" and "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014". The MPD includes Video, Audio and subtitle Adaptation Sets with @profiles "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014", Video, Audio and subtitle Adaptation Sets with @profiles "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2015" and Video, Audio and subtitle Adaptation Sets with both of these. When the load() method is called, no VideoTrack, AudioTrack or TextTrack objects are created for the Adaptation Sets where @profiles only contains "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2015". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 E.4.1: The following rules apply for Adaptation Sets and/or Representations that are not indicated as conforming to at least one of the "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" or "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" profiles: ....... • Adaptation Sets or Representations indicated as being compliant with profiles beginning "urn:dvb:dash:profile” shall be ignored unless the indicated profile is defined in a later version of the DVB-DASH specification than V1.1.1.[ 45] and the HbbTV terminal supports the indicated profile. • Where the MPD @profiles attribute includes either or both of "urn:hbbtv:dash:profile:isoff-live:2012" or "urn:dvb:dash:profile:dvb-dash:2014" as well as some other profile, AdaptationSets and Representations not inferred to have a @profiles attribute that includes one of "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014", "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" shall be ignored by HbbTV terminals that support only the DVB DASH profile [45]. TS-103-285,section 4.2.5: Representations not inferred to have an @profiles attribute equal to "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" may be ignored. | |||
| org.hbbtv_DASH_PROFILES0080 | 1 | Adaptation Set: rejection of non-supported profile | The src of an HTML5 video element points to a DASH MPD where the @profiles indicates "urn:example:future-dash-profile", "urn:dvb:dash:profile:dvb-dash:2014" and "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014". The MPD includes Video, Audio and subtitle Adaptation Sets with @profiles "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014", Video, Audio and subtitle Adaptation Sets with @profiles "urn:example:future-dash-profile" and Video, Audio and subtitle Adaptation Sets with both of these. When the load() method is called, no VideoTrack, AudioTrack or TextTrack objects are created for the Adaptation Sets where @profiles only contains "urn:example:future-dash-profile". | 2024-1 2023-3 2023-2 2023-1 2022-3 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 E.4.1: The following rules apply for Adaptation Sets and/or Representations that are not indicated as conforming to at least one of the "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" or "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" profiles: ....... • Where the MPD @profiles attribute includes either or both of "urn:hbbtv:dash:profile:isoff-live:2012" or "urn:dvb:dash:profile:dvb-dash:2014" as well as some other profile, AdaptationSets and Representations not inferred to have a @profiles attribute that includes one of "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014", "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" shall be ignored by HbbTV terminals that support only the DVB DASH profile [45]. | |||
| org.hbbtv_DASH_PROFILES0100 | 1 | Representation: DASH-IF not supported | The src of an HTML5 video element points to a DASH MPD where the @profiles indicates "http://dashif.org/guidelines/dash264", "urn:dvb:dash:profile:dvb-dash:2014" and "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014". The MPD includes one each of Video, Audio and subtitle Adaptation Sets with no @profiles element. Each Adaptation Set includes one or more Representations with @profiles set to "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014", one or more Representations with @profiles set to "http://dashif.org/guidelines/dash264" and one or more representations with @profiles set to both of these. When the play method is called on the video element, no segments for Representations with @profiles set only to "http://dashif.org/guidelines/dash264" are requested by the terminal". | 2024-1 2023-3 2023-2 2023-1 2022-3 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 E.4.1: The following rules apply for Adaptation Sets and/or Representations that are not indicated as conforming to at least one of the "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" or "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" profiles: • Adaptation Sets or Representations indicated as being compliant with one or more of the interoperability points in the DASH-IF interoperability guidelines [i.19] shall be ignored by HbbTV terminals that do not support that inter-operability point. | -DASHIF | ||
| org.hbbtv_DASH_PROFILES0110 | 1 | Representation: Non-standard HbbTV not supported | The src of an HTML5 video element points to a DASH MPD where the @profiles indicates "urn:hbbtv:dash:profile:isoff-live:2013", "urn:dvb:dash:profile:dvb-dash:2014" and "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014". The MPD includes one each of Video, Audio and subtitle Adaptation Sets with no @profiles element. Each Adaptation Set includes one or more Representations with @profiles set to "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014", one or more Representations with @profiles set to "urn:hbbtv:dash:profile:isoff-live:2013" and one or more representations with @profiles set to both of these. When the play method is called on the video element, no segments for Representations with @profiles set only to "urn:hbbtv:dash:profile:isoff-live:2013" are requested by the terminal. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 E.4.1: The following rules apply for Adaptation Sets and/or Representations that are not indicated as conforming to at least one of the "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" or "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" profiles: ....... • Adaptation Sets or Representations indicated as being compliant with profiles beginning "urn:hbbtv:dash:profile" shall be ignored unless the indicated profile is defined in a later version of the present document and the HbbTV terminal supports that profile. | |||
| org.hbbtv_DASH_PROFILES0120 | 1 | Representation: Non-standard DVB not supported | The src of an HTML5 video element points to a DASH MPD where the @profiles indicates "urn:dvb:dash:profile:dvb-dash:2014", "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" and "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2015". The MPD includes one each of Video, Audio and subtitle Adaptation Sets with no @profiles element. Each Adaptation Set includes one or more Representations with @profiles set to "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014", one or more Representations with @profiles set to "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2015" and one or more representations with @profiles set to both of these. When the play method is called on the video element, no segments for Representations with @profiles set only to "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2015" are requested by the terminal. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 E.4.1: The following rules apply for Adaptation Sets and/or Representations that are not indicated as conforming to at least one of the "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" or "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" profiles: ....... • Adaptation Sets or Representations indicated as being compliant with profiles beginning "urn:dvb:dash:profile” shall be ignored unless the indicated profile is defined in a later version of the DVB-DASH specification than V1.1.1.[ 45] and the HbbTV terminal supports the indicated profile. • Where the MPD @profiles attribute includes either or both of "urn:hbbtv:dash:profile:isoff-live:2012" or "urn:dvb:dash:profile:dvb-dash:2014" as well as some other profile, AdaptationSets and Representations not inferred to have a @profiles attribute that includes one of "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014", "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" shall be ignored by HbbTV terminals that support only the DVB DASH profile [45]. TS-103-285,section 4.2.5: Representations not inferred to have an @profiles attribute equal to "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" may be ignored. | |||
| org.hbbtv_DASH_PROFILES0130 | 1 | Representation: rejection of non-supported profile | The src of an HTML5 video element points to a DASH MPD where the @profiles indicates "urn:example:future-dash-profile", "urn:dvb:dash:profile:dvb-dash:2014" and "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014". The MPD includes one each of Video, Audio and subtitle Adaptation Sets with no @profiles element. Each Adaptation Set includes one or more Representations with @profiles set to "urn:example:future-dash-profile", one or more Representations with @profiles set to "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" and one or more Representations with @profiles set to both of these. When the play method is called on the video element, no segments for Representations with @profiles set only to "urn:example:future-dash-profile" are requested by the terminal. | 2024-1 2023-3 2023-2 2023-1 2022-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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: The following rules apply for Adaptation Sets and/or Representations that are not indicated as conforming to at least one of the "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" or "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" profiles: ....... • Where the MPD @profiles attribute includes either or both of "urn:hbbtv:dash:profile:isoff-live:2012" or "urn:dvb:dash:profile:dvb-dash:2014" as well as some other profile, AdaptationSets and Representations not inferred to have a @profiles attribute that includes one of "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014", "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" or "urn:hbbtv:dash:profile:isoff-live:2012" shall be ignored by HbbTV terminals that support only the DVB DASH profile [45]. TS-103-285,section 4.2.5: Representations not inferred to have an @profiles attribute equal to "urn:dvb:dash:profile:dvb-dash:isoff-ext-live:2014" may be ignored. | |||
| org.hbbtv_DASH-131_0010 | 1 | Segments greater than 960ms | The terminal shall play back, without artefacts or glitches, using an HTML5 video element, a stream defined in a dynamic DVB-DASH MPD in which HE-AAC audio and AVC video are encoded in segments 960 milliseconds in duration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 4.2.10: The reference to DVB-DASH / TS 103 285 is changed from 1.2.1 to 1.3.1 HBBTV,section 2.1: [45] ETSI TS 103 285 V1.3.1: "Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks". HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. TS-103-285,section 4.5: It is mandatory that: Segment duration shall be at least 960 ms, except for the last segment of a Period which may be shorter. | |||
| org.hbbtv_DASH-131_0110 | 1 | Multiple moof / mdat boxes per DASH segment - adaptation | When the available bandwidth becomes unrestricted, the device shall smoothly transition from an AVC representation with multiple moof / mdat boxes per DASH media segment whose bandwidth is below the restriction to a representation that is identical except for the bandwidth being above the restriction and the resolution being higher. The codecs being AVC and HE-AAC respectively. The moof / mdat pairs being evenly distributed through the part of the media timeline occupied by the DASH media segment. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-2 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 4.2.10: The reference to DVB-DASH / TS 103 285 is changed from 1.2.1 to 1.3.1 HBBTV,section 2.1: [45] ETSI TS 103 285 V1.3.1: "Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks". HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. TS-103-285,section 4.3: As stated in clause 6.3.4.2 of ISO/IEC 23009-1 [1], media segments may contain more than one pair of 'moof' and 'mdat' boxes. For example, a video segment may have one moof/mdat pair for each individual video frame, or it may have all frames covered by a single moof/mdat pair, or it may have an intermediate number of frames covered by each of a number of moof/mdat pairs in the segment. Similarly, an audio segment may have one moof/mdat pair for each ISOBMFF audio sample or it may have all ISOBMFF audio samples covered by a single moof/mdat pair, or it may have an intermediate number of samples covered by each of a number of moof/mdat pairs in the segment. 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 DASH,section 6.3.4.2: Each Media Segment shall contain one or more whole self-contained movie fragments. A whole, self-contained movie fragment is a movie fragment (‘moof’) box and a media data (‘mdat’) box that contains all the media samples that do not use external data references referenced by the track runs in the movie fragment box. | |||
| org.hbbtv_DASH-131_0120 | 1 | Multiple moof / mdat boxes per DASH segment - EME clearkey | The terminal is able to play, without artefacts or glitches, using an HTML5 video element, linearly from beginning to end, a DASH stream where the AVC video and HE-AAC audio representations have multiple moof / mdat boxes per DASH media segment and are encrypted using CENC with keys delivered using EME clearkey. | 2024-1 2023-3 2023-2 2023-1 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 4.2.10: The reference to DVB-DASH / TS 103 285 is changed from 1.2.1 to 1.3.1 HBBTV,section 2.1: [45] ETSI TS 103 285 V1.3.1: "Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks". HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. TS-103-285,section 4.3: As stated in clause 6.3.4.2 of ISO/IEC 23009-1 [1], media segments may contain more than one pair of 'moof' and 'mdat' boxes. For example, a video segment may have one moof/mdat pair for each individual video frame, or it may have all frames covered by a single moof/mdat pair, or it may have an intermediate number of frames covered by each of a number of moof/mdat pairs in the segment. Similarly, an audio segment may have one moof/mdat pair for each ISOBMFF audio sample or it may have all ISOBMFF audio samples covered by a single moof/mdat pair, or it may have an intermediate number of samples covered by each of a number of moof/mdat pairs in the segment. HBBTV,section A.3.11: The W3C encrypted media extensions API [66] shall be supported for encrypted content delivered via broadband as defined in clause B.3 of the present document. Use of this API with a DRM system is outside the scope of the present document. DASH,section 6.3.4.2: Each Media Segment shall contain one or more whole self-contained movie fragments. A whole, self-contained movie fragment is a movie fragment (‘moof’) box and a media data (‘mdat’) box that contains all the media samples that do not use external data references referenced by the track runs in the movie fragment box. | |||
| org.hbbtv_DASH-131_0130 | 1 | Multiple moof / mdat boxes per DASH segment for video but not for audio | The terminal is able to play without artefacts or glitches, using an HTML5 video element, linearly from beginning to end, a DASH stream where AVC video representations have multiple moof / mdat boxes per DASH media segment and HE-AAC audio representations have one moof / mdat box per DASH media segment. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 4.2.10: The reference to DVB-DASH / TS 103 285 is changed from 1.2.1 to 1.3.1 HBBTV,section 2.1: [45] ETSI TS 103 285 V1.3.1: "Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks". HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. TS-103-285,section 4.3: As stated in clause 6.3.4.2 of ISO/IEC 23009-1 [1], media segments may contain more than one pair of 'moof' and 'mdat' boxes. For example, a video segment may have one moof/mdat pair for each individual video frame, or it may have all frames covered by a single moof/mdat pair, or it may have an intermediate number of frames covered by each of a number of moof/mdat pairs in the segment. Similarly, an audio segment may have one moof/mdat pair for each ISOBMFF audio sample or it may have all ISOBMFF audio samples covered by a single moof/mdat pair, or it may have an intermediate number of samples covered by each of a number of moof/mdat pairs in the segment. DASH,section 6.3.4.2: Each Media Segment shall contain one or more whole self-contained movie fragments. A whole, self-contained movie fragment is a movie fragment (‘moof’) box and a media data (‘mdat’) box that contains all the media samples that do not use external data references referenced by the track runs in the movie fragment box. TS-103-285,section 10.2: • When playing more than one AdaptationSet simultaneously (e.g. one video AdaptationSet, one audio AdaptationSet and one subtitle AdaptationSet), players shall be able to play combinations for which the segments of one AdaptationSet do not align with the segments of another (e.g. due to differing segment durations) or the segments of one Adaptation Set contain multiple moof/mdat pairs and the segments of another only have a single moof/mdat pair. | |||
| org.hbbtv_DASH-131_0300 | 1 | Adaptation sets have different segment lengths | The terminal shall play back, without artefacts or glitches, using an HTML5 video element, a stream defined in a static MPD where AVC video, HE-AAC audio and subtitle representations all have different segment lengths (that are not integer multiples of each-other). | 2024-1 2023-3 2023-2 2023-1 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 4.2.10: The reference to DVB-DASH / TS 103 285 is changed from 1.2.1 to 1.3.1 HBBTV,section 2.1: [45] ETSI TS 103 285 V1.3.1: "Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks". HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. TS-103-285,section 4.3: When playing more than one AdaptationSet simultaneously (e.g. one video AdaptationSet, one audio AdaptationSet and one subtitle AdaptationSet), players shall be able to play combinations for which the segments of one AdaptationSet do not align with the segments of another (e.g. due to differing segment durations) or the segments of one Adaptation Set contain multiple moof/mdat pairs and the segments of another only have a single moof/mdat pair. TS-103-285,section 10.2: - | |||
| org.hbbtv_DASH-131_0400 | 1 | Maximum poll rate for dynamic MPDs | While playing, using an HTML5 video element, a stream defined using a dynamic MPD with HE-AAC audio and AVC video with 8s video segments, 1s audio segments and minimumUpdatePeriod of 1 minute, the terminal does not poll for MPD updates more frequently than an interval of 44 seconds. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 4.2.10: The reference to DVB-DASH / TS 103 285 is changed from 1.2.1 to 1.3.1 HBBTV,section 2.1: [45] ETSI TS 103 285 V1.3.1: "Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks". HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. TS-103-285,section 4.3: When playing an MPEG DASH presentation using a dynamic MPD for which minimumUpdatePeriod is defined and there is no InbandEventStream carrying MPD expiration events (see clause 9.1.4), DASH players should request updated MPDs at the minimum rate necessary for correct operation (see clause A.2 of ISO/IEC 23009-1 [1] for guidance). In any event, during normal playback of such a DASH presentation, DASH players shall not poll for a new MPD at an interval shorter than that defined by MPD@minimumUpdatePeriod less twice the longest segment duration described by the MPD. TS-103-285,section 10.9.5: - | |||
| org.hbbtv_DASH-131_0500 | 1 | Unknown essential property descriptor | While playing, using an HTML5 video element, a stream defined using a static MPD with 3 AVC video and 3 HE-AAC audio Adaptation Sets where the first and last of each Adaptation Set in the order found in the MPD have an Essential Property descriptor with schemeIdURI "urn:hbbtv:testing:dash:notToBeSupported", the Adaptation Sets with the EssentialProperty descriptor shall not be played by the terminal as a result of component selection by the terminal. Attempts to play those Adaptation Sets by the application shall fail. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 4.2.10: The reference to DVB-DASH / TS 103 285 is changed from 1.2.1 to 1.3.1 HBBTV,section 2.1: [45] ETSI TS 103 285 V1.3.1: "Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks". HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. TS-103-285,section 4.3: Players shall be able to process correctly any EssentialProperty or SupplementalProperty descriptors present within the MPD element, as permitted by ISO/IEC 23009-1 [1]. TS-103-285,section 10.10: Players shall ignore a parent element if the scheme or the value for the EssentialProperty child element is not recognized by the Player (as suggested by the note in ISO/IEC 23009-1 [1], clause 5.8.4.8). DASH,section 5.8.4.8: For the element EssentialProperty the Media Presentation author expresses that the successful processing of the descriptor is essential to properly use the information in the parent element that contains this descriptor unless the element shares the same @id with another EssentialProperty element. | |||
| org.hbbtv_DASH-131_0510 | 1 | Unknown essential property descriptor - @id | When play() is called on an HTMLVideoElement with its 'src' set to the absolute URL of an MPD referencing HEVC_UHD_25 / HLG10 video and HE-AAC audio with the HLG10 Adaptation Set having 1) an EssentialProperty descriptor with i) @schemeIdUri = "urn:mpeg:mpegB:cicp:ColourPrimaries", ii) @value="9" and iii) an @id attribute of "100" and 2) an EssentialProperty descriptor with i) @schemeIdURI = "urn:hbbtv:testing:dash:notToBeSupported" and ii) an @id attribute of "100"; the video and audio are played from beginning to end. | 2024-1 2023-3 2023-2 2021-2 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 4.2.10: The reference to DVB-DASH / TS 103 285 is changed from 1.2.1 to 1.3.1 HBBTV,section 2.1: [45] ETSI TS 103 285 V1.3.1: "Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks". HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. TS-103-285,section 4.3: Players shall be able to process correctly any EssentialProperty or SupplementalProperty descriptors present within the MPD element, as permitted by ISO/IEC 23009-1 [1]. TS-103-285,section 10.10: Players shall ignore a parent element if the scheme or the value for the EssentialProperty child element is not recognized by the Player (as suggested by the note in ISO/IEC 23009-1 [1], clause 5.8.4.8). DASH,section 5.8.4.8: For the element EssentialProperty the Media Presentation author expresses that the successful processing of the descriptor is essential to properly use the information in the parent element that contains this descriptor unless the element shares the same @id with another EssentialProperty element. If EssentialProperty elements share the same @id, then processing one of the EssentialProperty elements with the same value for @id is sufficient. At least one EssentialProperty element of each distinct @id value is expected to be processed. TS-103-285,section 5.2.6: Except where a DASH MPD is intended for use only with players already known to support BT.2020, use of HLG10 within an AdaptationSet shall be signalled as follows: • MPD and AdaptationSet profile signalling in accordance with clause 4.1 indicating urn:dvb:dash:profile:dvbdash:2017 • An EssentialProperty descriptor with @schemeIdUri = "urn:mpeg:mpegB:cicp:ColourPrimaries" and @value="9" | +HLG10 | ||
| org.hbbtv_DASH-131_0600 | 1 | Non LL-DASH player behaviour, availabilityTimeComplete attribute set to false | When playing content, using an HTML5 video element, described by a dynamic MPD where video (AVC) and audio (HE-AAC) representations with SegmentTemplate@availabilityTimeOffset set and SegmentTemplate@availabilityTimeComplete="false", the terminal does not request any segment until the complete segment becomes available. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 HBBTV 1.7.1 | HBBTV,section 4.2.10: The reference to DVB-DASH / TS 103 285 is changed from 1.2.1 to 1.3.1 HBBTV,section 2.1: [45] ETSI TS 103 285 V1.3.1: "Digital Video Broadcasting (DVB); MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks". HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. TS-103-285,section 10.17: Players not supporting low latency presentation shall ignore any SegmentTemplate @availabilityTimeOffset attribute for which there is a corresponding SegmentTemplate @availabilityTimeComplete attribute set to "false". TS-103-285,section 4.2.9: Low latency content using chunked segments (see clause11.18.1) that are available to players before they are complete is signalled using the SegmentTemplate@availabilityTimeOffset attribute in combination with the SegmentTemplate@availabilityTimeComplete attribute set to "false". NOTE: The similarly named BaseURL@availabilityTimeOffset and BaseURL@availabilityTimeComplete attributes are not used for the purposes of low latency live streaming. • The value of SegmentTemplate@availabilityTimeOffset shall not exceed the segment duration given by SegmentTemplate@duration divided by the value of appropriate @timescale attribute. EXAMPLE: An AdaptationSet using 3,84 second media segments with a 960 ms chunk duration would typically be signalled with SegmentTemplate@availabilityTimeOffset="2,88" and SegmentTemplate@availabilityTimeComplete="false". These attributes taken together convey the semantics that an incomplete segment starts to become available 2,88 seconds prior to its segment availability time. DASH,section 5.3.9.5.3: If the @availabilityTimeOffset attribute is present for a Representation in the Segment Information or the BaseURL element, then the parameter availabilityTimeOffset is determined as the sum of all values of @availabilityTimeOffset on all levels that are processed in determining the URL for the corresponding segment. Then the adjusted segment availability start time is determined by subtracting the value of availabilityTimeOffset from the Segment availability start time. This adjusted segment availability start time provides a time instant in wall-clock time at which a Segment becomes an available Segment. If the @availabilityTimeComplete flag is set to true for such a Representation on any level, then the entire Segment may not yet be available at the adjusted segment availability start time. | -DVB_LL_DASH | ||
| org.hbbtv_DASH-131-EVENTS0010 | 1 | MPD events with XML in other namespaces | The terminal is able to play, using an HTML5 video element, linearly from beginning to end, a DASH stream where the MPD contains 1) an AVC video Adaption Set, 2) an HE-AAC audio AdaptationSet and 3) DASH Event elements containing child XML elements in other namespaces - specifically SCTE35. | 2024-1 2023-3 2023-2 2023-1 2021-2 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. HBBTV,section 9.3.2.2: A TextTrack shall be provided for each event stream signalled in the MPD as defined in clause 5.10.2 of MPEG DASH ISO/IEC 23009-1 [29]excluding DASH-specific events as defined in clause 5.10.4 of MPEG DASH ISO/IEC 23009-1 [29] and excluding events streams defined by the DVB DASH specification [45] to be consumed by the terminal. .... DASH events shall be reported to applications as DataCues according to the following mapping: Id @id Id startTime @presentationTime (scaled according to the EventStream @timescale attribute) + the time offset of the start of the period from the start of the presentation. endTime The startTime + @duration, subject to the minimum duration requirements below. If the @duration attribute is not specified, endTime shall be set to Number.MAX_VALUE. .... data The string value of the <Event> element. DASH,section 5.10.2.3: <!-- Event --> <xs:complexType name="EventType"> <xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="presentationTime" type="xs:unsignedLong" default="0"/> <xs:attribute name="duration" type="xs:unsignedLong"/> <xs:attribute name="id" type="xs:unsignedInt"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> DASH,section 5.10.2.3: <!-- Event --> <xs:complexType name="EventType" mixed="true"> <xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="presentationTime" type="xs:unsignedLong" default="0"/> <xs:attribute name="duration" type="xs:unsignedLong"/> <xs:attribute name="id" type="xs:unsignedInt"/> <xs:attribute name="contentEncoding" type="ContentEncodingType"/> <xs:attribute name="messageData" type="xs:string"> <xs:annotation> <xs:documentation> Deprecated in favor of carrying the message information in the value space of the event </xs:documentation> </xs:annotation> </xs:attribute> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> | |||
| org.hbbtv_DASH-131-EVENTS0020 | 1 | MPD events with optional XML attributes absent - @presentationTime, @duration | The terminal is able to play, using an HTML5 video element, linearly from beginning to end, a DASH stream where the MPD contains 1) an AVC video Adaptation Set, 2) an HE-AAC audio Adaptation Set and 3) DASH Event elements where the optional @presentationTime and @duration attributes of the Event element are not present. When @presentationTime is absent, the DataCue generated has a startTime that is the time offset of the start of the period from the start of the presentation. When @duration is absent, the DataCue generated has endTime that is Number.MAX_VALUE. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-2 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section E.4.1: Terminals shall support the 2014 profile from the DVB DASH specification [45] as modified in the present document. HBBTV,section 9.3.2.2: A TextTrack shall be provided for each event stream signalled in the MPD as defined in clause 5.10.2 of MPEG DASH ISO/IEC 23009-1 [29]excluding DASH-specific events as defined in clause 5.10.4 of MPEG DASH ISO/IEC 23009-1 [29] and excluding events streams defined by the DVB DASH specification [45] to be consumed by the terminal. .... DASH events shall be reported to applications as DataCues according to the following mapping: Id @id Id startTime @presentationTime (scaled according to the EventStream @timescale attribute) + the time offset of the start of the period from the start of the presentation. endTime The startTime + @duration, subject to the minimum duration requirements below. If the @duration attribute is not specified, endTime shall be set to Number.MAX_VALUE. .... data The string value of the <Event> element. DASH,section 5.10.2.2: @presentationTime OD specifies the presentation time of the event relative to the start of the Period. The value of the presentation time in seconds is the division of the value of this attribute and the value of the @timescale attribute. If not present, the value of the presentation time is 0. @presentationTime OD default: 0 specifies the presentation time of the event relative to the start of the Period. The value of the presentation time in seconds is the division of the value of this attribute and the value of the @timescale attribute. If not present, the value of the presentation time is 0. .... @duration O specifies the presentation duration of the event. The value of the duration in seconds is the division of the value of this attribute and the value of the @timescale attribute. If not present, the value of the duration is unknown. .... For attributes: M=Mandatory, O=Optional, OD=Optional with Default Value, CM=Conditionally Mandatory. | |||
| org.hbbtv_DASH-131-EVENTS0030 | 1 | MPD events with optional XML attributes absent - @id | The terminal is able to play, using an HTML5 video element, linearly from beginning to end, a DASH stream where the MPD contains 1) an AVC video Adaptation Set, 2) an HE-AAC audio Adaptation Set and 3) more than one DASH Event element where the optional @id attribute of the Event element is absent. DataCues are generated for all MPD events. The DataCue has @id being an empty string. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-2 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 9.3.2.2: A TextTrack shall be provided for each event stream signalled in the MPD as defined in clause 5.10.2 of MPEG DASH ISO/IEC 23009-1 [29] excluding DASH-specific events as defined in clause 5.10.4 of MPEG DASH ISO/IEC 23009-1 [29] and excluding event streams defined by the DVB DASH specification [45] to be consumed by the terminal. .... DASH events shall be reported to applications as DataCues according to the following mapping: Id @id If the @id attribute is not specified, id shall be set to an empty string. With reference to clause 9.1.5 of DVB-DASH, events without a value of @id specified shall not be considered as repetitions of the same event. HBBTV,section 4.7.9: DASH events shall be reported to applications as DataCues according to the following mapping: Id @id. If the @id attribute is not specified, id shall be set to an empty string. With reference to clause 9.1.5 of DVB-DASH, events without a value of @id specified shall not be considered as repetitions of the same event. DASH,section 5.10.2.2: @id O specifies an identifier for this instance of the event. Events with equivalent content and attribute values in the Event element shall have the same value for this attribute. .... For attributes: M=Mandatory, O=Optional, OD=Optional with Default Value, CM=Conditionally Mandatory. | |||
| org.hbbtv_DASH-131-EVENTS0100 | 1 | MPD events with @contentEncoding equals base64 | The terminal is able to play, using an HTML5 video element, linearly from beginning to end, a DASH stream where the MPD contains 1) an AVC video Adaptation Set, 2) an HE-AAC audio Adaptation Set and 3) more than one DASH Event element with the optional contentEncoding attribute being set to "base64" and the Event element having a value that is a valid base 64 encoded string. DataCues are generated for each MPD event and DataCue.data is correctly set to the contents of the value of the Event element after base64 decoding. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-2 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 4.7.9: DASH events shall be reported to applications as DataCues according to the following mapping: data: The (character data) value of the Event element. If the optional contentEncoding attribute is set to “base64” then the (character data) value of the Event element shall be decoded as described in IETF RFC 4648 [1] before use. If the Event element does not solely contain character data (e.g. if it contains child elements or if it is empty) then this property shall be an XML document subset such that the canonical form of the XML returned by reading this property shall be identical to the canonical form of the Event element in the MPD starting with the opening <Event> tag and the closing </Event> tag. See clause 2.4, “Document subsets” of Canonical XML Version 1.1 [2]. HBBTV,section 9.3.2.2: DASH events shall be reported to applications as DataCues according to the following mapping: data The (character data) value of the Event element. If the optional contentEncoding attribute is set to “base64” then the (character data) value of the Event element shall be decoded as described in IETF RFC 4648 [71] before use. If the Event element does not solely contain character data (e.g. if it contains child elements or if it is empty) then this property shall be an XML document subset such that the canonical form of the XML returned by reading this property shall be identical to the canonical form of the Event element in the MPD starting with the opening <Event> tag and the closing </Event> tag. See clause 2.4, “Document subsets” of Canonical XML Version 1.1 [72]. DASH,section 5.10.2.2: @contentEncoding O specifies whether the information in the body and the information in the @messageData is encoded. If present, the following value is possible: base64 the content is encoded as described in IETF RFC 4648 prior to adding it to the field. If this attribute is present, the DASH Client is expected to decode the message data and only provide the decoded message to the application. | |||
| org.hbbtv_DASH-131-EVENTS0110 | 1 | MPD events with XML child elements | The terminal is able to play, using an HTML5 video element, linearly from beginning to end, a DASH stream where the MPD contains 1) an AVC video Adaptation Set, 2) an HE-AAC audio Adaptation Set and 3) more than one DASH Event element containing SCTE35 child elements. DataCues are generated for each MPD event and DataCue.data is correctly set to an XML document subset whose canonical form is identical to the canonical form of the Event element in the MPD starting with the opening <Event> tag and ending with the closing </Event> tag. | 2024-1 2023-3 2023-2 2021-2 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 4.7.9: DASH events shall be reported to applications as DataCues according to the following mapping: data: The (character data) value of the Event element. If the optional contentEncoding attribute is set to “base64” then the (character data) value of the Event element shall be decoded as described in IETF RFC 4648 [1] before use. If the Event element does not solely contain character data (e.g. if it contains child elements or if it is empty) then this property shall be an XML document subset such that the canonical form of the XML returned by reading this property shall be identical to the canonical form of the Event element in the MPD starting with the opening <Event> tag and the closing </Event> tag. See clause 2.4, “Document subsets” of Canonical XML Version 1.1 [2]. HBBTV,section 9.3.2.2: DASH events shall be reported to applications as DataCues according to the following mapping: data The (character data) value of the Event element. If the optional contentEncoding attribute is set to “base64” then the (character data) value of the Event element shall be decoded as described in IETF RFC 4648 [71] before use. If the Event element does not solely contain character data (e.g. if it contains child elements or if it is empty) then this property shall be an XML document subset such that the canonical form of the XML returned by reading this property shall be identical to the canonical form of the Event element in the MPD starting with the opening <Event> tag and the closing </Event> tag. See clause 2.4, “Document subsets” of Canonical XML Version 1.1 [72]. DASH,section 5.10.2.3: <!-- Event --> <xs:complexType name="EventType" mixed="true"> <xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="presentationTime" type="xs:unsignedLong" default="0"/> <xs:attribute name="duration" type="xs:unsignedLong"/> <xs:attribute name="id" type="xs:unsignedInt"/> <xs:attribute name="contentEncoding" type="ContentEncodingType"/> <xs:attribute name="messageData" type="xs:string"> <xs:annotation> <xs:documentation> Deprecated in favor of carrying the message information in the value space of the event </xs:documentation> </xs:annotation> </xs:attribute> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> | |||
| org.hbbtv_DASH-131-EVENTS0120 | 1 | MPD events which are empty | The terminal is able to play, using an HTML5 video element, linearly from beginning to end, a DASH stream where the MPD contains 1) an AVC video Adaptation Set, 2) an HE-AAC audio Adaptation Set and 3) more than one DASH Event element that is empty (no child elements, no character data or string content). DataCues are generated for each MPD event and DataCue.data is correctly set to an XML document subset whose canonical form is the same as the canonical XML of the corresponding Event element in the MPD starting with the opening <Event> tag and ending with the closing </Event> tag. | 2024-1 2023-3 2023-2 2022-3 2022-2 2022-1 2021-2 | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 | HBBTV,section 4.7.9: DASH events shall be reported to applications as DataCues according to the following mapping: data: The (character data) value of the Event element. If the optional contentEncoding attribute is set to “base64” then the (character data) value of the Event element shall be decoded as described in IETF RFC 4648 [1] before use. If the Event element does not solely contain character data (e.g. if it contains child elements or if it is empty) then this property shall be an XML document subset such that the canonical form of the XML returned by reading this property shall be identical to the canonical form of the Event element in the MPD starting with the opening <Event> tag and the closing </Event> tag. See clause 2.4, “Document subsets” of Canonical XML Version 1.1 [2]. HBBTV,section 9.3.2.2: DASH events shall be reported to applications as DataCues according to the following mapping: data The (character data) value of the Event element. If the optional contentEncoding attribute is set to “base64” then the (character data) value of the Event element shall be decoded as described in IETF RFC 4648 [71] before use. If the Event element does not solely contain character data (e.g. if it contains child elements or if it is empty) then this property shall be an XML document subset such that the canonical form of the XML returned by reading this property shall be identical to the canonical form of the Event element in the MPD starting with the opening <Event> tag and the closing </Event> tag. See clause 2.4, “Document subsets” of Canonical XML Version 1.1 [72]. | |||
| org.hbbtv_DASH-BASEURL0010 | 1 | DASH BaseURL - selecting BaseURL [by priority] | A live profile MPD has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 2 <BaseURL1> with @priority == 1 <BaseURL2> with @priority == 3. When a terminal starts playing the DASH stream described by this MPD, it makes segment requests using <BaseURL1> as its BaseURL. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: * It shall begin by taking the set of resolved BaseURLs present or inherited at the current position in the MPD, resolved and filtered as described in 10.8.2.1, that have the lowest @priority attribute value. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-BASEURL0020 | 1 | DASH BaseURL - selecting BaseURL [by priority with default] | A live profile MPD has a single Period and Adaptation Set and contains multiple absolute BaseURLs within its Period element, as follows: <BaseURL0> with @priority == 2 <BaseURL1> with @priority == 3 <BaseURL2> with no @priority attribute. The MPD also has a relative BaseURL, <BaseURL3>, within its MPD element. When a terminal starts playing the DASH stream described by this MPD, it makes segment requests using <BaseURL2> as its BaseURL. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.2.1: @priority is a positive integer. It has a default value of 1. TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: * It shall begin by taking the set of resolved BaseURLs present or inherited at the current position in the MPD, resolved and filtered as described in 10.8.2.1, that have the lowest @priority attribute value. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-BASEURL0030 | 1 | DASH BaseURL - selecting BaseURL [by weight] | A live profile MPD has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @weight == 50 <BaseURL1> with @priority == 1, @weight == 30 <BaseURL2> with @priority == 1, @weight == 20. When a terminal starts playing the DASH stream described by this MPD, it randomly selects either <BaseURL0>, <BaseURL1> or <BaseURL2> for segment requests such that over 100 separate playback sessions, <BaseURL0> is used between 40 and 60 times inclusive, <BaseURL1> is used between 21 and 39 times inclusive and <BaseURL2> is used between 12 and 28 times inclusive. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: * It shall begin by taking the set of resolved BaseURLs present or inherited at the current position in the MPD, resolved and filtered as described in 10.8.2.1, that have the lowest @priority attribute value. * If there is more than one BaseURL with this lowest @priority attribute value then the Player shall select one of them at random such that the probability of each BaseURL being chosen is proportional to the value of its @weight attribute. [...] HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-BASEURL0040 | 1 | DASH BaseURL - selecting BaseURL [by weight with default] | A live profile MPD has a single Period and Adaptation Set and contains multiple absolute BaseURLs within its Period element, as follows: <BaseURL0> with @priority == 1, @weight == 2 <BaseURL1> with @priority == 1 and no @weight attribute. When a terminal starts playing the DASH stream described by this MPD, it randomly selects either <BaseURL0> or <BaseURL1> for segment requests such that over 90 separate playback sessions, <BaseURL0> is used between 51 and 69 times inclusive. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.2.1: @weight is a positive integer. It has a default value of 1. TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: * It shall begin by taking the set of resolved BaseURLs present or inherited at the current position in the MPD, resolved and filtered as described in 10.8.2.1, that have the lowest @priority attribute value. * If there is more than one BaseURL with this lowest @priority attribute value then the Player shall select one of them at random such that the probability of each BaseURL being chosen is proportional to the value of its @weight attribute. [...] HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-BASEURL0050 | 1 | DASH BaseURL - resolving BaseURL [absolute in MPD; relative in AdaptationSet] | A live profile MPD has a single Adaptation Set and contains an absolute BaseURL, <BaseURL0>, within its MPD element and a relative BaseURL, <BaseURL1>, within its AdaptationSet element. The MPD contains no other BaseURLs. When a terminal starts playing the DASH stream described by this MPD, it makes segment requests using as its BaseURL the result of resolving <BaseURL1> according to RFC3986 with respect to <BaseURL0>. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.2.1: Players shall carry out BaseURL reference resolution as specified in clause 5.6.4 of ISO/IEC 23009-1 [...] DASH,section 5.6.4: URLs at each level of the MPD are resolved according to RFC3986 with respect to the BaseURL element specified at that level of the document or the level above in the case of resolving base URLs themselves. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-BASEURL0060 | 1 | DASH BaseURL - resolving BaseURL [absolute in Period; relative in Representation] | A live profile MPD has a single Period containing a single Adaptation Set, which itself contains a single Representation. The MPD contains an absolute BaseURL, <BaseURL0>, within its Period element and a relative BaseURL, <BaseURL1>, within its Representation element. The MPD contains no other BaseURLs. When a terminal starts playing the DASH stream described by this MPD, it makes segment requests using as its BaseURL the result of resolving <BaseURL1> according to RFC3986 with respect to <BaseURL0>. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.2.1: Players shall carry out BaseURL reference resolution as specified in clause 5.6.4 of ISO/IEC 23009-1 [...] DASH,section 5.6.4: URLs at each level of the MPD are resolved according to RFC3986 with respect to the BaseURL element specified at that level of the document or the level above in the case of resolving base URLs themselves. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-BASEURL0070 | 1 | DASH BaseURL - resolving BaseURL [only relative in MPD] | A live profile MPD requested from <MPD URL> has a relative BaseURL, <BaseURL0>, within its MPD element, and contains no other BaseURLs. When a terminal starts playing the DASH stream described by this MPD, it makes segment requests using as its BaseURL the result of resolving <BaseURL0> according to RFC3986 with respect to <MPD URL>. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.2.1: Players shall carry out BaseURL reference resolution as specified in clause 5.6.4 of ISO/IEC 23009-1 [...] DASH,section 5.6.4: URLs at each level of the MPD are resolved according to RFC3986 with respect to the BaseURL element specified at that level of the document or the level above in the case of resolving base URLs themselves (the document “base URI” as defined in RFC 3986 Section 5.1 is considered to be the level above the MPD level). HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-BASEURL0080 | 1 | DASH BaseURL - resolving BaseURL [relative to document Base URI following 301 permanent redirect] | A live profile MPD has a relative BaseURL, <BaseURL0>, within its MPD element, and contains no other BaseURLs. The MPD is requested from <MPD URL1> and the server responds with an HTTP 301 permanent redirect to a different location <MPD URL2>. The terminal follows the redirection and retrieves the MPD from <MPD URL2>. When the terminal starts playing the DASH stream described by this MPD, all segment requests are made with request URLs that are relative to <BaseURL0> and <MPD URL2> and not relative to <MPD URL1>. | 2024-1 2023-3 2023-2 2023-1 2022-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 | TS-103-285,section 10.8.2.1: Players shall carry out BaseURL reference resolution as specified in clause 5.6.4 of ISO/IEC 23009-1 [...] TS-103-285,section 10.11: Where Players receive an HTTP redirect status code of 301, 302 or 307 together with a Location header, they shall follow the redirect for that URL as described in clause 10.3 of RFC 2616 [17]. DASH,section 5.6.4: URLs at each level of the MPD are resolved according to RFC3986 with respect to the BaseURL element specified at that level of the document or the level above in the case of resolving base URLs themselves (the document “base URI” as defined in RFC 3986 Section 5.1 is considered to be the level above the MPD level). HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. RFC3986,section 5.1.3: If no base URI is embedded and the representation is not encapsulated within some other entity, then, if a URI was used to retrieve the representation, that URI shall be considered the base URI. Note that if the retrieval was the result of a redirected request, the last URI used (i.e., the URI that resulted in the actual retrieval of the representation) is the base URI. RFC2616,section 10.3: Redirection 3xx: This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. RFC2616,section 10.3.2: 301 Moved Permanently: The requested resource has been assigned a new permanent URI [...] | |||
| org.hbbtv_DASH-BASEURL0090 | 1 | DASH BaseURL - resolving BaseURL [relative to document Base URI following 302 temporary redirect] | A live profile MPD has a relative BaseURL, <BaseURL0>, within its MPD element, and contains no other BaseURLs. The MPD is requested from <MPD URL1> and the server responds with an HTTP 302 temporary redirect to a different location <MPD URL2>. The terminal follows the redirection and retrieves the MPD from <MPD URL2>. When the terminal starts playing the DASH stream described by this MPD, all segment requests are made with request URLs that are relative to <BaseURL0> and <MPD URL2> and not relative to <MPD URL1>. | 2024-1 2023-3 2023-2 2023-1 2022-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 | TS-103-285,section 10.8.2.1: Players shall carry out BaseURL reference resolution as specified in clause 5.6.4 of ISO/IEC 23009-1 [...] TS-103-285,section 10.11: Where Players receive an HTTP redirect status code of 301, 302 or 307 together with a Location header, they shall follow the redirect for that URL as described in clause 10.3 of RFC 2616 [17]. DASH,section 5.6.4: URLs at each level of the MPD are resolved according to RFC3986 with respect to the BaseURL element specified at that level of the document or the level above in the case of resolving base URLs themselves (the document “base URI” as defined in RFC 3986 Section 5.1 is considered to be the level above the MPD level). HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. RFC3986,section 5.1.3: If no base URI is embedded and the representation is not encapsulated within some other entity, then, if a URI was used to retrieve the representation, that URI shall be considered the base URI. Note that if the retrieval was the result of a redirected request, the last URI used (i.e., the URI that resulted in the actual retrieval of the representation) is the base URI. RFC2616,section 10.3: Redirection 3xx: This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. RFC2616,section 10.3.3: 302 Found: The requested resource resides temporarily under a different URI. [...] | |||
| org.hbbtv_DASH-COMPATIBILITY0100 | 1 | DASH video AdaptationSet with unknown video codec is ignored | When an application uses an HTML5 video element to play a DASH MPD containing an AVC HD video AdaptationSet that has the @codecs attribute "xxxx" then the video is not presented. | 2024-1 2023-3 2023-2 2023-1 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 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.17: Players shall ignore any AdaptationSet or Representation that has a @codecs (including information such as profile and level, object type etc.), @frameRate, @width or @height or @par or @sar attribute that the player does not understand or cannot process. | |||
| org.hbbtv_DASH-COMPATIBILITY0200 | 1 | DASH video AdaptationSet with unknown EssentialProperty descriptor is ignored | When an application uses an HTML5 video element to play a DASH MPD containing an AVC HD video AdaptationSet that has an EssentialProperty descriptor with schemeIdUri "urn:hbbtv:undefined" then the video is not presented. | 2024-1 2023-3 2023-2 2023-1 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 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.10: Players shall ignore a parent element if the scheme or the value for the EssentialProperty child element is not recognized by the Player | |||
| org.hbbtv_DASH-COMPATIBILITY0210 | 1 | DASH audio AdaptationSet with unknown EssentialProperty descriptor is ignored | When an application uses an HTML5 video element to play a DASH MPD containing an AAC audio AdaptationSet that has an EssentialProperty descriptor with schemeIdUri "urn:hbbtv:undefined" then the audio is not presented. | 2024-1 2023-3 2023-2 2023-1 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 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.10: Players shall ignore a parent element if the scheme or the value for the EssentialProperty child element is not recognized by the Player | |||
| org.hbbtv_DASH-COMPATIBILITY0220 | 1 | DASH AdaptationSets with an unknown EssentialProperty descriptor are ignored but ones without are selected | When an application uses an HTML5 video element to play a DASH MPD containing two AVC HD video AdaptationSets and two AAC audio AdaptationSets where the first video AdaptationSet and the second audio AdaptationSet have an EssentialProperty descriptor with schemeIdUri "urn:hbbtv:undefined" then video from the second video AdaptationSet is seen and audio from the first audio AdaptationSet is heard. | 2024-1 2023-3 2023-2 2023-1 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 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.10: Players shall ignore a parent element if the scheme or the value for the EssentialProperty child element is not recognized by the Player | |||
| org.hbbtv_DASH-DTS001 | 1 | Support for DTSE stereo, HbbTV ISOBMFF On Demand profile | The terminal shall correctly decode and present DTSE stereo audio as part of AV content from an MPEG DASH On Demand stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 7.3.1.1: The audio formats are specified in the OIPF-Media-Formats specification with the restrictions in clause 7.3.1.4. 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.7: DTS-HD format (Audio Format: DTS) audio coding shall be compliant with [DTS] and according to [TS101154] section 6.3. * Usage of DTS-HD in ISOBMFF is defined in Annex E of [DTS]. TS-103-285,section 6.4: The signalling of DTS audio formats using ISOBMFF encapsulation is provided in Table 8 [...] DASH,section 8.3: ISO Base media file format On Demand profile | +DTS | ||
| org.hbbtv_DASH-DTS002 | 1 | Support for DTSE 5.1 channel AV Content, HbbTV ISOBMFF On Demand profile | The terminal shall correctly decode and present 5.1 channel DTSE audio as part of AV content from an MPEG DASH On Demand stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 7.3.1.1: The audio formats are specified in the OIPF-Media-Formats specification with the restrictions in clause 7.3.1.4. 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.7: DTS-HD format (Audio Format: DTS) audio coding shall be compliant with [DTS] and according to [TS101154] section 6.3. * Usage of DTS-HD in ISOBMFF is defined in Annex E of [DTS]. TS-103-285,section 6.4: The signalling of DTS audio formats using ISOBMFF encapsulation is provided in Table 8 [...] DASH,section 8.3: ISO Base media file format On Demand profile | +DTS | ||
| org.hbbtv_DASH-ERRORHANDLE0001 | 2 | DASH Error Handling - heavy server load [static MPD; failed DNS resolution] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" and a hostname that does not exist in DNS; <BaseURL1> with @priority == 2, @serviceLocation == "B" and a hostname that does exist in DNS. When a terminal starts to play the stream described by this MPD, it makes segment requests using <BaseURL1> after retrying to resolve the hostname of <BaseURL0> up to 3 seconds from the first failure. | 2024-1 2023-3 2023-2 2023-1 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: DNS resolution failed - heavy server load - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0002 | 2 | DASH Error Handling - heavy server load [static MPD; host unreachable] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal starts to play the DASH stream described by this MPD, and it encounters an unreachable host error in response to its first segment request, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | TS-103-285,section 10.8.5: Host unreachable - heavy server load - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0004 | 2 | DASH Error Handling - heavy server load [static MPD; HTTP 500] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, receives an HTTP 500 (Internal server error) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-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 | TS-103-285,section 10.8.5: 500 (Internal server error) - heavy server load - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0005 | 2 | DASH Error Handling - heavy server load [static MPD; HTTP 503] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, receives an HTTP 503 (Service unavailable) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 503 (Service unavailable) - heavy server load - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0006 | 2 | DASH Error Handling - heavy server load [static MPD; HTTP 504] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, receives an HTTP 504 (Gateway timeout) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 504 (Gateway timeout) - heavy server load - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0007 | 3 | DASH Error Handling - Missing Segments [HTTP 404; Static MPD] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A"; <BaseURL1> with @priority == 2, @serviceLocation == "B". When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters a HTTP 404 (Not found) error code, it shall switch from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> and shall not attempt any retries of the failed segment. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-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 | TS-103-285,section 10.8.5: 404 (Not found) - Missing segments TS-103-285,section 10.8.6: static - The Player shall change BaseURL as specified in clause 10.8.2.3. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0009 | 3 | DASH Error Handling - Missing Segments [HTTP 404; Dynamic MPD; Timing Present; Request No Longer Valid] | When a terminal, which is playing the DASH stream described by a live profile MPD with @type == dynamic, encounters a HTTP 404 (Not found) error code in response to a request for a segment, it reloads the MPD. When the reloaded MPD contains at least one UTCTiming element, the terminal resynchronises its system time to the time server referenced by one of the UTCTiming elements; and when the segment that caused the HTTP 404 error is not, according to the updated MPD, available at the updated system time, the terminal adjusts its position in the media to reflect the new MPD and time. | 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 | TS-103-285,section 10.8.5: 404 (Not found) - Missing segments TS-103-285,section 10.8.6: dynamic - The Player shall reload the MPD. If the MPD indicates a source of time as specified in clause 4.7.3 the Player shall resynchronize to one of the time sources as described in clause 4.7.3. If, as a result of reloading the MPD and performing any required time synchronisation, the Player determines the request is no longer appropriate, it shall adjust its position in the media to reflect the new MPD and any new time value. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0010 | 3 | DASH Error Handling - Missing Segments [HTTP 404; Dynamic MPD; Timing Present; Request Still Valid] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A"; <BaseURL1> with @priority == 2, @serviceLocation == "B". When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters a HTTP 404 (Not found) error code, it shall reload the MPD. When the reloaded MPD contains at least one UTCTiming element, the terminal shall resynchronise its system time to the time server referenced by one of the UTCTiming elements; and when the segment that does not exist is still a member of the set of segments described by the updated MPD, and is still expected to be available according to the updated clock, the terminal shall switch from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0, 1 or 2 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | TS-103-285,section 10.8.5: 404 (Not found) - Missing segments TS-103-285,section 10.8.6: dynamic - The Player shall reload the MPD. If the MPD indicates a source of time as specified in clause 4.7.3 the Player shall resynchronise to one of the time sources as described in clause 4.7.3. [...] If the request is still valid the Player may retry the request up to the max number of retries specified. If trying the above does not result in success the Player shall change BaseURL as specified in clause 10.8.2.3. - [Maximum Number of retries] 2 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0011 | 2 | DASH Error Handling - missing segments [HTTP 410; static MPD] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 410 (Gone) error code it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> without attempting any retries of the failed segment. | 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 | TS-103-285,section 10.8.5: 410 (Gone) - missing segments - static TS-103-285,section 10.8.6: The Player shall change BaseURL as specified in clause 10.8.2.3. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0013 | 2 | DASH Error Handling - missing segments [HTTP 410; dynamic MPD; timing present; request no longer valid] | When a terminal, which is playing the DASH stream described by a live profile MPD with @type == dynamic, encounters an HTTP 410 (Gone) error code in response to a request for a segment, it reloads the MPD. When the reloaded MPD contains at least one UTCTiming element, the terminal resynchronises its system time to the time server referenced by one of the UTCTiming elements; and when the segment that caused the HTTP 410 error is not, according to the updated MPD, available at the updated system time, the terminal adjusts its position in the media to reflect the new MPD and time. | 2024-1 2023-3 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 | TS-103-285,section 10.8.5: 410 (Gone) - missing segments - dynamic TS-103-285,section 10.8.6: The Player shall reload the MPD. If the MPD indicates a source of time as specified in clause 4.7.3 the Player shall resynchronise to one of the time sources as described in clause 4.7.3. If as a result of reloading the MPD and carrying out time synchronisation the Player determines the request is no longer appropriate, it shall adjust its position in the media to reflect the new MPD and time. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | ||
| org.hbbtv_DASH-ERRORHANDLE0015 | 2 | DASH Error Handling - missing segments [HTTP 416; static MPD] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 416 (Requested range not satisfiable) error code it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> without attempting any retries of the failed segment. | 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 | TS-103-285,section 10.8.5: 416 (Requested range not satisfiable) - missing segments - static TS-103-285,section 10.8.6: The Player shall change BaseURL as specified in clause 10.8.2.3. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0019 | 2 | DASH Error Handling - configuration errors [static MPD; HTTP 502] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 502 (Bad gateway) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 502 (Bad gateway) - configuration errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0020 | 2 | DASH Error Handling - miscellaneous request errors [static MPD; HTTP 405] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 405 (Method not allowed) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 405 (Method not allowed) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0021 | 2 | DASH Error Handling - miscellaneous request errors [static MPD; HTTP 406] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 406 (Not acceptable) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 406 (Not acceptable) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0022 | 2 | DASH Error Handling - miscellaneous request errors [static MPD; HTTP 407] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 407 (Proxy authentication required) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 407 (Proxy authentication required) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0023 | 2 | DASH Error Handling - miscellaneous request errors [static MPD; HTTP 409] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 409 (Conflict) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 409 (Conflict) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0024 | 2 | DASH Error Handling - miscellaneous request errors [static MPD; HTTP 411] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 411 (Length required) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 411 (Length required) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0025 | 2 | DASH Error Handling - miscellaneous request errors [static MPD; HTTP 412] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 412 (Precondition failed) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 412 (Precondition failed) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0026 | 2 | DASH Error Handling - miscellaneous request errors [static MPD; HTTP 413] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 413 (Request entity too large) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 413 (Request entity too large) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0027 | 2 | DASH Error Handling - miscellaneous request errors [static MPD; HTTP 414] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 414 (Request-URI too long) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 414 (Request-URI too long) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0028 | 2 | DASH Error Handling - miscellaneous request errors [static MPD; HTTP 415] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 415 (Unsupported media type) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 415 (Unsupported media type) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0029 | 2 | DASH Error Handling - miscellaneous request errors [static MPD; HTTP 417] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 417 (Expectation failed) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 417 (Expectation failed) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0032 | 2 | DASH Error Handling - miscellaneous request errors [static MPD; HTTP 505] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 505 (HTTP version not supported) error code,it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 505 (HTTP version not supported) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0033 | 2 | DASH Error Handling - authentication errors [static MPD; HTTP 401] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 401 (Unauthorized) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 401 (Unauthorized) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0034 | 2 | DASH Error Handling - authentication errors [static MPD; HTTP 402] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 402 (Payment required) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 402 (Payment required) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0035 | 2 | DASH Error Handling - authentication errors [static MPD; HTTP 403] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 403 (Forbidden) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 403 (Forbidden) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0038 | 2 | DASH Error Handling - changing BaseURL [blacklisting matching serviceLocations; empty result; A/V Control] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, each of which have different @priority values but identical @serviceLocation values. When a terminal, which has been playing the DASH stream described by this MPD in an A/V Control object with no errors since the session began, encounters an HTTP 404 (Not found) error code, presentation of the DASH stream stops and the A/V Control object transitions to play state 6 with error code 5. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: [...] * If there are no BaseURLs after applying blacklisting, the Player shall stop playback and report an error. TS-103-285,section 10.8.2.3: At any point where a Player needs to change BaseURL as directed in clause 10.8.6, the Player shall: * If the previously used BaseURL had a non-empty @serviceLocation attribute, add that @serviceLocation attribute value to the blacklist. This BaseURL is removed from the list of available BaseURLs, as are any other BaseURLs in the list with the same @priority attribute value. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0039 | 2 | DASH Error Handling - changing BaseURL [blacklisting matching priorities; empty result; A/V Control] | A live profile MPD with @type == static has a single Period and Adaptation Set and contains multiple absolute BaseURLs within its Period element, each of which have identical @priority values but different @serviceLocation values. When a terminal, which has been playing the DASH stream described by this MPD in an A/V Control object with no errors since the session began, encounters an HTTP 404 (Not found) error code, presentation of the DASH stream stops and the A/V Control object transitions to play state 6 with error code 5. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: [...] * If there are no BaseURLs after applying blacklisting, the Player shall stop playback and report an error. TS-103-285,section 10.8.2.3: At any point where a Player needs to change BaseURL as directed in clause 10.8.6, the Player shall: * If the previously used BaseURL had a non-empty @serviceLocation attribute, add that @serviceLocation attribute value to the blacklist. This BaseURL is removed from the list of available BaseURLs, as are any other BaseURLs in the list with the same @priority attribute value. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0040 | 2 | DASH Error Handling - changing BaseURL [blacklisting matching serviceLocations and priorities; empty result; A/V Control] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "A" <BaseURL2> with @priority == 1, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD in an A/V Control object with no errors since the session began, encounters an HTTP 404 (Not found) error code, presentation of the DASH stream stops and the A/V Control object transitions to play state 6 with error code 5. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: [...] * If there are no BaseURLs after applying blacklisting, the Player shall stop playback and report an error. TS-103-285,section 10.8.2.3: At any point where a Player needs to change BaseURL as directed in clause 10.8.6, the Player shall: * If the previously used BaseURL had a non-empty @serviceLocation attribute, add that @serviceLocation attribute value to the blacklist. This BaseURL is removed from the list of available BaseURLs, as are any other BaseURLs in the list with the same @priority attribute value. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0041 | 2 | DASH Error Handling - changing BaseURL [blacklisting matching serviceLocations; single result] | A live profile MPD with @type == static has a single Period and Adaptation Set and contains multiple absolute BaseURLs within its Period element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "A" <BaseURL2> with @priority == 3, @serviceLocation == "B" The MPD also has a relative BaseURL, <BaseURL3>, within its MPD element. When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 404 (Not found) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL2>. | 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 | TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: * It shall begin by taking the set of resolved BaseURLs present or inherited at the current position in the MPD, resolved and filtered as described in 10.8.2.1, that have the lowest @priority attribute value. TS-103-285,section 10.8.2.3: At any point where a Player needs to change BaseURL as directed in clause 10.8.6, the Player shall: * If the previously used BaseURL had a non-empty @serviceLocation attribute, add that @serviceLocation attribute value to the blacklist. This BaseURL is removed from the list of available BaseURLs, as are any other BaseURLs in the list with the same @priority attribute value. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0042 | 2 | DASH Error Handling - changing BaseURL [blacklisting matching priorities; single result] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A", weight == 16777215 <BaseURL1> with @priority == 1, @serviceLocation == "B" <BaseURL2> with @priority == 2, @serviceLocation == "C" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 404 (Not found) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL2>. | 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 | TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: * It shall begin by taking the set of resolved BaseURLs present or inherited at the current position in the MPD, resolved and filtered as described in 10.8.2.1, that have the lowest @priority attribute value. TS-103-285,section 10.8.2.3: At any point where a Player needs to change BaseURL as directed in clause 10.8.6, the Player shall: * If the previously used BaseURL had a non-empty @serviceLocation attribute, add that @serviceLocation attribute value to the blacklist. This BaseURL is removed from the list of available BaseURLs, as are any other BaseURLs in the list with the same @priority attribute value. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0044 | 2 | DASH Error Handling - changing BaseURL [blacklisting matching priorities and serviceLocations; single result] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A", weight == 16777215 <BaseURL1> with @priority == 2, @serviceLocation == "A" <BaseURL2> with @priority == 1, @serviceLocation == "B" <BaseURL3> with @priority == 3, @serviceLocation == "C" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 404 (Not found) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL3>. | 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 | TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: * It shall begin by taking the set of resolved BaseURLs present or inherited at the current position in the MPD, resolved and filtered as described in 10.8.2.1, that have the lowest @priority attribute value. TS-103-285,section 10.8.2.3: At any point where a Player needs to change BaseURL as directed in clause 10.8.6, the Player shall: * If the previously used BaseURL had a non-empty @serviceLocation attribute, add that @serviceLocation attribute value to the blacklist. This BaseURL is removed from the list of available BaseURLs, as are any other BaseURLs in the list with the same @priority attribute value. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0050 | 1 | DASH Error Handling - blacklist retained after MPD reload | A live profile MPD with @type == dynamic and a defined @minimumUpdatePeriod (e.g. PT1M) has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A", weight == 16777215 <BaseURL1> with @priority == 2, @serviceLocation == "A" <BaseURL2> with @priority == 1, @serviceLocation == "B" <BaseURL3> with @priority == 3, @serviceLocation == "C" On a terminal which has switched to making segment requests using <BaseURL3> due to an HTTP 503 error occurring some time before the first required MPD update, then when the terminal subsequently reloads its MPD, it continues to use <BaseURL3> for subsequent segment requests. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.2.1: The @serviceLocation attribute is used to implement a blacklisting of failed BaseURL locations. To do this the Player shall maintain a list of @serviceLocation values which have failed (see clause 10.8.2.3). When an MPD is first loaded in a session the blacklist shall be empty. The blacklist is retained when the MPD is reloaded by the Player, but discarded when a different MPD is loaded or at the end of the current session. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0070 | 1 | DASH Error Handling - heavy server load [dynamic MPD; failed DNS resolution] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" and a hostname that does not exist in DNS; <BaseURL1> with @priority == 2, @serviceLocation == "B" and a hostname that does exist in DNS. When a terminal starts to play the stream described by this MPD, it makes segment requests using <BaseURL1> after retrying to resolve the hostname of <BaseURL0> up to 3 seconds from the first failure. | 2024-1 2023-3 2022-3 2022-2 2022-1 2021-3 2021-2 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: DNS resolution failed - heavy server load - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | ||
| org.hbbtv_DASH-ERRORHANDLE0080 | 1 | DASH Error Handling - heavy server load [dynamic MPD; host unreachable] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal starts to play the DASH stream described by this MPD, and it encounters an unreachable host error in response to its first segment request, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-3 2020-2 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | TS-103-285,section 10.8.5: Host unreachable - heavy server load - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0090 | 1 | DASH Error Handling - heavy server load [dynamic MPD; connection refused] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal starts to play the DASH stream described by this MPD, and it encounters a refused connection in response to its first segment request, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: Connection refused - heavy server load - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | ||
| org.hbbtv_DASH-ERRORHANDLE0100 | 1 | DASH Error Handling - heavy server load [dynamic MPD; HTTP 500] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, receives an HTTP 500 (Internal server error) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 500 (Internal server error) - heavy server load - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0110 | 1 | DASH Error Handling - heavy server load [dynamic MPD; HTTP 503] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, receives an HTTP 503 (Service unavailable) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 503 (Service unavailable) - heavy server load - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0120 | 1 | DASH Error Handling - heavy server load [dynamic MPD; HTTP 504] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, receives an HTTP 504 (Gateway timeout) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 504 (Gateway timeout) - heavy server load - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0130 | 1 | DASH Error Handling - configuration errors [dynamic MPD; HTTP 502] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 502 (Bad gateway) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 502 (Bad gateway) - configuration errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0140 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 405] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 405 (Method not allowed) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 405 (Method not allowed) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0150 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 406] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 406 (Not acceptable) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 406 (Not acceptable) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0160 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 407] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 407 (Proxy authentication required) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 407 (Proxy authentication required) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0170 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 409] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 409 (Conflict) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 409 (Conflict) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0180 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 411] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 411 (Length required) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 411 (Length required) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0190 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 412] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 412 (Precondition failed) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 412 (Precondition failed) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0200 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 413] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 413 (Request entity too large) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 413 (Request entity too large) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0210 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 414] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 414 (Request-URI too long) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 414 (Request-URI too long) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0220 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 415] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 415 (Unsupported media type) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 415 (Unsupported media type) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0230 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 417] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 417 (Expectation failed) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 417 (Expectation failed) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0240 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 408] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 408 (Request timeout) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 408 (Request timeout) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | ||
| org.hbbtv_DASH-ERRORHANDLE0250 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 501] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 501 (Not implemented) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 501 (Not implemented) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0260 | 1 | DASH Error Handling - miscellaneous request errors [dynamic MPD; HTTP 505] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 505 (HTTP version not supported) error code,it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 505 (HTTP version not supported) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0270 | 1 | DASH Error Handling - authentication errors [dynamic MPD; HTTP 401] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 401 (Unauthorized) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 401 (Unauthorized) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0280 | 1 | DASH Error Handling - authentication errors [dynamic MPD; HTTP 402] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 402 (Payment required) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 402 (Payment required) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0290 | 1 | DASH Error Handling - authentication errors [dynamic MPD; HTTP 403] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 403 (Forbidden) error code, it switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0 or 1 failed retry attempts. | 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 | TS-103-285,section 10.8.5: 403 (Forbidden) - miscellaneous request errors - static or dynamic TS-103-285,section 10.8.6: The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. Max number of retries: 1 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0300 | 2 | DASH Error Handling - Missing Segments [HTTP 404; Dynamic MPD; No Timing; Request Still Valid] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A"; <BaseURL1> with @priority == 2, @serviceLocation == "B". When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters a HTTP 404 (Not found) error code, it reloads the MPD. When the reloaded MPD does not contain any UTCTiming elements, and the segment that caused the HTTP 404 error is still a member of the set of segments described by the updated MPD and is still available, the terminal switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0, 1 or 2 failed retry attempts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | TS-103-285,section 10.8.5: 404 (Not found) - missing segments TS-103-285,section 10.8.6: dynamic - The Player shall reload the MPD. [...] If the request is still valid the Player may retry the request up to the max number of retries specified. If trying the above does not result in success the Player shall change BaseURL as specified in clause 10.8.2.3. [Maximum Number of retries] 2 HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0310 | 1 | DASH Error Handling - missing segments [HTTP 410; dynamic MPD; no timing; request still valid] | A live profile MPD with @type == dynamic has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, as follows: <BaseURL0> with @priority == 1, @serviceLocation == "A" <BaseURL1> with @priority == 2, @serviceLocation == "B" When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters an HTTP 410 (Gone) error code, it reloads the MPD. When the reloaded MPD does not contain any UTCTiming elements, and the segment that caused the HTTP 410 error is still a member of the set of segments described by the updated MPD and is still available, the terminal switches from making segment requests using <BaseURL0> to making segment requests using <BaseURL1> after 0, 1 or 2 failed retry attempts. | 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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.8.5: 410 (Gone) - missing segments - dynamic TS-103-285,section 10.8.6: The Player shall reload the MPD. If the request is still valid the Player may retry the request up to the max number of retries specified. Max number of retries: 2. If trying the above does not result in success the Player shall change BaseURL as specified in clause 10.8.2.3. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0330 | 1 | DASH Error Handling - changing BaseURL [blacklisting matching serviceLocations; empty result; HTML5 Video] | A live profile MPD with @type == static has a single Adaptation Set and contains multiple absolute BaseURLs within its MPD element, each of which have different @priority values but identical @serviceLocation values. When a terminal, which has been playing the DASH stream described by this MPD in an HTML5 Video element with no errors since the session began, encounters an HTTP 404 (Not found) error code, presentation of the DASH stream stops and the error attribute of the HTML5 Video element is set to MEDIA_ERR_NETWORK. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 | TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: [...] * If there are no BaseURLs after applying blacklisting, the Player shall stop playback and report an error. TS-103-285,section 10.8.2.3: At any point where a Player needs to change BaseURL as directed in clause 10.8.6, the Player shall: * If the previously used BaseURL had a non-empty @serviceLocation attribute, add that @serviceLocation attribute value to the blacklist. This BaseURL is removed from the list of available BaseURLs, as are any other BaseURLs in the list with the same @priority attribute value. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0340 | 1 | DASH Error Handling - changing BaseURL [blacklisting matching priorities; empty result; HTML5 Video] | A live profile MPD with @type == static has a single Period and Adaptation Set and contains multiple absolute BaseURLs within its Period element, each of which have identical @priority values but different @serviceLocation values. When a terminal, which has been playing the DASH stream described by this MPD in an HTML5 Video element with no errors since the session began, encounters an HTTP 404 (Not found) error code, presentation of the DASH stream stops and the error attribute of the HTML5 Video element is set to MEDIA_ERR_NETWORK. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 | TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: [...] * If there are no BaseURLs after applying blacklisting, the Player shall stop playback and report an error. TS-103-285,section 10.8.2.3: At any point where a Player needs to change BaseURL as directed in clause 10.8.6, the Player shall: * If the previously used BaseURL had a non-empty @serviceLocation attribute, add that @serviceLocation attribute value to the blacklist. This BaseURL is removed from the list of available BaseURLs, as are any other BaseURLs in the list with the same @priority attribute value. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0360 | 2 | DASH Error Handling - Missing Segments [HTTP 404; Dynamic MPD; Request Still Valid, But No Alternative BaseURLs; HTML5 Video] | A live profile MPD with @type == dynamic contains a single BaseURL. When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, encounters a HTTP 404 (Not found) error code, it reloads the MPD. When the reloaded MPD contains at least one UTCTiming element, the terminal resynchronises its system time to the time server referenced by one of the UTCTiming elements; and when the segment that caused the HTTP 404 error is still a member of the set of segments described by the updated MPD, and is still available at the updated system time according to the updated MPD, then after 0, 1 or 2 failed retry attempts presentation of the DASH stream stops and the error attribute of the HTML5 Video element is set to MEDIA_ERR_NETWORK. | 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 | TS-103-285,section 10.8.5: 404 (Not found) - Missing segments TS-103-285,section 10.8.6: dynamic - The Player shall reload the MPD. If the MPD indicates a source of time as specified in clause 4.7.3 the Player shall resynchronize to one of the time sources as described in clause 4.7.3. If, as a result of reloading the MPD and performing any required time synchronisation, the Player determines the request is no longer appropriate, it shall adjust its position in the media to reflect the new MPD and any new time value. [...] If trying the above does not result in success the Player shall change BaseURL as specified in clause 10.8.2.3. - [Maximum Number of retries] 2 TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: [...] If there are no BaseURLs after applying blacklisting, the Player shall stop playback and report an error. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORHANDLE0370 | 2 | DASH Error Handling - heavy server load [HTTP 500; dynamic MPD; request still valid, single BaseURL; HTML5 video] | A live profile MPD with @type == dynamic contains a single BaseURL. When a terminal, which has been playing the DASH stream described by this MPD with no errors since the session began, receives an HTTP 500 (Internal server error) error code, then after 0 or 1 failed retry attempts presentation of the DASH stream stops and the error attribute of the HTML5 Video element is set to MEDIA_ERR_NETWORK. | 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 | TS-103-285,section 10.8.5: 500 (Internal server error) - Heavy server load. TS-103-285,section 10.8.6: Heavy server load - static or dynamic - The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3. - Maximum number of retries: 1. TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: [...] * If there are no BaseURLs after applying blacklisting, the Player shall stop playback and report an error. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-ERRORREP0001 | 1 | DASH Errors - becoming a reporting client when probability=1000 | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL, which indicates a serviceLocation of "hbbtvTest". When an application requests playback of this MPD the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=S00 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> servicelocation=hbbtvTest | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.2: Players shall support the metrics reporting mechanism as defined in clause 10.12.3 and the DVBErrors metric described in clause 10.12.3. Players may ignore other reporting mechanisms or requests to report other metrics systems. TS-103-285,section 10.12.3.4: When the Player receives an MPD which indicates that the DVB metrics reporting mechanism is to be used, it shall determine whether it is a reporting Player as follows: * If the @priority attribute is set to 1000, it shall be a reporting Player. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: Becoming an error reporting Player Value: "S00" ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0002 | 1 | DASH Errors - becoming a reporting client with probability=700 | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="700" @dvb:reportingUrl=<HTTP URL to test server other than the one serving the MPD> The MPD contains one absolute BaseURL, which indicates a serviceLocation of "hbbtvTest". An application plays this MPD 75 times, closing the DASH player each time. Each time it is played a record is made of whether the terminal made an error report with: errorcode=S00 After each playback of the MPD there should be two numbers available: * numPlays - the number of times the MPD has been played during this test * numReports - the number of times the errorcode S00 has been reported during this test. The test passes if 0.6 < (numReports/numPlays) < 0.8 | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.3.4: When the Player receives an MPD which indicates that the DVB metrics reporting mechanism is to be used, it shall determine whether it is a reporting Player as follows: * For any other value of the @probability attribute, it shall decide at random whether to be a reporting Player, such that the probability of being one is @probability/1000. For example the Player could pick a random number from 1 to 1000 inclusive and if the number is greater than or equal to @priority, the Player is a reporting Player. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: Becoming an error reporting Player Value: "S00" ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0003 | 1 | DASH Errors - becoming a reporting client with probability=1 | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1" @dvb:reportingUrl=<HTTP URL to test server other than the one serving the MPD> The MPD contains one absolute BaseURL, which indicates a serviceLocation of "hbbtvTest". An application plays this MPD 50 times, closing the DASH player each time. Each time it is played a record is made of whether the terminal made an error report with: errorcode=S00 After each playback of the MPD there should be two numbers available: * numPlays - the number of times the MPD has been played during this test * numReports - the number of times the errorcode S00 has been reported during this test. The test passes if (numReports/numPlays) <= 0.05 | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.3.4: When the Player receives an MPD which indicates that the DVB metrics reporting mechanism is to be used, it shall determine whether it is a reporting Player as follows: * If the @priority attribute is missing, the Player shall not be a reporting Player. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: Becoming an error reporting Player Value: "S00" ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0004 | 1 | DASH Errors - becoming a reporting client when probability attribute missing | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:reportingUrl=<URL to test server> The @dvb:probability attribute is not present. The MPD contains one absolute BaseURL, which indicates a serviceLocation of "hbbtvTest". When an application requests playback of this MPD the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=S00 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> servicelocation=hbbtvTest | 2024-1 2023-3 2023-2 2023-1 2022-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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.3.4: When the Player receives an MPD which indicates that the DVB metrics reporting mechanism is to be used, it shall determine whether it is a reporting Player as follows: * For any other value of the @probability attribute, it shall decide at random whether to be a reporting Player, such that the probability of being one is @probability/1000. For example the Player could pick a random number from 1 to 1000 inclusive and if the number is less than or equal to @probability, the Player is a reporting Player. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * any other error with an errorcode assigned in Table 32, including SSL connection errors, unrecognized HTTP status codes or corrupt media, occurs. Error Type: Becoming an error reporting Player Value: "S00" ... Table 32: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] TS-103-285,section 10.12.3.3: @probability – A positive integer between 1 and 1000, indicating the probability, in thousandths of a whole, of this Player submitting error reports for this session. This enables "sampling" of the Player base for error reports to reduce the number of reports received. If absent it takes the value 1000. | |||
| org.hbbtv_DASH-ERRORREP0005 | 1 | DASH Errors - reporting a DNS lookup failure | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL, which indicates a hostname which does not exist in DNS and the serviceLocation "hbbtvTest". When an application requests playback of the MPD the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=C00 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> servicelocation=hbbtvTest | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: DNS resolution failed Value: "C00" ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0006 | 1 | DASH Errors - reporting an unreachable host | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL, which indicates a hostname and the serviceLocation "hbbtvTest". The IP address to which the hostname resolves is not assigned to any machine. When an application requests playback of this MPD the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=C01 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: Host unreachable Value: "C01" ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0007 | 1 | DASH Errors - reporting a connection refused | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL, which indicates a hostname and port identifier and the serviceLocation "hbbtvTest". The port identifier gives a port on the test server which does not accept connections. When an application requests playback of this MPD the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=C02 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: Connection refused Value: "C02" ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0008 | 1 | DASH Errors - reporting corrupt media | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". On the media server the third segment in all video representations is a file containing twenty bytes each with the value 0x0F. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=M00 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: Corrupt media – ISO BMFF container cannot be parsed Value: "M00" ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0009 | 1 | DASH Errors - reporting a change of Base URL after an error | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains two absolute BaseURLs. One with the attributes @serviceLocation="hbbtv1" and @priority="1" and one with the attributes @serviceLocation "hbbtvB" and @priority="2". On the server which the priority 1 URL points to, any request for the third media segment of any video representation returns a 403 Forbidden response. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=F00 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server from BaseURL with priority=1> servicelocation=hbbtv1 (the serviceLocation of BaseURL with priority=1) The client may also make error reports to the same server with the errorcode S00 and 403. This is expected, but testing those reports are not part of this assertion. However the client shall not make error reports with any other error codes. | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: Changing Base URL in use due to errors Value: "F00" ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] TS-103-285,section 10.8.2.2: When a Player needs to use a BaseURL to resolve a reference to external content, such as may be found inside a Segment Template, it shall pick the BaseURL as follows: * It shall begin by taking the set of resolved BaseURLs present or inherited at the current position in the MPD, resolved and filtered as described in 10.8.2.1, that have the lowest @priority attribute value. TS-103-285,section 10.8.6: Authentication errors - static or dynamic - The Player may retry the request up to the max number of retries specified. If the problem persists it shall change BaseURL as specified in clause 10.8.2.3.1 | |||
| org.hbbtv_DASH-ERRORREP0010 | 1 | DASH Errors - reporting HTTP error codes - 401 Unauthorized | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". The media server is configured such that any request for the 3rd media segment of any video representation will get a 401 Unauthorized response. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=401 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0011 | 1 | DASH Errors - reporting HTTP error codes - 403 Forbidden | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". The media server is configured such that any request for the 3rd media segment of any video representation will get a 403 Forbidden response. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=403 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0012 | 1 | DASH Errors - reporting HTTP error codes - 404 Not Found | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". On the media server the third segment is missing from all video representations. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=404 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0013 | 1 | DASH Errors - reporting HTTP error codes - 410 Gone | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". The media server is configured such that any request for the 3rd media segment of any video representation will get a 410 Gone response. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=410 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0014 | 1 | DASH Errors - reporting HTTP error codes - 500 Internal Server Error | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". The media server is configured such that any request for the 3rd media segment of any video representation will get a 500 Internal Server Error response. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=500 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0015 | 1 | DASH Errors - reporting HTTP error codes - 501 Not Implemented | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". The media server is configured such that any request for the 3rd media segment of any video representation will get a 501 Not Implemented response. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=501 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0016 | 1 | DASH Errors - reporting HTTP error codes - 502 Bad Gateway | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". The media server is configured such that any request for the 3rd media segment of any video representation will get a 502 Bad Gateway response. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=502 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0017 | 1 | DASH Errors - reporting HTTP error codes - 503 Service Unavailable | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". The media server is configured such that any request for the 3rd media segment of any video representation will get a 503 Service Unavailable response. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=503 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0018 | 1 | DASH Errors - reporting HTTP error codes - 504 Gateway Timeout | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". The media server is configured such that any request for the 3rd media segment of any video representation will get a 504 Gateway Timeout response. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=504 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0019 | 1 | DASH Errors - reporting unrecognised HTTP status codes - in error range - 418 I'm A Teapot | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". The media server is configured such that any request for the 3rd media segment of any video representation will get a 418 I'm a Teapot response. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=418 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0020 | 1 | DASH Errors - reporting unrecognised HTTP status codes - undefined range - 750 Wibble | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". The media server is configured such that any request for the 3rd media segment of any video representation will get a 750 Wibble response. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=750 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0021 | 1 | DASH Errors - ceasing being a reporting client after errors - incorrect HTTP status code from reporting server | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL, which indicates a serviceLocation of "hbbtvTest". The 20th media segment of all video representations is missing on the media server. A test server is available to accept GET requests at the URL indicated by <URL to test server>; however, that server responds with a 403 Forbidden status code to any reports logged. When an application requests playback of this MPD the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=S00 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> servicelocation=hbbtvTest For the test to pass the terminal must make that initial report and continue playing the media to the missing segments, but must not make any further error reports, either attempting to repeat the initial S00 report or to report the missing media segments. | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.3.5: If the Player is unable to make the report, for example because the @reportingUrl is invalid, the host cannot be reached, or an HTTP status code other than one in the 200 series is received, the Player shall cease being a reporting Player for the duration of the MPD. | |||
| org.hbbtv_DASH-ERRORREP0022 | 1 | DASH Errors - ceasing being a reporting client after errors - unable to reach reporting server | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL, which indicates a serviceLocation of "hbbtvTest". The 20th media segment of all video representations is missing on the media server. <URL to test server> uses a hostname which resolves in DNS to an IP address which is not present on the network. When an application requests playback of this MPD the client must try to open a connection to the host indicated by <URL to test server>. However, when that fails it must make no further attempts to connect to that host. It must continue playing the media until the missing segments. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.3.5: If the Player is unable to make the report, for example because the @reportingUrl is invalid, the host cannot be reached, or an HTTP status code other than one in the 200 series is received, the Player shall cease being a reporting Player for the duration of the MPD. | |||
| org.hbbtv_DASH-ERRORREP0027 | 1 | DASH Errors - downloadable fonts - unreachable server | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL, which indicates a hostname and the serviceLocation "hbbtvTest". The MPD contains one period containing three adaptation sets - one audio, one video and one subtitles. The subtitles adaptation set contains an EssentialProperty descriptor with @schemeIdUri="urn:dvb:dash:fontdownload:2014", @value="1", @mimeType="application/font-woff", @url="<URL of font on non-existent server>" @fontFamily="<something appropriate>". When an application requests playback of this MPD the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=C01 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of font on non-existent server> ipaddress=<IP address of font server> | 2024-1 2023-3 2023-2 2022-3 2022-2 2022-1 2021-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: Host unreachable Value: "C01" ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0028 | 1 | DASH Errors - downloadable fonts - 404 not found | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL, which indicates a hostname and the serviceLocation "hbbtvTest". The MPD contains one period containing three adaptation sets - one audio, one video and one subtitles. The subtitles adaptation set contains an EssentialProperty descriptor with @schemeIdUri="urn:dvb:dash:fontdownload:2014", @value="1", @mimeType="application/font-woff", @url="<absolute URL which points at non-existent file on a real server>" @fontFamily="<something appropriate>". When an application requests playback of this MPD the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=404 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<absolute URL which points at non-existent file on a real server> ipaddress=<IP address of font server> | 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 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-ERRORREP0029 | 1 | DASH Errors - downloadable fonts - invalid file format | An MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL, which indicates a hostname and the serviceLocation "hbbtvTest". The MPD contains one period containing three adaptation sets - one audio, one video and one subtitles. There is a file containing 20 bytes, each 0xFF, on an HTTP server which the terminal can access. The subtitles adaptation set contains an EssentialProperty descriptor with @schemeIdUri="urn:dvb:dash:fontdownload:2014", @value="1", @mimeType="application/font-woff", @url="<absolute URL which points to the corrupt file>" @fontFamily="<something appropriate>". When an application requests playback of this MPD the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=M01 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<absolute URL which points to the corrupt file> ipaddress=<IP address of font server> | 2024-1 2023-3 2023-2 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-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: Corrupt media – Not otherwise specified Value: "M01" ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] WOFF,section 4: The signature field in the WOFF header MUST contain the "magic number" 0x774F4646. If the field does not contain this value, user agents MUST reject the file as invalid. | |||
| org.hbbtv_DASH-ERRORREP0030 | 1 | DASH Errors - player maintains status as a reporting player with dynamic MPD after refresh period | A dynamic MPD for a live A/V stream contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="500" @dvb:reportingUrl=<URL to test server> The MPD@minimumUpdatePeriod is set to cause the terminal to refresh the MPD. Media segments are arranged to become unavailable some time after the first MPD refresh will have occurred. Whenever the terminal plays the stream, then after an MPD update occurs, the reporting status of the terminal does not change. Specifically, each of 6 times the terminal is requested to play the stream, it either (a) makes exactly one report with errorcode=S00, with the report being made before the MPD update, and then makes up to three subsequent reports after the update with errorcode=404, or (b) makes no report. | 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.3.4: A Player's status, as a reporting Player or not, shall remain static for the duration of the MPD, regardless of MPD updates. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in clause 10.8.5 occurs; ... Error Type: HTTP error status code - Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL TS-103-285,section 10.8.5: This clause lists errors as they are likely to be seen at a Player and the category they belong in. ... HTTP Status Code: 404 (Not found) - Error category: Missing segments ... Table 20: Specific errors and their categories TS-103-285,section 10.8.6: Error Category: Missing segments MPD@type: dynamic Action to take: The Player shall reload the MPD. If the MPD indicates a source of time as specified in clause 4.7.3 the Player shall resynchronize to one of the time sources as described in clause 4.7.3. If, as a result of reloading the MPD and performing any required time synchronization, the Player determines the request is no longer appropriate, it shall adjust its position in the media to reflect the new MPD and any new time value. If the request is still valid the Player may retry the request up to the max number of retries specified. Maximum Number of retries: 2 Table 21: Action to take in reaction to errors in the different categories | |||
| org.hbbtv_DASH-ERRORREP0031 | 1 | DASH Errors - player maintains status as a reporting player with dynamic MPD after an MPD update event message | A dynamic MPD for a live A/V stream contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="500" @dvb:reportingUrl=<URL to test server> The MPD indicates that there will be inband MPD events on the video representation. An MPD expiration event is present in the video representation some time into the stream. Segments become unavailable from the server some time later. Whenever the terminal plays the stream, then after an MPD update occurs, the reporting status of the terminal does not change. Specifically, each of 6 times the terminal is requested to play the stream, it either (a) makes exactly one report with errorcode=S00, with the report being made before the MPD update, and then makes up to three subsequent reports after the update with errorcode=404, or (b) makes no report. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-3 2020-2 2020-1 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.3.4: A Player's status, as a reporting Player or not, shall remain static for the duration of the MPD, regardless of MPD updates. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in clause 10.8.5 occurs; ... Error Type: HTTP error status code - Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL TS-103-285,section 10.8.5: This clause lists errors as they are likely to be seen at a Player and the category they belong in. ... HTTP Status Code: 404 (Not found) - Error category: Missing segments ... Table 20: Specific errors and their categories TS-103-285,section 10.8.6: Error Category: Missing segments MPD@type: dynamic Action to take: The Player shall reload the MPD. If the MPD indicates a source of time as specified in clause 4.7.3 the Player shall resynchronize to one of the time sources as described in clause 4.7.3. If, as a result of reloading the MPD and performing any required time synchronization, the Player determines the request is no longer appropriate, it shall adjust its position in the media to reflect the new MPD and any new time value. If the request is still valid the Player may retry the request up to the max number of retries specified. Maximum Number of retries: 2 Table 21: Action to take in reaction to errors in the different categories | |||
| org.hbbtv_DASH-ERRORREP0032 | 1 | DASH Errors - player reports missing segments in an audio only stream | A static MPD contains a Metrics element with the attribute @metrics="DVBErrors". Within that is a Reporting element with the following attributes: @schemeIdUri="urn:dvb:dash:reporting:2014" @value="1" @dvb:probability="1000" @dvb:reportingUrl=<URL to test server> The MPD contains one absolute BaseURL with the serviceLocation "hbbtvTest". There is only one adaptation set in the MPD. This adaptation set contains one audio Representation. On the media server the fourth media segment is missing from the audio representation. When an application requests playback of this MPD (from the beginning) the client makes a GET request to the URL indicated by <URL to test server> with a query string including the following field, value pairs: errorcode=404 mpdurl=<URL of the MPD in use> terror=<expected time including timezone +/-10s> url=<URL of a media or initialisation segment> ipaddress=<IP address of media server> servicelocation=hbbtvTest | 2024-1 2023-3 2023-2 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.12.4: Each entry in the DVBErrors list is an "error event". An error event shall be generated each time any of the following occur: * an error as identified in 10.8.5 occurs * any other error with an errorcode assigned in Table 23, including SSL connection errors, unrecognised HTTP status codes or corrupt media, occurs. Error Type: HTTP error status code Value: HTTP status code ... Table 23: Identifiers which are to be substituted within an ErrorURL ... [various fields including some derived from BaseURL] | |||
| org.hbbtv_DASH-EVENT0010 | 1 | DASH - Events - Poll for new MPD based on MPD validity expiration event with @value = 1 | When a terminal is presenting a DASH MPD with an InbandEventStream with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and its @value attribute set to 1, on a Representation that is currently being decoded, and an MPD validity expiration event is received on a Representation that is currently being decoded, the terminal polls for a new MPD. | 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 | TS-103-285,section 9.1.4: If an InbandEventStream element with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and the @value attribute set to 1 or 2 is present on a Representation that is currently being decoded, then a DASH player shall only poll for a new MPD if it receives an MPD validity expiration event. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-EVENT0011 | 1 | DASH - Events - Do not poll for new MPD based on minimumUpdateTime when validity expiration InbandEventStream is present with @value = 1 | When a terminal is presenting a DASH MPD with an InbandEventStream with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and its @value attribute set to "1", on a Representation that is currently being decoded, and the MPD@minimumUpdatePeriod is defined and segment duration is no longer than the minimumUpdatePeriod, and no MPD validity expiration event is present in the segments of any Representation that is currently being decoded, then the terminal does not poll for a new MPD. | 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 | TS-103-285,section 9.1.4: If an InbandEventStream element with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and the @value attribute set to 1 or 2 is present on a Representation that is currently being decoded, then a DASH player shall only poll for a new MPD if it receives an MPD validity expiration event. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-EVENT0020 | 1 | DASH - Events - Poll for new MPD based on MPD validity expiration event with @value = 2 | Two dynamic MPDs exist. (A) contains a single Representation with @id "1", which contains an InbandEventStream with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and its @value attribute set to "2". (B) is identical except that the media URLs for the Representation with @id "1" differ. <C> is defined as the patch which can be applied to (A) to yield (B). When presenting A, and an MPD validity expiration event with presentation_time_delta 0 and message_data <C> is received on the Representation that is currently being decoded, the terminal starts downloading media segments with URLs as in MPD (B). | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 9.1.4: If an InbandEventStream element with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and the @value attribute set to 1 or 2 is present on a Representation that is currently being decoded, then a DASH player shall only poll for a new MPD if it receives an MPD validity expiration event. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-EVENT0021 | 1 | DASH - Events - Do not poll for new MPD based on minimumUpdateTime when validity expiration InbandEventStream is present with @value = 2 | When a terminal is presenting a DASH MPD with an InbandEventStream with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and its @value attribute set to "2", on a Representation that is currently being decoded, and the MPD@minimumUpdatePeriod is defined and segment duration is no longer than the minimumUpdatePeriod, and no MPD validity expiration event is present in the segments of any Representation that is currently being decoded, then the terminal does not poll for a new MPD. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 9.1.4: If an InbandEventStream element with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and the @value attribute set to 1 or 2 is present on a Representation that is currently being decoded, then a DASH player shall only poll for a new MPD if it receives an MPD validity expiration event. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-EVENT0022 | 1 | DASH - Events - Terminal stops presentation when MPD validity expiration event with presentation_time_delta 0 and event_duration 0 is received | When a terminal is presenting a DASH MPD with an InbandEventStream with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and @value set to "1", on a Representation that is currently being decoded, and an MPD validity expiration event with presentation_time_delta 0 and event_duration 0 is received on that Representation, the terminal stops the presentation. | 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 | TS-103-285,section 9.1.4: If an InbandEventStream element with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and the @value attribute set to "1" or "2" is present on a Representation that is currently being decoded, then a DASH player shall only poll for a new MPD if it receives an MPD validity expiration event. [...] If the scheme_id_uri is set to "urn:mpeg:dash:event:2012" and the value is set to 1, then the fields in the event message box shall document the following: ... The event duration expresses the remaining duration of Media Presentation from the event time. If the event duration is 0, Media Presentation ends at the event time. If 0xFFFF, the media presentation duration is unknown. In the case in which both presentation_time_delta and event_duration are zero, then the Media Presentation is ended. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-EVENT0040 | 1 | DASH - Events - Do not download Representations solely to access InbandEventStream | An MPD contains three adaptation sets: one video, one audio and one alternative audio. Each adaptation set contains a single representation. Each representation contains an InbandEventStream with a @schemeIdUri unique with the MPD. When a terminal configured for video and main audio playback presents this MPD, it does not download any segments from the alternative audio Representation. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 9.1.6: Players shall not download a Representation solely to gain access to an InbandEventStream contained within it. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-EVENT0050 | 1 | DASH - Events - Do not create TextTrack for MPEG DASH-specific InbandEventStreams | When a terminal is presenting a DASH MPD with an InbandEventStream with @schemeIdUri set to "urn:mpeg:dash:event:2012" in the MPD or a selected representation, the terminal does not provide a TextTrack for the "urn:mpeg:dash:event:2012" event stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.2: A TextTrack shall be provided for each event stream included in currently selected Representations as defined in clause 5.10.3 of MPEG DASH [29] excluding DASH-specific events as defined in clause 5.10.4 of MPEG DASH [29] and excluding events streams defined by the DVB DASH specification [45] to be consumed by the terminal. DASH,section 5.10.4.1: DASH specific events that are of relevance for the DASH client are signalled in the MPD. The URN "urn:mpeg:dash:event:2012" is defined to identify the event scheme defined in Table 22. | |||
| org.hbbtv_DASH-EVENT0060 | 1 | DASH - Events - Do not create TextTrack for DVB DASH-specific InbandEventStreams | When a terminal is presenting a DASH MPD with an InbandEventStream with @schemeIdUri set to "urn:dvb:iptv:cpm:2014" in the MPD or a selected representation, the terminal does not provide a TextTrack for the "urn:dvb:iptv:cpm:2014" event stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 9.1.2.1: Content programme metadata may be delivered in the MPD by using an EventStream or in Media Segments using an InbandEventStream. It provides content identifiers and basic metadata relating to the current programme. HBBTV,section 9.3.2.2: A TextTrack shall be provided for each event stream included in currently selected Representations as defined in clause 5.10.3 of MPEG DASH [29] excluding DASH-specific events as defined in clause 5.10.4 of MPEG DASH [29] and excluding events streams defined by the DVB DASH specification [45] to be consumed by the terminal. | |||
| org.hbbtv_DASH-EVENT0070 | 1 | DASH - Events - Do not create TextTrack for MPEG DASH-specific EventStreams | When a terminal is presenting a DASH MPD with an EventStream with @schemeIdUri set to "urn:mpeg:dash:event:2012" in the MPD or a selected representation, the terminal does not provide a TextTrack for the "urn:mpeg:dash:event:2012" event stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.2: A TextTrack shall be provided for each event stream signalled in the MPD as defined in clause 5.10.2 of MPEG DASH [29] excluding DASH-specific events as defined in clause 5.10.4 of MPEG DASH [29] and excluding events streams defined by the DVB DASH specification [45] to be consumed by the terminal. DASH,section 5.10.4.1: DASH specific events that are of relevance for the DASH client are signalled in the MPD. The URN "urn:mpeg:dash:event:2012" is defined to identify the event scheme defined in Table 22. | |||
| org.hbbtv_DASH-EVENT0080 | 1 | DASH - Events - Do not create TextTrack for DVB DASH-specific EventStreams | When a terminal is presenting a DASH MPD with an EventStream with @schemeIdUri set to "urn:dvb:iptv:cpm:2014" in the MPD or a selected representation, the terminal does not provide a TextTrack for the "urn:dvb:iptv:cpm:2014" event stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 9.1.2.1: Content programme metadata may be delivered in the MPD by using an EventStream or in Media Segments using an InbandEventStream. It provides content identifiers and basic metadata relating to the current programme. HBBTV,section 9.3.2.2: A TextTrack shall be provided for each event stream signalled in the MPD as defined in clause 5.10.2 of MPEG DASH [29] excluding DASH-specific events as defined in clause 5.10.4 of MPEG DASH [29] and excluding events streams defined by the DVB DASH specification [45] to be consumed by the terminal. | |||
| org.hbbtv_DASH-EVENT0090 | 1 | DASH - Events - Handling InbandEventStreams with identical @schemeIdUri and @value in multiple AdaptationSets | An MPD contains two AdaptationSets with @id A and B respectively, each with a single Representation, and each Representation with an InbandEventStream with @schemeIdUri "<X>", @value "<Y>", where <X> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB, and <Y> is a valid value for <X>. The media for A's Representation contains ten events with the following properties: scheme_id_uri: <X> value: <Y> timescale: 1 presentation_time_delta: 0 event_duration: 0xFFFF id: z (where z is the event number from [1..10]) The media for B's representation also contains ten events with identical properties except that the id property takes the value for z from the range [11..20] When a terminal has completed presentation of the manifest with both AdaptationSets selected, the TextTrack with property inBandMetadataTrackDispatchType "<X> <Y>" contains all ten events from A OR all ten events from B. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 9.1.6: InbandEventStreams with the same @schemeIdUri and @value attributes that are present in multiple AdaptationSets shall be considered equivalent and only one of them shall be processed at any particular time. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-EVENT0110 | 1 | DASH - Events - Signalling removal of event streams from MPD | Two dynamic DASH MPDs exist: (A) contains an MPD@EventStream with @schemeIdUri "<X>", @value 1, where <X> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB; (B) is identical except that it does not contain any EventStream nodes. When presenting A, the terminal updates due to MPD@minimumUpdatePeriod expiring, and receives manifest B; the terminal fires a removetrack event on the TextTrackList. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 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 9.3.2.2: Changes in the set of event streams, either by updating the MPD or by changing the selected Representation, shall be reported using the onaddtrack/addtrack and onremovetrack/removetrack events. | ||
| org.hbbtv_DASH-EVENT0120 | 1 | DASH - Events - Signalling addition of event streams from MPD | Two dynamic DASH MPDs exist: (A) does not contain any EventStream nodes; (B) is identical except that it contains an MPD@EventStream with @schemeIdUri "<Y>", @value 1, where <Y> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB. When presenting A, the terminal updates due to MPD@minimumUpdatePeriod expiring, and receives manifest B; the terminal fires an addtrack event on the TextTrackList. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 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 9.3.2.2: Changes in the set of event streams, either by updating the MPD or by changing the selected Representation, shall be reported using the onaddtrack/addtrack and onremovetrack/removetrack events. | ||
| org.hbbtv_DASH-EVENT0130 | 1 | DASH - Events - Signalling removal of event streams when selecting a different representation | An MPD exists which contains a single AdaptationSet containing two Representations: (A) contains an InbandEventStream with @schemeIdUri "<X>", @value 1, where <X> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB; (B) is identical except that it does not contain any InbandEventStream nodes. When a terminal is presenting representation A and a representation change to B is forced to occur, the terminal fires a removetrack event on the TextTrackList. | 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 9.3.2.2: Changes in the set of event streams, either by updating the MPD or by changing the selected Representation, shall be reported using the onaddtrack/addtrack and onremovetrack/removetrack events. | |||
| org.hbbtv_DASH-EVENT0140 | 1 | DASH - Events - Signalling addition of event streams when selecting a different representation | An MPD contains a single AdaptationSet containing two Representations: (A) does not contain any InbandEventStream nodes; (B) is identical except that it contains an InbandEventStream with @schemeIdUri "<X>", @value 1, where <X> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB. When a terminal is presenting representation A and a representation change to B is forced to occur, the terminal fires an addtrack event on the TextTrackList. | 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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.3.2.2: Changes in the set of event streams, either by updating the MPD or by changing the selected Representation, shall be reported using the onaddtrack/addtrack and onremovetrack/removetrack events. | |||
| org.hbbtv_DASH-EVENT0150 | 1 | DASH - Events - Mapping of MPD EventStreams to TextTrack objects | When a terminal starts presenting an MPD which contains an EventStream with @schemeIdUri "<X>", @value "<Y>", where <X> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB, and <Y> is a valid value for <X>, the terminal creates a TextTrack object with properties set to the following values: kind: "metadata" label: "" language: "" id: "" inBandMetadataTrackDispatchType: "<X> <Y>" mode: "hidden" | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.2: The mapping between DASH event streams and TextTrack objects shall be as follows; kind "metadata" label: Empty string language: Empty string id: Empty String inBandMetadataTrackDispatchType: @schemeIdUri + "U+0020" (SPACE character) + @value mode: hidden | |||
| org.hbbtv_DASH-EVENT0160 | 1 | DASH - Events - Mapping of InbandEventStreams to TextTrack objects | When a terminal starts presenting a Representation which contains an InbandEventStream with @schemeIdUri "<X>", @value "<Y>", where <X> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB, and <Y> is a valid value for <X>, the terminal creates a TextTrack object with properties set to the following values: kind: "metadata" label: "" language: "" id: "" inBandMetadataTrackDispatchType: "<X> <Y>" mode: "hidden" | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.2: The mapping between DASH event streams and TextTrack objects shall be as follows; kind "metadata" label: Empty string language: Empty string id: Empty string inBandMetadataTrackDispatchType: @schemeIdUri + "U+0020" (SPACE character) + @value mode: hidden | |||
| org.hbbtv_DASH-EVENT0170 | 1 | DASH - Events - Constrain minimum duration of DataCue | An MPD contains an EventStream with @schemeIdUri "<X>", @value "<Y>", @timescale 1000, where <X> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB, and <Y> is a valid value for <X>. The EventStream contains a single Event with @duration 100. When the terminal starts presenting the MPD, the terminal adds a cue to the TextTrack with inBandMetadataTrackDispatchType "<X> <Y>" with startTime 0 and endTime 250. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.2: For any DASH event with a duration of 250ms or less, the terminal shall set the endTime property of the corresponding DataCue object to the startTime + 250ms. | |||
| org.hbbtv_DASH-EVENT0180 | 1 | DASH - Events - Raise cuechange event for any DataCue with duration of at least 250ms | An MPD contains an EventStream with @schemeIdUri "<X>", @value "<Y>", @timescale 1000, where <X> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB, and <Y> is a valid value for <X>. The EventStream contains a single Event with @duration 100, @id 1. When the terminal starts presenting the MPD, the terminal raises a cuechange event with a cue with startTime 0, endTime 250 and id 1 in the activeCues list. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.2: For any DataCue with a duration of at least 250 ms, the Terminal shall ensure that a cuechange event is raised with the cue listed in the activeCues list. | |||
| org.hbbtv_DASH-EVENT0210 | 1 | DASH - Events - TextTrack cues contents for InbandEventStreams | An MPD contains a single representation with <InbandEventStream schemeIdUri="<X>" value="<Y>" />, where <X> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB, and <Y> is a valid value for <X> The media for the representation contains an emsg box with parameters as follows: scheme_id_uri: "<X>" value: "<Y>" timescale: 1 presentation_time_delta: 0 event_duration: 0xFFFF id: 1 message_data: 0x54455354 When a terminal presents the MPD and encounters the emsg box, the cues attribute of the TextTrack with inBandMetadataTrackDispatchType "<X> <Y>" contains a cue with startTime 0, endTime Number.MAX_VALUE, id 1 and data 0x54455354. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.2: For an InbandEventStream, the cues attribute shall contain cues representing at least the DASH Events whose start times are less than or equal to the current playback position and whose end times are greater than the current playback position. | |||
| org.hbbtv_DASH-EVENT0260 | 1 | DASH - Events - Minimum concurrent events handled per event stream | An MPD contains a single representation with <InbandEventStream schemeIdUri="<X>" value="<Y>" />, where <X> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB, and <Y> is a valid value for <X>. The media for the representation contains eleven emsg boxes with parameters as follows: scheme_id_uri: "<X>" value: "<Y>" timescale: 1 presentation_time_delta: 0 event_duration: 0xFFFF message_data: 0x54455354 The boxes are identical except that id is a value in the range 0..10, taken sequentially. When the terminal has completed presentation of the MPD, the TextTrack with inBandMetadataTrackDispatchType "<X> <Y>" contains at least the ten cues with id 1..10. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 9.1.5: Players shall be able to track at least 10 concurrent or overlapping inband events from each inband event stream that it is monitoring. If a further overlapping event is encountered, Players may discard stored information about the oldest event. This may cause any further repetition of the discarded event to be registered as a new event. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-EVENT0270 | 1 | DASH - Events - Handling InbandEventStreams in every decoded Representation | An MPD contains three AdaptationSets: video, audio and subtitles, each containing a single Representation, each of those with a single InbandEventStream with an identical @schemeIdUri. video @value 1, audio @value 2, subtitles @value 3. The media for each representation contains a single emsg box with the following values: scheme_id_uri: @schemeIdUri value: @value timescale: 1 presentation_time_delta: 0 event_duration: 0xFFFF message_data: 0x54455354 When a terminal has presented the MPD with all three AdaptationSets selected, four TextTracks exist. One TextTrack corresponds to the subtitle AdaptationSet, and three contain one cue each with the correct message payload and id. | 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 | TS-103-285,section 9.1.6: Players shall support monitoring of InbandEventStreams in all Representations that it is decoding at the time. HBBTV,section 9.3.2.2: Specifically the TextTrackList shall include TextTracks corresponding to DASH event streams as follows: A TextTrack shall be provided for each event stream signalled in the MPD as defined in clause 5.10.2 of MPEG DASH ISO/IEC 23009-1 [29] excluding DASH-specific events as defined in clause 5.10.4 of MPEG DASH ISO/IEC 23009-1 [29] and excluding events streams defined by the DVB DASH specification [45] to be consumed by the terminal. A TextTrack shall be provided for each event stream included in currently selected Representations as defined in clause 5.10.3 of MPEG DASH ISO/IEC 23009-1 [29] excluding DASH-specific events as defined in clause 5.10.4 of MPEG DASH ISO/IEC 23009-1 [29] and excluding events streams defined by the DVB DASH specification [45] to be consumed by the terminal. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-EVENT0280 | 1 | DASH - Events - Signalling cuechange events | An MPD contains <EventStream schemeIdUri="<X>" value="<Y>" timescale="1000"> <Event presentationTime="0" id="1">TEST</Event> <Event presentationTime="100" id="2">TEST</Event> <Event presentationTime="200" id="3">TEST</Event> <Event presentationTime="300" id="4">TEST</Event> <Event presentationTime="400" id="5">TEST</Event> <Event presentationTime="500" id="6">TEST</Event> <Event presentationTime="600" id="7">TEST</Event> <Event presentationTime="700" id="8">TEST</Event> <Event presentationTime="800" id="9">TEST</Event> <Event presentationTime="900" id="10">TEST</Event> </EventStream>, where <X> is any valid schemeIdURI other than those reserved as DASH-specific by MPEG or DVB, and <Y> is a valid value for <X> When a terminal presents the MPD, the cuechange event is raised at least four times. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 9.3.2.2: The cuechange event of the TextTrack object shall be fired according to the "time marches on" algorithm defined in clause 4.7.10.8 of the HTML5 Recommendation [54]. | |||
| org.hbbtv_DASH-EVENT1000 | 1 | DASH - Events - Compatibility with emsg box in a video stream | When a terminal presents a valid DASH stream containing audio and video in which each video media segment has a valid emsg box at the start, the DASH stream plays normally. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 9.1.3: Application messages may be delivered in the MPD by using an EventStream or in Representations using an InbandEventStream. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. DASH,section 5.10.3.3.1: A Media Segment if encapsulated in ISO BMFF may contain one or more event message (‘emsg’) boxes. If present, any 'emsg' box shall be placed before any ‘moof’ box. ... If a DASH client detects an event message box with a scheme that is not defined in MPD, the client is expected to ignore it. | |||
| org.hbbtv_DASH-EVENT1010 | 1 | DASH - Events - Compatibility with emsg box in an audio stream | When a terminal presents a valid DASH stream containing audio and video in which each audio media segment has a valid emsg box at the start, the DASH stream plays normally. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 9.1.3: Application messages may be delivered in the MPD by using an EventStream or in Representations using an InbandEventStream. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. DASH,section 5.10.3.3.1: A Media Segment if encapsulated in ISO BMFF may contain one or more event message (‘emsg’) boxes. If present, any 'emsg' box shall be placed before any ‘moof’ box. ... If a DASH client detects an event message box with a scheme that is not defined in MPD, the client is expected to ignore it. | |||
| org.hbbtv_DASH-EVENT1022 | 1 | DASH - Events - Terminal stops presentation and stops requesting segments when notified of stream end | A dynamic DASH MPD indicates an adaptation set with an InbandEventStream with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and @value set to "1". The MPD contains one period. Initially the MPD indicates no @mediaPresentationDuration attribute and the period element contains no @duration attribute. The media segments contain no sidx boxes. The terminal is instructed to play the MPD. No seek operations are made by the application. During playback, the MPD is updated on the server to include a @mediaPresentationDuration attribute. This value indicates that the stream ends at media time Tend. The @publishTime attribute is updated to indicate the time when the MPD change was made. All media segments with a segment availability start time after the time at which the MPD was updated include an event message box. All of these event message boxes have the same id, and a duration of 0. Their message_data is a time which is 1s before the @publishTime of the updated MPD, indicating that MPDs dated up to that time no longer correctly describe the presentation. The presentation_time_delta value is the difference between Tend and the first presentation time in the media segment, in units of the Timescale set in the event message box. The client stops presentation when the media time reaches Tend and does not request any media segments which would have a presentation time after Tend. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 9.1.4: If an InbandEventStream element with its @schemeIdUri attribute set to "urn:mpeg:dash:event:2012" and the @value attribute set to 1 or 2 is present on a Representation that is currently being decoded, then a DASH player shall only poll for a new MPD if it receives an MPD validity expiration event. ... If the DASH Player has an MPD which includes a value of the @publishTime attribute that is greater than or equal to the value of the publish time in the message_data of the event message box, then this event message box may be ignored. For example, this may happen when static Media Presentations are converted from a dynamic Media Presentation. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile ETSI TS 103 285 [45] as modified in the present document. HBBTV,section 9.3.2.1: The DVB DASH specification, ETSI TS 103 285 [45] requires support for the event mechanism defined in clause 5.10 of the MPEG DASH specification ISO/IEC 23009-1 [29]. DASH,section 5.10.4.2: If the scheme_id_uri is set to "urn:mpeg:dash:event:2012" and the value is set to 1, then the fields in the event message box shall document the following: - the message_data field contains the publish time of an MPD, i.e. the value of the MPD@publishTime. - The media presentation time beyond the event time (indicated time by presentation_time_delta) is correctly described only by MPDs with publish time greater than indicated value in the message_data field. - the event duration expresses the remaining duration of Media Presentation from the event time. If the event duration is 0, Media Presentation ends at the event time. DASH,section 5.10.3.3.4: presentation_time_delta provides the Media Presentation time delta of the media presentation time of the event and the earliest presentation time in this segment. If the segment index is present, then the earliest presentation time is determined by the field earliest_presentation_time of the first 'sidx' box. If the segment index is not present, the earliest presentation time is determined as the earliest presentation time of any access unit in the media segment. The timescale is provided in the timescale field. | ||
| org.hbbtv_DASH-ISOBMFF0010 | 1 | DASH stream scenarios - negative composition time offsets | When the video representations within a DASH media presentation use a version 1 trun box including negative values within the composition time offset field within that box the terminal shall correctly play the stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.2: Players shall support the usage of the track fragment run box ('trun') with negative composition offsets in order to maintain audio visual presentation synchronisation. Note: Negative composition offsets were added to ISO/IEC 14496-12:2008 in Amendment 3 | |||
| org.hbbtv_DASH-ISOBMFF0020 | 1 | DASH stream scenarios - version 1 tfdt boxes | When the audio and video representations within a DASH media presentation use a version 1 tfdt box including a 64 bit baseMediaDecodeTime the terminal shall correctly play the presentation. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 10.9.4.3: Track fragment decode times, particularly for large track timescale values, are likely to require the use of 64 bit values. Therefore Players shall support track fragment decode time using 64 bit numbers. ISO/IEC-14496-12,section 8.8.12: version is an integer that specifies the version of this box (0 or 1 in this specification). | |||
| org.hbbtv_DASH-ISOBMFF0030 | 1 | DASH stream scenarios - no styp or sidx with live profile | When a DASH media presentation using the live profile has media segments which contain neither styp nor sidx boxes and the $Time$ parameter is not used in a segment template then the terminal shall play the presentation correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. DASH,section 6.3.4.2: Each Media Segment may contain a ‘styp’ box and if present shall carry ‘msdh’ as a compatible brand. The conformance requirement of this brand is defined in this subclause. ... Each Media Segment may contain one or more ‘sidx’ boxes. DASH,section 5.3.9.6.1: When the SegmentTemplate is in use and the $Time$ identifier is present in the SegmentTemplate@media then * at least one Segment Index (‘sidx’) box shall be present | |||
| org.hbbtv_DASH-ISOBMFF0040 | 1 | DASH stream scenarios - styp with live profile | When a DASH media presentation using the live profile has media segments which contain an styp box at the start of each media segment, but do not contain an sidx box and the $Time$ parameter is not used in a segment template then the terminal shall play the presentation correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. DASH,section 6.3.4.2: Each Media Segment may contain a ‘styp’ box and if present shall carry ‘msdh’ as a compatible brand. The conformance requirement of this brand is defined in this subclause. ... Each Media Segment may contain one or more ‘sidx’ boxes. DASH,section 5.3.9.6.1: When the SegmentTemplate is in use and the $Time$ identifier is present in the SegmentTemplate@media then * at least one Segment Index (‘sidx’) box shall be present | |||
| org.hbbtv_DASH-ISOBMFF0050 | 1 | DASH stream scenarios - sidx with live profile | When a DASH media presentation using the live profile has media segments which contain a valid sidx box at the start of each media segment, but do not contain an styp box and the $Time$ parameter is not used in a segment template then the terminal shall play the presentation correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. DASH,section 6.3.4.2: Each Media Segment may contain a ‘styp’ box and if present shall carry ‘msdh’ as a compatible brand. The conformance requirement of this brand is defined in this subclause. ... Each Media Segment may contain one or more ‘sidx’ boxes. DASH,section 5.3.9.6.1: When the SegmentTemplate is in use and the $Time$ identifier is present in the SegmentTemplate@media then * at least one Segment Index (‘sidx’) box shall be present | |||
| org.hbbtv_DASH-ISOBMFF0060 | 1 | DASH stream scenarios - styp and sidx with live profile | When a DASH media presentation using the live profile has media segments which contain an styp box indicating the 'msdh' compatible brand at the start of each media segment followed by a valid sidx box and the $Time$ parameter is not used in a segment template then the terminal shall play the presentation correctly. | 2024-1 2023-3 2023-2 2023-1 2022-2 2022-1 2021-3 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. DASH,section 6.3.4.2: Each Media Segment may contain a ‘styp’ box and if present shall carry ‘msdh’ as a compatible brand. The conformance requirement of this brand is defined in this subclause. ... Each Media Segment may contain one or more ‘sidx’ boxes. DASH,section 5.3.9.6.1: When the SegmentTemplate is in use and the $Time$ identifier is present in the SegmentTemplate@media then * at least one Segment Index (‘sidx’) box shall be present | |||
| org.hbbtv_DASH-ISOBMFF0070 | 1 | DASH stream scenarios - unreferenced data in mdat (AVC) | When a valid DASH media presentation using the live profile has audio, subtitle and AVC video Representations in all three of which there are (a) segments in which the 'mdat' box contains arbitrary data (unreferenced from the 'trun' box) preceding the media data, and (b) segments in which the 'mdat' box contains arbitrary data (unreferenced from the 'trun' box) following the media data, and the presentation is played using the HTML5 video element, the terminal plays the video, audio and subtitles correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 2018-3 2018-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. ISO/IEC-14496-12,section 8.1.1.1: The actual media data follows the type field; its structure is described by the metadata (see particularly the sample table, subclause 8.5, and the item location box, subclause 8.11.3). ISO/IEC-14496-12,section C.7.1: The media data box (‘mdat’) is merely one possible location, and looked at by itself, it can only be considered an un-ordered bag of un-identifiable bits. There is no assurance that the desirable material in a media-data box is the only data in the box or in any particular order, and, especially if data references are used, there is no assurance that any particular sample is even in a media-data box at all. | |||
| org.hbbtv_DASH-ISOBMFF0080 | 1 | DASH stream scenarios - unreferenced data in mdat (HEVC) | When a valid DASH media presentation using the live profile has audio, subtitle and HEVC video Representations in all three of which there are (a) segments in which the 'mdat' box contains arbitrary data (unreferenced from the 'trun' box) preceding the media data, and (b) segments in which the 'mdat' box contains arbitrary data (unreferenced from the 'trun' box) following the media data, and the presentation is played using the HTML5 video element, the terminal plays the video, audio and subtitles correctly. | 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-1 2018-3 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. ISO/IEC-14496-12,section 8.1.1.1: The actual media data follows the type field; its structure is described by the metadata (see particularly the sample table, subclause 8.5, and the item location box, subclause 8.11.3). ISO/IEC-14496-12,section C.7.1: The media data box (‘mdat’) is merely one possible location, and looked at by itself, it can only be considered an un-ordered bag of un-identifiable bits. There is no assurance that the desirable material in a media-data box is the only data in the box or in any particular order, and, especially if data references are used, there is no assurance that any particular sample is even in a media-data box at all. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-MISC0010 | 1 | DASH Miscellany - HTTP session cookie support | A live profile MPD has only relative URLs. The HTTP server returning the MPD includes a Set-Cookie header that is valid according to RFC 6265 Section 4.1.1 and includes a cookie name, cookie value and Domain and Path attributes covering all media segment locations, and does not include an Expires attribute. When the terminal starts playing the DASH presentation described by this MPD, all segment requests made by the terminal include an HTTP Cookie header containing the cookie name and value. | 2024-1 2023-3 2023-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 | TS-103-285,section 10.11: Players shall support [...] the use of Cookies as specified in RFC 6265 [18]. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. RFC6265,section 5.2: [...] the user agent MUST parse the field-value of the Set-Cookie header field as a set-cookie-string [...]. RFC6265,section 5.4: The user agent includes stored cookies in the Cookie HTTP request header. [...] If the user agent does attach a Cookie header field to an HTTP request, the user agent MUST send the cookie-string [...] as the value of the header field. | |||
| org.hbbtv_DASH-ONDEMAND001 | 1 | Test for DASH On Demand Profile | When the terminal is asked to play an MPEG DASH on-demand MPD with @profiles containing "urn:dvb:dash:profile:dvb-dash:2014,urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" and a Representation consisting of a single Segment that complies with the requirements for an Indexed Self-Initializing Media Segment and for which SegmentBase@indexRange is present, it plays correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile ... The URN for the profile (MPEG Interoperability Point) shall be "urn:dvb:dash:profile:dvb-dash:2014". TS-103-285,section 4.2.8: Representations not inferred to have an @profiles attribute equal to "urn:dvb:dash:profile:dvb-dash:isoff-ext-on-demand:2014" may be ignored ... If Representation consists of a single Segment that complies with Indexed Media Segment or Indexed Self-Initializing Media Segment, this Representation element can be ignored unless SegmentBase@indexRange is present. DASH,section 6.3.5.2: The Indexed Self-Initializing Media Segment conforms to the concatenation of an Initialization Segment and a single Indexed Media Segment without the 'styp' box preceeding the Media Segment and shall carry ‘dash’ as a compatible brand. The format of the Indexed self-initializing Media Segment is a conforming ISO base media file format file and defines the ‘dash’ brand. | |||
| org.hbbtv_DASH-SE0001 | 1 | DASH - avc3 sample entry in ISO BMFF segments (static parameter sets in samples) | When an application requests presentation of MPEG DASH content with a single H.264 video Representation using ISO BMFF segments and an 'avc3' sample entry name in which static parameter sets are present in the samples but not in the sample entry, the Representation plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 5.1.2: The encapsulation of H.264/AVC video data is based on the ISO BMFF as defined in ISO/IEC 14496-15 ... Content should be offered using Inband Storage for SPS/PPS i.e. sample entries 'avc3' and 'avc4' based on ISO/IEC 14496-15 [5]. Content may be offered using either of the 'avc1' or 'avc2' sample entries. ISO/IEC-14496-15,section 5.4.4: When the sample entry name is 'avc3' or 'avc4', parameter sets may be present in both sample entry and as part of samples, and an update of a parameter set by a parameter set of the same type that is stored as part of a sample is possible. HBBTV,section E.4.4: Additionally terminals shall support both the 'avc1' and 'avc3' sample entry types for H.264 content that are referred to in clause 5.1.2 of that profile. | |||
| org.hbbtv_DASH-SE0002 | 1 | DASH - avc3 sample entry in ISO BMFF segments (parameter sets in sample entry) | When an application requests presentation of MPEG DASH content with a single H.264 video Representation using ISO BMFF segments and an 'avc3' sample entry name in which parameter sets are present in the sample entry but not in the samples, the Representation plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 5.1.2: The encapsulation of H.264/AVC video data is based on the ISO BMFF as defined in ISO/IEC 14496-15 ... Content should be offered using Inband Storage for SPS/PPS i.e. sample entries 'avc3' and 'avc4' based on ISO/IEC 14496-15 [5]. Content may be offered using either of the 'avc1' or 'avc2' sample entries. ISO/IEC-14496-15,section 5.4.4: When the sample entry name is 'avc3' or 'avc4', parameter sets may be present in both sample entry and as part of samples, and an update of a parameter set by a parameter set of the same type that is stored as part of a sample is possible. HBBTV,section E.4.4: Additionally terminals shall support both the 'avc1' and 'avc3' sample entry types for H.264 content that are referred to in clause 5.1.2 of that profile. | |||
| org.hbbtv_DASH-SE0003 | 1 | DASH - avc3 sample entry in ISO BMFF segments (parameter set changes in samples) | When an application requests presentation of MPEG DASH content with two H.264 video Representations using ISO BMFF segments and an 'avc3' sample entry name, the Representations having the resolutions 1920x1080 and 704x396 (as indicated both in the Representation @width and @height attributes in the MPD and in the width and height fields within the AVCSampleEntry in the Representation's Initialisation Segment), with the parameter sets present in the samples but not in the sample entry, with only those parameter sets needed for each Representation included in the samples of that Representation, then when a representation change is forced to occur, the stream continues to play with unchanged picture size but different resolution. | 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 | TS-103-285,section 5.1.2: The encapsulation of H.264/AVC video data is based on the ISO BMFF as defined in ISO/IEC 14496-15 ... Content should be offered using Inband Storage for SPS/PPS i.e. sample entries 'avc3' and 'avc4' based on ISO/IEC 14496-15 [5]. Content may be offered using either of the 'avc1' or 'avc2' sample entries. ISO/IEC-14496-15,section 5.4.4: When the sample entry name is 'avc3' or 'avc4', parameter sets may be present in both sample entry and as part of samples, and an update of a parameter set by a parameter set of the same type that is stored as part of a sample is possible. HBBTV,section E.4.4: Additionally terminals shall support both the 'avc1' and 'avc3' sample entry types for H.264 content that are referred to in clause 5.1.2 of that profile. | |||
| org.hbbtv_DASH-SE0004 | 1 | DASH - hev1 sample entry in ISO BMFF segments (static parameter sets in samples) | When an application requests presentation of MPEG DASH content with a single HEVC video Representation using ISO BMFF segments and an 'hev1' sample entry name in which static parameter sets are present in the samples but not in the sample entry, the Representation plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-1 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 5.2.1: The encapsulation of HEVC video data in ISO BMFF is defined in ISO/IEC 14496-15 [5]. Players which support HEVC shall support both sample entries using 'hvc1' and 'hev1’ (both storage for VPS/SPS/PPS within the initialisation segment or inband within the media segment). ISO/IEC-14496-15,section 8.3.2: [Parameter sets] may be stored in the sample entry and the samples when the sample entry name is 'hev1'. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-SE0005 | 1 | DASH - hev1 sample entry in ISO BMFF segments (parameter sets in sample entry) | When an application requests presentation of MPEG DASH content with a single HEVC Representation using ISO BMFF segments and an 'hev1' sample entry name in which parameter sets are present in the sample entry but not in the samples, the Representation plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 5.2.1: The encapsulation of HEVC video data in ISO BMFF is defined in ISO/IEC 14496-15 [5]. Players which support HEVC shall support both sample entries using 'hvc1' and 'hev1’ (both storage for VPS/SPS/PPS within the initialisation segment or inband within the media segment). ISO/IEC-14496-15,section 8.3.2: [Parameter sets] may be stored in the sample entry and the samples when the sample entry name is 'hev1'. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-SE0006 | 1 | DASH - hev1 sample entry in ISO BMFF segments (parameter set changes in samples) | When an application requests presentation of MPEG DASH content with two HEVC video Representations using ISO BMFF segments and an 'hev1' sample entry name, the Representations having the resolutions 1920x1080 and 704x396 (as indicated both in the Representation@width and @height attributes in the MPD and in the width and height fields within the HEVCSampleEntry in the Representation's Initialisation Segment), with the parameter sets present in the samples but not in the sample entry, with only those parameter sets needed for each Representation included in the samples of that Representation, then when a representation change is forced to occur, the stream continues to play with unchanged picture size but different resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 5.2.1: The encapsulation of HEVC video data in ISO BMFF is defined in ISO/IEC 14496-15 [5]. Players which support HEVC shall support both sample entries using 'hvc1' and 'hev1’ (both storage for VPS/SPS/PPS within the initialisation segment or inband within the media segment). ISO/IEC-14496-15,section 8.3.2: [Parameter sets] may be stored in the sample entry and the samples when the sample entry name is 'hev1'. ISO/IEC-14496-15,section 8.4.1.1.2: class HEVCSampleEntry() extends VisualSampleEntry ... HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. ISO/IEC-14496-12,section 8.5.2.2: class VisualSampleEntry(codingname) extends SampleEntry (codingname) { ... unsigned int(16) width; unsigned int(16) height; ... } | |||
| org.hbbtv_DASH-SE0031 | 1 | DASH - avc3 sample entry in ISO BMFF segments (parameter set changes in samples, common init segment) | When an application requests presentation of MPEG DASH content with two H.264 video Representations using ISO BMFF segments and an 'avc3' sample entry name, the Representations having the resolutions 1920x1080 and 704x396 (as indicated both in the Representation@width and @height attributes in the MPD) but with both Representations having a common Initialisation Segment in which the width and height fields within the AVCSampleEntry are 1920 and 1080 respectively, with the parameter sets present in the samples but not in the sample entry, with only those parameter sets needed for each Representation included in the samples of that Representation, then when a representation change is forced to occur, the stream continues to play with unchanged picture size but different resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 5.1.2: The encapsulation of H.264/AVC video data is based on the ISO BMFF as defined in ISO/IEC 14496-15 ... Content should be offered using Inband Storage for SPS/PPS i.e. sample entries 'avc3' and 'avc4' based on ISO/IEC 14496-15 [5]. Content may be offered using either of the 'avc1' or 'avc2' sample entries. TS-103-285,section 5.1.4: The AVCSampleEntry contained within the initialization segment of an H.264/AVC track contains a number of values indicating information about the encoded video. These values shall always be set such that the encoded video in all Representations using this initialization segment does not exceed the size, profile, level or compatibility indicated within the initialization segment, however the values are not required to indicate the exact size or nature of the specific stream. ISO/IEC-14496-15,section 5.4.4: When the sample entry name is 'avc3' or 'avc4', parameter sets may be present in both sample entry and as part of samples, and an update of a parameter set by a parameter set of the same type that is stored as part of a sample is possible. ISO/IEC-14496-15,section 5.4.2.1.2: class AVCSampleEntry() extends VisualSampleEntry ... HBBTV,section E.4.4: Additionally terminals shall support both the 'avc1' and 'avc3' sample entry types for H.264 content that are referred to in clause 5.1.2 of that profile. ISO/IEC-14496-12,section 8.5.2.2: class VisualSampleEntry(codingname) extends SampleEntry (codingname) { ... unsigned int(16) width; unsigned int(16) height; ... } | |||
| org.hbbtv_DASH-TIME0001 | 1 | DASH - UTCTiming - http-head in Dynamic MPD | When an application requests playback of MPEG DASH content with a dynamic MPD that contains one UTCTiming element with @schemeIdURI set to "urn:mpeg:dash:utc:http-head:2014" with @value set to an HTTP URL, the terminal makes an HTTP HEAD request for the specified URL. | 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 | TS-103-285,section 4.7.3: If the MPD is dynamic or if the MPD@availabilityStartTime is present then [... if] the MPD contains a UTCTiming element with the @schemeIdURI attribute set to "urn:mpeg:dash:utc:http-head:2014" [...] then the [...] Player shall use one of the timing information sources listed in the MPD to synchronize its clock. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-TIME0002 | 1 | DASH - UTCTiming - http-head in Static MPD with MPD@availabilityStartTime | When an application requests playback of MPEG DASH content with a static MPD with MPD@availabilityStartTime present that contains one UTCTiming element with @schemeIdURI set to "urn:mpeg:dash:utc:http-head:2014" with @value set to an HTTP URL, the terminal makes an HTTP HEAD request for the specified URL. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 4.7.3: If the MPD is dynamic or if the MPD@availabilityStartTime is present then [... if] the MPD contains a UTCTiming element with the @schemeIdURI attribute set to "urn:mpeg:dash:utc:http-head:2014" [...] then the [...] Player shall use one of the timing information sources listed in the MPD to synchronize its clock. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-TIME0003 | 1 | DASH - UTCTiming - http-head in dynamic MPD - correct use of time reference for availability time check | When an application requests playback of MPEG DASH content with an MPD in which (a) MPD@type="dynamic", (b) MPD@timeshiftBufferDepth is set to a finite value, (c) segmentTemplate is used and (d) has one UTCTiming element with @schemeIdURI set to "urn:mpeg:dash:utc:http-head:2014" and @value set to an HTTP URL to a server on which the time is set in the past by at least 10 seconds more than the value of MPD@timeshiftBufferDepth, the terminal requests segments that are within the availability time window with respect to the referenced server clock and does not request any segments that are not. | 2024-1 2023-3 2023-2 2023-1 2022-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 | TS-103-285,section 4.7.3: If the MPD is dynamic or if the MPD@availabilityStartTime is present then [... if] the MPD contains a UTCTiming element with the @schemeIdURI attribute set to "urn:mpeg:dash:utc:http-head:2014" [...] then the [...] Player shall use one of the timing information sources listed in the MPD to synchronize its clock. The Player shall not request segments prior to the segment availability start time with reference to any of the chosen UTCTiming methods. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | ||
| org.hbbtv_DASH-TIME0004 | 1 | DASH - UTCTiming - http-xsdate in dynamic MPD | When an application requests playback of MPEG DASH content with a dynamic MPD with MPD@availabilityStartTime present that contains one UTCTiming element with @schemeIdURI set to "urn:mpeg:dash:utc:http-xsdate:2014" with @value set to an HTTP URL, the terminal makes an HTTP GET request for the specified URL. | 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 | TS-103-285,section 4.7.3: If the MPD is dynamic or if the MPD@availabilityStartTime is present then ... If the MPD contains a UTCTiming element with the @schemeIdURI attribute set to "urn:mpeg:dash:utc:http-head:2014" or "urn:mpeg:dash:utc:http-xsdate:2014" then the following requirements apply: The Player shall use one of the timing information sources listed in the MPD to synchronize its clock. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-TIME0005 | 1 | DASH - UTCTiming - http-xsdate in static MPD with MPD@availabilityStartTime | When an application requests playback of MPEG DASH content with a static MPD with MPD@availabilityStartTime present that contains one UTCTiming element with @schemeIdURI set to "urn:mpeg:dash:utc:http-xsdate:2014" with @value set to an HTTP URL, the terminal makes an HTTP GET request for the specified URL. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 4.7.3: If the MPD is dynamic or if the MPD@availabilityStartTime is present then ... If the MPD contains a UTCTiming element with the @schemeIdURI attribute set to "urn:mpeg:dash:utc:http-head:2014" or "urn:mpeg:dash:utc:http-xsdate:2014" then the following requirements apply: The Player shall use one of the timing information sources listed in the MPD to synchronize its clock. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | |||
| org.hbbtv_DASH-TIME0006 | 1 | DASH - UTCTiming - http-xsdate in dynamic MPD - correct use of time reference for availability time check | When an application requests playback of MPEG DASH content with an MPD in which (a) MPD@type="dynamic", (b) MPD@availabilityStartTime is present, (c) MPD@timeshiftBufferDepth is set to a finite value, (d) segmentTemplate is used and (e) has one UTCTiming element with @schemeIdURI set to "urn:mpeg:dash:utc:http-xsdate:2014" with @value set to an HTTP URL that returns in the body a valid xs:dateTime string of the form 2002-05-30T09:30:10Z that is offset into the past by at least 10 seconds more than the value of MPD@timeshiftBufferDepth, the terminal requests segments that are within the availability time window with respect to the referenced server clock and does not request any segments that are not. | 2024-1 2023-3 2023-2 2023-1 2022-3 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 | TS-103-285,section 4.7.3: If the MPD is dynamic or if the MPD@availabilityStartTime is present then ... If the MPD contains a UTCTiming element with the @schemeIdURI attribute set to "urn:mpeg:dash:utc:http-head:2014" or "urn:mpeg:dash:utc:http-xsdate:2014" then the following requirements apply: The Player shall use one of the timing information sources listed in the MPD to synchronize its clock. The Player shall not request segments prior to the segment availability start time with reference to any of the chosen UTCTiming methods. HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. | ||
| org.hbbtv_DASH-TIMELINE0010 | 1 | DASH on demand stream using live profile and segment template with fixed segment duration - seek works | When the terminal is playing a static DASH media presentation, which uses the live profile and has an MPD containing a SegmentTemplate including the $Number$ parameter with fixed segment duration, and the application asks to seek to a position which corresponds to the start of a video media segment in the presentation, the terminal seeks to the correct position and plays from there. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 4.2.4: AdaptationSet element can be ignored unless AdaptationSet.SegmentTemplate is present and/or the Representation.SegmentTemplate element is present for each Representation within this Adaptation Set. Note: SegmentTimeline is supported according to ISO/IEC 23009-1 [1] | |||
| org.hbbtv_DASH-TIMELINE0020 | 1 | DASH on demand stream using live profile and segment template with fixed segment duration - terminal does not request non-existent segments at end of stream | When the terminal is playing a static DASH media presentation, which uses the live profile and has an MPD containing a SegmentTemplate including the $Number$ parameter with fixed segment duration, the terminal only requests the segments which are present in the stream as indicated by the mediaPresentationDuration attribute of the MPD. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 4.2.4: AdaptationSet element can be ignored unless AdaptationSet.SegmentTemplate is present and/or the Representation.SegmentTemplate element is present for each Representation within this Adaptation Set. Note: SegmentTimeline is supported according to ISO/IEC 23009-1 [1] | |||
| org.hbbtv_DASH-TIMELINE0050 | 1 | DASH on demand stream using live profile, segment template and segment timeline with short first and last segments - seek works | A static DASH media presentation has one audio and one video representation and uses the live profile. Within the MPD each Adaptation Set has a SegmentTemplate which uses the $Number$ parameter in the media attribute and a SegmentTimeline element. Within the SegmentTimeline element the first and last segments have duration d1 and all other segments have duration d2. d1 is much smaller than d2. The actual duration of the media segments must be the same as this timeline. When the terminal is playing this presentation and the application asks to seek to a point which corresponds to the start of a video media segment the terminal seeks to the correct position and plays from there. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 4.2.4: AdaptationSet element can be ignored unless AdaptationSet.SegmentTemplate is present and/or the Representation.SegmentTemplate element is present for each Representation within this Adaptation Set. Note: SegmentTimeline is supported according to ISO/IEC 23009-1 [1] | |||
| org.hbbtv_DASH-TIMELINE0070 | 1 | DASH on demand stream using live profile, segment template and segment timeline with short first and last segments - terminal reports correct play position | A static DASH media presentation has one audio and one video representation and uses the live profile. Within the MPD each Adaptation Set has a SegmentTemplate which uses the $Number$ parameter in the media attribute and a SegmentTimeline element. Within the SegmentTimeline element the first segment has duration d1, the last segment has duration d2 and all other segments have duration d3. d1 and d2 are much smaller than d3. The actual duration of the media segments must be the same as this timeline. When the terminal is playing this presentation it reports the correct current play position to the application. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 4.2.4: AdaptationSet element can be ignored unless AdaptationSet.SegmentTemplate is present and/or the Representation.SegmentTemplate element is present for each Representation within this Adaptation Set. Note: SegmentTimeline is supported according to ISO/IEC 23009-1 [1] | |||
| org.hbbtv_DASH-TIMELINE0130 | 1 | DASH live stream using live profile and segment template with different segment duration between audio and video and with AvailabilityStartTime more than 20 years ago - stream plays | A dynamic DASH media presentation uses an MPD with an availabilityStartTime at least 20 years ago and a timeshiftBufferDepth set to a reasonable value. It contains audio and video representations, each using SegmentTemplates which include the $Number$ parameter in the media attribute, but with different fixed segment durations for audio and video. When the terminal plays this presentation, it is played correctly - with the start of each media segment being presented no more than 45 seconds after its segment availability start time and with correct A/V sync. | 2024-1 2023-3 2023-2 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 4.2.4: AdaptationSet element can be ignored unless AdaptationSet.SegmentTemplate is present and/or the Representation.SegmentTemplate element is present for each Representation within this Adaptation Set. Note: SegmentTimeline is supported according to ISO/IEC 23009-1 [1] TS-103-285,section 10.9.2: If there is no MPD Anchor and the MPD@type attribute is set to "dynamic": * If the MPD@suggestedPresentationDelay attribute is not present, then the Player shall begin playback from a point such that the media is being presented no more than 45 seconds behind the time at which it becomes available. | |||
| org.hbbtv_DASH-TIMELINE0140 | 1 | DASH live stream using live profile and segment template with different segment duration between audio and video and with AvailabilityStartTime more than 20 years ago - seek works | A dynamic DASH media presentation uses an MPD with an availabilityStartTime at least 20 years ago and a timeshiftBufferDepth set to a reasonable value. It contains audio and video representations, each using SegmentTemplates which include the $Number$ parameter in the media attribute, but with different fixed segment durations for audio and video. When the terminal is playing this presentation and the application asks to seek to a position behind the live edge which is available and corresponds to the start of a video media segment the terminal seeks to the correct position and plays from there. | 2024-1 2023-3 2023-2 2023-1 2022-3 2021-3 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 4.2.4: AdaptationSet element can be ignored unless AdaptationSet.SegmentTemplate is present and/or the Representation.SegmentTemplate element is present for each Representation within this Adaptation Set. Note: SegmentTimeline is supported according to ISO/IEC 23009-1 [1] | ||
| org.hbbtv_DASH-TIMELINE0150 | 1 | DASH live stream using live profile and segment template with different segment duration between audio and video and with AvailabilityStartTime more than 20 years ago - terminal reports correct play position. | A dynamic DASH media presentation uses an MPD with an availabilityStartTime at least 20 years ago and a timeshiftBufferDepth set to a reasonable value. It contains audio and video representations, each using SegmentTemplates which include the $Number$ parameter in the media attribute, but with different fixed segment durations for audio and video. When the terminal is playing this presentation, the terminal reports the correct current play position to the application. | 2024-1 2023-3 2023-2 2023-1 2022-3 2021-3 2021-2 2021-1 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section E.4.1: Terminals shall support the DVB DASH profile [45] as modified in the present document. TS-103-285,section 4.2.4: AdaptationSet element can be ignored unless AdaptationSet.SegmentTemplate is present and/or the Representation.SegmentTemplate element is present for each Representation within this Adaptation Set. Note: SegmentTimeline is supported according to ISO/IEC 23009-1 [1] | |||
| org.hbbtv_DASH-UHDCOLORIMETRY0010 | 1 | MPEG DASH UHD BT.2020 colorimetry support | When the terminal presents (a) a DASH HEVC 10-bit hev1 BT.2020 stream consisting of a static image that includes areas of white and of saturated colours, followed by (b) a DASH HEVC 10-bit hev1 stream consisting of an identical video elementary stream but signalled in both the MPD and the initialisation and media segments as having BT.709 colorimetry, the resulting picture displayed or output from the terminal for (a) and (b) differs in colour or saturation. | 2024-1 2023-3 2023-2 2023-1 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | The challenge exists but not validated | 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: |Broadcast IRD reqirement from TS 101 154|Related DASH Requirement|Labels in XML capabilities| |HEVC UHDTV IRD|hevc_uhd player conformance point as defined in clause L.2 of TS 101 154 ...|HEVC_UHD_25, HEVC_UHD_30 TS-103-285,section 10.14: For the purposes of this clause, a player is considered to support ITU-R BT.2020 colour if one or more of the following is true: * The player has an integrated display and the picture that is displayed when ITU-R BT.2020 is signalled is different from the picture displayed when ITU-R BT.709 colour is signalled for an otherwise identical elementary stream. * A BT.2020 picture is passed over an HDMI connection operating with BT.2020 colorimetry to an HDMI Sink that indicates support for BT.2020. * A BT.2020 picture is colour space converted prior to passing over an HDMI connection operating with different colorimetry. TS-101-154,section L.2.1: hevc_uhd|HEVC Main and Main 10 Profile up to level 5.1|Progressive|BT.709 and BT.2020|Up to 3840x2160|50 Hz and 60 Hz families | +HAS_DISPLAY +HEVC_UHD | |
| org.hbbtv_DASH-VRESHD002 | 1 | MPEG DASH, 1600x900p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 1600x900p@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD004D | 1 | Scaling video down, MPEG DASH, 1024x576p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content 1024x576p@25, when video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD005 | 1 | MPEG DASH, 960x540p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 960x540p@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in Table 18 in the DVB DASH profile ETSI TS 103 285 [45], 720 x 576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD006 | 1 | MPEG DASH, 852x480p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 852x480p@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD007D | 1 | Scaling video down, MPEG DASH, 768x432p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content 768x432p@25, when video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD008U | 1 | Scaling video up, MPEG DASH, 720x404p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content 720x404p@25, when video object is scaled up to 2 by 2 of the width and height of the logical video plane. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. The decoded and processed video corner shall match to the A/V control object corner. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 7.3.1.1: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. The decoded and processed video corner shall match to the A/V control object corner. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD009 | 1 | MPEG DASH, 704x396p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 704x396p@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in Table 18 in the DVB DASH profile ETSI TS 103 285 [45], 720 x 576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. [...] Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD010 | 1 | MPEG DASH, 640x360p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 640x360p@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in Table 18 in the DVB DASH profile ETSI TS 103 285 [45], 720 x 576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD011 | 1 | MPEG DASH, 512x288p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 512x288p@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in Table 18 in the DVB DASH profile ETSI TS 103 285 [45], 720 x 576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD012U | 1 | Scaling video up, MPEG DASH, 480x270p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content 480x270p@25, when video object is scaled up to 2 by 2 of the width and height of the logical video plane. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. The decoded and processed video corner shall match to the A/V control object corner. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. The decoded and processed video corner shall match to the A/V control object corner. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD013 | 1 | MPEG DASH, 384x216p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 384x216p@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in Table 18 in the DVB DASH profile ETSI TS 103 285 [45], 720 x 576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD017U | 1 | Scaling video up, MPEG DASH, 704x576i@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content 704x576i@25, when video object is scaled up to 2 by 2 of the width and height of the logical video plane. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. The decoded and processed video corner shall match to the A/V control object corner. | 2024-1 2023-3 2023-2 2023-1 2022-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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. The decoded and processed video corner shall match to the A/V control object corner. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 18: Luminance Resolutions for interlaced content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD020D | 1 | Scaling video down, MPEG DASH, 720x576i@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content 720x576i@25, when video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD022 | 1 | MPEG DASH, HTML5 media object, 1600x900p@50, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 1600x900p@50. The video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD024D | 1 | Scaling video down, MPEG DASH, HTML5 media object, 1024x576p@50, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 1024x576p@50, when HTML5 video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD025 | 1 | MPEG DASH, HTML5 media object, 960x540p@50, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 960x540p@50. The HTML5 video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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 7.3.1.1: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in Table 18 in the DVB DASH profile ETSI TS 103 285 [45], 720 x 576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD026 | 1 | MPEG DASH, HTML5 media object, 852x480p@50, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 852x480p@50. The HTML5 video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD027D | 1 | Scaling video down, MPEG DASH, HTML5 media object, 768x432p@50, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 768x432p@50, when HTML5 video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD028U | 1 | Scaling video up, MPEG DASH, HTML5 media object, 720x404p@50, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 720x404p@50, when HTML5 video object is scaled up to 2 by 2 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. The decoded and processed video corner shall match to the A/V control object corner. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. The decoded and processed video corner shall match to the A/V control object corner. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD029 | 1 | MPEG DASH, HTML5 media object, 704x396p@50, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 704x396p@50. The HTML5 video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD030D | 1 | Scaling video down, MPEG DASH, HTML5 media object, 640x360p@50, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 640x360p@50, when HTML5 video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD031U | 1 | Scaling video up, MPEG DASH, HTML5 media object, 512x288p@50, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 512x288p@50, when HTML5 video object is scaled up to 2 by 2 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. The decoded and processed video corner shall match to the A/V control object corner. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. The decoded and processed video corner shall match to the A/V control object corner. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD032 | 1 | MPEG DASH, HTML5 media object, 480x270p@50, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 480x270p@50. The HTML5 video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD033D | 1 | Scaling video down, MPEG DASH, HTML5 media object, 384x216p@50, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 384x216p@50, when HTML5 video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | |||
| org.hbbtv_DASH-VRESHD1001 | 1 | MPEG DASH, 1920x1080p@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 1920x1080p@25 in which the video Representation is encoded using at least 11.5 Mbps and in which the total packaged data rate of the media presentation does not exceed 12 Mbps. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: 12 Mbit/s if the terminal does not support UHD video 26 Mbit/s if the terminal does support UHD video NOTE 2: For MPEG DASH content, the channel bandwidth requirement for continuous presentation of a Representation is indicated in the Representation@bandwidth attribute in the MPD. It covers packaging overheads but does not include protocol overheads. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: NOTE: The requirements formerly in this clause can now be found in clauses 10.3 and 10.4 of the DVB DASH profile. In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content ... 1920 1080 | |||
| org.hbbtv_DASH-VRESHD1016 | 1 | MPEG DASH, 1920x1080i@25, AVC_25 | The terminal shall correctly decode and display DASH AVC_25 content at 1920x1080i@25 in which the video Representation is encoded using at least 11.5 Mbps and in which the total packaged data rate of the media presentation does not exceed 12 Mbps. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: 12 Mbit/s if the terminal does not support UHD video 26 Mbit/s if the terminal does support UHD video NOTE 2: For MPEG DASH content, the channel bandwidth requirement for continuous presentation of a Representation is indicated in the Representation@bandwidth attribute in the MPD. It covers packaging overheads but does not include protocol overheads. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: NOTE: The requirements formerly in this clause can now be found in clauses 10.3 and 10.4 of the DVB DASH profile. In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 18: Luminance Resolutions for interlaced content ... 1920 1080 | |||
| org.hbbtv_DASH-VRESHD104 | 1 | MPEG DASH, A/V control object, 1024x576p@25, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content at 1024x576p@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD105D | 1 | Scaling video down, A/V control object, MPEG DASH, 960x540p@25, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 960x540p@25, when video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corners shall match to the A/V control object corners. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD106U | 1 | Scaling video up, A/V control object, MPEG DASH, 852x480p@25, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 852x480p@25, when video object is scaled up to 2 by 2 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corner shall match to the A/V control object corner. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD107 | 1 | MPEG DASH, A/V control object, 768x432p@25, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content at 768x432p@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD108D | 1 | Scaling video down, A/V control object, MPEG DASH, 720x404p@25, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 720x404p@25, when video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corners shall match to the A/V control object corners. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD109U | 1 | Scaling video up, A/V control object, MPEG DASH, 704x396p@25, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 704x396p@25, when video object is scaled up to 2 by 2 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corner shall match to the A/V control object corner. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD110 | 1 | MPEG DASH, A/V control object, 640x360p@25, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content at 640x360p@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD111D | 1 | Scaling video down, A/V control object, MPEG DASH, 512x288p@25, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 512x288p@25, when video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corners shall match to the A/V control object corners. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD112U | 1 | Scaling video up, A/V control object, MPEG DASH, 480x270p@25, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 480x270p@25, when video object is scaled up to 2 by 2 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled AV object. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corner shall match to the A/V control object corner. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD113 | 1 | MPEG DASH, A/V control object, 384x216p@25, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content at 384x216p@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD119 | 1 | MPEG DASH, A/V control object, 352x288i@25, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content at 352x288i@25. The video object is in full screen resolution, the 'fullscreen' property of A/V control object is set to false. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 18: Luminance Resolutions for interlaced content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD124 | 1 | MPEG DASH, HTML5 media object, 1024x576p@50, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content at 1024x576p@50. The HTML5 video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD1240 | 1 | MPEG DASH, HTML5 media object, 3840x2160p@50, HEVC, 10bit | The terminal shall correctly decode and display DASH HEVC 10bit content at 3840x2160p@50 in which the video Representation is encoded using at least 25 Mbps and in which the total packaged data rate of the media presentation does not exceed 26 Mbps. The HTML5 video object is in full screen resolution. | 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-3 2019-2 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: 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. HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: 12 Mbit/s if the terminal does not support UHD video 26 Mbit/s if the terminal does support UHD video NOTE 2: For MPEG DASH content, the channel bandwidth requirement for continuous presentation of a Representation is indicated in the Representation@bandwidth attribute in the MPD. It covers packaging overheads but does not include protocol overheads. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section E.4.2.1: NOTE: The requirements formerly in this clause can now be found in clauses 10.3 and 10.4 of the DVB DASH profile. In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports UHDTV content shall support the decode and display of pictures with the resolutions shown in Table 19 in addition to the resolutions in Table 17 and Table 18. ... Table 19: Luminance Resolutions for UHDTV Progressive Content ... 3840 2160 | +HEVC_UHD | ||
| org.hbbtv_DASH-VRESHD1241 | 1 | MPEG DASH, HTML5 media object, 1920x1080p@50, HEVC, 10bit | The terminal shall correctly decode and display DASH HEVC 10bit content at 1920x1080p@50 in which the video Representation is encoded using at least 11.5 Mbps and in which the total packaged data rate of the media presentation does not exceed 12 Mbps. The HTML5 video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-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: 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. HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: 12 Mbit/s if the terminal does not support UHD video 26 Mbit/s if the terminal does support UHD video NOTE 2: For MPEG DASH content, the channel bandwidth requirement for continuous presentation of a Representation is indicated in the Representation@bandwidth attribute in the MPD. It covers packaging overheads but does not include protocol overheads. HBBTV,section 7.3.1.3: Different requirements on video resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section E.4.2.1: NOTE: The requirements formerly in this clause can now be found in clauses 10.3 and 10.4 of the DVB DASH profile. In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content ... 1920 1080 | +HEVC_HD_10 | ||
| org.hbbtv_DASH-VRESHD1242 | 1 | MPEG DASH, HTML5 media object, 3840x2160p50, HEVC, 10bit, max bitrate, non-TLS | The terminal shall correctly decode and display DASH HEVC 10bit content at 3840x2160p@50 in which the video Representation is encoded using at least 38 Mbps and in which the total packaged data rate of the media presentation does not exceed 39 Mbps. The DASH MPD and all initialisation and media segments are delivered over HTTP without TLS. The HTML5 video object is in full screen resolution. | 2024-1 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 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: ... 39 Mbit/s if the terminal does support UHD video but does not support HFR video ... NOTE 2: For MPEG DASH content, the channel bandwidth requirement for continuous presentation of a Representation is indicated in the Representation@bandwidth attribute in the MPD. It covers packaging overheads but does not include protocol overheads. | +HEVC_UHD | ||
| org.hbbtv_DASH-VRESHD1243 | 1 | MPEG DASH, HTML5 media object, 3840x2160p50, HEVC, 10bit, max bitrate, TLS | The terminal shall correctly decode and display DASH HEVC 10bit content at 3840x2160p@50 in which the video Representation is encoded using at least 38 Mbps and in which the total packaged data rate of the media presentation does not exceed 39 Mbps. The DASH MPD and all initialisation and media segments are delivered over TLS. The HTML5 video object is in full screen resolution. | 2024-1 2023-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: ... 39 Mbit/s if the terminal does support UHD video but does not support HFR video ... This requirement shall apply for media segments delivered with or without the use of TLS and shall apply for all TLS cipher suites that the terminal offers when establishing a connection for the purposes of media delivery. NOTE 2: For MPEG DASH content, the channel bandwidth requirement for continuous presentation of a Representation is indicated in the Representation@bandwidth attribute in the MPD. It covers packaging overheads but does not include protocol overheads. | +HEVC_UHD | ||
| org.hbbtv_DASH-VRESHD125D | 1 | Scaling video down, MPEG DASH, HTML5 media object, 960x540p@50, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 960x540p@50, when HTML5 video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled HTML5 video object. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corners shall match to the HTML5 media object corners. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD126U | 1 | Scaling video up, MPEG DASH, HTML5 media object, 852x480p@50, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 852x480p@50, when HTML5 video object is scaled up to 2 by 2 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled HTML5 video object. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corner shall match to the HTML5 media object corner. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD127 | 1 | MPEG DASH, HTML5 media object, 768x432p@50, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content at 768x432p@50. The HTML5 video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD128D | 1 | Scaling video down, MPEG DASH, HTML5 media object, 720x404p@50, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 720x404p@50, when HTML5 video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled HTML5 video object. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corners shall match to the HTML5 media object corners. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD129U | 1 | Scaling video up, MPEG DASH, HTML5 media object, 704x396p@50, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 704x396p@50, when HTML5 video object is scaled up to 2 by 2 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled HTML5 video object. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corner shall match to the HTML5 media object corner. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD130 | 1 | MPEG DASH, HTML5 media object, 640x360p@50, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content at 640x360p@50. The HTML5 video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD131D | 1 | Scaling video down, MPEG DASH, HTML5 media object, 512x288p@50, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 512x288p@50, when HTML5 video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled HTML5 video object. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corners shall match to the HTML5 media object corners. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD132U | 1 | Scaling video up, MPEG DASH, HTML5 media object, 480x270p@50, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content 480x270p@50, when HTML5 video object is scaled up to 2 by 2 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled HTML5 video object. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corner shall match to the HTML5 media object corner. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD133 | 1 | MPEG DASH, HTML5 media object, 384x216p@50, HEVC, 8bit | The terminal shall correctly decode and display DASH HEVC 8bit content at 384x216p@50. The HTML5 video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_8 | ||
| org.hbbtv_DASH-VRESHD225D | 1 | Scaling video down, MPEG DASH, HTML5 media object, 960x540p@50, HEVC, 10bit | The terminal shall correctly decode and display DASH HEVC 10bit content 960x540p@50, when HTML5 video object is scaled down to 1/4 by 1/4 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled HTML5 video object. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corners shall match to the HTML5 media object corners. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video down to 1/4 by 1/4 HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_10 | ||
| org.hbbtv_DASH-VRESHD229U | 1 | Scaling video up, MPEG DASH, HTML5 media object, 704x396p@50, HEVC, 10bit | The terminal shall correctly decode and display DASH HEVC 10bit content 704x396p@50, when HTML5 video object is scaled up to 2 by 2 of the width and height of the logical video plane. The decoded and processed video shall be correctly aligned within the scaled HTML5 video object. The video shall be correctly cropped at the edges of the display, since the decoded video is larger than the display. Aspect ratio shall be preserved, no black bars are present, the decoded and processed video corner shall match to the HTML5 media object corner. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. HBBTV,section 7.3.1.3: Different requirements on video formats, resolutions and decoder capabilities apply to content delivered using MPEG DASH as defined in Annex E. HBBTV,section 10.2.1: Terminals shall be able to scale video up to 2 x 2 of the width and height of the logical video plane. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. .... -Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. HBBTV,section 9.6.10: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. HBBTV,section A.2.14: - 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. .... If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. HBBTV,section E.4.2.1: In addition to the set of resolutions in the table "Luminance Resolutions for interlaced content" in the DVB DASH profile [45], 720x576i shall also be supported. TS-103-285,section 10.3: A Player that supports HD content shall support the decode and display of pictures with the resolutions in Table 17 and Table 18 at all supported frame rates. ... Table 17: Luminance Resolutions for progressive content TS-101-154,section 5.2.2: The source video format for 50 Hz frame rate material shall be progressive.The source video format for 25 Hz frame rate material may be interlaced or progressive. | +HEVC_HD_10 | ||
| org.hbbtv_DASH-VRESHFR0010 | 1 | MPEG DASH, HTML5 media object, 3840x2160p100, HEVC, 10bit, max bitrate | The terminal shall correctly decode and display DASH HEVC 10bit content at 3840x2160p@100 in which the video Representation is encoded using at least 50 Mbps and in which the total packaged data rate of the media presentation does not exceed 51 Mbps. The HTML5 video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 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.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: ... 51 Mbit/s if the terminal supports UHD HFR video ... NOTE 2: For MPEG DASH content, the channel bandwidth requirement for continuous presentation of a Representation is indicated in the Representation@bandwidth attribute in the MPD. It covers packaging overheads but does not include protocol overheads 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: Related DASH Requirement | Labels in XML capabilities hevc_uhd_hfr_hlg10 player conformance point as defined in clause L.2 of TS 101 154 [] (see note 1) | HEVC_UHD_HFR_25, HEVC_UHD_HFR_30 (see note 2) hevc_uhd_hfr_pq10 player conformance point as defined in clause L.2 of TS 101 154 [] (see note 1) | HEVC_UHD_HFR_25, HEVC_UHD_HFR_30 (see note 2) TS-103-285,section 10.3: Table 26: Luminance Resolutions for UHDTV Progressive Content ... 3840 2160 ... A Player that supports UHDTV content shall support the decode and display of pictures with the resolutions shown in Table 26 in addition to the resolutions in Table 24. TS-101-154,section L.2.1: Table L.1 Player conformance points Name | ... | Resolutions | Frame rates hevc_uhd_hfr_hlg10 | ... | Up to 3840x2160 | 50 Hz and 60 Hz families, and 100 Hz, 120/1 001 Hz, 120 Hz hevc_uhd_hfr_pq10 | ... | Up to 3840x2160 | 50 Hz and 60 Hz families, and 100 Hz, 120/1 001 Hz, 120 Hz | +DASH_HFR | ||
| org.hbbtv_DASH-VRESHFR0020 | 1 | MPEG DASH, HTML5 media object, 3840x2160p100, HEVC, 10bit, max bitrate, TLS | The terminal shall correctly decode and display DASH HEVC 10bit content at 3840x2160p@100 in which the video Representation is encoded using at least 50 Mbps and in which the total packaged data rate of the media presentation does not exceed 51 Mbps. The DASH MPD and all initialisation and media segments are delivered over TLS. The HTML5 video object is in full screen resolution. | 2024-1 2023-3 2023-2 2023-1 | The challenge exists but not validated | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: ... 51 Mbit/s if the terminal supports UHD HFR video ... This requirement shall apply for media segments delivered with or without the use of TLS and shall apply for all TLS cipher suites that the terminal offers when establishing a connection for the purposes of media delivery. NOTE 2: For MPEG DASH content, the channel bandwidth requirement for continuous presentation of a Representation is indicated in the Representation@bandwidth attribute in the MPD. It covers packaging overheads but does not include protocol overheads. 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: Related DASH Requirement | Labels in XML capabilities hevc_uhd_hfr_hlg10 player conformance point as defined in clause L.2 of TS 101 154 [] (see note 1) | HEVC_UHD_HFR_25, HEVC_UHD_HFR_30 (see note 2) hevc_uhd_hfr_pq10 player conformance point as defined in clause L.2 of TS 101 154 [] (see note 1) | HEVC_UHD_HFR_25, HEVC_UHD_HFR_30 (see note 2) TS-103-285,section 10.3: Table 26: Luminance Resolutions for UHDTV Progressive Content ... 3840 2160 ... A Player that supports UHDTV content shall support the decode and display of pictures with the resolutions shown in Table 26 in addition to the resolutions in Table 24. TS-101-154,section L.2.1: Table L.1 Player conformance points Name | ... | Resolutions | Frame rates hevc_uhd_hfr_hlg10 | ... | Up to 3840x2160 | 50 Hz and 60 Hz families, and 100 Hz, 120/1 001 Hz, 120 Hz hevc_uhd_hfr_pq10 | ... | Up to 3840x2160 | 50 Hz and 60 Hz families, and 100 Hz, 120/1 001 Hz, 120 Hz | +DASH_HFR | |
| org.hbbtv_DASH-VRESHFR0030 | 1 | MPEG DASH, HTML5 media object, 1920x1080p100, HEVC, 10bit | The terminal shall correctly decode and display DASH HEVC 10bit content at 1920x1080p@100. | 2024-1 2023-3 2023-2 2023-1 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 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: Related DASH Requirement | Labels in XML capabilities hevc_uhd_hfr_hlg10 player conformance point as defined in clause L.2 of TS 101 154 [] (see note 1) | HEVC_UHD_HFR_25, HEVC_UHD_HFR_30 (see note 2) hevc_uhd_hfr_pq10 player conformance point as defined in clause L.2 of TS 101 154 [] (see note 1) | HEVC_UHD_HFR_25, HEVC_UHD_HFR_30 (see note 2) TS-103-285,section 10.3: Table 24: Luminance Resolutions for progressive content ... 1920 1080 ... A Player that supports UHDTV content shall support the decode and display of pictures with the resolutions shown in Table 26 in addition to the resolutions in Table 24. TS-101-154,section L.2.1: Table L.1 Player conformance points Name | ... | Resolutions | Frame rates hevc_uhd_hfr_hlg10 | ... | Up to 3840x2160 | 50 Hz and 60 Hz families, and 100 Hz, 120/1 001 Hz, 120 Hz hevc_uhd_hfr_pq10 | ... | Up to 3840x2160 | 50 Hz and 60 Hz families, and 100 Hz, 120/1 001 Hz, 120 Hz | +DASH_HFR | ||
| org.hbbtv_DASH-XLINK0001 | 1 | Test for DASH MPD using xlink | Terminal plays content with a manifest that contains a single remote period | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0002 | 1 | Test for DASH MPD using xlink | Terminal plays content with a manifest containing three remote periods | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0003 | 1 | Test for DASH MPD using xlink | Terminal plays content with a manifest containing one remote period before two local periods | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0004 | 1 | Test for DASH MPD using xlink | Terminal plays content with a manifest having a remote period between two local periods | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0005 | 1 | Test for DASH MPD using xlink | Terminal plays content with a manifest having two remote periods after a local period | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0006 | 1 | Test for DASH MPD using xlink | Terminal plays content with a manifest that contains a single remote period resolving to two periods | 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.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0007 | 1 | Test for DASH MPD using xlink | Terminal plays content from resolved remote period, not manifest period | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0008 | 1 | Test for DASH MPD using xlink | Terminal plays content from manifest local period, when remote period resolution fails | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0009 | 1 | Test for DASH MPD using xlink | Single remote adaptation set with local adaptation sets | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-1 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 TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0010 | 1 | Test for DASH MPD using xlink | all adaptation sets are remotely loaded | 2024-1 2023-3 2023-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.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0011 | 1 | Test for DASH MPD using xlink | failed remote adaptation sets do not affect playout of others | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0012 | 1 | Test for DASH MPD using xlink | remote adaptation set replaces that defined in MPD | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DASH-XLINK0013 | 1 | Test for DASH MPD using xlink | failure to resolve remote adaptation set uses adaptation set defined locally in MPD | 2024-1 2023-3 2023-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.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E TS-103-285,section 4.1: The DVB Profile of MPEG-DASH [...] is based on the merging of the ISO/IEC 23009-1 ISO Base media file format live profile and ISO Base media file formal On Demand profile. In addition it includes xlink but only in combination with the actuate property set to "onLoad". DASH,section 3.1.33: remote element entity: entity that contains one or more elements and is referenced in the MPD with an HTTP-URL contained in an @xlink:href attribute | |||
| org.hbbtv_DDP-GC-CODEC-DASH | 1 | AV Components: getComponents() returns correct the 'encoding' strings for DD+ (E-AC3) and HEAAC in a DASH stream | The terminal shall correctly return values of E-AC3 and HEAAC for the 'encoding' parameter when calling getComponents on an AV Control object playing a stream with DD+ (E-AC3) and HEAAC audio (respectively) as part of a DASH stream | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.2.1: Properties | readonly String encoding | The encoding of the stream. The value of video format or audio format defined in section 3 of [MEDIA] SHALL be used. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | ||
| org.hbbtv_DDP-GC-CODEC-MP4 | 1 | AV Components: getComponents() returns correct the 'encoding' strings for DD+ (E-AC3) and HEAAC in an mp4 stream | The terminal shall correctly return values of E-AC3 and HEAAC for the 'encoding' parameter when calling getComponents on an AV Control object playing a stream with DD+ (E-AC3) and HEAAC audio (respectively) as part of an mp4 stream | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.2.1: Properties | readonly String encoding | The encoding of the stream. The value of video format or audio format defined in section 3 of [MEDIA] SHALL be used. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | ||
| org.hbbtv_DDP-GC-CODEC-TS | 1 | AV Components: getComponents() returns correct the 'encoding' strings for DD+ (E-AC3) and HEAAC in a TS stream | The terminal shall correctly return values of E-AC3 and HEAAC for the 'encoding' parameter when calling getComponents on an AV Control object playing a stream with DD+ (E-AC3) and HEAAC audio (respectively) as part of a TS stream | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.2.1: Properties | readonly String encoding | The encoding of the stream. The value of video format or audio format defined in section 3 of [MEDIA] SHALL be used. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | ||
| org.hbbtv_DDP-GC-LANG-DASH | 1 | AV Components: getComponents() returns correct the 'language' strings for multiple DD+ (EAC3) audio components in a DASH stream | The terminal shall return the correct ISO 639-2 value for the 'language' parameter when calling getComponents on an AV Control object playing a DASH stream for each of multiple DD+ audio components | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.4.1: Properties | readonly String language | An ISO 639.2 language code representing the language of the stream, as defined in [ISO 639.2]. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | ||
| org.hbbtv_DDP-GC-LANG-MP4 | 1 | AV Components: getComponents() returns correct the 'language' strings for multiple DD+ (EAC3) audio components in an mp4 stream | The terminal shall return the correct ISO 639-2 value for the 'language' parameter when calling getComponents on an AV Control object playing an mp4 stream for each of multiple DD+ audio components | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.4.1: Properties | readonly String language | An ISO 639.2 language code representing the language of the stream, as defined in [ISO 639.2]. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | ||
| org.hbbtv_DDP-GC-LANG-TS | 1 | AV Components: getComponents() returns correct the 'language' strings for multiple DD+ (EAC3) audio components in a TS stream | The terminal shall return the correct ISO 639-2 value for the 'language' parameter when calling getComponents on an AV Control object playing a TS stream for each of multiple DD+ audio components | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.4.1: Properties | readonly String language | An ISO 639.2 language code representing the language of the stream, as defined in [ISO 639.2]. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | ||
| org.hbbtv_DDP-SC-CODEC-DASH | 1 | AV Components: Selecting audio components from a DASH stream with DD+ (E-AC3) and HE-AAC audio components | The terminal shall correctly select and play the audio component which is not initially played, by using the selectComponents function on an AV Control object playing a DASH stream with DD+ (E-AC3) and HEAAC audio components | 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 | 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 A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | void selecComponent(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. OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getCurrentActiveComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.2.1: Properties | readonly String encoding | The encoding of the stream. The value of video format or audio format defined in section 3 of [MEDIA] SHALL be used. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | |
| org.hbbtv_DDP-SC-CODEC-MP4 | 1 | AV Components: Selecting audio components from an mp4 stream with DD+ (E-AC3) and HE-AAC audio components | The terminal shall correctly select and play the audio component which is not initially played, by using the selectComponents function on an AV Control object playing an mp4 stream with DD+ (E-AC3) and HEAAC audio components | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | void selecComponent(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. OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getCurrentActiveComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.2.1: Properties | readonly String encoding | The encoding of the stream. The value of video format or audio format defined in section 3 of [MEDIA] SHALL be used. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | ||
| org.hbbtv_DDP-SC-CODEC-TS | 1 | AV Components: Selecting audio components from a TS stream with DD+ (E-AC3) and HE-AAC audio components | The terminal shall correctly select and play the audio component which is not initially played, by using the selectComponents function on an AV Control object playing a TS stream with DD+ (E-AC3) and HEAAC audio components | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | void selecComponent(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. OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getCurrentActiveComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.2.1: Properties | readonly String encoding | The encoding of the stream. The value of video format or audio format defined in section 3 of [MEDIA] SHALL be used. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | ||
| org.hbbtv_DDP-SC-LANG-DASH | 1 | AV Components: Selecting audio components from a DASH stream with multiple language DD+ (EAC3) audio components | The terminal shall correctly select and play the audio component which is not initially played, by using the selectComponents function on an AV Control object playing a DASH stream with multiple language DD+ (EAC3) audio components | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | void selecComponent(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. OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getCurrentActiveComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.4.1: Properties | readonly String language | An ISO 639.2 language code representing the language of the stream, as defined in [ISO 639.2]. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | ||
| org.hbbtv_DDP-SC-LANG-MP4 | 1 | AV Components: Selecting audio components from an mp4 stream with multiple language DD+ (EAC3) audio components | The terminal shall correctly select and play the audio component which is not initially played, by using the selectComponents function on an AV Control object playing an mp4 stream with multiple language DD+ (EAC3) audio components | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | void selecComponent(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. OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getCurrentActiveComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.4.1: Properties | readonly String language | An ISO 639.2 language code representing the language of the stream, as defined in [ISO 639.2]. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | ||
| org.hbbtv_DDP-SC-LANG-TS | 1 | AV Components: Selecting audio components from a TS stream with multiple language DD+ (EAC3) audio components | The terminal shall correctly select and play the audio component which is not initially played, by using the selectComponents function on an AV Control object playing a TS stream with multiple language DD+ (EAC3) audio components | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A1: Extensions to A/V object for playback of selected components | 7.14.4 | Mandatory OIPF-DAE,section 7.16.5.1.3: Methods | void selecComponent(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. OIPF-DAE,section 7.16.5.1.3: Methods | AVComponentCollection getCurrentActiveComponents( Integer componentType ) | For an AV Control object, the set of components SHALL be known if the AV Control object is in the playing state OIPF-DAE,section 7.16.5.4.1: Properties | readonly String language | An ISO 639.2 language code representing the language of the stream, as defined in [ISO 639.2]. OIPF-Media-Formats,section 3: A/V Media Formats | +EAC3 | ||
| org.hbbtv_DEMUX0010 | 1 | AIT monitoring when playing MPEG-2 TS via IP | A broadcast-related application starts presenting A/V delivered over broadband in an MPEG-2 transport stream. Later the AIT in the broadcast service changes such that the running app is removed from the AIT and a new autostart app is added. The running app is killed and the new autostart app is started. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.7: Terminals shall be able to present broadband delivered A/V at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular the following examples shall apply:- AIT monitoring shall continue. HBBTV,section 6.2.2.3: AIT updated -> Is an application already running? -> Yes -> Is it signalled in the new service with the same transport protocol? -> No -> Kill currently running application. | |||
| org.hbbtv_DEMUX0020 | 2 | Carousel access when playing MPEG-2 TS via IP | A broadcast-related application carried in a DSM-CC object carousel starts presenting A/V delivered over broadband in an MPEG-2 transport stream. When a file in its carousel is updated, the running application is able to access the updated file. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.7: Terminals shall be able to present broadband delivered A/V at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular the following examples shall apply:- Files in a carousel shall be accessible including updates. HBBTV,section 8.2.2: In order to access the content of a carousel file, the XMLHttpRequest object can be used with the following constraints: HBBTV,section 7.2.5.2: A broadcast-related application whose initial page is broadcast will cause its carousel to be mounted by the terminal (in order to be loaded and launched) | |||
| org.hbbtv_DEMUX0030 | 1 | Stream event monitoring when mplaying MPEG-2 TS via IP | A broadcast-related application starts presenting A/V delivered over broadband in an MPEG-2 transport stream. The application registers to listen to DSM-CC stream events in the broadcast. When the stream events are received by the terminal, events are dispatched to the application. | 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-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.7: Terminals shall be able to present broadband delivered A/V at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular the following examples shall apply:- DSM-CC stream event monitoring shall continue. HBBTV,section 7.2.4: The terminal shall support "do-it-now" events as defined in clause 8 of ETSI TS 102 809 [3]. HBBTV,section 8.2.1.1: The following additional methods on the video/broadcast object (as defined in the OIPF DAE specification [1]) shall be supported for synchronization to broadcast events as defined in clause 7.2.4. void addStreamEventListener(String targetURL, String eventName, EventListener listener) | |||
| org.hbbtv_DEMUX0040 | 1 | ProgrammesChanged event generation when playing MPEG-2 TS via IP | A broadcast-related application starts presenting A/V delivered over broadband in an MPEG-2 transport stream. The application registers to receive ProgrammesChanged events. While the broadband delivered transport stream is playing, the DVB-SI event in the broadcast changes and a ProgrammesChanged event is sent to the registered listener. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.7: Terminals shall be able to present broadband delivered A/V at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular the following examples shall apply:- ProgrammesChanged events shall be sent to any registered listeners. HBBTV,section A.2.9: The Metadata APIs listed in table A.1 of the present document shall allow access to DVB-SI EIT event schedule information for the actual transport stream and for the other transport streams (as defined in ETSI EN 300 468 [16]) that are carried on the transport stream of the currently selected broadcast service. The terminal shall use EIT-present/following information and, if present, EIT-schedule information. If both EIT-schedule and EIT-present/following information are present, it is implementation dependent which shall be used in cases where there are conflicts. OIPF-DAE,section 7.13.3: function onProgrammesChanged() The function that is called when the programmes property has been updated with new programme information, e.g. when the current broadcast programme is finished and a new one has started. The specified function is called with no arguments. OIPF-DAE,section 7.13.3.1: Intrinsic event, Corresponding DOM event, DOM Event propertiesonProgrammesChanged, ProgrammesChanged,Bubbles: No Cancellable: NoContext Info: None | |||
| org.hbbtv_DEMUX0110 | 1 | AIT monitoring when playing ISOBMFF via IP | A broadcast-related application starts presenting A/V delivered over broadband by HTTP streaming of an ISOBMFF file. Later the AIT in the broadcast service changes such that the running app is removed from the AIT and a new autostart app is added. The running app is killed and the new autostart app is started. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.7: Terminals shall be able to present broadband delivered A/V at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular the following examples shall apply:- AIT monitoring shall continue. HBBTV,section 6.2.2.3: AIT updated -> Is an application already running? -> Yes -> Is it signalled in the new service with the same transport protocol? -> No -> Kill currently running application. | |||
| org.hbbtv_DEMUX0220 | 2 | Carousel access when playing DASH via IP | A broadcast-related application carried in a DSM-CC object carousel starts presenting A/V delivered over broadband using MPEG DASH. When a file in its carousel is updated, the running application is able to access the updated file. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.7: Terminals shall be able to present broadband delivered A/V at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular the following examples shall apply:- Files in a carousel shall be accessible including updates. HBBTV,section 8.2.2: In order to access to the content of a carousel file, the XMLHttpRequest object can be used with the following constraints: HBBTV,section 7.2.5.2: A broadcast-related application whose initial page is broadcast will cause its carousel to be mounted by the terminal (in order to be loaded and launched) | |||
| org.hbbtv_DEVICEID0010 | 1 | Device Id, access granted | An HbbTV application reads the deviceId property of the Configuration class. When access to deviceId is granted, then an identifier containing only alphanumeric characters and/or hyphen is returned. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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.20.5: The following property is added to the Configuration class. readonly String deviceId Returns either a string representing a distinctive identifier that is unique for the combination of the terminal and the HTML document origin or a status code. The distinctive identifier shall use a character set that is restricted to alphanumeric characters and the hyphen. | -DEVICE_ID_DISABLED | ||
| org.hbbtv_DEVICEID0020 | 1 | Read device ID by 2 documents from the same web origin | An HbbTV application contains two documents delivered by HTTP from the same origin. When each document reads the deviceId property of the Configuration class, the same value is returned. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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.20.5: The following property is added to the Configuration class. readonly String deviceId Returns either a string representing a distinctive identifier that is unique for the combination of the terminal and the HTML document origin or a status code. | -DEVICE_ID_DISABLED | ||
| org.hbbtv_DEVICEID0030 | 1 | Read device ID by 2 documents from different web origins | An HbbTV application contains two documents delivered by HTTP from different origins. When each document reads the deviceId property of the Configuration class, a different value is returned. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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.20.5: The following property is added to the Configuration class. readonly String deviceId Returns either a string representing a distinctive identifier that is unique for the combination of the terminal and the HTML document origin or a status code. | -DEVICE_ID_DISABLED | ||
| org.hbbtv_DEVICEID0040 | 1 | Read device ID by 2 documents from HTTP and HTTPS | An HbbTV application contains two documents, one referenced by an HTTP URL and one referenced by an HTTPS URL but both from the same server. When each document reads the deviceId property of the Configuration class, a different value is returned. | 2024-1 2023-3 2023-2 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.2.20.5: The following property is added to the Configuration class. readonly String deviceId Returns either a string representing a distinctive identifier that is unique for the combination of the terminal and the HTML document origin or a status code. RFC6454,section 5: Two origins are "the same" if, and only if, they are identical. In particular: o If the two origins are scheme/host/port triples, the two origins are the same if, and only if, they have identical schemes, hosts, and ports. | -DEVICE_ID_DISABLED | |
| org.hbbtv_DEVICEID0050 | 1 | Read device ID by 2 documents from the same broadcast origin | An HbbTV application contains two documents delivered by DSM-CC from the same channel. When each document reads the deviceId property of the Configuration class, the same value is returned. | 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 A.2.20.5: The following property is added to the Configuration class. readonly String deviceId Returns either a string representing a distinctive identifier that is unique for the combination of the terminal and the HTML document origin or a status code. The distinctive identifier shall use a character set that is restricted to alphanumeric characters and the hyphen. | -DEVICE_ID_DISABLED | ||
| org.hbbtv_DEVICEID0060 | 1 | Read device ID by 2 documents from different broadcast origins | An HbbTV application contains two documents delivered by DSM-CC from different channels. When each document reads the deviceId property of the Configuration class, a different value is returned. | 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 A.2.20.5: Returns either a string representing a distinctive identifier that is unique for the combination of the terminal and the HTML document origin or a status code. The distinctive identifier shall use a character set that is restricted to alphanumeric characters and the hyphen. The status code shall be a number preceded by the ‘#’ character HBBTV,section 12.1.5: Terminals shall support the deviceId property in A.2.20.5 but may restrict the availability of the distinctive identifier. If the availability is restricted, the terminal shall implement one or more of the following: 1) Offer the user the option to enable or disable the availability of a distinctive identifier on a per-application or per organisation basis (e.g. as part of the device settings or installation menu). The availability of the distinctive identifier should be enabled by default unless blocked due to local regulatory requirements | -DEVICE_ID_DISABLED | ||
| org.hbbtv_DEVICEID0070 | 1 | User generates new device ID | An HbbTV application reads the deviceId property of the Configuration class. The user then generates a new device ID. The HbbTV application then reads the device ID again and the ID is different. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 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.2.20.5: The following property is added to the Configuration class. readonly String deviceId Returns either a string representing a distinctive identifier that is unique for the combination of the terminal and the HTML document origin or a status code. The distinctive identifier shall use a character set that is restricted to alphanumeric characters and the hyphen. The status code shall be a number preceded by the ‘#’ character. ... The value of this property may change after a call to requestAccessToDistinctiveIdentifier, a change to the user option, a request by the user to generate a new distinctive identifier or some other event. HBBTV,section 12.1.5: Terminals shall implement the extensions to the Configuration class for distinctive identifiers as defined in A.2.20.5 and as required in this clause. ... It shall be possible for the user to generate a new but distinct value for the device ID | -DEVICE_ID_DISABLED | |
| org.hbbtv_DISCOVERY0010 | 1 | Discovery - MSearch response | The terminal shall respond to a M-SEARCH request as defined in clause 5.1 of DIAL where the ST header (Search Target) contains "urn:dial-multiscreen-org:service:dial:1" as the identifier with an M-SEARCH response as defined in clause 5.2 of DIAL, including a HTTP "Location" header containing an absolute HTTP URL where the host portion of the URL shall either resolve to an IPv4 address or be an IPv4 address. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.7.2: For terminal and service endpoint discovery, the terminal shall support DIAL [50]. [...] Before the HbbTV service endpoints can be determined, the DIAL REST Service and the DIAL Application Resource URL need to be found. This is achieved using the mechanisms described in DIAL [50] clause 5. This consists of an SSDP M-SEARCH request and response DIAL,section 5.1: A DIAL client that wishes to discover DIAL servers SHALL send an MSEARCH request as defined in Section 1.3.2 of [1] over UDP to the IPv4 multicast address 239.255.255.250 and UDP port 1900 including the Search Target header (ST) with the following value defined by this specification: urn:dial-multiscreen-org:service:dial:1 DIAL,section 5.2: An SSDP/UPnP server receiving an M-SEARCH request with the Search Target defined above shall respond as defined in Section 1.3.3 of [1], including a LOCATION header containing an absolute HTTP URL for the UPnP description of the root device. The host portion of the URL SHALL either resolve to an IPv4 address or be an IPv4 address. The Search Target header (ST) of the response SHALL contain the identifier defined in Section 5.1. | |||
| org.hbbtv_DISCOVERY0020 | 1 | Discovery - Device description response (1) | The terminal shall respond to an HTTP GET request to the URL provided in the Location header of the DIAL M-SEARCH response with a UPnP device description and an HTTP header Application-URL where the value is an absolute URL. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.7.2: For terminal and service endpoint discovery, the terminal shall support DIAL [50]. [...] an HTTP GET to the URL obtained from the LOCATION: header in the M-SEARCH response. This HTTP response contains an Application-URL header and a body. The response body is a UPnP device description as required by clause 5.4 of DIAL [50]. DIAL,section 5.4: On receipt of a valid HTTP GET for the device description, a DIAL server SHALL respond with an HTTP response containing the UPnP device description as defined in Section 2 of [1]....If the request is successful, the HTTP response SHALL contain an additional header field, Application-URL, the value of which SHALL be an absolute HTTP URL. This URL, minus any trailing slash ("/") character, identifies the DIAL REST Service and is referred to as the DIAL REST Service URL. The host portion of the URL SHALL either resolve to an IPv4 address or be an IPv4 address. | |||
| org.hbbtv_DISCOVERY0030 | 1 | Discovery - Device description response (2) | The terminal shall not redirect an HTTP GET request to the URL provided in the Location header of the DIAL M-SEARCH response. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.7.2: For terminal and service endpoint discovery, the terminal shall support DIAL [50]. [...] an HTTP GET to the URL obtained from the LOCATION: header in the M-SEARCH response. This HTTP response contains an Application-URL header and a body. The response body is a UPnP device description as required by clause 5.4 of DIAL [50] DIAL,section 5.4: In addition to the requirements of [1], the request SHALL NOT be redirected. | |||
| org.hbbtv_DISCOVERY0040 | 1 | Discovery - Device description response (3) | The terminal shall respond to an HTTP GET request to the DIAL Application Resource URL for HbbTV of the terminal with a 200 OK response code, with the HTTP header Content-Type signalling a mime type "text/xml" and a character encoding UTF-8 and with a response body conforming to the XML schema defined in annex A of DIAL and where the additionalData element conforms to the XML schema defined in clause 14.7.2. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.7.2: The DIAL Application Resource URL for HbbTV is the DIAL REST Service URL followed by a single slash character ('/') and the application name 'HbbTV'. For example: "http://192.168.1.11:11111/apps/HbbTV". The terminal shall support the HbbTV DIAL application, and (shall) respond to an HTTP GET request to the DIAL Application Resource URL for HbbTV with a 200 OK response. The response shall include an XML document, as described in clause 6.1.2 and Annex A of DIAL [51], in the body. The XML document in the HTTP response shall include the mandatory elements and attributes defined in clause 6.1.2 and Annex A of DIAL [51]. There shall be one <additionalData> element containing one of each of the following elements:* An <X_HbbTV_App2AppURL> element that provides the absolute URL of an Application to Application communication service endpoint, i.e. a Web Socket Server URL, as defined in clause 14.5 and the W3C Web Socket protocol specification [40]. * An <X_HbbTV_InterDevSyncURL> element that provides the absolute URL of a CSS-CII service endpoint, i.e. a URL, as defined in clause 13.6 that is used for inter-device synchronisation. * An <X_HbbTV_UserAgent> element that provides the value of the HbbTV terminal's User Agent header as defined in clause 7.3.2.4. See also clause 14.6.3. The xmlns attribute for the HbbTV elements defined above shall be present, and shall be set to:urn:hbbtv:HbbTVCompanionScreen:2014 [...] The additional elements carried in the <additionalData> element shall be encoded using the following XML Schema: <?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:hbbtv:HbbTVCompanionScreen:2014" targetNamespace="urn:hbbtv:HbbTVCompanionScreen:2014" elementFormDefault="qualified"><xs:element name="X_HbbTV_App2AppURL" type="xs:anyURI"/><xs:element name="X_HbbTV_InterDevSyncURL" type="xs:anyURI"/><xs:element name="X_HbbTV_UserAgent" type="xs:string"/></xs:schema> DIAL,section 6.1.2: The MIME type of the response SHALL be text/xml and the character encoding SHALL be UTF-8 and SHALL be explicitly indicated with the charset MIME parameter [...] The XML document SHALL conform to the schema defined in Annex A DIAL,section A: <?xml version="1.0" encoding="UTF-8"?><xs:schema targetNamespace="urn:dial-multiscreen-org:schemas:dial" attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:dial-multiscreen-org:schemas:dial"><xs:import namespace="http://www.w3.org/2005/Atom" schemaLocation="atom.xsd"/><xs:element name="service" type="ServiceType"/><xs:complexType name="ServiceType"><xs:sequence><xs:element name="name" type="xs:string" minOccurs="1" maxOccurs="1"/><xs:element name="options" type="optionsType" minOccurs="0" maxOccurs="1"/><xs:element name="state" type="xs:string" minOccurs="1" maxOccurs="1"/><xs:element name="link" type="linkType" minOccurs="0" maxOccurs="1"/><xs:element name="additionalData" minOccurs="0" maxOccurs="1"><xs:complexType><xs:sequence><xs:any minOccurs="0" processContents="lax"/></xs:sequence></xs:complexType></xs:element></xs:sequence><xs:attribute name="dialVer" type="xs:string" use="optional"/></xs:complexType><xs:complexType name="optionsType"><xs:attribute name="allowStop" type="xs:boolean" use="optional"/></xs:complexType><xs:complexType name="linkType" mixed="true"><xs:attribute name="href" use="required" type="xs:anyURI"/><xs:attribute name="rel" type="xs:string" use="optional"/></xs:complexType></xs:schema> | |||
| org.hbbtv_DISCOVERY0080 | 1 | Discovery - Cross Origin request | When a client is requesting the DIAL XML document using CORS, i.e. including an HTTP Origin header, the terminal shall include HTTP headers as defined in CORS, i.e. the Access-Control-Allow-Origin header shall be present and either contain the asterik character "*" or a case-sensitive match for the value of the Origin header from the HTTP request. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: The HbbTV terminal shall allow cross-origin requests to the HbbTV UPnP device description (for the DIAL service) and the DIAL REST Service. It shall do this by implementing the resource processing model defined in the W3C Cross-Origin Resource Sharing recommendation [42] and authorising all HTTP requests made by a CS application or an HbbTV application on another terminal to come from any origin. Specifically, when the HbbTV terminal receives an HTTP request with request URL targeting the UPnP device description or the DIAL REST Service: If the request contains an Origin header, then the HbbTV terminal shall include an Access-Control-Allow-Origin header in the HTTP response. The value of this response header shall be either the asterisk character "*" or a case-sensitive match for the value of the Origin header from the HTTP request. CORS,section 5.1: The Access-Control-Allow-Origin header indicates whether a resource can be shared based by returning the value of the Origin request header, "*", or "null" in the response. | |||
| org.hbbtv_DISPLAY_SIZE0010 | 1 | Display size - built in display | The XML capabilities include a display_size element with a measurement_type attribute that is "built-in" and width and height attributes indicating the horizontal width and vertical height of the display respectively, both in units of centimeters and both accurate within 5cm. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.4.7: Terminals with a built-in or HDMI-connected display shall include one or more elements of the following form to describe the size of display: <display_size width="w" height="h" measurement_type=”t”/> where w and h are integer values describing the horizontal width and vertical height of the display respectively, both in units of centimeters, and t is a string taking one of the following values: • "built-in", where the display forms an integral part of the terminal. In this case, the width, w, and height, h, shall be accurate to within 5cm. • "hdmi-accurate", where the display is connected by HDMI and the width, w, and height, h, are reported by the display as being accurate to within 5cm or less. • "hdmi-other", where the display is connected by HDMI and the width, w, and height, h, are not reported as accurate to within 5cm. NOTE 4: HDMI carries display size information in the Maximum Image Size fields of EDID Block 0. Image Size accuracy information is carried in the HDMI extensions in the CTA Data Block within the EDID. All terminals with a built-in or HDMI-connected display shall include one such element representing the terminal’s primary display. Terminals that have, or are connected to more than one display may optionally include additional elements describing other displays. The meaning of “primary display” in this context is implementation dependent but would normally be the built-in display if there is one, or the active display that has the best quality. | +HAS_DISPLAY | ||
| org.hbbtv_DISPLAY_SIZE0020 | 1 | Display size - HDMI display accurately reporting size within 5cm | The XML capabilities include a display_size element with width and height attributes indicating the horizontal width and vertical height of the connected HDMI display respectively, both in units of centimeters and a measurement_type attribute that is "hdmi-accurate". The accuracy of the width and height attributes is within 5cm. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.4.7: Terminals with a built-in or HDMI-connected display shall include one or more elements of the following form to describe the size of display: <display_size width="w" height="h" measurement_type=”t”/> where w and h are integer values describing the horizontal width and vertical height of the display respectively, both in units of centimeters, and t is a string taking one of the following values: • "built-in", where the display forms an integral part of the terminal. In this case, the width, w, and height, h, shall be accurate to within 5cm. • "hdmi-accurate", where the display is connected by HDMI and the width, w, and height, h, are reported by the display as being accurate to within 5cm or less. • "hdmi-other", where the display is connected by HDMI and the width, w, and height, h, are not reported as accurate to within 5cm. NOTE 4: HDMI carries display size information in the Maximum Image Size fields of EDID Block 0. Image Size accuracy information is carried in the HDMI extensions in the CTA Data Block within the EDID. All terminals with a built-in or HDMI-connected display shall include one such element representing the terminal’s primary display. Terminals that have, or are connected to more than one display may optionally include additional elements describing other displays. The meaning of “primary display” in this context is implementation dependent but would normally be the built-in display if there is one, or the active display that has the best quality. | -HAS_DISPLAY | ||
| org.hbbtv_DISPLAY_SIZE0030 | 1 | Display size - HDMI display not accurately reporting size within 5cm | The XML capabilities include a display_size element with width and height attributes and a measurement_type attribute that is "hdmi-other". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.4.7: Terminals with a built-in or HDMI-connected display shall include one or more elements of the following form to describe the size of display: <display_size width="w" height="h" measurement_type=”t”/> where w and h are integer values describing the horizontal width and vertical height of the display respectively, both in units of centimeters, and t is a string taking one of the following values: • "built-in", where the display forms an integral part of the terminal. In this case, the width, w, and height, h, shall be accurate to within 5cm. • "hdmi-accurate", where the display is connected by HDMI and the width, w, and height, h, are reported by the display as being accurate to within 5cm or less. • "hdmi-other", where the display is connected by HDMI and the width, w, and height, h, are not reported as accurate to within 5cm. NOTE 4: HDMI carries display size information in the Maximum Image Size fields of EDID Block 0. Image Size accuracy information is carried in the HDMI extensions in the CTA Data Block within the EDID. All terminals with a built-in or HDMI-connected display shall include one such element representing the terminal’s primary display. Terminals that have, or are connected to more than one display may optionally include additional elements describing other displays. The meaning of “primary display” in this context is implementation dependent but would normally be the built-in display if there is one, or the active display that has the best quality. | -HAS_DISPLAY | ||
| org.hbbtv_DSM200 | 1 | Cache validity - carousel unmounted | A broadcast-related application retrieves a file from an object carousel that contains content 1. The application becomes broadcast-independent. The object carousel is then updated to contain content 2, but the version number of the module containing the content is not changed. The application becomes broadcast-related again. When the application retrieves the same file, content 2 is retrieved. | 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.2: The terminal shall consider cached information to remain valid only whilst the relevant object carousel is mounted and is being monitored. This prevents the possibility of retrieving stale data from a carousel which has been unmounted and remounted if the version number of an object has been incremented such that it has the same value as when it was cached. For the avoidance of doubt, changes to DSI messages shall not be considered to be an unmounting of the carousel. [...] Any cached information that is invalid shall be flushed from the cache. | |||
| org.hbbtv_DSM210 | 1 | Cache validity - carousel removed from PMT | A broadcast-related application retrieves a file from an object carousel that contains content 1. The data_broadcast_id_descriptor and carousel_id_descriptor for the carousel are removed from the PMT. The object carousel is then updated to contain content 2, but the version number of the module containing the content is not changed. The descriptors are re-added to the PMT. When the application retrieves the same file, content 2 is retrieved. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: The cache ceases to be valid if the carousel signalling is removed from the PMT. [...] Any cached information that is invalid shall be flushed from the cache. | |||
| org.hbbtv_DSM230 | 1 | Cache validity - service change - different carousel | A broadcast-related application retrieves a file from an object carousel that contains content 1. The object carousel is then updated to contain content 2 and the carousel ID is also changed, but the version number of the module containing the content is not changed. The service is then changed to a second service, which contains the same carousel (i.e. the same PID and association tags) but signals the new carousel ID. When the second application retrieves the same file, content 2 is retrieved. | 2024-1 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.2.2: The cache ceases to be valid when the selected broadcast service changes unless the new service contains the same carousel as the previous service (see clause B.2.10 of ETSI TS 102 809 [3]) and the terminal is able to monitor the carousel continuously. Any cached information that is invalid shall be flushed from the cache. | |||
| org.hbbtv_DSM250 | 1 | Cache validity - files and directories updated | An object carousel contains three different files: //data.txt //dir/data.txt //dir/subdir/data.txt At regular intervals, the content of all three files changes, and the directory "subdir" is renamed "newdir" and back to "subdir" again. When an application makes regular attempts to retrieve files, the results are as follows: //data.txt - content A1, then content A2, then content A3, then content A4 //dir/data.txt - content B1, then content B2, then content B3, then content B4 //dir/subdir/data.txt - content C1, then 404, then content C3, then 404 //dir/newdir/data.txt - 404, then content C2, then 404, then content C4 | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: Support for the caching_priority_descriptor as defined in clause B.2.2.4.2 of ETSI TS 102 809 [3] is not included. Clause B.5.2 of ETSI TS 102 809 [3] specifies that transparent caching is the default caching level in the absence of this descriptor. [...] Any cached information that is invalid shall be flushed from the cache. | |||
| org.hbbtv_DSM260 | 1 | Cache validity - carousel structure updated | An object carousel contains the files //real/data.txt and //dummy/data.txt. Module 1 contains the directory "real" and the file "//dummy/data.txt" and module 2 contains the directory "dummy" and the file "//real/data.txt". At regular intervals, the file and directory objects swap modules. During the first swap, the object keys are unchanged; during the second swap, the object keys change to new values; during the third swap, the object keys are also swapped; during the fourth swap, the object keys return to their original values. When an application retrieves //real/data.txt during each state of the carousel, the correct content is retrieved. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: Support for the caching_priority_descriptor as defined in clause B.2.2.4.2 of ETSI TS 102 809 [3] is not included. Clause B.5.2 of ETSI TS 102 809 [3] specifies that transparent caching is the default caching level in the absence of this descriptor. [...] Any cached information that is invalid shall be flushed from the cache. | |||
| org.hbbtv_DSMCC001 | 1 | Adding stream event listeners: valid stream event | The addStreamEventListener method is called with a valid targetURL and eventName of a valid and available StreamEvent. The EventListener supplied to the method is also valid and instantiated. A StreamEvent of type "StreamEvent" with status equal to "trigger" shall be dispatched and passed to the event listener. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: Adding and removing stream event listeners | |||
| org.hbbtv_DSMCC002 | 1 | Adding stream event listeners: malformed targetURL | The addStreamEventListener method is called with a malformed targetURL. The EventListener supplied to the method is valid and instantiated. A StreamEvent of type "StreamEvent" with status equal to "error" shall be dispatched and passed to the event listener. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: Adding and removing stream event listeners | |||
| org.hbbtv_DSMCC003 | 1 | Adding stream event listeners: malformed eventName | The addStreamEventListener method is called with a malformed eventName. The EventListener supplied to the method is valid and instantiated. A StreamEvent of type "StreamEvent" with status equal to "error" shall be dispatched and passed to the event listener. | 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 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.1.1: Adding and removing stream event listeners | |||
| org.hbbtv_DSMCC004 | 1 | Adding stream event listeners: eventName not found | The addStreamEventListener method is called with a well formed eventName. However, the StreamEvent object pointed to by targetURL does not contain the event specified by eventName. The EventListener supplied to the method is valid and instantiated. A StreamEvent of type "StreamEvent" with status equal to "error" shall be dispatched and passed to the event listener. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: Adding and removing stream event listeners | |||
| org.hbbtv_DSMCC005 | 1 | Removing stream event listeners with an altered eventName | It shall be impossible to remove a registered stream event listener via removeStreamEventListener with all matching parameters but a different eventName value compared with the one used when registering the listener. The registered listener shall function as before. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: Adding and removing stream event listeners | |||
| org.hbbtv_DSMCC006 | 1 | Adding stream event listeners: identical instances | The addStreamEventListener method is called with a valid targetURL and eventName of a valid and available StreamEvent. The EventListener supplied to the method is valid and instantiated and the call succeeds. Upon the reception of multiple identical instances of the MPEG private data section carrying an event (including the version number), only one event shall be dispatched. A StreamEvent of type "StreamEvent" with status equal to "trigger" shall be dispatched and passed to the event listener. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: Adding and removing stream event listeners | |||
| org.hbbtv_DSMCC007 | 1 | Adding stream event listeners: different version numbers | The addStreamEventListener method is called with a valid targetURL and eventName of a valid and available StreamEvent. The EventListener supplied to the method is valid and instantiated and the call succeeds. Upon receiving multiple instances of an event, with the same event name (but different version numbers), one event shall be dispatched for each different event received. A StreamEvent of type "StreamEvent" with status equal to "trigger" shall be dispatched and passed to the event listener in each case. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: Adding and removing stream event listeners | |||
| org.hbbtv_DSMCC008 | 1 | Removing stream event listeners with matching parameters | It shall be possible to remove a registered stream event listener via removeStreamEventListener with matching parameters and the removed listeners shall not receive any stream event afterwards. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: Adding and removing stream event listeners | |||
| org.hbbtv_DSMCC009 | 1 | Removing stream event listeners with an altered targetURL value | It shall be impossible to remove a registered stream event listener via removeStreamEventListener with all matching parameters but a different targetURL value compared with the one used when registering the listener. The registered listener shall function as before. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: Adding and removing stream event listeners | |||
| org.hbbtv_DSMCC010 | 1 | Removing stream event listeners with an altered listener function value | It shall be impossible to remove a registered stream event listener via removeStreamEventListener with all matching parameters but a different listener function value compared with the one used when registering the listener. The registered listener shall function as before. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: Adding and removing stream event listeners | |||
| org.hbbtv_DSMCC011 | 1 | DSM-CC StreamEvent event: returns valid name | The addStreamEventListener method is called with a valid targetURL and eventName of a valid and available StreamEvent. The EventListener supplied to the method is also valid and instantiated. When a StreamEvent of type "StreamEvent" with status equal to "trigger" is dispatched and passed to the event listener we check that the name element of the StreamEvent returned matches the eventName made in the call to the addStreamEventListener method. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: DSM-CC StreamEvent event | |||
| org.hbbtv_DSMCC012 | 1 | DSM-CC StreamEvent event: returns well formed data element | The addStreamEventListener method is called with a valid targetURL and eventName of a valid and available StreamEvent. The EventListener supplied to the method is also valid and instantiated. When a StreamEvent of type "StreamEvent" with status equal to "trigger" is dispatched and passed to the event listener we check that the data element of the StreamEvent returned is well formed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: DSM-CC StreamEvent event | |||
| org.hbbtv_DSMCC013 | 1 | DSM-CC StreamEvent event: returns well formed text element | The addStreamEventListener method is called with a valid targetURL and eventName of a valid and available StreamEvent. The EventListener supplied to the method is also valid and instantiated. When a StreamEvent of type "StreamEvent" with status equal to "trigger" is dispatched and passed to the event listener we check that the text element of the StreamEvent returned is well formed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: DSM-CC StreamEvent event | |||
| org.hbbtv_DSMCC014 | 1 | Carousel objects access with XMLHttpRequest: XML file via relative URL | The status returned from accessing a relative URL to a DSM-CC xml file object (with extension ".xml") via open() method of XMLHttpRequest shall be 200, the responseText and responseXml returned shall be as defined in XMLHTTPRequest [11] | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_DSMCC015 | 1 | Carousel objects access with XMLHttpRequest: A directory via relative URL | The status returned from accessing a relative URL to a DSM-CC directory object via open() method of XMLHttpRequest shall be 200, the responseText returned shall be a comma-separated list of all objects in the directory including path and name information, the responseXML returned shall be null. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_DSMCC016 | 1 | Carousel objects access with XMLHttpRequest: XML file via absolute URL | The status returned from accessing an absolute URL to a DSM-CC xml file object (with extension ".xml") via open() method of XMLHttpRequest shall be 200, the responseText and responseXml returned shall be as defined in XMLHTTPRequest [11] | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_DSMCC017 | 1 | Carousel objects access with XMLHttpRequest: A directory via absolute URL | The status returned from accessing an absolute URL to a DSM-CC directory object via open() method of XMLHttpRequest shall be 200, the responseText returned shall be a comma-separated list of all objects in the directory including path and name information, the responseXML returned shall be null. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_DSMCC018 | 1 | Carousel objects access with XMLHttpRequest: stream event listing via relative URL | The status returned from accessing a relative URL to a DSM-CC stream event object via open() method of XMLHttpRequest shall be 200, the responseText returned shall be a comma-separated list of all events in the stream event, the responseXML returned shall be null. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_DSMCC019 | 1 | Carousel objects access with XMLHttpRequest: stream event listing via absolute URL | The status returned from accessing an absolute URL to a DSM-CC stream event object via open() method of XMLHttpRequest shall be 200, the responseText returned shall be a comma-separated list of all events in the stream event, the responseXML returned shall be null. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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_DSMCC040 | 1 | Mounting carousel via broadcasting initial page in the same transport stream. | The initial page of the application is broadcast in the current channel, the carousel shall be mounted and the application shall be launched successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.2: A broadcast-related application whose initial page is broadcast will cause its carousel to be mounted by the terminal (in order to be loaded and launched) unless mounting the carousel would require tuning to a transport stream other than the one carrying the current channel. If tuning would be required, the attempt to load the page shall fail as if the file did not exist. A broadcast-related application whose initial page is not broadcast may mount a carousel on the same service using the component_tag, e.g. through an XMLHttpRequest request or a reference (e.g. from an .img. element). If the elementary stream pointed to by the component_tag does not contain a service gateway, the mounting will fail. The terminal shall not allow broadcast-independent applications to mount carousels. In order to mount a carousel or access any other broadcast resources, a broadcast-independent application must first become a broadcast-related application (see clause 6.2.2.6) | |||
| org.hbbtv_DSMCC042 | 1 | Mounting carousel via the component_tag of a carousel containing service gateway. | A broadcast-related application, whose initial page is not broadcast in the current channel, launches. It contains an "img" element referencing an image file and also makes an XMLHttpRequest to a file, which are both in the current channel's carousel encoded with service gateway. The two files shall be retrieved and shall be presented on the screen correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.2: A broadcast-related application whose initial page is broadcast will cause its carousel to be mounted by the terminal (in order to be loaded and launched) unless mounting the carousel would require tuning to a transport stream other than the one carrying the current channel. If tuning would be required, the attempt to load the page shall fail as if the file did not exist. A broadcast-related application whose initial page is not broadcast may mount a carousel on the same service using the component_tag, e.g. through an XMLHttpRequest request or a reference (e.g. from an .img. element). If the elementary stream pointed to by the component_tag does not contain a service gateway, the mounting will fail. The terminal shall not allow broadcast-independent applications to mount carousels. In order to mount a carousel or access any other broadcast resources, a broadcast-independent application must first become a broadcast-related application (see clause 6.2.2.6) | |||
| org.hbbtv_DSMCC043 | 1 | Mounting carousel via the component_tag of a carousel containing no service gateway. | A broadcast-related application, whose initial page is not broadcast in the current channel, launches. It contains an "img" element referencing an image file and also makes an XMLHttpRequest to a second file, which are both in the current channel's carousel carrying no service gateway. The two files shall not be retrieved and shall not be presented. | 2024-1 2023-3 2023-2 2023-1 2022-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.5.2: A broadcast-related application whose initial page is broadcast will cause its carousel to be mounted by the terminal (in order to be loaded and launched) unless mounting the carousel would require tuning to a transport stream other than the one carrying the current channel. If tuning would be required, the attempt to load the page shall fail as if the file did not exist. A broadcast-related application whose initial page is not broadcast may mount a carousel on the same service using the component_tag, e.g. through an XMLHttpRequest request or a reference (e.g. from an .img. element). If the elementary stream pointed to by the component_tag does not contain a service gateway, the mounting will fail. The terminal shall not allow broadcast-independent applications to mount carousels. In order to mount a carousel or access any other broadcast resources, a broadcast-independent application must first become a broadcast-related application (see clause 6.2.2.6) HBBTV,section 8.2.2: Carousel objects access with XMLHttpRequest | |||
| org.hbbtv_DSMCC044 | 1 | Mounting the carousel in broadcast-independent application | Application2 is created via a broadcast-related application, whose initial page is not broadcast, by using createApplication method. Application2 tries to access a file via XMLHttpRequest in the current channel's carousel encoded with service gateway via XMLHttpRequest, the file shall not be retrieved. Application2 is converted to broadcast-related application via using the setchannel(current channel) method and requires the same file again, the content of file shall be retrieved and shall be presented correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.2: A broadcast-related application whose initial page is broadcast will cause its carousel to be mounted by the terminal (in order to be loaded and launched) unless mounting the carousel would require tuning to a transport stream other than the one carrying the current channel. If tuning would be required, the attempt to load the page shall fail as if the file did not exist. A broadcast-related application whose initial page is not broadcast may mount a carousel on the same service using the component_tag, e.g. through an XMLHttpRequest request or a reference (e.g. from an .img. element). If the elementary stream pointed to by the component_tag does not contain a service gateway, the mounting will fail. The terminal shall not allow broadcast-independent applications to mount carousels. In order to mount a carousel or access any other broadcast resources, a broadcast-independent application must first become a broadcast-related application (see clause 6.2.2.6) HBBTV,section 8.2.2: Carousel objects access with XMLHttpRequest | |||
| org.hbbtv_DSMCC046 | 1 | Carousel update | A broadcast-related application, whose initial page is broadcast, requires one file via XMLHttpRequest carried in the current mounted carousel. The file shall be retrieved and shall be presented correctly. After a few seconds, the carousel is updated and the content of the file is updated as well. The file is required again. The updated content of the file shall be retrieved and shall be presented correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: A terminal shall mount a maximum of one carousel at a time for use by the running application. Mounting means that the terminal makes the latest version of the files of the carousel available to the application. Terminals shall support carousels split across up to and including three elementary streams simultaneously as defined in clause 10.2.1. NOTE: Typically, mounting a carousel may involve reading data from the carousel into a cache and monitoring for updates to the carousel. HBBTV,section 8.2.2: Carousel objects access with XMLHttpRequest | |||
| org.hbbtv_DSMCC047 | 1 | Carousel split across: Minimum 3 elementary streams | A broadcast-related application, whose initial page is broadcast, requires four files (file1, file2, file3 and file4) via XMLHttpRequest. The entries of the four files are in the current mounted carousel. The actual content of file1 is located in the current carousel's DDB which is different from the one carrying the application's initial page. The actual content of file2 is located in the same DDB as the one carrying the application's initial page. The actual content of file3 and file4 are located in different carousels, which are different from the ones carrying initial page and file1. The four files shall be retrieved and shall be presented correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: A terminal shall mount a maximum of one carousel at a time for use by the running application. Mounting means that the terminal makes the latest version of the files of the carousel available to the application. Terminals shall support carousels split across up to and including three elementary streams simultaneously as defined in clause 10.2.1. NOTE: Typically, mounting a carousel may involve reading data from the carousel into a cache and monitoring for updates to the carousel. HBBTV,section 10.2.1: Minimum terminal capabilities which shall be available to applications are listed in table 14 for general capabilities. HBBTV,section 8.2.2: Carousel objects access with XMLHttpRequest | |||
| org.hbbtv_DSMCC048 | 1 | Carousel split across: minimum 3 elementary streams plus one reserved for StreamEvent. | A broadcast-related application, whose initial page is not broadcast, requires two files (file1 and file2) via XMLHttpRequest and calls the addStreamEventListener() method to listen for a StreamEvent. The entries of the two files and the StreamEvent are in the current mounted carousel (carousel1), which contains the service gateway. The actual content of file1 and file2 are located in two other carousels (carousel2 and carousel3). The StreamEvent is signalled in another carousel (carousel4). Only carousel1 contains the service gateway. The two files shall be retrieved and presented correctly and the StreamEvent shall be captured. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: A terminal shall mount a maximum of one carousel at a time for use by the running application. Mounting means that the terminal makes the latest version of the files of the carousel available to the application. Terminals shall support carousels split across up to and including three elementary streams simultaneously as defined in clause 10.2.1. NOTE: Typically, mounting a carousel may involve reading data from the carousel into a cache and monitoring for updates to the carousel. HBBTV,section 10.2.1: Minimum terminal capabilities which shall be available to applications are listed in table 14 for general capabilities. HBBTV,section 8.2.2: Carousel objects access with XMLHttpRequest HBBTV,section 8.2.1: Acquisition of DSM-CC stream events | |||
| org.hbbtv_DSMCC049 | 1 | Subsequent carousel mounting in the same transport stream. | A broadcast-related application that requests a file from a valid carousel other than the one that is currently mounted, causes the new carousel to be mounted and the requested file to be loaded successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.3: For a broadcast-related application, once a carousel has been mounted, a request that would require another carousel to be mounted shall succeed and cause the previous carousel to be un-mounted and all of its pending requests to be cancelled, unless mounting the carousel would require tuning to a transport stream other than the one carrying the current channel. | |||
| org.hbbtv_DSMCC051 | 1 | Subsequent carousel mounting in the same transport stream: The pending requests | A broadcast-related application with pending requests from a currently mounted carousel that requires a file from a valid carousel other than the one that is currently mounted, causes the pending requests to the currently mounted carousel to be cancelled, the new carousel to be mounted and the requested file to successfully be loaded. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.3: For a broadcast-related application, once a carousel has been mounted, a request that would require another carousel to be mounted shall succeed and cause the previous carousel to be un-mounted and all of its pending requests to be cancelled, unless mounting the carousel would require tuning to a transport stream other than the one carrying the current channel. | |||
| org.hbbtv_DSMCC053 | 1 | The length constraint of DSM-CC object reference: File object | A broadcast-related application, whose initial page has a DSM-CC object reference which is 64 bytes long, shall be possible to launch. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.4: A resolved DSM-CC object reference shall be at most 64 bytes. | |||
| org.hbbtv_DSMCC054 | 1 | The length constraint of DSM-CC object reference: StreamEvent object | It shall be possible to subscribe to a stream event whose DSM-CC object reference is 64 bytes long. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.4: A resolved DSM-CC object reference shall be at most 64 bytes. | |||
| org.hbbtv_DSMCC101 | 2 | CRC errors in DSM-CC sections | An object carousel composed of DSM-CC sections with and without CRC32 errors is received. | 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 | 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.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.1: The DSM-CC standard provides an option to use either a CRC32 or a checksum for detecting bit errors. For the present document, we make the following restriction: section_syntax_indicator is 1 (indicating the use of the CRC32). | ||
| org.hbbtv_DSMCC102 | 2 | last_section_number for DDB sections is 0xFE | An DSM-CC object carousel with all sections that transport DDB messages have last_section_number set to 0xFE must be received successfully | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.1: For sections transporting DownloadDataBlock fragments: - all modules intended to be retrieved shall have the last section number 0xFE. | ||
| org.hbbtv_DSMCC103 | 2 | Maximum DSM-CC section length is 4096 bytes | An object carousel with DSM-CC sections using maximum allowed section size of 4096 must be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.1: The maximum section length is 4096 bytes for all types of sections used in object carousels. The section overhead is 12 bytes, leaving a maximum of 4084 bytes of payload per section. An object carousel with DSM-CC sections using maximum allowed section size of 4096 must be received. | ||
| org.hbbtv_DSMCC104 | 2 | Maximum number of four DSM-CC sections per TS packet | A DSM-CC object carousel composed of DSM-CC sections with the maximum allowed number of sections per TS packet must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.1.1: Parts of no more than four sections shall be delivered in a single TS packet. | ||
| org.hbbtv_DSMCC105 | 2 | Ignore dsmccAdaptationHeader | A DSM-CC object carousel with dsmccDownloadDataHeader and dsmccMessageHeader with non empty dsmccAdaptationHeader must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.1: Restrictions on DSM-CC DownloadData and Message headers: The terminal may ignore the possible contents of the dsmccAdaptationHeader field. | ||
| org.hbbtv_DSMCC106 | 2 | Maximum size 4066 bytes for DII blockSize | A DSM-CC object carousel with maximum size (4066 bytes) of DII blockSize must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.2: maximum size 4066 bytes (max. section payload - DDB-header size (18)). The recommended blockSize is 4066 bytes. | ||
| org.hbbtv_DSMCC107 | 2 | Ignore privateData field in DII messages | A DSM-CC object carousel with non-empty privateData in the DII messages must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.2: The DownloadInfoIndication is a message that describes a set of modules and gives the necessary parameters to locate the module and retrieve it. The terminal may ignore the possible contents of the privateData field. | ||
| org.hbbtv_DSMCC108 | 2 | Ignore id and selector fields of BIOP::ModuleInfo::Taps | A DSM-CC object carousel with a DII message which encodes a moduleInfo with different values for the tap id and non-empty selector fields must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.4: The moduleInfo structure is placed in the moduleInfo field of the DownloadInfoIndication of the data carousel. It contains the information needed to locate the module. The first tap shall have the use value 0x0017 (BIOP_OBJECT_USE). The id and selector fields are not used and the terminal may ignore them. The terminal may ignore possible other taps in the list. | ||
| org.hbbtv_DSMCC109 | 2 | Ignore additional taps in the BIOP::ModuleInfo::Taps. | A DSM-CC object carousel with a DII message which encodes a moduleInfo with a BIOP::ModuleInfo::Taps with more than one tap must be successfully received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.4: Restrictions on the DII moduleInfo field: BIOP::ModuleInfo::Taps: The terminal may ignore possible other taps in the list. | ||
| org.hbbtv_DSMCC110 | 2 | Support compressed modules in DSM-CC object carousels | A DSM-CC object carousel with compressed modules must be supported. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.4: The terminal shall support the compressed_module_descriptor (tag 0x09) used to signal that the module is transmitted in compressed form. | ||
| org.hbbtv_DSMCC111 | 2 | Ignore unknown descriptors in BIOP::ModuleInfo::UserInfo | A DSM-CC object carousel with a DII message which encodes a moduleInfo with a BIOP::ModuleInfo::UserInfo with unknown descriptors must be succesfully received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.4: BIOP::ModuleInfo::UserInfo The userInfo field contains a loop of descriptors. | ||
| org.hbbtv_DSMCC112 | 2 | BIOP::ModuleInfo::moduleTimeOut, blockTimeOut and minBlockTime | A DSM-CC object carousel whose repetition rate is with the duration defined in its moduleTimeout, blockTimeOut and minBlockTime must be received successfully | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.4: These fields are defined in units of μs. An appropriate value must be explicitly encoded by carousel generation equipment. | ||
| org.hbbtv_DSMCC113 | 2 | Ignore BIOP::ServiceGatewayInfo::downloadTaps | A DSM-CC object carousel with a DSI message which encodes a non-empty BIOP::ServiceGatewayInfo::downloadTaps must be successfully received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.5: Restrictions on the ServiceGatewayInfo. BIOP::ServiceGatewayInfo::downloadTaps: The terminal may ignore the downloadTap list. | ||
| org.hbbtv_DSMCC114 | 2 | Ignore BIOP::ServiceGatewayInfo::serviceContextList | A DSM-CC object carousel with a DSI message which encodes a non-empty BIOP::ServiceGatewayInfo::serviceContextList must be succesfully received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.5: Restrictions on the ServiceGatewayInfo. BIOP::ServiceGatewayInfo::serviceContextList: The terminal may ignore the service context list. | ||
| org.hbbtv_DSMCC115 | 2 | Ignore BIOP::ServiceGatewayInfo::UserInfo | A DSM-CC object carousel with a DSI message which encodes a non-empty BIOP::ServiceGatewayInfo::UserInfo must be succesfully received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.5: Restrictions on the ServiceGatewayInfo. BIOP::ServiceGatewayInfo::UserInfo: The terminal may ignore the user info. | ||
| org.hbbtv_DSMCC116 | 2 | Ignore DownloadCancel messages in DSM-CC object carousels | A DSM-CC object carousel with a DownloadCancel message must be successfully received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.2.6: Download cancel: There is no semantic for this message in this profile. Receivers may ignore them. | ||
| org.hbbtv_DSMCC117 | 2 | BIOP::FileMessage with empty MessageSubHeader::ObjectInfo | A DSM-CC object carousel with a BIOP::FileMessage with empty MessageSubHeader::ObjectInfo must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.3: Restrictions on the BIOP File Message. MessageSubHeader::ObjectInfo: The ObjectInfo may be empty (have a length of zero). | ||
| org.hbbtv_DSMCC118 | 2 | BIOP:FileMessage with MessageSubHeader::ObjectInfo with DSM::File::ContentSize | A DSM-CC object carousel with a BIOP::FileMessage which encodes a MessageSubHeader::ObjectInfo with a DSM::File::ContentSize and no descriptors must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.3: Restrictions on the BIOP File Message. MessageSubHeader::ObjectInfo: If not empty the first 8 bytes of the ObjectInfo shall contain the DSM::File::ContentSize attribute. | ||
| org.hbbtv_DSMCC119 | 2 | BIOP:FileMessage with MessageSubHeader::ObjectInfo with content_type descriptor | A DSM-CC object carousel with a BIOP::FileMessage which encodes a MessageSubHeader::ObjectInfo with a DSM::File::ContentSize and a content_type_descriptor must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.3: Restrictions on the BIOP File Message. MessageSubHeader::ObjectInfo: If not empty the first 8 bytes of the ObjectInfo shall contain the DSM::File::ContentSize attribute. This is optionally followed by a loop of descriptors. The descriptors defined for possible use in this location are: Content type descriptor. | ||
| org.hbbtv_DSMCC120 | 2 | BIOP:FileMessage with MessageSubHeader::ObjectInfo unknown descriptors | A DSM-CC object carousel with a BIOP::FileMessage which encodes a MessageSubHeader::ObjectInfo with a DSM::File::ContentSize followed by unknown descriptors must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.3: Restrictions on the BIOP File Message. MessageSubHeader::ObjectInfo: If not empty the first 8 bytes of the ObjectInfo shall contain the DSM::File::ContentSize attribute. This is optionally followed by a loop of descriptors. | ||
| org.hbbtv_DSMCC121 | 2 | Ignore the MessageSubHeader::ServiceContextList in a BIOP::FileMessage | A DSM-CC object carousel with a non-empty MessageSubHeader::ServiceContextList in a BIOP::FileMessage must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.3: Restrictions on the BIOP File Message. MessageSubHeader::ServiceContextList: The terminal may skip the possible serviceContextList structures. | ||
| org.hbbtv_DSMCC122 | 2 | Ignore MessageSubHeader::ObjectInfo in a BIOP::DirectoryMessage | A DSM-CC object carousel with a BIOP::DirectoryMessage with non-empty MessageSubHeader::ObjectInfo must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.5: Restrictions on the BIOP Directory Message: MessageSubHeader::ObjectInfo: The terminal may skip the N2 possible bytes in the objectInfo field. | ||
| org.hbbtv_DSMCC123 | 2 | Ignore MessageSubHeader::ServiceContextList in a BIOP::DirectoryMessage | A DSM-CC object carousel with a BIOP::DirectoryMessage with non-empty MessageSubHeader::ServiceContextList must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.5: Restrictions on the BIOP Directory Message: MessageSubHeader::ServiceContextList: The terminal may skip the N3 possible serviceContextList structures. | ||
| org.hbbtv_DSMCC125 | 2 | BIOP::DirectoryMessage with empty BIOP::Binding::ObjectInfo | A DSM-CC object carousel with a BIOP::DirectoryMessage with empty BIOP::Binding::ObjectInfo must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.5: Restrictions on the BIOP Directory Message: BIOP::Binding::ObjectInfo: The ObjectInfo for bound objects may be empty (have a length of zero). | ||
| org.hbbtv_DSMCC126 | 2 | BIOP::DirectoryMessage with BIOP::Binding::ObjectInfo with DSM::File::ContentSize | A DSM-CC object carousel with a BIOP::DirectoryMessage with BIOP::Binding::ObjectInfo with DSM::File::ContentSize must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.5: Restrictions on the BIOP Directory Message: BIOP::Binding::ObjectInfo: If the bound object is a file and the ObjectInfo is not empty the first 8 bytes of the ObjectInfo shall contain the ContentSize attribute. | ||
| org.hbbtv_DSMCC127 | 2 | BIOP::DirectoryMessage with BIOP::Binding::ObjectInfo with content_type_descriptor | A DSM-CC object carousel with a BIOP::DirectoryMessage with BIOP::Binding::ObjectInfo with DSM::File::ContentSize followed by a content_type_descriptor must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.5: Restrictions on the BIOP Directory Message: BIOP::Binding::ObjectInfo: If the bound object is a file and the ObjectInfo is not empty the first 8 bytes of the ObjectInfo shall contain the ContentSize attribute. This is optionally followed by a loop of descriptors. The descriptors defined for possible use in this location are: content_type_descriptor. | ||
| org.hbbtv_DSMCC128 | 2 | Ignore unknown descriptors in BIOP::Binding::ObjectInfo in BIOP::DirectoryMessage | A DSM-CC object carousel with a BIOP::DirectoryMessage with BIOP::Binding::ObjectInfo with unknown descriptors must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.5: Restrictions on the BIOP Directory Message: BIOP::Binding::ObjectInfo: If the bound object is a file and the ObjectInfo is not empty the first 8 bytes of the ObjectInfo shall contain the ContentSize attribute. This is optionally followed by a loop of descriptors. The descriptors defined for possible use in this location are: Content type descriptor. | ||
| org.hbbtv_DSMCC129 | 2 | Ignore BIOP::IOR with unknown profile | BIOP object references with unknown profiles must be ignored. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.7: Restrictions on the BIOP IOR, IOP::IOR::taggedProfileList: There shall be at least 1 taggedProfile included in an IOR. For objects carried in a broadcast object carousel, the first taggedProfile shall be either a TAG_BIOP profile or a TAG_LITE_OPTIONS. If the first tagged profile is some other profile, the object is not carried in a broadcast object carousel and the terminal may ignore the object subject to its own capabilities. | ||
| org.hbbtv_DSMCC130 | 2 | BIOP::IOR: Ignore additional IOP::taggedProfiles | IOP::TaggedProfiles following the first profile in a BIOP::IOR must be received successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.7: Restrictions on the BIOP IOR, IOP::IOR::taggedProfileList: There shall be at least 1 taggedProfile included in an IOR. For objects carried in a broadcast object carousel, the first taggedProfile shall be either a TAG_BIOP profile or a TAG_LITE_OPTIONS. If the first tagged profile is some other profile, the object is not carried in a broadcast object carousel and the terminal may ignore the object subject to its own capabilities. | ||
| org.hbbtv_DSMCC131 | 2 | BiopProfileBody: ignore additional BIOP::LiteComponents | BiopProfileBody::LiteComponents following the BiopObjectLocation and DSM::ConnBinder in a BIOP Profile Body must be ignored. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.7.1: Restrictions on the BIOP Profile Body, BiopProfileBody::LiteComponent: The list shall contain exactly 1 BiopObjectLocation and exactly 1 DSM::ConnBinder as the first two components in that order. The terminal may ignore possible other components in the list. | ||
| org.hbbtv_DSMCC132 | 2 | Ignore BIOP object reference with wrong tap type in DSM::ConnBinder | BIOP object references with wrong tap type in DSM::ConnBinder must be ignored. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.7.1: For objects carried in the broadcast object carousel, the first Tap shall be of type BIOP_DELIVERY_PARA_USE. If there is another type of tap in the first position, the terminal may ignore this object reference, as it is a reference for object accessed using another type of protocol (e.g. for return channel use). | ||
| org.hbbtv_DSMCC133 | 2 | BiopProfileBody: Ignore additional taps in DSM::ConnBinder | Taps following the first one in DSM::ConnBinder must be ignored. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.7.1: Restrictions on the BIOP Profile Body, DSM::ConnBinder: For objects carried in the broadcast object carousel, the first Tap shall be of type BIOP_DELIVERY_PARA_USE. If there is another type of tap in the first position, the terminal may ignore this object reference, as it is a reference for object accessed using another type of protocol (e.g. for return channel use). The terminal may ignore possible other taps in the list. | ||
| org.hbbtv_DSMCC134 | 2 | BiopProfileBody: Ignore id field of tap in a DSM::ConnBinder | The id field in a tap of a DSM::ConnBinder must be ignored | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.2.3.7.1: Restrictions on the BIOP Profile Body, DSM::Tap: In the BIOP_DELIVERY_PARA_USE tap, the id field is not used and may be ignored by the terminal. | ||
| org.hbbtv_DSMCC137 | 2 | Add file to DSM-CC object carousel | A new file added to a DSM-CC object carousel must be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.5.3: The Object Carousel may change structure over time, i.e. both files and directories may be added or deleted. | ||
| org.hbbtv_DSMCC138 | 2 | Update file of DSM-CC object carousel | Updates of files of a DSM-CC object carousel must be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.5.3: The Object Carousel may change structure over time, i.e. both files and directories may be added or deleted. | ||
| org.hbbtv_DSMCC139 | 2 | Add directory to DSM-CC object carousel | A new directory added to a DSM-CC object carousel must be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.5.3: The Object Carousel may change structure over time, i.e. both files and directories may be added or deleted. | ||
| org.hbbtv_DSMCC140 | 2 | Update directory of DSM-CC object carousel | An updated directory of a DSM-CC object carousel must be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.5.3: The Object Carousel may change structure over time, i.e. both files and directories may be added or deleted. | ||
| org.hbbtv_DSMCC141 | 2 | Move file object to different module in DSM-CC object carousel | Object moved from one module to another module in a DSM-CC object carousel must still be accessible. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.5.3: The Object Carousel may change structure over time, i.e. both files and directories may be added or deleted. | ||
| org.hbbtv_DSMCC142 | 2 | Change PID of DSM-CC object carousel | The PIDs where an object carousel is transmitted may be updated. The carousel must still be accessible. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 7.2.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.5.3: The Object Carousel may change structure over time, i.e. both files and directories may be added or deleted. | ||
| org.hbbtv_DSMCC143 | 2 | Add new PID for DSM-CC object carousel | The data transmitted on the new PID must be accessible. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: DSM-CC object carousel as defined in clause 7 of TS 102 809 shall be supported. TS-102-809,section B.5.3: The Object Carousel may change structure over time, i.e. both files and directories may be added or deleted. | |||
| org.hbbtv_DVBI_APPLC0020 | 2 | DVB-I;Test for running PRESENT application after change from DVB-DASH to DVB-RF | An autostart broadcast-related application starts as a result of selecting a DVB-I service with a single service instance delivered by DVB-DASH and a linked application controlling media presentation signalled in the service element. The application is not service bound. A new service is selected with a service instance delivered by classic RF-based broadcast with the same application signaled with control code PRESENT in the broadcast AIT. The terminal shall allow the application to run uninterrupted. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0030 | 2 | DVB-I; Test for KILLED application after service selection from DVB-DASH to DVB-RF | An autostart broadcast-related application starts as a result of selecting a DVB-I service with a single service instance delivered by DVB-DASH and a linked application controlling media presentation signalled in the service element. The application is not service bound. A new service is selected with a service instance delivered by classic RF-based broadcast with the same application signaled with control code KILL in the broadcast AIT of the newly selected service, the terminal shall kill the currently running application. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0040 | 1 | DVB-I; Test for NOT SIGNALLED application after service selection from DVB-DASH to DVB-RF | An autostart broadcast-related application starts as a result of selecting a DVB-I service with a single service instance delivered by DVB-DASH and a linked application controlling media presentation signalled in the service element. The application is not service bound. A new service is selected with a service instance delivered by classic RF-based broadcast with the same application not signaled at all in the broadcast AIT of the newly selected service, the terminal shall kill the currently running application. | 2024-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 HBBTV,section O.3: The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0100 | 1 | DVB-I; Application lifecycle - switching from DVB RF channel without app to DVB-I channel with app | A DVB-I service with a single service instance delivered by classic RF-based broadcast is selected that has no application signalled. A DVB-I service is then selected with a single service instance delivered by DVB-DASH and a broadcast-related AUTOSTART application signalled in the service element as a linked application controlling media presentation. The application is started. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.3: The application model and lifecycle in clause 6 of the present document shall be unchanged. The lifecycle of a broadcast-related application that is related to a DVB-I service instance delivered by DVB-DASH shall follow the same rules as a broadcast-related application related to a service delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). All references to AITs in this clause shall be taken as references to XML AITs, more detail is provided in clause O.4. Specifically: • The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). - When both the previously selected service and the newly selected service are DVB-I services delivered by DVB-DASH. TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0110 | 1 | DVB-I;Test for running AUTOSTART application after change from DVB-RF to DVB-DASH | An autostart broadcast-related application starts as a result of selecting a DVB-I service with a single service instance delivered by classic RF-based broadcast and application signalling in a broadcast AIT. The application is not service bound. A new service is selected with a single service instance delivered by DVB-DASH with the already running application signalled in the service element as an application controlling media presentation with control code AUTOSTART. The terminal shall allow the application to run uninterrupted. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0120 | 2 | DVB-I;Test for running PRESENT application after change from DVB-RF to DVB-DASH | An autostart broadcast-related application starts as a result of selecting a DVB-I service with a single service instance delivered by classic RF-based broadcast and application signalling in a broadcast AIT. The application is not service bound. A new service is selected with a single service instance delivered by DVB-DASH with the already running application signalled in the service element as an application controlling media presentation with control code PRESENT. The terminal shall allow the application to run uninterrupted. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0140 | 1 | DVB-I; Test for NOT SIGNALLED application after service selection after service selection from DVB-RF to DVB-DASH | An autostart broadcast-related application starts as a result of selecting a DVB-I service with a service instance delivered by classic RF-based broadcast and application signalling in a broadcast AIT. The application is not service bound. A new service is selected with a single service instance delivered by DVB-DASH with the already running application not signaled at all in the newly selected service, the terminal shall kill the currently running application. | 2024-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 HBBTV,section O.3: The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0200 | 1 | DVB-I; Application lifecycle - switching from DVB-I service without app to DVB-I service with app | A DVB-I service with a single service instance delivered by DVB-DASH is selected that has no application signalled. Another DVB-I service with a single service instance delivered by DVB-DASH is then selected that has a broadcast-related AUTOSTART application signalled in the service element as a linked application controlling media presentation. The application is started. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.3: The application model and lifecycle in clause 6 of the present document shall be unchanged. The lifecycle of a broadcast-related application that is related to a DVB-I service instance delivered by DVB-DASH shall follow the same rules as a broadcast-related application related to a service delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). All references to AITs in this clause shall be taken as references to XML AITs, more detail is provided in clause O.4. Specifically: • The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). - When both the previously selected service and the newly selected service are DVB-I services delivered by DVB-DASH. TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0220 | 2 | DVB-I;Test for running PRESENT application after change from DVB-DASH to DVB-DASH | An autostart broadcast-related application starts as a result of selecting a DVB-I service with a single service instance delivered by DVB-DASH and a linked application controlling media presentation signalled in the service element. The application is not service bound. A new service is selected with a single service instance delivered by DVB-DASH with the same application signaled in the service element with control code PRESENT. The terminal shall allow the application to run uninterrupted. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0230 | 2 | DVB-I; Test for KILLED application after service selection from DVB-DASH to DVB-DASH | An autostart broadcast-related application starts as a result of selecting a DVB-I service with a single service instance delivered by DVB-DASH and a linked application controlling media presentation signalled in the service element. The application is not service bound. A new service is selected with a single service instance delivered by DVB-DASH with the same application signaled in the service element with control code KILL. The terminal shall kill the currently running application. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0240 | 1 | DVB-I; Test for NOT SIGNALLED application after service selection from DVB-DASH to DVB-DASH | An autostart broadcast-related application starts as a result of selecting a DVB-I service with a single service instance delivered by DVB-DASH and a linked application controlling media presentation signalled in the service element. The application is not service bound. A new service is selected with a single service instance delivered by DVB-DASH with the same application not signaled at all for the newly selected service, the terminal shall kill the currently running application. | 2024-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 HBBTV,section O.3: The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0250 | 1 | DVB-I;Test for running AUTOSTART application after change from DVB-DASH to DVB-DASH - serviceBound is true | An autostart broadcast-related application starts as a result of selecting a single DVB-I service with a service instance delivered by DVB-DASH and a linked application controlling media presentation signalled in the service element. The application is signalled with serviceBound as true. A new service is selected with a single service instance delivered by DVB-DASH with the same application signaled in the service element with control code AUTOSTART. The terminal shall kill and restart the application. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0300 | 2 | DVB-I; AIT changes while broadcast related application is running, application still signalled | A DVB-I service delivered by DVB-DASH is selected that has an AUTOSTART broadcast-related application linked to the service signalled in the service element. The MPD contains an event stream with an event signalling the application consistently with the signalling in the DVB-I service list. The event has a duration. The MPD also signals a second event starting at the end of the first event that changes the application signalling but continues to signal the autostart application with a control other than KILL. The application SHALL continue to run. | 2024-1 | The challenge exists but not validated | 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. HBBTV,section O.3: The flow chart in clause 6.2.2.3 shall be followed while the currently selected broadcast service is a DVB-I service instance delivered by DVB-DASH and; The application signalling changes HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.3: DVB-I metadata provides quasi-static application signalling. Certain service instance types can also carry dynamic application signalling. This clause describes those and their relationship with signalling carried in DVB-I metadata. .... The DVB-I client that supports service instances delivered using DVB-DASH and supports an application type that can be signalled by means of a DVB AIT shall support AITs referenced using a RelatedMaterial element and AITs referenced from a DVB-DASH EventStream (see clause 9.1.8 of ETSI TS 103 285 [1]). When a DVB-DASH service instance is selected, application signalling using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 (app with media in parallel) shall take effect until superseded by presentation of a DVB-DASH Period that contains an EventStream with schemeIdUri set to urn:dvb:dash:appsignalling:2016. Presentation of a DVB-DASH Period without such an EventStream shall have no effect on application signalling. TS-103-285,section 9.1.8: An EventStream carrying application signalling information shall have the following properties: - @xlink attributes with value "on request" in an MPD event may be ignored by Players. - The @schemeIdUri attribute shall be set to "urn:dvb:dash:appsignalling:2016". - The @value attribute for this scheme is "1". Other values of the @value attribute are reserved for definition by a future revision of the present document and shall be ignored by terminals. Events associated with the @schemeIdUri attribute "urn:dvb:dash:appsignalling:2016" and the @value attribute of "1" are defined as follows: - The presentation time (as indicated by the @presentationTime attribute) shall be set to indicate a time from which the application signalling is applicable. - A duration (as indicated by the @duration attribute) may be defined for the event, indicating the duration for which the application signalling is applicable. If the duration is undefined, the application signalling can be assumed to be applicable until the presentation time of the next application signalling event. - The value of the element shall be an ApplicationDiscovery record as defined in clause 5.4.5 of ETSI TS 102 809 [31] which shall contain at least one application element. In order to carry XML structured data within the string value of an MPD Event element, the data shall be escaped or placed in a CDATA section in accordance with the XML specification 1.0 [26]. Players following standard XML parsing rules need take no special action in order to extract valid ServiceDiscovery elements from the Event element. - If multiple application signalling events overlap, the one with the latest presentation time shall be applicable in preference to earlier application signalling events. | +DVB_I | |
| org.hbbtv_DVBI_APPLC0310 | 2 | DVB-I; AIT changes while broadcast related application is running, application signaled with KILL and new application signaled instead | A DVB-I service delivered by DVB-DASH is selected that has an AUTOSTART broadcast-related application linked to the service signalled in the service element. The MPD contains an event stream with an event signalling the application consistently with the signalling in the DVB-I service list. The event has a duration. The MPD also signals a second event starting at the end of the first event that signals the previous autostart application with a KILL control code and adds a new AUTOSTART application. The running application SHALL be killed and the new application shall be started. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.3 shall be followed while the currently selected broadcast service is a DVB-I service instance delivered by DVB-DASH and; The application signalling changes HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.1: The DVB-I client that supports service instances delivered using DVB-DASH and supports an application type that can be signalled by means of a DVB AIT shall support AITs referenced using a RelatedMaterial element and AITs referenced from a DVB-DASH EventStream (see clause 9.1.8 of ETSI TS 103 285 [1]). When a DVB-DASH service instance is selected, application signalling using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 (app with media in parallel) shall take effect until superseded by presentation of a DVB-DASH Period that contains an EventStream with schemeIdUri set to urn:dvb:dash:appsignalling:2016. Presentation of a DVB-DASH Period without such an EventStream shall have no effect on application signalling. TS-103-770,section 5.2.3.3: DVB-I metadata provides quasi-static application signalling. Certain service instance types can also carry dynamic application signalling. This clause describes those and their relationship with signalling carried in DVB-I metadata. .... The DVB-I client that supports service instances delivered using DVB-DASH and supports an application type that can be signalled by means of a DVB AIT shall support AITs referenced using a RelatedMaterial element and AITs referenced from a DVB-DASH EventStream (see clause 9.1.8 of ETSI TS 103 285 [1]). When a DVB-DASH service instance is selected, application signalling using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 (app with media in parallel) shall take effect until superseded by presentation of a DVB-DASH Period that contains an EventStream with schemeIdUri set to urn:dvb:dash:appsignalling:2016. Presentation of a DVB-DASH Period without such an EventStream shall have no effect on application signalling. TS-103-285,section 9.1.8: An EventStream carrying application signalling information shall have the following properties: - @xlink attributes with value "on request" in an MPD event may be ignored by Players. - The @schemeIdUri attribute shall be set to "urn:dvb:dash:appsignalling:2016". - The @value attribute for this scheme is "1". Other values of the @value attribute are reserved for definition by a future revision of the present document and shall be ignored by terminals. Events associated with the @schemeIdUri attribute "urn:dvb:dash:appsignalling:2016" and the @value attribute of "1" are defined as follows: - The presentation time (as indicated by the @presentationTime attribute) shall be set to indicate a time from which the application signalling is applicable. - A duration (as indicated by the @duration attribute) may be defined for the event, indicating the duration for which the application signalling is applicable. If the duration is undefined, the application signalling can be assumed to be applicable until the presentation time of the next application signalling event. - The value of the element shall be an ApplicationDiscovery record as defined in clause 5.4.5 of ETSI TS 102 809 [31] which shall contain at least one application element. In order to carry XML structured data within the string value of an MPD Event element, the data shall be escaped or placed in a CDATA section in accordance with the XML specification 1.0 [26]. Players following standard XML parsing rules need take no special action in order to extract valid ServiceDiscovery elements from the Event element. - If multiple application signalling events overlap, the one with the latest presentation time shall be applicable in preference to earlier application signalling events. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0320 | 2 | DVB-I; AIT changes while broadcast related application is running, application no longer signalled and new application signalled instead | A DVB-I service delivered by DVB-DASH is selected that has an AUTOSTART broadcast-related application linked to the service signalled in the service element. The MPD contains an event stream with an event signalling the application consistently with the signalling in the DVB-I service list. The event has a duration. The MPD also signals a second event starting at the end of the first event that does not signal the previous autostart application at all but adds a new AUTOSTART application. The running application SHALL be killed and the new application shall be started. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.3 shall be followed while the currently selected broadcast service is a DVB-I service instance delivered by DVB-DASH and; The application signalling changes HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.3: DVB-I metadata provides quasi-static application signalling. Certain service instance types can also carry dynamic application signalling. This clause describes those and their relationship with signalling carried in DVB-I metadata. .... The DVB-I client that supports service instances delivered using DVB-DASH and supports an application type that can be signalled by means of a DVB AIT shall support AITs referenced using a RelatedMaterial element and AITs referenced from a DVB-DASH EventStream (see clause 9.1.8 of ETSI TS 103 285 [1]). When a DVB-DASH service instance is selected, application signalling using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 (app with media in parallel) shall take effect until superseded by presentation of a DVB-DASH Period that contains an EventStream with schemeIdUri set to urn:dvb:dash:appsignalling:2016. Presentation of a DVB-DASH Period without such an EventStream shall have no effect on application signalling. TS-103-285,section 9.1.8: An EventStream carrying application signalling information shall have the following properties: - @xlink attributes with value "on request" in an MPD event may be ignored by Players. - The @schemeIdUri attribute shall be set to "urn:dvb:dash:appsignalling:2016". - The @value attribute for this scheme is "1". Other values of the @value attribute are reserved for definition by a future revision of the present document and shall be ignored by terminals. Events associated with the @schemeIdUri attribute "urn:dvb:dash:appsignalling:2016" and the @value attribute of "1" are defined as follows: - The presentation time (as indicated by the @presentationTime attribute) shall be set to indicate a time from which the application signalling is applicable. - A duration (as indicated by the @duration attribute) may be defined for the event, indicating the duration for which the application signalling is applicable. If the duration is undefined, the application signalling can be assumed to be applicable until the presentation time of the next application signalling event. - The value of the element shall be an ApplicationDiscovery record as defined in clause 5.4.5 of ETSI TS 102 809 [31] which shall contain at least one application element. In order to carry XML structured data within the string value of an MPD Event element, the data shall be escaped or placed in a CDATA section in accordance with the XML specification 1.0 [26]. Players following standard XML parsing rules need take no special action in order to extract valid ServiceDiscovery elements from the Event element. - If multiple application signalling events overlap, the one with the latest presentation time shall be applicable in preference to earlier application signalling events. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0330 | 2 | DVB-I; AIT changes from no application signalled to add AUTOSTART application | A DVB-I service delivered by DVB-DASH is selected that has no application linked to the service signalled anywhere. The MPD contains an event stream with an event starting some time in the future that signals one application with control code AUTOSTART. The terminal shall not start the application initially. When the start of the event is reached, the application shall be started. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.3 shall be followed while the currently selected broadcast service is a DVB-I service instance delivered by DVB-DASH and; The application signalling changes HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.3: DVB-I metadata provides quasi-static application signalling. Certain service instance types can also carry dynamic application signalling. This clause describes those and their relationship with signalling carried in DVB-I metadata. .... The DVB-I client that supports service instances delivered using DVB-DASH and supports an application type that can be signalled by means of a DVB AIT shall support AITs referenced using a RelatedMaterial element and AITs referenced from a DVB-DASH EventStream (see clause 9.1.8 of ETSI TS 103 285 [1]). When a DVB-DASH service instance is selected, application signalling using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 (app with media in parallel) shall take effect until superseded by presentation of a DVB-DASH Period that contains an EventStream with schemeIdUri set to urn:dvb:dash:appsignalling:2016. Presentation of a DVB-DASH Period without such an EventStream shall have no effect on application signalling. TS-103-285,section 9.1.8: An EventStream carrying application signalling information shall have the following properties: - @xlink attributes with value "on request" in an MPD event may be ignored by Players. - The @schemeIdUri attribute shall be set to "urn:dvb:dash:appsignalling:2016". - The @value attribute for this scheme is "1". Other values of the @value attribute are reserved for definition by a future revision of the present document and shall be ignored by terminals. Events associated with the @schemeIdUri attribute "urn:dvb:dash:appsignalling:2016" and the @value attribute of "1" are defined as follows: - The presentation time (as indicated by the @presentationTime attribute) shall be set to indicate a time from which the application signalling is applicable. - A duration (as indicated by the @duration attribute) may be defined for the event, indicating the duration for which the application signalling is applicable. If the duration is undefined, the application signalling can be assumed to be applicable until the presentation time of the next application signalling event. - The value of the element shall be an ApplicationDiscovery record as defined in clause 5.4.5 of ETSI TS 102 809 [31] which shall contain at least one application element. In order to carry XML structured data within the string value of an MPD Event element, the data shall be escaped or placed in a CDATA section in accordance with the XML specification 1.0 [26]. Players following standard XML parsing rules need take no special action in order to extract valid ServiceDiscovery elements from the Event element. - If multiple application signalling events overlap, the one with the latest presentation time shall be applicable in preference to earlier application signalling events. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0340 | 2 | DVB-I; AIT changes from no broadcast related application is running to add PRESENT app to service | A DVB-I service delivered by DVB-DASH is selected that has no application linked to the service signalled anywhere. The MPD contains an event stream with an event starting some time in the future that signals one application with control code PRESENT. The terminal shall not start the application. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.3 shall be followed while the currently selected broadcast service is a DVB-I service instance delivered by DVB-DASH and; The application signalling changes HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.3: DVB-I metadata provides quasi-static application signalling. Certain service instance types can also carry dynamic application signalling. This clause describes those and their relationship with signalling carried in DVB-I metadata. .... The DVB-I client that supports service instances delivered using DVB-DASH and supports an application type that can be signalled by means of a DVB AIT shall support AITs referenced using a RelatedMaterial element and AITs referenced from a DVB-DASH EventStream (see clause 9.1.8 of ETSI TS 103 285 [1]). When a DVB-DASH service instance is selected, application signalling using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 (app with media in parallel) shall take effect until superseded by presentation of a DVB-DASH Period that contains an EventStream with schemeIdUri set to urn:dvb:dash:appsignalling:2016. Presentation of a DVB-DASH Period without such an EventStream shall have no effect on application signalling. TS-103-285,section 9.1.8: An EventStream carrying application signalling information shall have the following properties: - @xlink attributes with value "on request" in an MPD event may be ignored by Players. - The @schemeIdUri attribute shall be set to "urn:dvb:dash:appsignalling:2016". - The @value attribute for this scheme is "1". Other values of the @value attribute are reserved for definition by a future revision of the present document and shall be ignored by terminals. Events associated with the @schemeIdUri attribute "urn:dvb:dash:appsignalling:2016" and the @value attribute of "1" are defined as follows: - The presentation time (as indicated by the @presentationTime attribute) shall be set to indicate a time from which the application signalling is applicable. - A duration (as indicated by the @duration attribute) may be defined for the event, indicating the duration for which the application signalling is applicable. If the duration is undefined, the application signalling can be assumed to be applicable until the presentation time of the next application signalling event. - The value of the element shall be an ApplicationDiscovery record as defined in clause 5.4.5 of ETSI TS 102 809 [31] which shall contain at least one application element. In order to carry XML structured data within the string value of an MPD Event element, the data shall be escaped or placed in a CDATA section in accordance with the XML specification 1.0 [26]. Players following standard XML parsing rules need take no special action in order to extract valid ServiceDiscovery elements from the Event element. - If multiple application signalling events overlap, the one with the latest presentation time shall be applicable in preference to earlier application signalling events. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0350 | 2 | DVB-I; AIT changes from no broadcast related application is running to add multiple AUTOSTART applications, highest priority app runs | A DVB-I service delivered by DVB-DASH is selected that has no application linked to the service signalled anywhere. The MPD contains an event stream with an event starting some time in the future that signals two AUTOSTART applications carried via HTTP, App1 and App2; App1 has a higher priority. The terminal shall start App1. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.3 shall be followed while the currently selected broadcast service is a DVB-I service instance delivered by DVB-DASH and; The application signalling changes HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.3: DVB-I metadata provides quasi-static application signalling. Certain service instance types can also carry dynamic application signalling. This clause describes those and their relationship with signalling carried in DVB-I metadata. .... The DVB-I client that supports service instances delivered using DVB-DASH and supports an application type that can be signalled by means of a DVB AIT shall support AITs referenced using a RelatedMaterial element and AITs referenced from a DVB-DASH EventStream (see clause 9.1.8 of ETSI TS 103 285 [1]). When a DVB-DASH service instance is selected, application signalling using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 (app with media in parallel) shall take effect until superseded by presentation of a DVB-DASH Period that contains an EventStream with schemeIdUri set to urn:dvb:dash:appsignalling:2016. Presentation of a DVB-DASH Period without such an EventStream shall have no effect on application signalling. TS-103-285,section 9.1.8: An EventStream carrying application signalling information shall have the following properties: - @xlink attributes with value "on request" in an MPD event may be ignored by Players. - The @schemeIdUri attribute shall be set to "urn:dvb:dash:appsignalling:2016". - The @value attribute for this scheme is "1". Other values of the @value attribute are reserved for definition by a future revision of the present document and shall be ignored by terminals. Events associated with the @schemeIdUri attribute "urn:dvb:dash:appsignalling:2016" and the @value attribute of "1" are defined as follows: - The presentation time (as indicated by the @presentationTime attribute) shall be set to indicate a time from which the application signalling is applicable. - A duration (as indicated by the @duration attribute) may be defined for the event, indicating the duration for which the application signalling is applicable. If the duration is undefined, the application signalling can be assumed to be applicable until the presentation time of the next application signalling event. - The value of the element shall be an ApplicationDiscovery record as defined in clause 5.4.5 of ETSI TS 102 809 [31] which shall contain at least one application element. In order to carry XML structured data within the string value of an MPD Event element, the data shall be escaped or placed in a CDATA section in accordance with the XML specification 1.0 [26]. Players following standard XML parsing rules need take no special action in order to extract valid ServiceDiscovery elements from the Event element. - If multiple application signalling events overlap, the one with the latest presentation time shall be applicable in preference to earlier application signalling events. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0360 | 2 | AIT changes from no broadcast related application is running to add multiple AUTOSTART applications, highest priority app cannot be loaded successfully, lower priority app runs | A DVB-I service delivered by DVB-DASH is selected that has no application linked to the service signalled anywhere. The MPD contains an event stream with an event starting some time in the future that signals two AUTOSTART applications carried via HTTP, App1 and App2; App1 has a higher priority. App1 is temporarily unavailable. The terminal shall finally start App2. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.3: The flow chart in clause 6.2.2.3 shall be followed while the currently selected broadcast service is a DVB-I service instance delivered by DVB-DASH and; - The application signalling changes HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.3: DVB-I metadata provides quasi-static application signalling. Certain service instance types can also carry dynamic application signalling. This clause describes those and their relationship with signalling carried in DVB-I metadata. .... The DVB-I client that supports service instances delivered using DVB-DASH and supports an application type that can be signalled by means of a DVB AIT shall support AITs referenced using a RelatedMaterial element and AITs referenced from a DVB-DASH EventStream (see clause 9.1.8 of ETSI TS 103 285 [1]). When a DVB-DASH service instance is selected, application signalling using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 (app with media in parallel) shall take effect until superseded by presentation of a DVB-DASH Period that contains an EventStream with schemeIdUri set to urn:dvb:dash:appsignalling:2016. Presentation of a DVB-DASH Period without such an EventStream shall have no effect on application signalling. TS-103-285,section 9.1.8: An EventStream carrying application signalling information shall have the following properties: - @xlink attributes with value "on request" in an MPD event may be ignored by Players. - The @schemeIdUri attribute shall be set to "urn:dvb:dash:appsignalling:2016". - The @value attribute for this scheme is "1". Other values of the @value attribute are reserved for definition by a future revision of the present document and shall be ignored by terminals. Events associated with the @schemeIdUri attribute "urn:dvb:dash:appsignalling:2016" and the @value attribute of "1" are defined as follows: - The presentation time (as indicated by the @presentationTime attribute) shall be set to indicate a time from which the application signalling is applicable. - A duration (as indicated by the @duration attribute) may be defined for the event, indicating the duration for which the application signalling is applicable. If the duration is undefined, the application signalling can be assumed to be applicable until the presentation time of the next application signalling event. - The value of the element shall be an ApplicationDiscovery record as defined in clause 5.4.5 of ETSI TS 102 809 [31] which shall contain at least one application element. In order to carry XML structured data within the string value of an MPD Event element, the data shall be escaped or placed in a CDATA section in accordance with the XML specification 1.0 [26]. Players following standard XML parsing rules need take no special action in order to extract valid ServiceDiscovery elements from the Event element. - If multiple application signalling events overlap, the one with the latest presentation time shall be applicable in preference to earlier application signalling events. 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. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0370 | 2 | DVB-I; AIT changes while broadcast related application is running, application still signalled - service instance | A DVB-I service delivered by DVB-DASH is selected that has an AUTOSTART broadcast-related application signalled in the service instance. The MPD contains an event stream with an event signalling the application consistently with the signalling in the DVB-I service list. The event has a duration. The MPD also signals a second event starting at the end of the first event that changes the application signalling but continues to signal the autostart application with a control other than KILL. The application SHALL continue to run. | 2024-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. HBBTV,section O.3: The flow chart in clause 6.2.2.3 shall be followed while the currently selected broadcast service is a DVB-I service instance delivered by DVB-DASH and; The application signalling changes HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). TS-103-770,section 5.2.3.3: DVB-I metadata provides quasi-static application signalling. Certain service instance types can also carry dynamic application signalling. This clause describes those and their relationship with signalling carried in DVB-I metadata. .... The DVB-I client that supports service instances delivered using DVB-DASH and supports an application type that can be signalled by means of a DVB AIT shall support AITs referenced using a RelatedMaterial element and AITs referenced from a DVB-DASH EventStream (see clause 9.1.8 of ETSI TS 103 285 [1]). When a DVB-DASH service instance is selected, application signalling using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 (app with media in parallel) shall take effect until superseded by presentation of a DVB-DASH Period that contains an EventStream with schemeIdUri set to urn:dvb:dash:appsignalling:2016. Presentation of a DVB-DASH Period without such an EventStream shall have no effect on application signalling. TS-103-285,section 9.1.8: An EventStream carrying application signalling information shall have the following properties: - @xlink attributes with value "on request" in an MPD event may be ignored by Players. - The @schemeIdUri attribute shall be set to "urn:dvb:dash:appsignalling:2016". - The @value attribute for this scheme is "1". Other values of the @value attribute are reserved for definition by a future revision of the present document and shall be ignored by terminals. Events associated with the @schemeIdUri attribute "urn:dvb:dash:appsignalling:2016" and the @value attribute of "1" are defined as follows: - The presentation time (as indicated by the @presentationTime attribute) shall be set to indicate a time from which the application signalling is applicable. - A duration (as indicated by the @duration attribute) may be defined for the event, indicating the duration for which the application signalling is applicable. If the duration is undefined, the application signalling can be assumed to be applicable until the presentation time of the next application signalling event. - The value of the element shall be an ApplicationDiscovery record as defined in clause 5.4.5 of ETSI TS 102 809 [31] which shall contain at least one application element. In order to carry XML structured data within the string value of an MPD Event element, the data shall be escaped or placed in a CDATA section in accordance with the XML specification 1.0 [26]. Players following standard XML parsing rules need take no special action in order to extract valid ServiceDiscovery elements from the Event element. - If multiple application signalling events overlap, the one with the latest presentation time shall be applicable in preference to earlier application signalling events. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0410 | 1 | DVBI; Stability - no A/V glitches when application launches - autostart/IP | When a terminal is presenting audio and video from a single DVB-I service instance delivered by DVB-DASH, a broadcast-related autostart (linked) application delivered over broadband launches, and the application does not try to control video playback, there are no artifacts or glitches in the presented audio or video. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 9.8: Terminals shall be able to present broadcast audio and video reliably when HbbTV applications are launching and stopping. Specifically: When the terminal launches a broadcast-related application and broadcast audio or video is being presented and that application does not try to control video playback, there shall not be any artifacts or glitches in presented broadcast audio or video. This includes applications delivered by broadband and DSM-CC object carousel, as well as both autostart and non-autostart applications. HBBTV,section O.6.5: The requirements in clause 9.8 of the present document are extended as follows for broadcast-related applications linked to a DVB-I service instance delivered by DVB-DASH. - Terminals shall operate reliably in response to rapid user interaction. Specifically, the terminal shall remain fully functional in the following circumstances. Fully functional in this case means at least that the appropriate application at the end of each sequence starts successfully, that it functions as designed and that, where a broadcast service is selected, the video and audio from that service are presented: The user changes the selected service 20 times consecutively between two services carrying broadcast-related autostart applications, one delivered in a carousel, the other delivered over broadband, the time interval between requested service changes varying between 50 ms and the greater of (a) the time interval required for the application to start fully and (b) 1 second. The service with the carousel-delivered application is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). The service with the broadband-delivered application is a DVB-I service instance delivered by DVB-DASH. - The requirements relating to terminals being able to present broadcast audio and video reliably when HbbTV applications are launching shall apply to applications linked to DVB-I service instances delivered by DVB-DASH excluding the reference to applications delivered by DSM-CC object carousel. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0530 | 4 | DVB-I; A broadcast-independent application originally started as a broadcast-related autostart application successfully transitions back to a broadcast-related application | An autostart broadcast-related application starts as a result of selecting a DVB-I service with a single service instance delivered by DVB-DASH and a linked application controlling media presentation. The application transitions itself to become a broadcast-independent application using setChannel(null). The broadcast-independent application attempts to become a broadcast-related application, by successfully selecting a DVB-I service delivered by DVB-DASH. The application is signalled as a linked application controlling media presentation. It 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 DVB-I service to be selected with control code AUTOSTART or PRESENT. 3. The application signalled in the DVB-I service 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 DVB-I 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-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. HBBTV,section O.3: The requirements in clause 6.2.2.6 of the present document concerning broadcast-independent applications that select a broadcast service using a video/broadcast object shall apply identically when the service selected is delivered by DVB-DASH as when the service selected is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). This shall apply regardless of how the broadcast-independent application was originally started; as an autostart broadcast-related application that later changed to broadcast-independent, HBBTV,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0540 | 4 | DVB-I; A broadcast-independent application started by DIAL successfully transitions to a broadcast-related application | A broadcast-independent application is started using DIAL. The terminal has a DVB-I service list installed that a service with the "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" extension with known values for the DVB triplet and that signals, in its service element, a broadcast-related linked application meeting the following requirements; 1. the Application.applicationIdentifier matches the Application.applicationIdentifier of the broadcast-independent application, 2. it is signalled with control code AUTOSTART, 3. it includes an HTTP transport protocol descriptor, 4. the URL signalled by the HTTP transport protocol descriptor has the same origin as the entry point document of the broadcast-independent application and 5. it has an application boundary that contains the URL of the page currently loaded in the broadcast-independent application. The broadcast-independent application creates a Channel object by calling createChannelObject with idType equal to ID_DVB_I and onid, tsid and sid equal to the known values for the DVB-I service referred to earlier. The broadcast-independent application calls the setChannel method with that Channel object. The broadcast-related application successfully transitions to become broadcast-related. | 2024-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. HBBTV,section O.3: The requirements in clause 6.2.2.6 of the present document concerning broadcast-independent applications that select a broadcast service using a video/broadcast object shall apply identically when the service selected is delivered by DVB-DASH as when the service selected is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). This shall apply regardless of how the broadcast-independent application was originally started; as an autostart broadcast-related application that later changed to broadcast-independent, HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). HBBTV,section O.4: The following XML fragment shall be supported as an extension of the ServiceType.AdditionalServiceParameters element defined in clause 5.5.2 of TS 103 770 [96]. The mandatory extensionName attribute inherited from the base type shall be "urn:hbbtv:dvbi:service:serviceIdentifierTriplet". The added element shall be in the XML namespace "urn:hbbtv:dvbi:schema:2021". The normative definition of this schema is found in the electronic attachments - see annex N of the present document. …. xmlns:hbbtv-i="urn:hbbtv:dvbi:schema:2021" … <complexType name="ServiceIdentifierTriplet"> <complexContent> <extension base="dvbisd:ExtensionBaseType"> <element name="DVBTriplet" type="dvbisd:DVBTripletType"/> </extension> </complexContent> </complexType> OIPF-DAE,section 7.13.1.3: Channel createChannelObject( Integer idType, Integer onid, Integer tsid, Integer sid, Integer sourceID, String ipBroadcastID ) Description Creates a Channel object of the specified idType. The Channel object can subsequently be used by the setChannel() method to switch a tuner to this channel, which may or may not be part of the channel list in the OITF. The resulting Channel object represents a locally defined channel which, if not already present there, does not get added to the channel list accessed through the ChannelConfig class (see section 7.13.9). If the channel of the given idType cannot be created or the given (combination of) arguments are not considered valid or complete, the method SHALL return null. If the channel of the given type can be created and arguments are considered valid and complete, then either: 1. If the channel is in the channel list then a new object of the same type and with properties with the same values SHALL be returned as would be returned by calling getChannelWithTriplet() with the same parameters as this method. 2. Otherwise, the method SHALL return a Channel object whereby at a minimum the properties with the same names are given the same value as the given arguments of the createChannelObject() method. The values specified for the remaining properties of the Channel object are set to undefined. Arguments idType; The type of channel, as indicated by one of the ID_* constants defined in section 7.13.11.1. onid; The original network ID. Optional argument that SHALL be specified when the idType specifies a channel of type ID_DVB_*, ID_IPTV_URI, or ID_ISDB_* and SHALL otherwise be ignored by the OITF. tsid; The transport stream ID. Optional argument that MAY be specified when the idType specifies a channel of type ID_DVB_*, ID_IPTV_URI, or ID_ISDB_* and SHALL otherwise be ignored by the OITF. sid; The service ID. Optional argument that SHALL be specified when the idType specifies a channel of type ID_DVB_*, ID_IPTV_URI, or ID_ISDB_* and SHALL otherwise be ignored by the OITF. sourceID; The source_ID. Optional argument that SHALL be specified when the idType specifies a channel of type ID_ATSC_T and SHALL otherwise be ignored by the OITF. ipBroadcastID; The DVB textual service identifier of the IP broadcast service, specified in the format “ServiceName.DomainName” when idType specifies a channel of type ID_IPTV_SDS, or the URI of the IP broadcast service when idType specifies a channel of type ID_IPTV_URI. Optional argument that SHALL be specified when the idType specifies a channel of type ID_IPTV_SDS or ID_IPTV_URI and SHALL otherwise be ignored by the OITF. | +DVB_I +RLAUNCH_USER_APPROVAL | ||
| org.hbbtv_DVBI_APPLC0550 | 4 | DVB-I; A broadcast-independent application started from app store successfully transitions to a broadcast-related application | A broadcast-independent application is started from an app store. The terminal has a DVB-I service list intalled that a service with the "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" extension with known values for the DVB triplet and that signals, in its service element, a broadcast-related linked application meeting the following requirements: 1. the Application.applicationIdentifier matches the Application.applicationIdentifier of the broadcast-independent application, 2. it is signalled with control code AUTOSTART, 3. it includes an HTTP transport protocol descriptor, 4. the URL signalled by the HTTP transport protocol descriptor has the same origin as the entry point document of the broadcast-independent application and 5. it has an application boundary that contains the URL of the page currently loaded in the broadcast-independent application. The broadcast-independent application creates a Channel object by calling createChannelObject with idType equal to ID_DVB_I and onid, tsid and sid equal to the known values for the DVB-I service referred to earlier. The broadcast-independent application calls the setChannel method with that Channel object. The broadcast-related application successfully transitions to become broadcast-related. | 2024-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. HBBTV,section O.3: The requirements in clause 6.2.2.6 of the present document concerning broadcast-independent applications that select a broadcast service using a video/broadcast object shall apply identically when the service selected is delivered by DVB-DASH as when the service selected is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). This shall apply regardless of how the broadcast-independent application was originally started; as an autostart broadcast-related application that later changed to broadcast-independent, HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). HBBTV,section O.4: The following XML fragment shall be supported as an extension of the ServiceType.AdditionalServiceParameters element defined in clause 5.5.2 of TS 103 770 [96]. The mandatory extensionName attribute inherited from the base type shall be "urn:hbbtv:dvbi:service:serviceIdentifierTriplet". The added element shall be in the XML namespace "urn:hbbtv:dvbi:schema:2021". The normative definition of this schema is found in the electronic attachments - see annex N of the present document. …. xmlns:hbbtv-i="urn:hbbtv:dvbi:schema:2021" … <complexType name="ServiceIdentifierTriplet"> <complexContent> <extension base="dvbisd:ExtensionBaseType"> <element name="DVBTriplet" type="dvbisd:DVBTripletType"/> </extension> </complexContent> </complexType> OIPF-DAE,section 7.13.1.3: Channel createChannelObject( Integer idType, Integer onid, Integer tsid, Integer sid, Integer sourceID, String ipBroadcastID ) Description Creates a Channel object of the specified idType. The Channel object can subsequently be used by the setChannel() method to switch a tuner to this channel, which may or may not be part of the channel list in the OITF. The resulting Channel object represents a locally defined channel which, if not already present there, does not get added to the channel list accessed through the ChannelConfig class (see section 7.13.9). If the channel of the given idType cannot be created or the given (combination of) arguments are not considered valid or complete, the method SHALL return null. If the channel of the given type can be created and arguments are considered valid and complete, then either: 1. If the channel is in the channel list then a new object of the same type and with properties with the same values SHALL be returned as would be returned by calling getChannelWithTriplet() with the same parameters as this method. 2. Otherwise, the method SHALL return a Channel object whereby at a minimum the properties with the same names are given the same value as the given arguments of the createChannelObject() method. The values specified for the remaining properties of the Channel object are set to undefined. Arguments idType; The type of channel, as indicated by one of the ID_* constants defined in section 7.13.11.1. onid; The original network ID. Optional argument that SHALL be specified when the idType specifies a channel of type ID_DVB_*, ID_IPTV_URI, or ID_ISDB_* and SHALL otherwise be ignored by the OITF. tsid; The transport stream ID. Optional argument that MAY be specified when the idType specifies a channel of type ID_DVB_*, ID_IPTV_URI, or ID_ISDB_* and SHALL otherwise be ignored by the OITF. sid; The service ID. Optional argument that SHALL be specified when the idType specifies a channel of type ID_DVB_*, ID_IPTV_URI, or ID_ISDB_* and SHALL otherwise be ignored by the OITF. sourceID; The source_ID. Optional argument that SHALL be specified when the idType specifies a channel of type ID_ATSC_T and SHALL otherwise be ignored by the OITF. ipBroadcastID; The DVB textual service identifier of the IP broadcast service, specified in the format “ServiceName.DomainName” when idType specifies a channel of type ID_IPTV_SDS, or the URI of the IP broadcast service when idType specifies a channel of type ID_IPTV_URI. Optional argument that SHALL be specified when the idType specifies a channel of type ID_IPTV_SDS or ID_IPTV_URI and SHALL otherwise be ignored by the OITF. | +APPSTORE +DVB_I | ||
| org.hbbtv_DVBI_APPLC0620 | 2 | DVB-I; CreateApplication with parameters in URL | An AUTOSTART broadcast-related application in a DVB-I service delivered by DVB-DASH that is a linked application controlling media presentation calls createApplication to start a second broadcast-related application in the same service that is signalled as PRESENT including some parameters (?param2=value2) with the method call. The second application has parameters in the XML AIT (?param1=value1). The parameters of the createApplication call and from the XML AIT are combined. | 2024-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) HBBTV,section O.3: Broadcast-related applications related to a DVB-I service shall be able to; ... Create broadcast-related applications using the createApplication method with a URL of the form ‘dvb://current.ait/orgid.appid?param1=val1&...’ (see clause 9.2 of the present document and table 2 of TS 102 851 []). HBBTV,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0630 | 1 | DVB-I; Service is inactive | A service signalled using DVB-I has a linked application of type 1.1, a linked application of type 2 and a RelatedMaterial link to a still image. The service is outside its availability period. When the service is selected, the linked application of type 2 runs. The linked application has a launch context query parameter of the form "lloc=availability". | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.4: Signalling of applications in the DVB-I sevice list as defined in clause 5.2.3 of TS 103 770 [] shall be supported. HBBTV,section O.3: Requirements in clause 6 of the present document that are modified in the context of DVB-I are the following: ...... - In clause 6.2.2.6.1, the list of ways in which a broadcast-independent application may be created is extended with creation from a DVB-I content guide based on the signalling defined in clause 5.2.4 of TS 103 770 [96]. - Terminals shall add a launch context query parameter to linked applications as defined in clause 5.2.3.1 of TS 103 770 [96] and table 2a of the present document. NOTE: It is intentional that the above is a requirement even though the referenced text uses "may" or "should" or is located in an informative clause. TS-103-770,section 5.2.3.1: There may optionally be a separate RelatedMaterial element referencing an application with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:2 . This is for use when the service is not active (i.e. outside of the specified availability period, if included). Such an application shall be started in preference to the presentation of any still image signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:HowRelatedCS:2020:1000.1 (see clause 5.2.5.3) where the application type is Supported. TS-103-770,section 5.2.3.1: When a linked application is launched, the context in which the application was invoked may be passed to the application. For broadcast-independent HbbTV applications, this is defined in clause 6.2.2.6.2 of ETSI TS 102 796 [21]. …. • For linked applications where HowRelated@href is set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:2 , the launch location "availability" should be Used. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0660 | 2 | DVB-I; Service-bound application started from service instance delivered over broadband | An autostart broadcast-related application starts as a result of selecting a DVB-I service with a single service instance delivered by DVB-DASH. The application is signalled as service bound and 'application with media in parallel'. A new service is selected with a service instance delivered by classic RF-based broadcast with the same application signaled with control code PRESENT in the broadcast AIT. The terminal shall kill the currently running application. | 2024-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. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0680 | 2 | DVB-I; Application lifecycle on changing service instance - application initiated - application killed | A DVB-I service is selected that has a broadcast-delivered service instance and a broadband-delivered service instance. The broadcast-delivered service instance has the highest priority. Different applications are signalled as autostart in the AIT of the broadcast-delivered service instances and the service instance element of the broadband-delivered service instance. The autostart application in the broadcast service instance calls setChannel with a Channel object corresponding to the broadband-delivered service instance. The broadband-delivered service instance is selected, the running application killed and the application signalled in the broadband-delivered service is started. | 2024-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 is killed and new one started - Done. HBBTV,section O.3: The flow chart in clause 6.2.2.3 shall be followed while the currently selected broadcast service is a DVB-I service instance delivered by DVB-DASH and; ... A different DVB-I service instance is selected within the same DVB-I service HBBTV,section O.5.4: The video/broadcast object shall be extended with the following property; Channel currentServiceInstance Description When the current channel corresponds to a service in a DVB-I service list, this property shall return a Channel object corresponding to the currently selected service instance. Otherwise undefined shall be returned. HBBTV,section O.3: The flow chart in clause 6.2.2.3 shall be followed while the currently selected broadcast service is a DVB-I service instance delivered by DVB-DASH and; .... - A different DVB-I service instance is selected within the same DVB-I service HBBTV,section O.3: For DVB-I service instance delivered by DVB-DASH, requirements relating to the AIT, AIT subtables and specific fields in the MPEG-2 table and descriptor based encoding of the AIT shall be replaced with requirements relating to an XML AIT and to the equivalent field(s) in the XML encoding of the AIT. (See TS 102 809 [] for the two AIT encodings). | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0700 | 1 | DVB-I; Application lifecycle - Application with media in parallel - signalling in service instance only | A DVB-I service with a single service instance delivered by DVB-DASH is selected. The service has a broadcast-related AUTOSTART linked application with media in parallel signalled in the service instance element. The application is started. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.3: The application model and lifecycle in clause 6 of the present document shall be unchanged. The lifecycle of a broadcast-related application that is related to a DVB-I service instance delivered by DVB-DASH shall follow the same rules as a broadcast-related application related to a service delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). All references to AITs in this clause shall be taken as references to XML AITs, more detail is provided in clause O.4. Specifically: • The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). - When both the previously selected service and the newly selected service are DVB-I services delivered by DVB-DASH. TS-103-770,section 5.2.3.2: Application with media in parallel Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1, the RelatedMaterial element provides initial application signalling for use when the service is active and is selected. The process to present media shall begin in parallel with, and decoupled from, the application signalling being processed and any signalled application being started. Any application signalling delivered as part of the service itself (see clause 5.2.3.3) that the DVB-I client supports shall be processed whilst the service is active. The relationship between the initial signalling delivered in the RelatedMaterial element, any application signalling delivered as part of the service itself and the lifecycle of the signalled application(s) is outside the scope of the present document. TS-103-770,section 5.2.3.4: Applications can be referenced at service or service instance level. A RelatedMaterial element within a ServiceInstance element referencing an application with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 or urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2 overrides any RelatedMaterial element in the Service element that has either of those HowRelated@href values and has the same MediaURL@contentType. Similarly, a RelatedMaterial element in the ServiceInstance element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:2 overrides any RelatedMaterial element in the Service element with that HowRelated@href value and has the same MediaURI@contentType value. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0710 | 1 | DVB-I; Application lifecycle - Application with media in parallel - signalling in service instance and service | A DVB-I service with a single service instance delivered by DVB-DASH is selected. The service has a broadcast-related AUTOSTART linked application with media in parallel signalled in the service instance element and a different application signalled in the service element. The application signalled in the service instance element is started. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.3: The application model and lifecycle in clause 6 of the present document shall be unchanged. The lifecycle of a broadcast-related application that is related to a DVB-I service instance delivered by DVB-DASH shall follow the same rules as a broadcast-related application related to a service delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). All references to AITs in this clause shall be taken as references to XML AITs, more detail is provided in clause O.4. Specifically: • The flow chart in clause 6.2.2.2 of the present document shall be followed at all times; - When the previously selected service was a DVB-I service instance delivered by DVB-DASH and the newly selected service is delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). - When both the previously selected service and the newly selected service are DVB-I services delivered by DVB-DASH. TS-103-770,section 5.2.3.2: Application with media in parallel Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1, the RelatedMaterial element provides initial application signalling for use when the service is active and is selected. The process to present media shall begin in parallel with, and decoupled from, the application signalling being processed and any signalled application being started. Any application signalling delivered as part of the service itself (see clause 5.2.3.3) that the DVB-I client supports shall be processed whilst the service is active. The relationship between the initial signalling delivered in the RelatedMaterial element, any application signalling delivered as part of the service itself and the lifecycle of the signalled application(s) is outside the scope of the present document. TS-103-770,section 5.2.3.4: Applications can be referenced at service or service instance level. A RelatedMaterial element within a ServiceInstance element referencing an application with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 or urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2 overrides any RelatedMaterial element in the Service element that has either of those HowRelated@href values and has the same MediaURL@contentType. Similarly, a RelatedMaterial element in the ServiceInstance element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:2 overrides any RelatedMaterial element in the Service element with that HowRelated@href value and has the same MediaURI@contentType value. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0730 | 1 | DVB-I; Application lifecycle - Application with media in parallel - inconsistent signalling in service and MPD | A DVB-I service with a single service instance delivered by DVB-DASH is selected. The service has a linked application with media in parallel signalled in the service element. A different application is signalled in the MPD. The terminal begins to start the application signalled in the service element but stops this process and instead starts the application signalled in the MPD. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.3: The application model and lifecycle in clause 6 of the present document shall be unchanged. The lifecycle of a broadcast-related application that is related to a DVB-I service instance delivered by DVB-DASH shall follow the same rules as a broadcast-related application related to a service delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). All references to AITs in this clause shall be taken as references to XML AITs, more detail is provided in clause O.4. TS-103-770,section 5.2.3.3: The DVB-I client that supports service instances delivered using DVB-DASH and supports an application type that can be signalled by means of a DVB AIT shall support AITs referenced using a RelatedMaterial element and AITs referenced from a DVB-DASH EventStream (see clause 9.1.8 of ETSI TS 103 285 [1]). When a DVB-DASH service instance is selected, application signalling using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1 (app with media in parallel) shall take effect until superseded by presentation of a DVB-DASH Period that contains an EventStream with schemeIdUri set to urn:dvb:dash:appsignalling:2016. Presentation of a DVB-DASH Period without such an EventStream shall have no effect on application signalling. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0740 | 1 | DVB-I; Application lifecycle - Application with media in parallel - inconsistent signalling in service instance and MPD | A DVB-I service with a single service instance delivered by DVB-DASH is selected. The service has a linked application with media in parallel signalled in the service instance element. A different application is signalled in the MPD. The terminal begins to start the application signalled in the service instance element but stops this process and instead starts the application signalled in the MPD. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.4: Signalling of applications in the DVB-I sevice list as defined in clause 5.2.3 of TS 103 770 [] shall be supported. TS-103-770,section 5.2.3.2: Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1, the RelatedMaterial element provides initial application signalling for use when the service is active and is selected. The process to present media shall begin in parallel with, and decoupled from, the application signalling being processed and any signalled application being started. Any application signalling delivered as part of the service itself (see clause 5.2.3.3) that the DVB-I client supports shall be processed whilst the service is active. The relationship between the initial signalling delivered in the RelatedMaterial element, any application signalling delivered as part of the service itself and the lifecycle of the signalled application(s) is outside the scope of the present document. HBBTV,section 5.2.3.4: - | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0750 | 1 | DVB-I; Application lifecycle - Application controlling media presentation - signalling in service instance only | A DVB-I service with a single service instance delivered by DVB-DASH is selected. The service has a broadcast-related AUTOSTART linked application controlling media presentation signalled in the service instance element. The application is started. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.4: Signalling of applications in the DVB-I sevice list as defined in clause 5.2.3 of TS 103 770 [] shall be supported. TS-103-770,section 5.2.3.2: Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. TS-103-770,section 5.2.3.1: When a linked application is launched, the context in which the application was invoked may be passed to the application. For broadcast-independent HbbTV applications, this is defined in clause 6.2.2.6.2 of ETSI TS 102 796 [21]. • For linked applications where HowRelated@href is set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2 , the launch location "service" should be used. | +DVB_I | ||
| org.hbbtv_DVBI_APPLC0760 | 1 | DVB-I; Application lifecycle - Application controlling media presentation - signalling in both service instance and service | A DVB-I service with a single service instance delivered by DVB-DASH is selected. The service has a broadcast-related AUTOSTART linked application controlling media presentation signalled in the service instance element and a different application signalled in the service element. The application signalled in the service instance element is started. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.4: Signalling of applications in the DVB-I sevice list as defined in clause 5.2.3 of TS 103 770 [] shall be supported. TS-103-770,section 5.2.3.2: Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1, the RelatedMaterial element provides initial application signalling for use when the service is active and is selected. The process to present media shall begin in parallel with, and decoupled from, the application signalling being processed and any signalled application being started. Any application signalling delivered as part of the service itself (see clause 5.2.3.3) that the DVB-I client supports shall be processed whilst the service is active. The relationship between the initial signalling delivered in the RelatedMaterial element, any application signalling delivered as part of the service itself and the lifecycle of the signalled application(s) is outside the scope of the present document. TS-103-770,section 5.2.3.1: When a linked application is launched, the context in which the application was invoked may be passed to the application. For broadcast-independent HbbTV applications, this is defined in clause 6.2.2.6.2 of ETSI TS 102 796 [21]. • For linked applications where HowRelated@href is set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2 , the launch location "service" should be used. | +DVB_I | ||
| org.hbbtv_DVBI_CHAN0100 | 1 | DVB-I; Channel class corresponding to DVB-I service - TYPE_RADIO | The installed DVB-I service list includes a DVB-I service signalled with Service.ServiceType="urn:dvb:metadata:cs:ServiceTypeCS:2019:linear-radio" and one Service.ServiceName element. The service list has a single LCNTable with no TargetRegion. An application reads the ChannelList and obtains the Channel object corresponding to the service. Channel.channelType is TYPE_RADIO. Channel.name is Service.ServiceName. Channel.ipBroadcastID is Service.UniqueIdentifier. Channel.majorChannel is LCNTableEntry.channelNumber for the LCNTableEntry whose @serviceRef field matches the UniqueIdentifier of the service. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.6.2.1: The mapping defined in table O.1 shall be used for Channel objects that correspond to a service in a DVB-I service list instead of the one in clause 8.4.3 of the OIPF DAE specification [1]. .... Table O.1: Property mapping for Channel objects corresponding to a service in a DVB-I service list Property name ; Source / Value channelType; If Service.ServiceType="urn:dvb:metadata:cs:ServiceTypeCS:2019:linear-radio" then TYPE_RADIO. Otherwise if Service.ServiceType="urn:dvb:metadata:cs:ServiceTypeCS:2019:linear" or not present then TYPE_TV. Otherwise if Service.ServiceType is "urn:dvb:metadata:cs:ServiceTypeCS:2019:data" and Service.RelatedMaterial contains at least one RelatedMaterial element with both i) a HowRelated element with an @href attribute carrying a value from urn:dvb:metadata:cs:LinkedApplicationCS:2019 and ii) a MediaLocator with aMediaUri whose @contentType attribute contains application/vnd.dvb.ait+xml then TYPE_HBBTV_DATA. Otherwise TYPE_OTHER. idType; If the DVB-I service contains service instance(s) all delivered by the same broadcast technology and Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service: serviceIdentifierTriplet" (see clause O.4) then this shall be the appropriate one of ID_DVB_C, ID_DVB_T, ID_DVB_T2, ID_DVB_S, ID_DVB_S2 for the broadcast technology concerned. Otherwise this shall be ID_DVB_I (see clause O.5.3). ccid; Unique identifier for the channel generated by the terminal. onid; If Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" (see clause O.4) and that extension contains the optional origNetId attribute then this shall be DVBTriplet.origNetId from that extension. Otherwise shall be undefined. nid; Shall be undefined tsid; If Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" (see clause O.4) and that extension contains the optional tsId attribute then this shall be DVBTriplet.tsId from that extension. Otherwise shall be undefined. sid; If Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" (see clause O.4) then this shall be DVBTriplet.serviceId from that extension. Otherwise shall be undefined. name; Shall be set to Service.ServiceName. If multiple languages are present one of which is the same as Configuration.preferredUILanguage then that language shall be used. majorChannel; If the DVB-I client has selected an applicable LCN table (taking into account any currently selected region and/or subscription package) and if the LCN table includes an entry whose @serviceRef field matches the UniqueIdentifier of a service then the value of the majorChannel property shall be the contents of the @channelNumber field of that LCN table entry. Otherwise the the value of the majorChannel property of a channel shall be set to undefined. dsd; Shall be set to undefined. ipBroadcastID; Shall be set to the UniqueIdentifier of the DVB-I service as defined in clause 5.5.2 of TS 103 770 [96]. serviceInstances; See clause O.5.3. | +DVB_I | ||
| org.hbbtv_DVBI_CHAN0110 | 1 | DVB-I; Channel class corresponding to DVB-I service - TYPE_TV | The installed DVB-I service list includes a DVB-I service signalled with Service.ServiceType="urn:dvb:metadata:cs:ServiceTypeCS:2019:linear" and one Service.ServiceName element. The service list has a single LCNTable with no TargetRegion. An application reads the ChannelList and obtains the Channel object corresponding to the service. Channel.channelType property is TYPE_TV. Channel.name is Service.ServiceName. Channel.ipBroadcastID is Service.UniqueIdentifier. Channel.majorChannel is LCNTableEntry.channelNumber for the LCNTableEntry whose @serviceRef field matches the UniqueIdentifier of the service. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.6.2.1: The mapping defined in table O.1 shall be used for Channel objects that correspond to a service in a DVB-I service list instead of the one in clause 8.4.3 of the OIPF DAE specification [1]. .... Table O.1: Property mapping for Channel objects corresponding to a service in a DVB-I service list Property name ; Source / Value channelType; If Service.ServiceType="urn:dvb:metadata:cs:ServiceTypeCS:2019:linear-radio" then TYPE_RADIO. Otherwise if Service.ServiceType="urn:dvb:metadata:cs:ServiceTypeCS:2019:linear" or not present then TYPE_TV. Otherwise if Service.ServiceType is "urn:dvb:metadata:cs:ServiceTypeCS:2019:data" and Service.RelatedMaterial contains at least one RelatedMaterial element with both i) a HowRelated element with an @href attribute carrying a value from urn:dvb:metadata:cs:LinkedApplicationCS:2019 and ii) a MediaLocator with aMediaUri whose @contentType attribute contains application/vnd.dvb.ait+xml then TYPE_HBBTV_DATA. Otherwise TYPE_OTHER. idType; If the DVB-I service contains service instance(s) all delivered by the same broadcast technology and Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service: serviceIdentifierTriplet" (see clause O.4) then this shall be the appropriate one of ID_DVB_C, ID_DVB_T, ID_DVB_T2, ID_DVB_S, ID_DVB_S2 for the broadcast technology concerned. Otherwise this shall be ID_DVB_I (see clause O.5.3). idType; If the DVB-I service contains service instance(s) all delivered by the same broadcast technology and Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" (see clause O.4) then this shall be the appropriate one of ID_DVB_C, ID_DVB_T, ID_DVB_T2, ID_DVB_S, ID_DVB_S2 for the broadcast technology concerned. Otherwise this shall be ID_DVB_I (see clause O.5.3). ccid; Unique identifier for the channel generated by the terminal. onid; If Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" (see clause O.4) and that extension contains the optional origNetId attribute then this shall be DVBTriplet.origNetId from that extension. Otherwise shall be undefined. nid; Shall be undefined tsid; If Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" (see clause O.4) and that extension contains the optional tsId attribute then this shall be DVBTriplet.tsId from that extension. Otherwise shall be undefined. sid; If Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" (see clause O.4) then this shall be DVBTriplet.serviceId from that extension. Otherwise shall be undefined. name; Shall be set to Service.ServiceName. If multiple languages are present one of which is the same as Configuration.preferredUILanguage then that language shall be used. majorChannel; If the DVB-I client has selected an applicable LCN table (taking into account any currently selected region and/or subscription package) and if the LCN table includes an entry whose @serviceRef field matches the UniqueIdentifier of a service then the value of the majorChannel property shall be the contents of the @channelNumber field of that LCN table entry. Otherwise the the value of the majorChannel property of a channel shall be set to undefined. dsd; Shall be set to undefined. ipBroadcastID; Shall be set to the UniqueIdentifier of the DVB-I service as defined in clause 5.5.2 of TS 103 770 [96]. serviceInstances; See clause O.5.3. | +DVB_I | ||
| org.hbbtv_DVBI_CHAN0120 | 1 | DVB-I; Channel class corresponding to DVB-I service - TYPE_HBBTV_DATA | The installed DVB-I service list includes a DVB-I service that was signalled with Service.ServiceType = "urn:dvb:metadata:cs:ServiceTypeCS:2019:data" and Service.RelatedMaterial containing at least one RelatedMaterial element with both i) a HowRelated element with an @href attribute carrying a value from urn:dvb:metadata:cs:LinkedApplicationCS:2019 and ii) MediaLocator that contains a MediaUri whose @contentType attribute contains application/vnd.dvb.ait+xml. There is one Service.ServiceName element. There is a single LCNTable with no TargetRegion. An application reads the ChannelList and obtains the Channel object corresponding to the service. Channel.channelType property is TYPE_HBBTV_DATA. Channel.name is Service.ServiceName. Channel.ipBroadcastID is Service.UniqueIdentifier. Channel.majorChannel property is LCNTableEntry.channelNumber for the LCNTableEntry whose @serviceRef field matches the UniqueIdentifier of the service. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.6.2.1: The mapping defined in table O.1 shall be used for Channel objects that correspond to a service in a DVB-I service list instead of the one in clause 8.4.3 of the OIPF DAE specification [1]. .... Table O.1: Property mapping for Channel objects corresponding to a service in a DVB-I service list Property name ; Source / Value - channelType ; If Service.ServiceType="urn:dvb:metadata:cs:ServiceTypeCS:2019:linear" and Service.ServiceInstance.ContentAttributes.AudioAttributes.Coding= contains any term from urn:mpeg:mpeg7:cs:AudioCodingFormatCS:2001 and Service.ServiceInstance.ContentAttributes.VideoAttributes does not exist then TYPE_RADIO. Otherwise if Service.ServiceType="urn:dvb:metadata:cs:ServiceTypeCS:2019:linear" and Service.ServiceInstance.ContentAttributes.VideoAttributes.Coding contains any term from urn:mpeg:mpeg7:cs:VisualCodingFormatCS:2001 then TYPE_TV. Otherwise if Service.ServiceType is "urn:dvb:metadata:cs:ServiceTypeCS:2019:data" and Service.RelatedMaterial contains at least one RelatedMaterial elemet with both i) a HowRelated element with an @href attribute carrying a value from urn:dvb:metadata:cs:LinkedApplicationCS:2019 and ii) a MediaURI whose @contentType attribute contains application/vnd.dvb.ait+xml then TYPE_HBBTV_DATA. Otherwise TYPE_OTHER. - idType; If the DVB-I service contains service instance(s) all delivered by the same broadcast technology and Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" (see clause O.4) then this shall be the appropriate one of ID_DVB_C, ID_DVB_T, ID_DVB_T2, ID_DVB_S, ID_DVB_S2 for the broadcast technology concerned. Otherwise this shall be ID_DVB_I (see clause O.5.3). - ccid; Unique identifier for the channel generated by the terminal. - onid; If Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" (see clause O.4) and that extension contains the optional origNetId attribute then this shall be DVBTriplet.origNetId from that extension. Otherwise shall be undefined. - nid; Shall be undefined - tsid; If Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" (see clause O.4) and that extension contains the optional tsId attribute then this shall be DVBTriplet.tsId from that extension. Otherwise shall be undefined. - sid; If Service.AdditionalServiceParameters contains an extension with extensionName "urn:hbbtv:dvbi:service:serviceIdentifierTriplet" (see clause O.4) then this shall be DVBTriplet.serviceId from that extension. Otherwise shall be undefined. - name; Shall be set to Service.ServiceName. If multiple languages are present one of which is the same as Configuration.preferredUILanguage then that language shall be used. - majorChannel; If the DVB-I client has selected an applicable LCN table (taking into account any currently selected region and/or subscription package) and if the LCN table includes an entry whose @serviceRef field matches the UniqueIdentifier of a service then the value of the majorChannel property shall be the contents of the @channelNumber field of that LCN table entry. Otherwise the the value of the majorChannel property of a channel shall be set to undefined. - dsd; Shall be set to undefined. - ipBroadcastID; Shall be set to the UniqueIdentifier of the DVB-I service as defined in clause 5.5.2 of TS 103 770 [96]. - serviceInstances; See clause O.5.3. | +DVB_I | ||
| org.hbbtv_DVBI_COMP0030 | 1 | DVB-I; video/broadcast object correctly converts AdaptationSet@id into componentTag property of AVComponent. | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes 8 Adaptation Sets with AdaptationSet@id from 1 to 8. The application starts and calls the getComponents(null) method of video/broadcast object that returns a collection of AVcomponents where the componentTag property of the items is respectively 1, 2, 3, 4, 5, 6, 7, 8. Array notation to access AVcomponents is supported. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.3: Each Adaptation Set in the DASH MPD for the service that is in the scope of an @profile supported by the terminal shall have an AVVideoComponent, an AVAudioComponent or an AVSubtitleComponent object created as appropriate. The properties of the objects shall be as defined for MPEG DASH in clause 8.4.2 of the OIPF DAE specification [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: Name: componentTag Type: Integer .... The value of the id attribute in the AdaptationSet (if provided) DASH,section 5.3.3.2: @id O specifies a unique identifier for this Adaptation Set in the scope of the Period. The attribute shall be a unique unsigned integer value in the scope of the containing Period. The attribute shall not be present in a remote element entity. If not present, no identifier for the Adaptation Set is specified. | +DVB_I | ||
| org.hbbtv_DVBI_COMP0060 | 1 | DVB-I; getComponents(COMPONENT_TYPE_VIDEO) method of video/broadcast object returns correct collection of video AVcomponents. | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes two video adaptation sets with AdaptationSet@id being 1 and 2. The application calls the getComponents method with COMPONENT_TYPE_VIDEO that returns a collection of components with length = 2, one component has componentTag=1, the other other componentTag=2. Both have AVComponent.type as COMPONENT_TYPE_VIDEO. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.3: The following shall apply when the current service is a DVB-I service instance delivered by DVB-DASH.Each Adaptation Set in the DASH MPD for the service that is in the scope of an @profile supported by the terminal shall have an AVVideoComponent, an AVAudioComponent or an AVSubtitleComponent object created as appropriate. The properties of the objects shall be as defined for MPEG DASH in clause 8.4.2 of the OIPF DAE specification [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 | +DVB_I | ||
| org.hbbtv_DVBI_COMP0070 | 1 | DVB-I; getComponents(COMPONENT_TYPE_AUDIO) method of video/broadcast object returns correct collection of audio AVcomponents. | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes 4 audio Adaptation Sets with AdaptationSet@id being 3, 4, 5 and 6. The application calls the getComponents method which returns a collection of audio components with length = 4, where the components have parameters: componentTag=3, componentTag=4, componentTag=5 and componentTag=6 respectively. Both have AVComponent.type as COMPONENT_TYPE_AUDIO. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.3: The following shall apply when the current service is a DVB-I service instance delivered by DVB-DASH. Each Adaptation Set in the DASH MPD for the service that is in the scope of an @profile supported by the terminal shall have an AVVideoComponent, an AVAudioComponent or an AVSubtitleComponent object created as appropriate. The properties of the objects shall be as defined for MPEG DASH in clause 8.4.2 of the OIPF DAE specification [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 | +DVB_I | ||
| org.hbbtv_DVBI_COMP0080 | 1 | DVB-I; getComponents(COMPONENT_TYPE_SUBTITLE) method of video/broadcast object returns correct collection of subtitle AVcomponents. | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes two subtitle Adaptation Sets that have AdaptationSet@id being 7 and 8. The application calls the getComponents method which returns a collection of subtitle components with length = 2, where the components have parameters: componentTag=7 and componentTag=8. Both have AVComponent.type as COMPONENT_TYPE_SUBTITLE. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.3: The following shall apply when the current service is a DVB-I service instance delivered by DVB-DASH.Each Adaptation Set in the DASH MPD for the service that is in the scope of an @profile supported by the terminal shall have an AVVideoComponent, an AVAudioComponent or an AVSubtitleComponent object created as appropriate. The properties of the objects shall be as defined for MPEG DASH in clause 8.4.2 of the OIPF DAE specification [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 | +DVB_I | ||
| org.hbbtv_DVBI_COMP0090 | 1 | DVB-I; Terminal correctly recognizes scrambling of AVComponent. | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes an encrypted Adaptation Set with AdaptationSet@id being 5. The application calls the getComponents method of video/broadcast object that returns a collection of AVcomponents with one audio component with componentTag=5 and property encrypted=true. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.3: The encrypted property shall be true for AVComponents where the corresponding Adaptation Set includes an mp4protection ContentProtection descriptor with @schemeIdUri of "urn:mpeg:dash:mp4protection:2011" as required by clause 8.4 of TS 103 285 []. Otherwise it shall be false. 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 TS-103-285,section 8.4: Any Adaptation Set containing protected content shall contain one "mp4protection" ContentProtection descriptor as described in ISO/IEC 23009-1 [1], clause 5.8.5.2 first bullet with the following values: • @schemeIdUri = "urn:mpeg:dash:mp4protection:2011" • @value = "cenc" or "cbcs" | +DVB_I | ||
| org.hbbtv_DVBI_COMP0100 | 1 | DVB-I; Terminal correctly calculates 'aspectRatio' property of AVVideoComponents | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes one video Adaptation Set with HD 16:9 and one SD Adaptation Set with SD 4:3. The application calls the getComponents method that returns an AVComponentCollection containing two AVVideoComponents with 'aspectRatio' properties of 1.33 and 1.78. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. 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: Name: aspectRatio Type: Number containing width divided by height as a decimal Only defined for video components. ... Defined by the value of the ‘@par’ attribute DASH,section 5.3.3.2: Table 5 — Semantics of AdaptationSet element Element or Attribute Name | Use | Description ... @par | O | specifies the picture aspect ratio of the video media component type, in the form of a string consisting of two integers separated by ':', e.g. "16:9". When this attribute is present, and the attributes @width and @height for the set of Representations are also present, the picture aspect ratio as specified by this attribute shall be the same as indicated by the values of @width, @height, and @sar, i.e. it shall express the same ratio as (@width * sarx): (@height * sary), with sarx the first number in @sar and sary the second number. If not present, the picture aspect ratio may be defined for each media component or it may be unknown. | +DVB_I | ||
| org.hbbtv_DVBI_COMP0120 | 1 | DVB-I; Terminal correctly sets audioDescription of audio AVComponent. | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes a number of audio Adaptation Sets where one has 1) a Role element with @schemeIdUri = "urn:mpeg:dash:role:2011" and @value = "alternate" and 2) an Accessibility element with @schemeIdUri = "urn:tva:metadata:cs:AudioPurposeCS:2007" and @value = "1". The application calls the getComponents method of the video/broadcast object which returns a collection of AVAudioComponents where one audio component has audioDescription=true and other AVAudioComponents have audioDescription=false. | 2024-1 | HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition. HBBTV,section 9.4.3: When an instance of the AVComponent class refers to a DASH audio media content component: * If the audio media component is identified as being audio description (as defined in clause E.2.4), the audioDescription property of the AVComponent shall be set to true. HBBTV,section E.2.4: E.2.4 Role Related requirements NOTE: The requirements formerly in this clause can now be found in clause 6.1.2 of ETSI TS 103 285 [45]. 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 TS-103-285,section 6.1.2: As shown in Table 5, the combined use of Role and Accessibility Descriptors shall identify Adaptation Sets containing the @dependencyId attribute to indicate the dependency to the related Adaptation Set's Representations and hence also indicate that the associated audio stream shall not be provided as a Representation on its own. Players should ignore audio streams with other Role and Accessibility descriptor attributes that they do not understand. ... Description Role element Accessibility element Broadcast mix AD @schemeIdUri = "urn:mpeg:dash:role:2011" @value = "alternate" @schemeIdUri = "urn:tva:metadata:cs:AudioPurposeCS:2007" @value = "1" for the visually impaired Receiver mix AD @schemeIdUri = "urn:mpeg:dash:role:2011" @value = "commentary" @schemeIdUri = "urn:tva:metadata:cs:AudioPurposeCS:2007" @value = "1" for the visually impaired HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.3: The following shall apply when the current service is a DVB-I service instance delivered by DVB-DASH. Each Adaptation Set in the DASH MPD for the service that is in the scope of an @profile supported by the terminal shall have an AVVideoComponent, an AVAudioComponent or an AVSubtitleComponent object created as appropriate. The properties of the objects shall be as defined for MPEG DASH in clause 8.4.2 of the OIPF DAE specification [1]. .... The AVAudioComponent.audioDescription property shall be true for AVAudioComponents corresponding to audio Adaptation Sets identified as "Broadcast mix AD" as defined in table 5 of clause 6.1.2 of TS 103 285 []. If the terminal supports "Receiver mix AD" as defined in that clause then it shall also be true for Adaptation Sets identified as "Receiver mix AD". It shall be false for all other AVAudioComponents. | +DVB_I | ||
| org.hbbtv_DVBI_COMP0140 | 1 | DVB-I; Terminal correctly recognizes hearing impaired of subtitle AVComponent. | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes one subtitle Adaptation Set with 1) a Role element with @schemeIdUri "urn:mpeg:dash:role:2011" and @value "main" and 2) an Accessibility element with @schemeIdUri "urn:tva:metadata:cs:AudioPurposeCS:2007" and @value=2. The application calls the getComponents method of the video/broadcast object with COMPONENT_TYPE_SUBTITLE which returns a collection of AVcomponents where 1 subtitle component has hearingImpaired=true. | 2024-1 | HBBTV 1.7.1 | 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 TS-103-285,section 7.1.2: In order to allow a Player to identify the primary purpose of a subtitle track, Role element and Accessibility element descriptors shall be used as necessary and the language attribute shall be set on the Adaptation Set. Table 19 shows the values to be set in these to indicate common subtitle types. There are also examples in Table 20. Table 19: Signalling different subtitle types Description | @lang | Role @schemeIdUri "urn:mpeg:dash:role:2011" @value | Accessibility @schemeIdUri "urn:tva:metadata:cs:AudioPurposeCS:2007" @value Subtitles for the hard of hearing in the same language as the programme | Same as main audio for the programme | main | 2 (for the hard of hearing) HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table A.1 of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.3: The following shall apply when the current service is a DVB-I service instance delivered by DVB-DASH. Each Adaptation Set in the DASH MPD for the service that is in the scope of an @profile supported by the terminal shall have an AVVideoComponent, an AVAudioComponent or an AVSubtitleComponent object created as appropriate. The properties of the objects shall be as defined for MPEG DASH in clause 8.4.2 of the OIPF DAE specification [1]. .... The AVSubtitleComponent.hearingImpaired property shall be true if the corresponding Adaptation Set is signalled as "Subtitles for the hard of hearing in the same language as the programme" as defined in clause 7.1.2 of TS 103 285 [45]. Otherwise it shall be false. | +DVB_I | ||
| org.hbbtv_DVBI_COMP0160 | 1 | DVB-I; Terminal correctly switches AVComponents using selectComponent( AVComponent component ) method of video/broadcast object. | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes more than one Adaptation Set for each of video, audio and subtitles. The terminal calls the selectComponent method to change the audio component and subtitle component. The Adaptation Set corresponding to the newly selected component of each type is presented. | 2024-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 HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.3: The following shall apply when the current service is a DVB-I service instance delivered by DVB-DASH. …… The selection of the video and audio components (Adaptation Sets) in the DVB-I service instance delivered by DVB-DASH shall be according to clause of the present document. OIPF-DAE,section 7.16.5.1.3: void selectComponent( AVComponent component ) ... Description ... 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. | +DVB_I | ||
| org.hbbtv_DVBI_COMP0180 | 1 | DVB-I; SelectedComponentChange callback is called when selectComponent switches AVComponents. | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes more than one audio Adaptation Set and more than one subtitle Adaptation Set. The application calls the selectComponent method to switch AVAudioComponent and again to switch AVSubtitleComponent. After each switch, SelectedComponentChange is called with the appropriate argument. | 2024-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 HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.3: The following shall apply when the current service is a DVB-I service instance delivered by DVB-DASH. Each Adaptation Set in the DASH MPD for the service that is in the scope of an @profile supported by the terminal shall have an AVVideoComponent, an AVAudioComponent or an AVSubtitleComponent object created as appropriate. The properties of the objects shall be as defined for MPEG DASH in clause 8.4.2 of the OIPF DAE specification [1]. Updates to the MPD that result in additions, removals or other changes of the Adaptation Sets shall result in the set of AVComponent subclasses being updated accordingly. OIPF-DAE,section 7.16.5.1.2: function onSelectedComponentChanged( Integer componentType ) ... This function is called when there is a change in the set of components being presented. This may occur if one of the currently selected components is no longer available and an alternative is chosen based on user preferences, or when presentation has changed due to a different component or set of components being selected. OITFs MAY optimise event dispatch by dispatching a single event in response to several calls to selectComponent() or unselectComponent() made in rapid succession. .... The specified function is called with one argument: .... Integer componentType - The type of component whose presentation has changed, as represented by one of the constant values listed in section 7.16.5.1.1. If more than one component type has changed, this argument will take the value undefined. | +DVB_I | ||
| org.hbbtv_DVBI_COMP0230 | 1 | DVB-I; Terminal stops and re-starts rendering audio AVComponents after calling unselectComponent and selectComponent. | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes at least one audio component. The application calls unselectComponent(COMPONENT_TYPE_AUDIO) and the audio component stops being rendered. Then, the application calls selectComponent( COMPONENT_TYPE_AUDIO ) and the audio component is rendered again. | 2024-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. HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.3: The following shall apply when the current service is a DVB-I service instance delivered by DVB-DASH.Each Adaptation Set in the DASH MPD for the service that is in the scope of an @profile supported by the terminal shall have an AVVideoComponent, an AVAudioComponent or an AVSubtitleComponent object created as appropriate. The properties of the objects shall be as defined for MPEG DASH in clause 8.4.2 of the OIPF DAE specification [1]. | +DVB_I | ||
| org.hbbtv_DVBI_COMP0250 | 1 | DVB-I; Terminal selects by default audio AV component with preferred language | A DVB-I service instance delivered by DASH has a broadcast-related application that is a DVB-I linked application "with media in parallel". The MPD for the service instance includes audio Adaptation Sets in at least English, Polish, Korean and Italian. The language of the current active audio component is the same as the first of the language codes in preferredAudioLanguage47 in the Configuration object. | 2024-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. Name: language Type: String containing an ISO 639-2 language code as defined in [ISO 639-2] Only defined for audio and subtitle components. DASH: Defined by the value of the ‘@lang’ attribute in the MPD, whether set explicitly or inherited. The contents of the language field in the ‘mdhd” of the track SHALL be ignored. HBBTV,section O.5.6: The APIs for playback of selected media components defined in clause 7.16.5 of the OIPF DAE specification [] and profiled, subset and modified by table of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section A.2.20.6: String preferredAudioLanguage47 A comma-separated set of languages to be used for audio playback, in order of preference. Each language shall be indicated by its language code as defined according to IETF BCP47 – RFC 4647 [100] and RFC 5646[101]. OIPF-DAE,section 7.16.5.1.3: void selectComponent( AVComponent component ) .. Description ... 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. If property preferredAudioLanguage in the Configuration object (refer to section 7.3.2) is set then a component is by default selected and it is not necessary to perform selectComponent(). DASH,section 5.3.3.2: Element or Attribute Name | Use | Description ... @lang | O | Declares the language code for this Adaptation Set. The syntax and semantics according to IETF RFC 5646 shall be used. RFC5646,section 2.2.1: When languages have both an ISO 639-1 two-character code and a three-character code (assigned by ISO 639-2, ISO 639-3, or ISO 639-5), only the ISO 639-1 two-character code is defined in the IANA registry. | +DVB_I | ||
| org.hbbtv_DVBI_EVENTS0040 | 1 | DVB-I; Stream events after broadband content being presented after transition to broadcast independent | A DVB-I service instance delivered by DASH has an MPD that carries MPD events. A broadcast-related application that is a DVB-I linked application "with media in parallel" starts and registers to receive stream events. Stream events are received correctly. The application then: transitions to broadcast-independent, starts to present DASH content over broadband using an HTML5 video element. When the A/V playback ends, the application transitions back to broadcast-related. Once that succeeds, the application re-subscribes to the stream events and then the correct stream events for that point in the broadcast stream are received. This process is repeated at least 3 times. | 2024-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 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. NOTE: Applications that wish to become broadcast-independent and later transition back to broadcast-related should remember the current channel before transitioning to broadcast-independent. ... 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: HBBTV,section 7.2.4: The terminal shall support "do-it-now" events as defined in clause 8 of ETSI TS 102 809 [3]. Support of events synchronized to a DVB timeline as referred to in that document is not included. Broadcasters shall place all "do-it-now" stream descriptors to be monitored simultaneously by an application on a single PID. This may be the same PID as is used for other DSM-CC sections. HBBTV,section 8.2.1.1: The following additional methods on the video/broadcast object (as defined in the OIPF DAE specification [1]) shall be supported for synchronization to broadcast events as defined in clause 7.2.4. void addStreamEventListener(String targetURL, String eventName, EventListener listener) Description Add a listener for the specified DSM-CC stream event. ... When a broadcaster transmits different events using the same event name id (i.e. with different version numbers), one StreamEvent event shall be dispatched for each different stream event descriptor received. void removeStreamEventListener(String targetURL, String eventName, EventListener listener) Description Remove a stream event listener for the specified stream event name. HBBTV,section 8.2.1.2: interface StreamEvent : Event { readonly attribute String name; readonly attribute String data; readonly attribute String text; readonly attribute DOMString status name The name of the DSM-CC StreamEvent's event. data Data of the DSM-CC StreamEvent's event encoded in hexadecimal. EXAMPLE: "0A10B81033" (for a payload 5 bytes long). text Text data of the DSM-CC StreamEvent's event as a string assuming UTF-8 as the encoding for the DSM-CC StreamEvent's event. Characters that cannot be transcoded are skipped. status Equal to "trigger" when the event is dispatched in response to a trigger in the stream or "error" when an error occurred (e.g. attempting to add a listener for an event that does not exist, or when a StreamEvent object with registered listeners is removed from the carousel). Circumstances under which an event shall be dispatched with an error status include: ... the elementary stream which contains the StreamEvent event descriptor is no longer being monitored HBBTV,section O.6.2.3: When the current service is a DVB-I service instance delivered by DVB-DASH, the addStreamEvent and removeStreamEvent methods shall be supported as follows. • Terminals shall support MPD events and inband events in the DASH MPD of the current DVB-I service as defined in the present document and TS 103 285 [45] and as modified in this clause. • Calls to the addStreamEventListener method shall result in the specified listener being linked to MPD events where EventStream@schemeIdUri matches the targetURL argument and either (i) EventStream@value matches the eventName argument or (ii) eventName is null • Calls to the addStreamEventListener method shall result in the specified listener being linked to inband events where InbandEventStream@schemeIdUri matches the targetURL argument and either (i) InbandEventStream@value matches the eventName argument or (ii) eventName is null. NOTE 1: In these cases, any URI may be passed as the targetURL String argument, not just URLs as the parameter name might suggest. NOTE 2: When a stream event listener is called for an event, the listener does not receive the targetURL parameter. Therefore, if an application needs to handle multiple EventStreams or InbandEventStreams with different @schemeIdUri attributes, it should use a different event listener for each one. • In the event that the MPD contains more than one matching EventStream or InbandEventStream element, the specified listener shall receive events from all matching EventStreams and InbandEventStreams. • Calls to the removeStreamEvent method shall remove all previous linkages from all MPD events and inband events to the specified combination of eventName and listener. • As the current service is played in normal linear playback by the terminal, and the DASH period-relative timeline passes Event@presentationTime for an MPD event that has a listener linked to it, a StreamEvent shall be posted to that listener. • As the current service is played in normal linear playback by the terminal, and the DASH period-relative timeline passes the presentation time of an inband event that has a listener linked to it, a StreamEvent shall be posted to that listener. | +DVB_I | ||
| org.hbbtv_DVBI_EVENTS0100 | 1 | DVB-I; Adding stream event listeners: eventName not found | A DVB-I service instance delivered by DASH has an MPD that carries an event stream with MPD events. A broadcast-related application that is a DVB-I linked application "with media in parallel" registers to receive stream events using a non-null eventName argument that does not match EventStream@value. A StreamEvent of type "StreamEvent" with status equal to "error" shall be dispatched and passed to the event listener. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 8.2.1.1: Adding and removing stream event listeners HBBTV,section O.6.2.3: When the current service is a DVB-I service instance delivered by DVB-DASH, the addStreamEvent and removeStreamEvent methods shall be supported as follows. • Terminals shall support MPD events and inband events in the DASH MPD of the current DVB-I service as defined in the present document and TS 103 285 [45] and as modified in this clause. • Calls to the addStreamEventListener method shall result in the specified listener being linked to MPD events where EventStream@schemeIdUri matches the targetURL argument and either (i) EventStream@value matches the eventName argument or (ii) eventName is null • Calls to the addStreamEventListener method shall result in the specified listener being linked to inband events where InbandEventStream@schemeIdUri matches the targetURL argument and either (i) InbandEventStream@value matches the eventName argument or (ii) eventName is null. NOTE 1: In these cases, any URI may be passed as the targetURL String argument, not just URLs as the parameter name might suggest. NOTE 2: When a stream event listener is called for an event, the listener does not receive the targetURL parameter. Therefore, if an application needs to handle multiple EventStreams or InbandEventStreams with different @schemeIdUri attributes, it should use a different event listener for each one. • In the event that the MPD contains more than one matching EventStream or InbandEventStream element, the specified listener shall receive events from all matching EventStreams and InbandEventStreams. • Calls to the removeStreamEvent method shall remove all previous linkages from all MPD events and inband events to the specified combination of eventName and listener. • As the current service is played in normal linear playback by the terminal, and the DASH period-relative timeline passes Event@presentationTime for an MPD event that has a listener linked to it, a StreamEvent shall be posted to that listener. • As the current service is played in normal linear playback by the terminal, and the DASH period-relative timeline passes the presentation time of an inband event that has a listener linked to it, a StreamEvent shall be posted to that listener. HBBTV,section 8.2.1.2: Status = Equal to "trigger" when the event is dispatched in response to a trigger in the stream or "error" when an error occurred (e.g. attempting to add a listener for an event that does not exist, or when a StreamEvent object with registered listeners is removed from the carousel). Circumstances under which an event shall be dispatched with an error status include: the StreamEvent object pointed to by targetURL is not found in the carousel or via broadband; the StreamEvent object pointed to by targetURL does not contain the event specified by the eventName parameter; the carousel cannot be mounted; the elementary stream which contains the StreamEvent event descriptor is no longer being monitored (e.g. due to another monitoring request or because it disappears from the PMT). Once an error is dispatched, the listener is automatically unregistered by the terminal. | +DVB_I | ||
| org.hbbtv_DVBI_EVENTS0110 | 1 | DVB-I; Adding stream event listeners: targetURL not found | A DVB-I service instance delivered by DASH has an MPD that carries an event stream with MPD events. A broadcast-related application that is a DVB-I linked application "with media in parallel" registers to receive stream events using a non-null targetURL argument that does not match EventStream@schemeIdUri. The EventListener supplied to the method is valid and instantiated. A StreamEvent of type "StreamEvent" with status equal to "error" shall be dispatched and passed to the event listener. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 8.2.1.1: Adding and removing stream event listeners HBBTV,section O.6.2.3: When the current service is a DVB-I service instance delivered by DVB-DASH, the addStreamEvent and removeStreamEvent methods shall be supported as follows. • Terminals shall support MPD events and inband events in the DASH MPD of the current DVB-I service as defined in the present document and TS 103 285 [45] and as modified in this clause. • Calls to the addStreamEventListener method shall result in the specified listener being linked to MPD events where EventStream@schemeIdUri matches the targetURL argument and either (i) EventStream@value matches the eventName argument or (ii) eventName is null • Calls to the addStreamEventListener method shall result in the specified listener being linked to inband events where InbandEventStream@schemeIdUri matches the targetURL argument and either (i) InbandEventStream@value matches the eventName argument or (ii) eventName is null. NOTE 1: In these cases, any URI may be passed as the targetURL String argument, not just URLs as the parameter name might suggest. NOTE 2: When a stream event listener is called for an event, the listener does not receive the targetURL parameter. Therefore, if an application needs to handle multiple EventStreams or InbandEventStreams with different @schemeIdUri attributes, it should use a different event listener for each one. • In the event that the MPD contains more than one matching EventStream or InbandEventStream element, the specified listener shall receive events from all matching EventStreams and InbandEventStreams. • Calls to the removeStreamEvent method shall remove all previous linkages from all MPD events and inband events to the specified combination of eventName and listener. • As the current service is played in normal linear playback by the terminal, and the DASH period-relative timeline passes Event@presentationTime for an MPD event that has a listener linked to it, a StreamEvent shall be posted to that listener. • As the current service is played in normal linear playback by the terminal, and the DASH period-relative timeline passes the presentation time of an inband event that has a listener linked to it, a StreamEvent shall be posted to that listener. | +DVB_I | ||
| org.hbbtv_DVBI_EVENTS0120 | 1 | DVB-I; Removing stream event listeners with an altered eventName | A DVB-I service instance delivered by DASH has an MPD that carries an event stream with MPD events. A broadcast-related application that is a DVB-I linked application "with media in parallel" registers to receive stream events using a targetURL argument that matches EventStream@schemeIdUri and an eventName that matches EventStream@value. After an event has been received, the application calls removeStreamEvent with a targetURL argument that matches EventStream@schemeIdUri and the correct event listener but an eventName that does not match EventStream@value. Stream events continue to be received. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 8.2.1.1: Adding and removing stream event listeners HBBTV,section O.6.2.3: When the current service is a DVB-I service instance delivered by DVB-DASH, the addStreamEvent and removeStreamEvent methods shall be supported as follows. • Terminals shall support MPD events and inband events in the DASH MPD of the current DVB-I service as defined in the present document and TS 103 285 [45] and as modified in this clause. • Calls to the addStreamEventListener method shall result in the specified listener being linked to MPD events where EventStream@schemeIdUri matches the targetURL argument and either (i) EventStream@value matches the eventName argument or (ii) eventName is null • Calls to the addStreamEventListener method shall result in the specified listener being linked to inband events where InbandEventStream@schemeIdUri matches the targetURL argument and either (i) InbandEventStream@value matches the eventName argument or (ii) eventName is null. NOTE 1: In these cases, any URI may be passed as the targetURL String argument, not just URLs as the parameter name might suggest. NOTE 2: When a stream event listener is called for an event, the listener does not receive the targetURL parameter. Therefore, if an application needs to handle multiple EventStreams or InbandEventStreams with different @schemeIdUri attributes, it should use a different event listener for each one. • In the event that the MPD contains more than one matching EventStream or InbandEventStream element, the specified listener shall receive events from all matching EventStreams and InbandEventStreams. • Calls to the removeStreamEvent method shall remove all previous linkages from all MPD events and inband events to the specified combination of eventName and listener. • As the current service is played in normal linear playback by the terminal, and the DASH period-relative timeline passes Event@presentationTime for an MPD event that has a listener linked to it, a StreamEvent shall be posted to that listener. • As the current service is played in normal linear playback by the terminal, and the DASH period-relative timeline passes the presentation time of an inband event that has a listener linked to it, a StreamEvent shall be posted to that listener. | +DVB_I | ||
| org.hbbtv_DVBI_EVENTS0150 | 1 | DVB-I; Removing stream event listeners with matching parameters | A DVB-I service instance delivered by DASH has an MPD that carries an event stream with MPD events. A broadcast-related application that is a DVB-I linked application "with media in parallel" registers to receive stream events using a targetURL argument that matches EventStream@schemeIdUri and an eventName that matches EventStream@value. After an event has been received, the application calls removeStreamEvent with a targetURL argument that matches EventStream@schemeIdUri, an eventName that matches EventStream@value and the correct event listener. The removed listener does not receive any stream event afterwards. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 8.2.1.1: Adding and removing stream event listeners HBBTV,section O.6.2.3: When the current service is a DVB-I service instance delivered by DVB-DASH, the addStreamEvent and removeStreamEvent methods shall be supported as follows. • Terminals shall support MPD events and inband events in the DASH MPD of the current DVB-I service as defined in the present document and TS 103 285 [45] and as modified in this clause. • Calls to the addStreamEventListener method shall result in the specified listener being linked to MPD events where EventStream@schemeIdUri matches the targetURL argument and either (i) EventStream@value matches the eventName argument or (ii) eventName is null • Calls to the addStreamEventListener method shall result in the specified listener being linked to inband events where InbandEventStream@schemeIdUri matches the targetURL argument and either (i) InbandEventStream@value matches the eventName argument or (ii) eventName is null. NOTE 1: In these cases, any URI may be passed as the targetURL String argument, not just URLs as the parameter name might suggest. NOTE 2: When a stream event listener is called for an event, the listener does not receive the targetURL parameter. Therefore, if an application needs to handle multiple EventStreams or InbandEventStreams with different @schemeIdUri attributes, it should use a different event listener for each one. • In the event that the MPD contains more than one matching EventStream or InbandEventStream element, the specified listener shall receive events from all matching EventStreams and InbandEventStreams. • Calls to the removeStreamEvent method shall remove all previous linkages from all MPD events and inband events to the specified combination of eventName and listener. • As the current service is played in normal linear playback by the terminal, and the DASH period-relative timeline passes Event@presentationTime for an MPD event that has a listener linked to it, a StreamEvent shall be posted to that listener. • As the current service is played in normal linear playback by the terminal, and the DASH period-relative timeline passes the presentation time of an inband event that has a listener linked to it, a StreamEvent shall be posted to that listener. | +DVB_I | ||
| org.hbbtv_DVBI_GUIDE0010 | 1 | DVB-I; findProgrammesFromStream(currentChannel, startTime,...) of Metadata API shall retrieve programme showing at the startTime on current channel. | A broadcast-related application linked to a DVB-I service delivered by DVB-DASH calls findProgrammesFromStream(currentChannel, startTime) where startTime represents a time that is within the period covered by the current or next programme on the current channel. After calling getResults(), a Programme object is retrieved which starts before startTime and is showing at the startTime. Programme.name shall correspond to ProgramInformation / BasicDescription / Title with type="main". Programme.description shall correspond to ProgramInformation / BasicDescription / Synopsis with length="medium". Programme.longDescription shall be undefined. Programme.startTime shall correspond to ScheduleEvent / PublishedStartTime. Programme.duration shall correspond to ScheduleEvent / PublishedDuration Programme.channelID shall be the same as Channel.ccid for the Channel object of the service concerned. Programme.programmeID shall be ScheduleEvent / Program which, by definition, matches ProgramInformation@programId Programme.programmeIDType shall be ID_TVA_CRID Programme.parentalRatings shall correspond to ProgramInformation / BasicDescription / ParentalGuidance | 2024-1 | HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.12.2.2: The start time is inclusive; any programmes starting at the start time, or which are showing at the start time, will be included in the search results. HBBTV,section O.5.7: The metadata APIs defined in clause 7.12 of the OIPF DAE specification [] and profiled, subset and modified by table A.1 of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.4: In response to calls to the findProgrammesFromStream method, terminals shall support access to metadata about programmes in DVB-I services delivered through the metadata APIs and the Programme class as defined in clauses O.5.7 and table O.3 of the present document with the following additional requirements. ... - Terminals shall support requesting schedule information from the ScheduleInfoEndpoint (see clause 6.5 of TS 103 770 []). At least the Now/Next Filtered Schedule Request shall be supported. Terminals shall set window_type to either true or to window - it is implementation specific which is used. HBBTV,section O.6.2.2: The mapping defined in table shall be used for Programme objects that correspond to programmes in a DVB-I service instance delivered by DVB-DASH instead of the one in clause 8.4.3 of the OIPF DAE specification []. See also clauses 6.10.5 and 6.10.7 of TS 103 770 []. Table O.: Property mapping for Programme objects Property name ; Source / Value name ; ProgramInformation / BasicDescription / Title with type="main" description ; ProgramInformation / BasicDescription / Synopsis with length="medium" longDescription ; undefined startTime ; ScheduleEvent / PublishedStartTime duration ; ScheduleEvent / PublishedDuration channelID; Populated from ccid of the channel carrying this programme. programmeID ; ScheduleEvent / Program which, by definition, matches ProgramInformation@programId programmeIDType ; ID_TVA_CRID parentalRatings; ProgramInformation / BasicDescription / ParentalGuidance TS-103-770,section 6.5.3.1: A DVB-I client wishing to retrieve only the current event and one future event shall query the schedules endpoint without start and end times but with the query parameter now_next=true. A DVB-I client wishing to retrieve the current event and up to ten previous and ten future events shall query the schedules endpoint without start and end times but with the query parameter now_next=window. URL format: <ScheduleInfoEndpoint>?sid=<service_id>&now_next=<window_type>&image_variant=<variant> where: • service_id: shall be a single service identifier as derived from the service list information. Either the UniqueIdentifier or the ContentGuideServiceRef of the service. ContentGuideServiceRef, when specified, takes precedence over UniqueIdentifier: - only a single occurrence of the sid parameter shall be passed. • window_type: denotes the set of events provided in addition to the current event; true denotes only the current event and next scheduled event are requested, window denotes that up to 10 previous events and 10 future events can be provided with the current event. • variant: (Optional) shall specify an image variant (see clause 5.2.8.2.1) for the image URLs provided in the response. NOTE: In previous versions of this specification the &now_next query parameter in the URL format above was incorrectly specified as &nownext. Example URL: <ScheduleInfoEndpoint>?sid=12345&now_next=true NOTE: For hybrid devices, EIT p/f from DVB-C/S/T is usually the primary source of metadata for the forwards EPG and the DVB-I client should determine the present and following events from EIT p/f and match them against the now/next events returned by a Content Guide Server. OIPF-DAE,section 7.12.2.2: void findProgrammesFromStream( Channel channel, Integer startTime, Integer count ) Description Set a query and constraints for retrieving metadata for programmes from a given channel and given start time from metadata contained in the stream as defined in section 4.1.3 of [OIPF_META2]. Setting the search parameters using this method will implicitly remove any existing constraints, ordering or queries created by prior calls to methods on this object. This method does not cause the search to be performed; applications must call getResults() to retrieve the results. Applications SHALL be notified of the progress of the search via MetadataSearch events as described in section 7.12.1.2. .... Arguments channel The channel for which programme information should be found. startTime The start of the time period for which results should be returned measured in seconds since midnight (GMT) on 1/1/1970. The start time is inclusive; any programmes starting at the start time, or which are showing at the start time, will be included in the search results. If null, the search will start from the current time. | +DVB_I | ||
| org.hbbtv_DVBI_GUIDE0020 | 1 | DVB-I; findProgrammesFromStream(Channel, startTime,...) of Metadata API shall retrieve programme showing at the startTime from given (not current) Channel. | A broadcast-related application linked to a DVB-I service delivered by DVB-DASH calls findProgrammesFromStream(Channel, startTime) where the Channel parameter refers to a different DVB-I service delivered by DVB-DASH and startTime represents a time that is within the period covered by the current or next programme on Channel. After calling getResults, a Programme object is retrieved which starts before startTime and is showing at the startTime. Programme.name shall correspond to ProgramInformation / BasicDescription / Title with type="main". Programme.description shall correspond to ProgramInformation / BasicDescription / Synopsis with length="medium". Programme.longDescription shall be undefined. Programme.startTime shall correspond to ScheduleEvent / PublishedStartTime. Programme.duration shall correspond to ScheduleEvent / PublishedDuration Programme.channelID shall be the same as Channel.ccid for the Channel object of the service concerned. Programme.programmeID shall be ScheduleEvent / Program which, by definition, matches ProgramInformation@programId Programme.programmeIDType shall be ID_TVA_CRID Programme.parentalRatings shall correspond to ProgramInformation / BasicDescription / ParentalGuidance | 2024-1 | HBBTV 1.7.1 | HBBTV,section A.1: Detailed section by section definition OIPF-DAE,section 7.12.2.2: The start time is inclusive; any programmes starting at the start time, or which are showing at the start time, will be included in the search results. HBBTV,section O.5.7: The metadata APIs defined in clause 7.12 of the OIPF DAE specification [] and profiled, subset and modified by table A.1 of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.4: In response to calls to the findProgrammesFromStream method, terminals shall support access to metadata about programmes in DVB-I services delivered through the metadata APIs and the Programme class as defined in clauses O.5.7 and table O.3 of the present document with the following additional requirements. ... - Terminals shall support requesting schedule information from the ScheduleInfoEndpoint (see clause 6.5 of TS 103 770 []). At least the Now/Next Filtered Schedule Request shall be supported. Terminals shall set window_type to either true or to window - it is implementation specific which is used. HBBTV,section O.6.2.2: The mapping defined in table shall be used for Programme objects that correspond to programmes in a DVB-I service instance delivered by DVB-DASH instead of the one in clause 8.4.3 of the OIPF DAE specification []. See also clauses 6.10.5 and 6.10.7 of TS 103 770 []. Table O.: Property mapping for Programme objects Property name; Source / Value name ; ProgramInformation / BasicDescription / Title with type="main" description ; ProgramInformation / BasicDescription / Synopsis with length="medium" longDescription ; undefined startTime ; ScheduleEvent / PublishedStartTime duration ; ScheduleEvent / PublishedDuration channelID; Populated from ccid of the channel carrying this programme. programmeID ; ScheduleEvent / Program which, by definition, matches ProgramInformation@programId programmeIDType ; ID_TVA_CRID parentalRatings; ProgramInformation / BasicDescription / ParentalGuidance TS-103-770,section 6.5.3.1: A DVB-I client wishing to retrieve only the current event and one future event shall query the schedules endpoint without start and end times but with the query parameter now_next=true. A DVB-I client wishing to retrieve the current event and up to ten previous and ten future events shall query the schedules endpoint without start and end times but with the query parameter now_next=window. URL format: <ScheduleInfoEndpoint>?sid=<service_id>&now_next=<window_type>&image_variant=<variant> where: • service_id: shall be a single service identifier as derived from the service list information. Either the UniqueIdentifier or the ContentGuideServiceRef of the service. ContentGuideServiceRef, when specified, takes precedence over UniqueIdentifier: - only a single occurrence of the sid parameter shall be passed. • window_type: denotes the set of events provided in addition to the current event; true denotes only the current event and next scheduled event are requested, window denotes that up to 10 previous events and 10 future events can be provided with the current event. • variant: (Optional) shall specify an image variant (see clause 5.2.8.2.1) for the image URLs provided in the response. NOTE: In previous versions of this specification the &now_next query parameter in the URL format above was incorrectly specified as &nownext. Example URL: <ScheduleInfoEndpoint>?sid=12345&now_next=true NOTE: For hybrid devices, EIT p/f from DVB-C/S/T is usually the primary source of metadata for the forwards EPG and the DVB-I client should determine the present and following events from EIT p/f and match them against the now/next events returned by a Content Guide Server. OIPF-DAE,section 7.12.2.2: void findProgrammesFromStream( Channel channel, Integer startTime, Integer count ) Description Set a query and constraints for retrieving metadata for programmes from a given channel and given start time from metadata contained in the stream as defined in section 4.1.3 of [OIPF_META2]. Setting the search parameters using this method will implicitly remove any existing constraints, ordering or queries created by prior calls to methods on this object. This method does not cause the search to be performed; applications must call getResults() to retrieve the results. Applications SHALL be notified of the progress of the search via MetadataSearch events as described in section 7.12.1.2. .... Arguments channel The channel for which programme information should be found. startTime The start of the time period for which results should be returned measured in seconds since midnight (GMT) on 1/1/1970. The start time is inclusive; any programmes starting at the start time, or which are showing at the start time, will be included in the search results. If null, the search will start from the current time. | +DVB_I | ||
| org.hbbtv_DVBI_GUIDE0050 | 4 | DVB-I; EIT Schedule - MetadataSearch object can decode all required UTF-8 characters | An application requests a Programme object for a programme where ProgramInformation / BasicDescription / Synopsis with length="medium" is filled with characters from the "Generic Western European character set" as defined in annex C of TS 102 809 excluding characters between 32 and 127. All characters shall have the expected UTF-16 character codes when retrieved using the application/oipfSearchManager object. | 2024-1 | HBBTV 1.7.1 | HBBTV,section O.5.7: The metadata APIs defined in clause 7.12 of the OIPF DAE specification [] and profiled, subset and modified by table A.1 of the present document shall be supported for DVB-I service instances delivered by DVB-DASH. HBBTV,section O.6.4: In response to calls to the findProgrammesFromStream method, terminals shall support access to metadata about programmes in DVB-I services delivered through the metadata APIs and the Programme class as defined in clauses O.5.7 and table O.3 of the present document with the following additional requirements. ... - Terminals shall support requesting schedule information from the ScheduleInfoEndpoint (see clause 6.5 of TS 103 770 []). At least the Now/Next Filtered Schedule Request shall be supported. Terminals shall set window_type to either true or to window - it is implementation specific which is used. HBBTV,section O.6.2.2: The mapping defined in table shall be used for Programme objects that correspond to programmes in a DVB-I service instance delivered by DVB-DASH instead of the one in clause 8.4.3 of the OIPF DAE specification []. See also clauses 6.10.5 and 6.10.7 of TS 103 770 []. Table O.: Property mapping for Programme objects Property name ; Source / Value name ; ProgramInformation / BasicDescription / Title with type="main" description ; ProgramInformation / BasicDescription / Synopsis with length="medium" longDescription ; undefined startTime ; ScheduleEvent / PublishedStartTime duration ; ScheduleEvent / PublishedDuration channelID; Populated from ccid of the channel carrying this programme. programmeID ; ScheduleEvent / Program which, by definition, matches ProgramInformation@programId programmeIDType ; ID_TVA_CRID parentalRatings; ProgramInformation / BasicDescription / ParentalGuidance ProgramInformation / BasicDescription / ParentalGuidance TS-103-770,section 6.5.3.1: A DVB-I client wishing to retrieve only the current event and one future event shall query the schedules endpoint without start and end times but with the query parameter now_next=true. A DVB-I client wishing to retrieve the current event and up to ten previous and ten future events shall query the schedules endpoint without start and end times but with the query parameter now_next=window. URL format: <ScheduleInfoEndpoint>?sid=<service_id>&now_next=<window_type>&image_variant=<variant> where: • service_id: shall be a single service identifier as derived from the service list information. Either the UniqueIdentifier or the ContentGuideServiceRef of the service. ContentGuideServiceRef, when specified, takes precedence over UniqueIdentifier: - only a single occurrence of the sid parameter shall be passed. • window_type: denotes the set of events provided in addition to the current event; true denotes only the current event and next scheduled event are requested, window denotes that up to 10 previous events and 10 future events can be provided with the current event. • variant: (Optional) shall specify an image variant (see clause 5.2.8.2.1) for the image URLs provided in the response. NOTE: In previous versions of this specification the &now_next query parameter in the URL format above was incorrectly specified as &nownext. Example URL: <ScheduleInfoEndpoint>?sid=12345&now_next=true NOTE: For hybrid devices, EIT p/f from DVB-C/S/T is usually the primary source of metadata for the forwards EPG and the DVB-I client should determine the present and following events from EIT p/f and match them against the now/next events returned by a Content Guide Server. TS-103-770,section 6.10.5.3: Synopsis Mandatory {1..3} per language Descriptive text about the entity. The @length attribute shall be mandatory. The possible values of this enumerated attribute are as follows: • short - the length of the synopsis shall not exceed 90 characters. • medium - the length of the synopsis shall not exceed 250 characters. OIPF-DAE,section 8.4.1: [...] the OITF SHALL translate all characters extracted from DVB SI tables and descriptors into their UTF-16 equivalent when exposing the character in a JavaScript character or string object. In addition, the following rules SHALL apply: The character table of text fields in DVB SI SHALL be determined as specified in EN 300 468 Annex A. The default character table MAY be determined by the local broadcast system. The bytes denoting the character table and the control codes for character emphasis on and off SHALL be filtered out by the OITF. [...] | +DVB_I | ||
| org.hbbtv_DVBI_KEY0010 | 1 | DVB-I; Fast forwards and rewind before activation - application controlling media presentation | An application starts that is a broadcast-related autostart application signalled in a DVB-I service as 'application controlling media presentation'. The application requests the fast forwards and fast rewind key events, this request is granted and the key events received when the keys concerned are pressed. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Fast forward and fast rewind[.....]Only available to applications once activated HBBTV,section O.7: Except as follows, clause 10 of the present document shall apply identically to a broadcast-related application that is related to a DVB-I service instance delivered by DVB-DASH as it does to a broadcast-related application that related to a service delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). - The key events VK_STOP, VK_PLAY, VK_PAUSE, VK_PLAY_PAUSE, VK_FAST_FWD, VK_REWIND and VK_RECORD shall always be available to linked applications that are controlling media presentation without requiring the application to be activated first. TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_KEY0020 | 1 | DVB-I; play, stop, pause keys before activation - application controlling media presentation | An application starts that is a broadcast-related autostart application signalled in a DVB-I service as 'application controlling media presentation'. The application requests the play, stop and pause key events, this request is granted and the key events received when the keys concerned are pressed. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Play, stop, pause[.....]Only available to applications once activated HBBTV,section O.7: Except as follows, clause 10 of the present document shall apply identically to a broadcast-related application that is related to a DVB-I service instance delivered by DVB-DASH as it does to a broadcast-related application that related to a service delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). - The key events VK_STOP, VK_PLAY, VK_PAUSE, VK_PLAY_PAUSE, VK_FAST_FWD, VK_REWIND and VK_RECORD shall always be available to linked applications that are controlling media presentation without requiring the application to be activated first. TS-103-770,section 5.2.3.2: Application controlling media presentation Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.2, media presentation is to be managed by the linked application and no media stream shall be presented by the DVB-I client when the service is selected. The processing of any application signalling delivered as part of the service itself (see clause 5.2.3.3) is outside the scope of the present document. | +DVB_I +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_DVBI_KEY0110 | 1 | DVB-I; Fast forwards and rewind before activation - application with media in parallel | An application starts that is a broadcast-related autostart application signalled in a DVB-I service as 'application with media in parallel'. It requests the fast forwards and fast rewind keys, the request is refused and no key events are delivered if the keys are pressed | 2024-1 | HBBTV 1.7.1 | HBBTV,section 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Fast forward and fast rewind[.....]Only available to applications once activated HBBTV,section O.7: Except as follows, clause 10 of the present document shall apply identically to a broadcast-related application that is related to a DVB-I service instance delivered by DVB-DASH as it does to a broadcast-related application that related to a service delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). - The key events VK_STOP, VK_PLAY, VK_PAUSE, VK_PLAY_PAUSE, VK_FAST_FWD, VK_REWIND and VK_RECORD shall always be available to linked applications that are controlling media presentation without requiring the application to be activated first. TS-103-770,section 5.2.3.2: Application with media in parallel Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1, the RelatedMaterial element provides initial application signalling for use when the service is active and is selected. The process to present media shall begin in parallel with, and decoupled from, the application signalling being processed and any signalled application being started. Any application signalling delivered as part of the service itself (see clause 5.2.3.3) that the DVB-I client supports shall be processed whilst the service is active. The relationship between the initial signalling delivered in the RelatedMaterial element, any application signalling delivered as part of the service itself and the lifecycle of the signalled application(s) is outside the scope of the present document. | +DVB_I | ||
| org.hbbtv_DVBI_KEY0120 | 1 | DVB-I; play, stop, pause keys before activation - application with media in parallel | An application starts that is a broadcast-related autostart application signalled in a DVB-I service as 'application with media in parallel'. It requests the play, stop and pause keys, the request is refused and these key events are not delivered if the keys are pressed | 2024-1 | HBBTV 1.7.1 | HBBTV,section 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Play, stop, pause[.....]Only available to applications once activated HBBTV,section O.7: Except as follows, clause 10 of the present document shall apply identically to a broadcast-related application that is related to a DVB-I service instance delivered by DVB-DASH as it does to a broadcast-related application that related to a service delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). - The key events VK_STOP, VK_PLAY, VK_PAUSE, VK_PLAY_PAUSE, VK_FAST_FWD, VK_REWIND and VK_RECORD shall always be available to linked applications that are controlling media presentation without requiring the application to be activated first. TS-103-770,section 5.2.3.2: Application with media in parallel Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1, the RelatedMaterial element provides initial application signalling for use when the service is active and is selected. The process to present media shall begin in parallel with, and decoupled from, the application signalling being processed and any signalled application being started. Any application signalling delivered as part of the service itself (see clause 5.2.3.3) that the DVB-I client supports shall be processed whilst the service is active. The relationship between the initial signalling delivered in the RelatedMaterial element, any application signalling delivered as part of the service itself and the lifecycle of the signalled application(s) is outside the scope of the present document. | +DVB_I +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_DVBI_KEY0130 | 1 | DVB-I; play-pause, stop keys before activation - application with media in parallel | An application starts that is a broadcast-related autostart application signalled in a DVB-I service as 'application with media in parallel'. It requests the play-pause and stop keys, the request is refused and these key events are not delivered if the keys are pressed | 2024-1 | HBBTV 1.7.1 | HBBTV,section 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Play, stop, pause[.....]Only available to applications once activated HBBTV,section O.7: Except as follows, clause 10 of the present document shall apply identically to a broadcast-related application that is related to a DVB-I service instance delivered by DVB-DASH as it does to a broadcast-related application that related to a service delivered by classic RF-based broadcast (DVB-C, DVB-S, DVB-S2, DVB-T, DVB-T2). - The key events VK_STOP, VK_PLAY, VK_PAUSE, VK_PLAY_PAUSE, VK_FAST_FWD, VK_REWIND and VK_RECORD shall always be available to linked applications that are controlling media presentation without requiring the application to be activated first. TS-103-770,section 5.2.3.2: Application with media in parallel Where an application (with any MediaURI@contentType) is signalled using a RelatedMaterial element with a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1, the RelatedMaterial element provides initial application signalling for use when the service is active and is selected. The process to present media shall begin in parallel with, and decoupled from, the application signalling being processed and any signalled application being started. Any application signalling delivered as part of the service itself (see clause 5.2.3.3) that the DVB-I client supports shall be processed whilst the service is active. The relationship between the initial signalling delivered in the RelatedMaterial element, any application signalling delivered as part of the service itself and the lifecycle of the signalled application(s) is outside the scope of the present document. | +DVB_I +VK_PLAY_PAUSE | ||
| org.hbbtv_DVBI_VBO0020 | 2 | DVB-I; video/broadcast object presentation - presenting state | An autostart broadcast-related application is linked to a DVB-I service as an "Application with media in parallel". The application has a video/broadcast object. When the video/broadcast object is in the presenting state, the video/broadcast object contains the video being presented. | 2024-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 HBBTV,section O.5.4: When the current channel is a DVB-I service instance delivered by DVB-DASH; …. For linked applications signalled as "Application with media in parallel" (a HowRelated@href attribute set to urn:dvb:metadata:cs:LinkedApplicationCS:2019:1.1), a video/broadcast object in the presenting state where the current channel is a DVB-I service instance delivered by DVB-DASH shall display the video and present the audio of that service. …. In all the above cases, when the running application survives the channel change; PlayStateChange and either ChannelChangeSucceeded or ChannelChangeFailed events shall be generated. The video for the new service shall be presented in the video/broadcast object respecting the requirements defined in the present document, including but not limited to whether the video is to be rendered in full screen or windowed mode as defined by the setFullScreen method. The generation of a ChannelChangeSucceeded event shall follow the video for the new service being presented in the video/broadcast object and the audio for the new service being output. | +DVB_I | ||
| org.hbbtv_DVBI_VBO0030 | 2 | DVB-I; Change of state of a video/broadcast object when the stop() method is called while it is in the presenting state | An autostart broadcast-related application is linked to a DVB-I service as an "Application with media in parallel". The application has a video/broadcast object. 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-1 | HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes HBBTV,section O.5.4: Calling the stop method shall cause a state change to the Stopped state and make the video and audio decoders available to be used by other objects, e.g. an HTML5 video element. | +DVB_I | ||
| org.hbbtv_DVBI_VBO0040 | 2 | DVB-I; Change of state of a video/broadcast object when the bindToCurrentChannel() method is called while it is in the stopped state | An autostart broadcast-related application is linked to a DVB-I service as an "Application with media in parallel". The application has a video/broadcast object. 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-1 | HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes HBBTV,section O.5.4: Call the bindToCurrentChannel method when a video/broadcast object is in the stopped state and the current channel is a DVB-I service instance delivered by DVB-DASH shall start a transition to the presenting state and, if no errors occur, start the video of the DVB-I service being presented in the video/broadcast object and start the audio being decoded and output. | +DVB_I | ||
| org.hbbtv_DVBI_VBO0060 | 2 | DVB-I; Change of state of a video/broadcast object when the release() method is called while it is in the presenting state | An autostart broadcast-related application is linked to a DVB-I service as an "Application with media in parallel". The application has a video/broadcast object. 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-1 | HBBTV 1.7.1 | HBBTV,section A.2.4.1: Extensions to the video/broadcast object - State machine and related changes | +DVB_I | ||
| org.hbbtv_DVBI_VBO0110 | 2 | DVB-I; selecting a Channel corresponding to a DVB-I service - quiet=1 | An autostart broadcast-related application is linked, as an "Application with media in parallel", to a DVB-I service with a single service instance delivered by DVB-DASH. The application has a video/broadcast object. The application binds the video/broadcast object to the current channel. When it calls the setChannel method on that video/broadcast object with a Channel object referring to a DVB-I service with a single service instance delivered by DVB-DASH and the quiet argument set to 1, the HbbTV terminal changes to the specified channel. PlayStateChange events are generated from Presenting to Connecting and then back to Presenting. No channel change banner or equivalent is drawn by the HbbTV terminal. Any front panel display or channel info UI shows the new channel. | 2024-1 | HBBTV 1.7.1 | HBBTV,section A.2.4.3.1: The following changes shall apply to the video/broadcast object to support "quiet" service selection. void setChannel( Channel channel, Boolean trickplay, String contentAccessDescriptorURL, Number quiet ) HBBTV,section A.2.4.3.2: If the quiet argument is set to 1 then the terminal shall execute the channel change operation but shall not present any channel banner that is usually displayed by the terminal. ... After a channel change where the quiet argument is set to a value of 1 or 2, the application lifecycle shall be identical to a normal channel change, i.e. one where the quiet argument is set to the value 0 or omitted. The lifecycle of the application shall follow the rules defined in sections 6.2.2.2 and 6.2.2.3 of the present document. The AIT of the new channel shall be obeyed following the channel change operation. HBBTV,section O.5.3: Channel objects shall correspond to one of the following: - DVB-I services that are in a DVB-I service list currently used by the terminal. - DVB-I service instances associated with a DVB-I service that is in a DVB-I service list currently used by the terminal. HBBTV,section O.5.4: Calling the setChannel method with a Channel object representing a DVB-I service instance delivered by DVB-DASH shall cause that service instance to be selected in accordance with the state transition model defined in clause 7.13.1.1 of the OIPF DAE specification []. … If the Channel object is one that corresponds to a DVB-I service (and not to a DVB-I service instance) then the DVB-I player is responsible for selecting which of the service instances of that service is to be presented initially and can change this at any time based on its internal logic. Applications shall be able to take control of service instance selection from the DVB-I player by changing from a channel that corresponds to a DVB-I service to one that corresponds to one of the DVB-I service instances within that service. If such a change has the optional quiet argument (see A.2.4.3) set to true then the change shall be invisible. | +DVB_I | ||
| org.hbbtv_DVBNID0010 | 1 | Application can access DVB NID values (broadcast-independent) | When a broadcast-independent application obtains a Configuration object and reads the dtt_network_ids property, the value is a list of the DVB network_ids from the DTT channels in the terminal's channel list. | 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 A.2.20.4: readonly Number dtt_network_ids[] Returns the ordered list of DVB network_ids from the DTT channels, if any, that are included in the terminal's channel list. If the terminal does not have a DTT receiver or no DTT channels are present in the channel list then the property shall be undefined. | +DTT | ||
| org.hbbtv_DVBNID0020 | 1 | Application can access DVB NID values (broadcast-related) | When a broadcast-related application obtains a Configuration object and reads the dtt_network_ids property, the value is a list of the DVB network_ids from the DTT channels in the terminal's channel list. | 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 A.2.20.4: readonly Number dtt_network_ids[] Returns the ordered list of DVB network_ids from the DTT channels, if any, that are included in the terminal's channel list. If the terminal does not have a DTT receiver or no DTT channels are present in the channel list then the property shall be undefined. | +DTT | ||
| org.hbbtv_DVBNID0030 | 1 | dtt_network_ids with no DTT receiver (broadcast-independent) | When a broadcast-independent application obtains a Configuration object and reads the dtt_network_ids property, the value is undefined. | 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 A.2.20.4: readonly Number dtt_network_ids[] Returns the ordered list of DVB network_ids from the DTT channels, if any, that are included in the terminal's channel list. If the terminal does not have a DTT receiver or no DTT channels are present in the channel list then the property shall be undefined. | -DTT | ||
| org.hbbtv_DVBNID0040 | 1 | dtt_network_ids with no DTT receiver (broadcast-related) | When a broadcast-related application obtains a Configuration object and reads the dtt_network_ids property, the value is undefined. | 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 A.2.20.4: readonly Number dtt_network_ids[] Returns the ordered list of DVB network_ids from the DTT channels, if any, that are included in the terminal's channel list. If the terminal does not have a DTT receiver or no DTT channels are present in the channel list then the property shall be undefined. | -DTT | ||
| org.hbbtv_DVBNID0050 | 1 | dtt_network_ids with no DTT channels (broadcast-independent) | When the terminal's channel list is empty and a broadcast-independent application obtains a Configuration object and reads the dtt_network_ids property, the value is undefined. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 A.2.20.4: readonly Number dtt_network_ids[] Returns the ordered list of DVB network_ids from the DTT channels, if any, that are included in the terminal's channel list. If the terminal does not have a DTT receiver or no DTT channels are present in the channel list then the property shall be undefined. | +DTT +RLAUNCH_USER_APPROVAL | |
| org.hbbtv_E1210020 | 4 | EIT P/F - video/broadcast object can decode all required UTF-8 characters | When all the characters in the "Generic Western European character set" as defined in annex C of TS 102 809 excluding 0149 and 066B are encoded in the EIT present/following table with UTF-8 encoding; all characters shall have the expected UTF-16 character codes when retrieved using the video/broadcast object | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 10.2.1: Minimum terminal capabilities which shall be available to applications are listed in table 11 for general capabilities. Additional capabilities should be signalled in the capability profile as defined by clause 9 of the OIPF DAE specification [1]. [...] "Tiresias Screenfont" v8.03 (or equivalent) with the support for the Unicode character range "Generic Western European character set" as defined in annex C of TS 102 809 [3] but excluding the unicode character codes 0149 and 066B. OIPF-DAE,section 8.4.1: [...] the OITF SHALL translate all characters extracted from DVB SI tables and descriptors into their UTF-16 equivalent when exposing the character in a JavaScript character or string object. In addition, the following rules SHALL apply: The character table of text fields in DVB SI SHALL be determined as specified in EN 300 468 Annex A. The default character table MAY be determined by the local broadcast system. The bytes denoting the character table and the control codes for character emphasis on and off SHALL be filtered out by the OITF. [...] | ||
| org.hbbtv_E1210030 | 4 | EIT Schedule - MetadataSearch object can decode all required UTF-8 characters | When all characters in the "Generic Western European character set" as defined in annex C of TS 102 809 excluding codes 0149 and 066B are encoded in the EIT schedule table with UTF-8 encoding; all characters shall have the expected UTF-16 character codes when retrieved using the application/oipfSearchManager object | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 10.2.1: Minimum terminal capabilities which shall be available to applications are listed in table 11 for general capabilities. Additional capabilities should be signalled in the capability profile as defined by clause 9 of the OIPF DAE specification [1]. [...] "Tiresias Screenfont" v8.03 (or equivalent) with the support for the Unicode character range "Generic Western European character set" as defined in annex C of TS 102 809 [3] but excluding the unicode character codes 0149 and 066B. OIPF-DAE,section 8.4.1: [...] the OITF SHALL translate all characters extracted from DVB SI tables and descriptors into their UTF-16 equivalent when exposing the character in a JavaScript character or string object. In addition, the following rules SHALL apply: The character table of text fields in DVB SI SHALL be determined as specified in EN 300 468 Annex A. The default character table MAY be determined by the local broadcast system. The bytes denoting the character table and the control codes for character emphasis on and off SHALL be filtered out by the OITF. [...] | |||
| org.hbbtv_E1210040 | 2 | Correct graphics display and aspect ratio when showing broadband video which contains 4:3 to 16:9 transition. | When a full screen 1280 x 720 PNG is displayed on top of a full screen SD broadband video; it shall not be changed in any way when the video transitions from 4:3 to 16:9 aspect ratio | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 table 11 for general capabilities. Additional capabilities should be signalled in the capability profile as defined by clause 9 of the OIPF DAE specification [1]. [...] Hybrid Broadcast Broadband TV application graphic plane resolution [...] 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. | |||
| org.hbbtv_E1210050 | 2 | Correct graphics display and aspect ratio when showing broadband video which contains 16:9 to 4:3 transition. | When a full screen 1280 x 720 PNG is displayed on top of a full screen SD broadband video; it shall not be changed in any way when the video transitions from 16:9 to 4:3 aspect ratio | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 table 11 for general capabilities. Additional capabilities should be signalled in the capability profile as defined by clause 9 of the OIPF DAE specification [1]. [...] Hybrid Broadcast Broadband TV application graphic plane resolution [...] 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. | |||
| org.hbbtv_E1210060 | 3 | Correct graphics display and aspect ratio when showing broadcast video which contains 4:3 to 16:9 transition. | When a full screen 1280 x 720 PNG is displayed on top of full screen SD broadcast video, which is bound to the video/broadcast object; it shall not be changed in any way when the video transitions from 4:3 to 16:9 aspect ratio | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2020-2 2020-1 2019-3 2019-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 10.2.1: Minimum terminal capabilities which shall be available to applications are listed in table 11 for general capabilities. Additional capabilities should be signalled in the capability profile as defined by clause 9 of the OIPF DAE specification [1]. [...] Hybrid Broadcast Broadband TV application graphic plane resolution [...] 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. | ||
| org.hbbtv_E1210070 | 3 | Correct graphics display and aspect ratio when showing broadcast video which contains 16:9 to 4:3 transition. | When a full screen 1280 x 720 PNG is displayed on top of full screen SD broadcast video, which is bound to the video/broadcast object; it shall not be changed in any way when the video transitions from 16:9 to 4:3 aspect ratio | 2024-1 2023-3 2023-2 2023-1 2022-1 2021-3 | The challenge exists but not validated | 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 table 11 for general capabilities. Additional capabilities should be signalled in the capability profile as defined by clause 9 of the OIPF DAE specification [1]. [...] Hybrid Broadcast Broadband TV application graphic plane resolution [...] 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. | ||
| org.hbbtv_E1210080 | 3 | Correct graphics display and aspect ratio when transitioning from 4:3 broadband video to 16:9 broadcast video | When a full screen 1280 x 720 PNG is displayed on top of 4:3 full screen SD broadband video; it shall not be changed in any way when the video transitions to 16:9 full screen SD broadcast video | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 table 11 for general capabilities. Additional capabilities should be signalled in the capability profile as defined by clause 9 of the OIPF DAE specification [1]. [...] Hybrid Broadcast Broadband TV application graphic plane resolution [...] 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. | |||
| org.hbbtv_E1210090 | 3 | Correct graphics display and aspect ratio when transitioning from 16:9 broadband video to 4:3 broadcast video | When a full screen 1280 x 720 PNG is displayed on top of 16:9 full screen SD broadband video; it shall not be changed in any way when the video transitions to 4:3 full screen SD broadcast video | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 table 11 for general capabilities. Additional capabilities should be signalled in the capability profile as defined by clause 9 of the OIPF DAE specification [1]. [...] Hybrid Broadcast Broadband TV application graphic plane resolution [...] 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. | |||
| org.hbbtv_E12100A0 | 1 | Correct graphics display and aspect ratio when transitioning from 4:3 broadcast video to 16:9 broadband video | When a full screen 1280 x 720 PNG is displayed on top of 4:3 full screen SD broadcast video which has been bound using the video/broadcast object, it shall not be changed in any way when the video transitions to 16:9 full screen SD broadband video | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 table 11 for general capabilities. Additional capabilities should be signalled in the capability profile as defined by clause 9 of the OIPF DAE specification [1]. [...] Hybrid Broadcast Broadband TV application graphic plane resolution [...] 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. | |||
| org.hbbtv_E12100B0 | 1 | Correct graphics display and aspect ratio when transitioning from 16:9 broadcast video to 4:3 broadband video | When a full screen 1280 x 720 PNG is displayed on top of 16:9 full screen SD broadcast video which has been bound using the video/broadcast object, it shall not be changed in any way when the video transitions to 4:3 full screen SD broadband video | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 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 table 11 for general capabilities. Additional capabilities should be signalled in the capability profile as defined by clause 9 of the OIPF DAE specification [1]. [...] Hybrid Broadcast Broadband TV application graphic plane resolution [...] 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. | |||
| org.hbbtv_E1210100 | 1 | Broadcast / Broadband Video Multiple Switch - Full Screen - Broadcast-related - CSS 'visibility' Property | Using the 'visibility' CSS property to show/hide the respective objects, where both objects are scaled to fill the entire graphics plane, the terminal shall correctly play broadcast and broadband video when performing the following: show video/broadcast object and call bindToCurrentChannel() (broadcast video plays); stop showing video/broadcast object, show A/V Control object and play broadband video; stop broadband video, stop showing A/V Control object, show video/broadcast object and call bindToCurrentChannel() (broadcast video plays); stop showing video/broadcast object, show A/V Control object and play broadband video | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: Broadcast-related applications shall have full access to the video/broadcast object OIPF-DAE,section 7.13.1.1: The video/broadcast object SHALL be in the unrealized state when it is instantiated OIPF-DAE,section 7.13.1.3: void bindToCurrentChannel() [...] If the video/broadcast object is in the unrealized state and video from exactly one channel is currently being presented by the OITF then this binds the video/broadcast object to that video. If the video/broadcast object is in the stopped state then this restarts presentation of video and audio from the current channel under the control of the video/broadcast object. OIPF-DAE,section 7.13.1.3: void stop() [...] Stop presenting broadcast video. If the video/broadcast object is in any state other than the unrealized state, it SHALL transition to the stopped state and stop video and audio presentation. OIPF-DAE,section B: [A/V Control object] Boolean play(Number speed) - plays the media referenced by data [...] This method SHALL always return true OIPF-DAE,section B: [A/V Control object] Boolean stop() - stops the playback of the current media referenced by data, and reverts the play position to 0. Returns true if the method succeeded, and false otherwise. | |||
| org.hbbtv_E1210110 | 1 | Broadcast / Broadband Video Multiple Switch - Full Screen - Broadcast-independent - CSS 'visibility' Property | Using the 'visibility' CSS property to show/hide the respective objects, where both objects are scaled to fill the entire graphics plane, the terminal shall correctly play broadcast and broadband video when performing the following: show video/broadcast object and make application broadcast-independent; stop showing video/broadcast object, show A/V Control object and play broadband video; stop broadband video, stop showing A/V Control object, show video/broadcast object and call setChannel() (application becomes broadcast-related and broadcast video plays); make application broadcast-independent (broadcast video plays); stop showing video/broadcast object, show A/V Control object and play broadband video | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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: Calling the setChannel() method from any state of the video/broadcast object with a null argument shall cause the application to transition to a broadcast-independent application (as described in clause 6.2.2.6). HBBTV,section A.2.4.2: The setChannel method shall trigger the behaviours defined in clause 6.2. 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. HBBTV,section 6.2.2.2: New service selected → Is an application already running? → Yes → Was it signalled as service bound on the previous service? → No → Is it broadcast-related? → Yes → It is signalled in the new service with the same transport protocol? → Yes → Is it signalled with the control code KILL? → No → Application continues to run → Done OIPF-DAE,section 7.13.1.1: The video/broadcast object SHALL be in the unrealized state when it is instantiated OIPF-DAE,section 7.13.1.3: void setChannel( Channel channel, [...] ) [...] If the channel specifies an idType attribute value supported by the OITF, and the combination of properties defines a valid channel, the OITF SHALL relay the channel switch request to a local physical tuner that is currently not in use by another video/broadcast object and that can tune to the specified channel. [... Argument: ] channel [...] If null, the video/broadcast object SHALL transition to the unrealized state and [... a] ChannelChangeSucceeded event SHALL be generated when the operation has completed. OIPF-DAE,section 7.13.1.3: void stop() [...] Stop presenting broadcast video. If the video/broadcast object is in any state other than the unrealized state, it SHALL transition to the stopped state and stop video and audio presentation. OIPF-DAE,section B: [A/V Control object] Boolean play(Number speed) - plays the media referenced by data [...] This method SHALL always return true OIPF-DAE,section B: [A/V Control object] Boolean stop() - stops the playback of the current media referenced by data, and reverts the play position to 0. Returns true if the method succeeded, and false otherwise. | |||
| org.hbbtv_E1210120 | 1 | Broadcast / Broadband Video Multiple Switch - Full Screen - Broadcast-related - CSS 'display' Property | Using the 'display' CSS property to start/stop rendering the respective objects, where both objects are scaled to fill the entire graphics plane, the terminal shall correctly play broadcast and broadband video when performing the following: render video/broadcast object and call bindToCurrentChannel() (broadcast video plays); stop rendering video/broadcast object, render A/V Control object and play broadband video; stop broadband video, stop rendering A/V Control object, render video/broadcast object and call bindToCurrentChannel() (broadcast video plays); stop rendering video/broadcast object, render A/V Control object and play broadband video | 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,section A.2.4.2: Broadcast-related applications shall have full access to the video/broadcast object OIPF-DAE,section 7.13.1.1: The video/broadcast object SHALL be in the unrealized state when it is instantiated OIPF-DAE,section 7.13.1.3: void bindToCurrentChannel() [...] If the video/broadcast object is in the unrealized state and video from exactly one channel is currently being presented by the OITF then this binds the video/broadcast object to that video. If the video/broadcast object is in the stopped state then this restarts presentation of video and audio from the current channel under the control of the video/broadcast object. OIPF-DAE,section 7.13.1.3: void stop() [...] Stop presenting broadcast video. If the video/broadcast object is in any state other than the unrealized state, it SHALL transition to the stopped state and stop video and audio presentation. OIPF-DAE,section B: [A/V Control object] Boolean play(Number speed) - plays the media referenced by data [...] This method SHALL always return true OIPF-DAE,section B: [A/V Control object] Boolean stop() - stops the playback of the current media referenced by data, and reverts the play position to 0. Returns true if the method succeeded, and false otherwise. | |||
| org.hbbtv_E1210130 | 1 | Broadcast / Broadband Video Multiple Switch - Full Screen - Broadcast-independent - CSS 'display' Property | Using the 'display' CSS property to start/stop rendering the respective objects, where both objects are scaled to fill the entire graphics plane, the terminal shall correctly play broadcast and broadband video when performing the following: render video/broadcast object and make application broadcast-independent (broadcast video plays); stop rendering video/broadcast object, render A/V Control object and play broadband video; stop broadband video, stop rendering A/V Control object, render video/broadcast object and call setChannel() (application becomes broadcast-related and broadcast video plays); make application broadcast-independent (broadcast video plays); stop rendering video/broadcast object, render A/V Control object and play broadband video | 2024-1 2023-3 2023-2 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-1 | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section A.2.4.1: Calling the setChannel() method from any state of the video/broadcast object with a null argument shall cause the application to transition to a broadcast-independent application (as described in clause 6.2.2.6). HBBTV,section A.2.4.2: The setChannel method shall trigger the behaviours defined in clause 6.2. 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. HBBTV,section 6.2.2.2: New service selected → Is an application already running? → Yes → Was it signalled as service bound on the previous service? → No → Is it broadcast-related? → Yes → It is signalled in the new service with the same transport protocol? → Yes → Is it signalled with the control code KILL? → No → Application continues to run → Done OIPF-DAE,section 7.13.1.1: The video/broadcast object SHALL be in the unrealized state when it is instantiated OIPF-DAE,section 7.13.1.3: void setChannel( Channel channel, [...] ) [...] If the channel specifies an idType attribute value supported by the OITF, and the combination of properties defines a valid channel, the OITF SHALL relay the channel switch request to a local physical tuner that is currently not in use by another video/broadcast object and that can tune to the specified channel. [... Argument: ] channel [...] If null, the video/broadcast object SHALL transition to the unrealized state and [... a] ChannelChangeSucceeded event SHALL be generated when the operation has completed. OIPF-DAE,section 7.13.1.3: void stop() [...] Stop presenting broadcast video. If the video/broadcast object is in any state other than the unrealized state, it SHALL transition to the stopped state and stop video and audio presentation. OIPF-DAE,section B: [A/V Control object] Boolean play(Number speed) - plays the media referenced by data [...] This method SHALL always return true OIPF-DAE,section B: [A/V Control object] Boolean stop() - stops the playback of the current media referenced by data, and reverts the play position to 0. Returns true if the method succeeded, and false otherwise. | |||
| org.hbbtv_E1210140 | 1 | Broadcast / Broadband Video Multiple Switch - Full Screen - Broadcast-related - Add/Remove objects | Using the DOM API to add/remove the respective objects, where both objects are scaled to fill the entire graphics plane, the terminal shall correctly play broadcast and broadband video when performing the following: add video/broadcast object and call bindToCurrentChannel() (broadcast video plays); remove video/broadcast object, add A/V Control object and play broadband video; stop broadband video, remove A/V Control object, add video/broadcast object and call bindToCurrentChannel() (broadcast video plays); remove video/broadcast object, add A/V Control object and play broadband video | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: Broadcast-related applications shall have full access to the video/broadcast object OIPF-DAE,section 7.13.1.1: The video/broadcast object SHALL be in the unrealized state when it is instantiated OIPF-DAE,section 7.13.1.3: void bindToCurrentChannel() [...] If the video/broadcast object is in the unrealized state and video from exactly one channel is currently being presented by the OITF then this binds the video/broadcast object to that video. If the video/broadcast object is in the stopped state then this restarts presentation of video and audio from the current channel under the control of the video/broadcast object. OIPF-DAE,section 7.13.1.3: void stop() [...] Stop presenting broadcast video. If the video/broadcast object is in any state other than the unrealized state, it SHALL transition to the stopped state and stop video and audio presentation. OIPF-DAE,section B: [A/V Control object] Boolean play(Number speed) - plays the media referenced by data [...] This method SHALL always return true OIPF-DAE,section B: [A/V Control object] Boolean stop() - stops the playback of the current media referenced by data, and reverts the play position to 0. Returns true if the method succeeded, and false otherwise. | |||
| org.hbbtv_E1210150 | 1 | Broadcast / Broadband Video Multiple Switch - Full Screen - Broadcast-independent - Add/Remove objects | Using the DOM API to add/remove the respective objects, where both objects are scaled to fill the entire graphics plane, the terminal shall correctly play broadcast and broadband video when performing the following: add video/broadcast object and make application broadcast-independent (broadcast video plays); remove video/broadcast object, add A/V Control object and play broadband video; stop broadband video, remove A/V Control object, add video/broadcast object and call setChannel() (application becomes broadcast-related and broadcast video plays); make application broadcast-independent (broadcast video plays); remove video/broadcast object, add A/V Control object and play broadband video | 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 A.2.4.1: Calling the setChannel() method from any state of the video/broadcast object with a null argument shall cause the application to transition to a broadcast-independent application (as described in clause 6.2.2.6). HBBTV,section A.2.4.2: The setChannel method shall trigger the behaviours defined in clause 6.2. 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. HBBTV,section 6.2.2.2: New service selected → Is an application already running? → Yes → Was it signalled as service bound on the previous service? → No → Is it broadcast-related? → Yes → It is signalled in the new service with the same transport protocol? → Yes → Is it signalled with the control code KILL? → No → Application continues to run → Done OIPF-DAE,section 7.13.1.1: The video/broadcast object SHALL be in the unrealized state when it is instantiated OIPF-DAE,section 7.13.1.3: void setChannel( Channel channel, [...] ) [...] If the channel specifies an idType attribute value supported by the OITF, and the combination of properties defines a valid channel, the OITF SHALL relay the channel switch request to a local physical tuner that is currently not in use by another video/broadcast object and that can tune to the specified channel. OIPF-DAE,section 7.13.1.3: void stop() [...] Stop presenting broadcast video. If the video/broadcast object is in any state other than the unrealized state, it SHALL transition to the stopped state and stop video and audio presentation. OIPF-DAE,section B: [A/V Control object] Boolean play(Number speed) - plays the media referenced by data [...] This method SHALL always return true OIPF-DAE,section B: [A/V Control object] Boolean stop() - stops the playback of the current media referenced by data, and reverts the play position to 0. Returns true if the method succeeded, and false otherwise. | |||
| org.hbbtv_EAC30001 | 2 | Test of support for E-AC3 stereo, Streamed over HTTP. MP4 container. | The terminal shall correctly decode and present E-AC3 stereo AV content from an MP4 container streamed over HTTP. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4. HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 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_EAC30002 | 3 | Test of support for down-mixed E-AC3; 5.1 channel, AV Content, Streamed over HTTP. MP4 container. | The terminal shall correctly decode and present down-mixed 5.1 channel E-AC3 AV content from an MP4 container streamed over HTTP. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4. HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 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_EAC30003 | 3 | Test of support for down-mixed E-AC3; 7.1 channel, AV Content, Streamed over HTTP. MP4 container. | The terminal shall correctly decode and present down-mixed 7.1 channel E-AC3 AV content from an MP4 container streamed over HTTP. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4. HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 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_EAC30004 | 3 | Test of support for E-AC-3 stereo. HbbTV ISOBMFF Live profile | The terminal shall correctly decode and present E-AC3 stereo AV content from an MPEG DASH live stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 8.4: ISO Base media file format live profile HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 7.3.1.1: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4. HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] HBBTV,section E.2.5: For E-AC-3 the Audio Channel Configuration shall use the "urn:dolby:dash:audio_channel_configuration:2011" schemeURI. The value element shall contain a four digit hexadecimal representation of the 16 bit field that describes the channel assignment as defined by Table E.5 in [11] where left channel is MSB. For example, for a stream with L, C, R, Ls, Rs, LFE, the value shall be "F801" (hexadecimal equivalent of the binary value 1111 1000 0000 0001) as follows: ... | +EAC3 | ||
| org.hbbtv_EAC30004_NEW_URI | 1 | New Audio Channel Configuration schemeURI for E-AC-3 (2.0 channels) | The terminal shall correctly decode and present 2.0 channel E-AC-3 AV content from an MPEG DASH live stream which uses the "urn:dolby:dash:audio_channel_configuration:2011" scheme URI with value: A000 for Audio Channel Configuration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 8.4: ISO Base media file format live profile HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. 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. HBBTV,section 7.3.1.4: The terminal shall use metadata, where provided, to control the stereo down-mix from multichannel audio, and shall use it, or pass it through, when providing bitstream output. Such metadata may be provided as described in the OIPF Media Formats specification [2] and clause 6.8 of TS 102 366 [15]. HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] HBBTV,section E.2.5: For E-AC-3 the Audio Channel Configuration shall use either the "tag:dolby.com,2014:dash:audio_channel_configuration:2011" (as defined in the DVB DASH profile [45]) or the legacy "urn:dolby:dash:audio_channel_configuration:2011" schemeURI. | +EAC3 | ||
| org.hbbtv_EAC30005 | 4 | Test of support for down-mixed E-AC3; 5.1 channel, AV Content, HbbTV ISOBMFF Live profile | The terminal shall correctly decode and present down-mixed 5.1 channel E-AC3 AV content from an MPEG DASH live stream | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 8.4: ISO Base media file format live profile HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 7.3.1.1: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4. HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] HBBTV,section E.2.5: For E-AC-3 the Audio Channel Configuration shall use the “urn:dolby:dash:audio_channel_configuration:2011” schemeURI. The value element shall contain a four digit hexadecimal representation of the 16 bit field that describes the channel assignment as defined by Table E.5 in [11] where left channel is MSB. For example, for a stream with L, C, R, Ls, Rs, LFE, the value shall be "F801" (hexadecimal equivalent of the binary value 1111 1000 0000 0001) as follows: ... | +EAC3 | ||
| org.hbbtv_EAC30005_NEW_URI | 1 | New Audio Channel Configuration schemeURI for E-AC-3 (5.1 channels) | The terminal shall correctly decode and present down-mixed 5.1 channel E-AC-3 AV content from an MPEG DASH live stream which uses the "urn:dolby:dash:audio_channel_configuration:2011" scheme URI with value: F801 for Audio Channel Configuration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 8.4: ISO Base media file format live profile HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. 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. HBBTV,section 7.3.1.4: The terminal shall use metadata, where provided, to control the stereo down-mix from multichannel audio, and shall use it, or pass it through, when providing bitstream output. Such metadata may be provided as described in the OIPF Media Formats specification [2] and clause 6.8 of TS 102 366 [15]. HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] HBBTV,section E.2.5: For E-AC-3 the Audio Channel Configuration shall use either the "tag:dolby.com,2014:dash:audio_channel_configuration:2011" (as defined in the DVB DASH profile [45]) or the legacy "urn:dolby:dash:audio_channel_configuration:2011" schemeURI. | +EAC3 | ||
| org.hbbtv_EAC30006 | 4 | Test of support for down-mixed E-AC3; 7.1 channel, AV Content, HbbTV ISOBMFF Live profile | The terminal shall correctly decode and present down-mixed 7.1 channel E-AC3 AV content from an MPEG DASH live stream | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 8.4: ISO Base media file format live profile HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 7.3.1.1: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4. HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] HBBTV,section E.2.5: For E-AC-3 the Audio Channel Configuration shall use the “urn:dolby:dash:audio_channel_configuration:2011” schemeURI. The value element shall contain a four digit hexadecimal representation of the 16 bit field that describes the channel assignment as defined by Table E.5 in [11] where left channel is MSB. For example, for a stream with L, C, R, Ls, Rs, LFE, the value shall be "F801" (hexadecimal equivalent of the binary value 1111 1000 0000 0001) as follows: ... | +EAC3 | ||
| org.hbbtv_EAC30006_NEW_URI | 1 | New Audio Channel Configuration schemeURI for E-AC-3 (7.1 channels) | The terminal shall correctly decode and present down-mixed 7.1 channel E-AC-3 AV content from an MPEG DASH live stream which uses the "urn:dolby:dash:audio_channel_configuration:2011" scheme URI with value: FA01 for Audio Channel Configuration. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 8.4: ISO Base media file format live profile HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. 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. HBBTV,section 7.3.1.4: The terminal shall use metadata, where provided, to control the stereo down-mix from multichannel audio, and shall use it, or pass it through, when providing bitstream output. Such metadata may be provided as described in the OIPF Media Formats specification [2] and clause 6.8 of TS 102 366 [15]. HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] HBBTV,section E.2.5: For E-AC-3 the Audio Channel Configuration shall use either the "tag:dolby.com,2014:dash:audio_channel_configuration:2011" (as defined in the DVB DASH profile [45]) or the legacy "urn:dolby:dash:audio_channel_configuration:2011" schemeURI. | +EAC3 | ||
| org.hbbtv_EAC30007 | 2 | Test of support for E-AC3 stereo, Streamed over HTTP. MPEG-2 TS container. | The terminal shall correctly decode and present E-AC3 stereo AV content from an MPEG-2 TS container streamed over HTTP. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4. HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 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_EAC30008 | 3 | Test of support for down-mixed E-AC3; 5.1 channel, AV Content, Streamed over HTTP. MPEG-2 TS container. | The terminal shall correctly decode and present down-mixed 5.1 channel E-AC3 AV content from an MPEG-2 TS container streamed over HTTP | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4. HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 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_EAC30009 | 3 | Test of support for down-mixed E-AC3; 7.1 channel, AV Content, Streamed over HTTP. MPEG-2 TS container. | The terminal shall correctly decode and present down-mixed 7.1 channel E-AC3 AV content from an MPEG-2 TS container streamed over HTTP | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4. HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 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_EAC3000D | 2 | Test of support for an E-AC-3 Audio Description. HbbTV ISOBMFF Live profile (audio description only) | Terminal correctly presents broadcast mix Audio Description from an MPEG DASH stream containing 1 video and 2 E-AC-3 audio AdaptationSets, where 1 audio AdaptationSet is signalled as containing broadcast mix Audio Description (Live Streaming Profile). | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4 HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] HBBTV,section 9.4: When an instance of the AVComponent class refers to a DASH audio media content component; If the audio media component is identified as being audio description (as defined in clause E.2.4 Role Related Requirements below), the audioDescription property of the AVComponent shall be set to true. HBBTV,section E.2.4: Table E.2 : Role and Accessibility descriptor values for Audio Description | +EAC3 | ||
| org.hbbtv_EAC3000D_2 | 2 | Test of support for an E-AC-3 Audio Description. HbbTV ISOBMFF Live profile (main audio only) | Terminal correctly presents main broadcast audio from an MPEG DASH stream containing 1 video and 2 E-AC-3 audio AdaptationSets, where 1 audio AdaptationSet is signalled as containing broadcast mix Audio Description (Live Streaming Profile). | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4 HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] HBBTV,section 9.4: When an instance of the AVComponent class refers to a DASH audio media content component; If the audio media component is identified as being audio description (as defined in clause E.2.4 Role Related Requirements below), the audioDescription property of the AVComponent shall be set to true. HBBTV,section E.2.4: Table E.2 : Role and Accessibility descriptor values for Audio Description | +EAC3 | ||
| org.hbbtv_EAC3000F | 3 | HbbTV ISOBMFF Live profile, DD+ 5.1, single bitrate, contradicting channel layout metadata | When an MPD contains channel layout metadata that contradicts the channel layout of the audio content, the terminal shall correctly play the audio content. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4 HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH | +EAC3 | ||
| org.hbbtv_EAC30010 | 3 | DASH Live Profile, DD+ 5.1, single bitrate, contradicting codec metadata | When an MPD contains codec metadata contradicting the audio content, the terminal shall correctly play the audio content. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 HBBTV,section E.3.2: All information necessary to decode any Segment chosen from Representations shall be provided in the Initialization Segment. For example, movie box for video Representation shall contain AVC decoder configuration records including all encoding parameters | +EAC3 | ||
| org.hbbtv_EAC30013 | 4 | Test of support for Multiple Languages from multiple E-AC-3 elementary streams, MP4 container (audio language change during test) | For a terminal that supports changing the audio language while an application is running, it shall be able to decode and present multiple languages (English and French) from multiple E-AC-3 elementary streams stored in an MP4 container. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4 HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 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: Enhanced AC-3 (Dolby Digital Plus) [AC3] (audio format label: E-AC3) MAY be used when appropriate, as designated by systems requirements. | +EAC3 | ||
| org.hbbtv_EAC30013_2 | 4 | Test of support for Multiple Languages from multiple E-AC-3 elementary streams, MP4 container (English) (audio language change before test) | For a terminal that only supports changing the audio language when an application is not running, The terminal shall be able to decode and present the selected language (English) from multiple E-AC-3 elementary streams stored in an MP4 container. | 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 7.3.1.1: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4 HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 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: Enhanced AC-3 (Dolby Digital Plus) [AC3] (audio format label: E-AC3) MAY be used when appropriate, as designated by systems requirements. | +EAC3 | ||
| org.hbbtv_EAC30013_3 | 4 | Test of support for Multiple Languages from multiple E-AC-3 elementary streams, MP4 container (French) (audio language change before test) | For a terminal that only supports changing the audio language when an application is not running, The terminal shall be able to decode and present the selected language (French) from multiple E-AC-3 elementary streams stored in an MP4 container. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4 HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 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: Enhanced AC-3 (Dolby Digital Plus) [AC3] (audio format label: E-AC3) MAY be used when appropriate, as designated by systems requirements. | +EAC3 | ||
| org.hbbtv_EAC30014 | 4 | Test of support for Multiple Languages from multiple E-AC-3 elementary streams, HbbTV ISOBMFF Live profile (English) (audio language change during test) | For a terminal that supports changing the audio language while an application is running, the terminal shall be able to decode and present multiple languages (English and French) from multiple E-AC-3 Adaptation Sets in an MPEG-DASH stream (HbbTV ISOBMFF Live profile) | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 8.4: ISO Base media file format live profile HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 7.3.1.1: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4 HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] | +EAC3 | ||
| org.hbbtv_EAC30014_2 | 4 | Test of support for Multiple Languages from multiple E-AC-3 elementary streams, HbbTV ISOBMFF Live profile (English) (audio language change before test) | For a terminal that only supports changing the audio language when an application is not running, the terminal shall be able to decode and present the selected language (English) from multiple E-AC-3 Adaptation Sets in an MPEG-DASH stream (HbbTV ISOBMFF Live profile) | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 8.4: ISO Base media file format live profile HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 7.3.1.1: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4 HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] | +EAC3 | ||
| org.hbbtv_EAC30014_3 | 4 | Test of support for Multiple Languages from multiple E-AC-3 elementary streams, HbbTV ISOBMFF Live profile (French) (audio language change before test) | For a terminal that only supports changing the audio language when an application is not running, the terminal shall be able to decode and present the selected language (French) from multiple E-AC-3 Adaptation Sets in an MPEG-DASH stream (HbbTV ISOBMFF Live profile) | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | DASH,section 8.4: ISO Base media file format live profile HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH as defined in annex E. HBBTV,section 7.3.1.1: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4 HBBTV,section 7.3.1.2: E-AC3 shall comply with TS 102 366 HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] | +EAC3 | ||
| org.hbbtv_EAC30016 | 4 | HbbTV ISOBMFF Live profile, DD+ Stereo MultiRate, Low to High | During playout of a stream defined in a static MPD in response to increased bandwidth availability the terminal shall transition seamlessly from an audio representation with a bitrate of 96kbps to an audio representation with a bitrate of 384kbps, both representations being encoded using E-AC3. | 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 | HBBTV 1.4.1 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 with the restrictions in clause 7.3.1.4 HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.4.2.2: During playback of adaptively streamed content encoded using HE-AAC or E-AC3, terminals shall support transitions between audio Representations as follows: 1) Between Representations which differ by bit-rate. Transitions shall be seamless unless combined with other changes which do not have that requirement. | +EAC3 | ||
| org.hbbtv_EAC30017 | 4 | HbbTV ISOBMFF Live profile, DD+ Stereo MultiRate, High to Low | During playout of a stream defined in a static MPD in response to decreased bandwidth availability the terminal shall transition seamlessly from an audio representation with a bitrate of 384kbps to an audio representation with a bitrate of 96kbps, both representations being encoded using E-AC3. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The audio formats are specified in the OIPF Media Formats specification with the restrictions in clause 7.3.1.4 HBBTV,section 7.3.1.4: Audio formats shall comply with clause 8.1 of the OIPF Media Formats specification [...] HBBTV,section 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH HBBTV,section E.4.2.2: During playback of adaptively streamed content encoded using HE-AAC or E-AC3, terminals shall support transitions between audio Representations as follows: 1) Between Representations which differ by bit-rate. Transitions shall be seamless unless combined with other changes which do not have that requirement. | +EAC3 | ||
| org.hbbtv_EME0010 | 1 | Clear Key: successful call to requestMediaKeySystemAccess method | When the application calls requestMediaKeySystemAccess with 'org.w3.clearkey' as the keysystem and a MediaKeySystemConfiguration specifying 'cenc' as an initialization data format and a valid audio/video MediaKeySystemMediaCapability, a new MediaKeySystemAccess object is returned | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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.3.11: The W3C encrypted media extensions API [66] shall be supported for encrypted content delivered via broadband as defined in clause B.3 of the present document. Use of this API [nn] with a DRM system is outside the scope of the present document. HBBTV,section B.3: The “Clear Key” key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). EME,section 9: 9. Common Key Systems All user agents MUST support the common key systems described in this section. ... 9.1 Clear Key The "org.w3.clearkey" Key System uses plain-text clear (unencrypted) key(s) to decrypt the source. No additional client-side content protection is required. This Key System is described below. EME,section 3.1.1: requestMediaKeySystemAccess ... Requests access to the specified Key System. When supportedConfigurations is specified, the configuration specified by at least one of its elements must be supported. The resulting MediaKeySystemAccess will correspond to the first such elment. Any permission checks or user interaction, such as a prompt, MUST be performed before resolving the promise. If the keySystem is not supported or not allowed (in one at least one of the supportedConfigurations, if specified), the promise is rejected. Otherwise, it is resolved with a new MediaKeySystemAccess object. | ||
| org.hbbtv_EME0020 | 1 | Clear Key: successful call to createMediaKeys method | An application obtains a MediaKeySystemAccess object for the "Clear Key" key system and then calls the createMediaKeys method. A MediaKeys object is created. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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.3.11: The W3C encrypted media extensions API [66] shall be supported for encrypted content delivered via broadband as defined in clause B.3 of the present document. Use of this API [nn] with a DRM system is outside the scope of the present document. HBBTV,section B.3: The “Clear Key” key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). EME,section 9: 9. Common Key Systems All user agents MUST support the common key systems described in this section. ... 9.1 Clear Key The "org.w3.clearkey" Key System uses plain-text clear (unencrypted) key(s) to decrypt the source. No additional client-side content protection is required. This Key System is described below. EME,section 3.1.1: requestMediaKeySystemAccess ... Requests access to the specified Key System. EME,section 4.2: createMediaKeys Creates a new MediaKeys object for keySystem. No parameters. Return type: Promise<MediaKeys> When this method is invoked, the user agent must run the following steps: 1. Let promise be a new promise. 2. Run the following steps in parallel: 1. Let configuration be the value of this object's configuration value. 2. Let distinctive identifier be the value of configuration's distinctiveIdentifier member. 3. Follow the steps for the value of distinctive identifier from the following list: "required" Let use distinctive identifier be true. "not-allowed" Let use distinctive identifier be false. 4. Let persistent state be the value of configuration's persistentState member. 5. Follow the steps for the value of persistent state from the following list: "required" Let persistent state allowed be true. "not-allowed" Let persistent state allowed be false. 6. Load and initialize the Key System implementation represented by this object's cdm implementation value if necessary. 7. Let instance be a new instance of the Key System implementation represented by this object's cdm implementation value. 8. If use distinctive identifier is false, prevent instance from using Distinctive Identifier(s). 9. If persistent state allowed is false, prevent instance from persisting any state related to the application or origin of this object's Document. 10. If any of the preceding steps failed, reject promise with a new DOMException whose name is the appropriate error name. 11. Let media keys be a new MediaKeys object, and initialize it as follows: 1. Let the use distinctive identifier value be use distinctive identifier. 2. Let the persistent state allowed value be persistent state allowed. 3. Let the supported session types value be be the value of configuration's sessionTypes member. 4. Let the cdm implementation value be this object's cdm implementation value. 5. Let the cdm instance value be instance. 12. Resolve promise with media keys. 3. Return promise. | ||
| org.hbbtv_EME0030 | 1 | Clear Key: successful call to setMediaKeys method | An application that has created a MediaKeys object for the Clear Key keysystem and a video element and has set the source of the video element to refer to an MPEG DASH MPD then calls the setMediaKeys method to link the MediaKeys object to the video element. The method call succeeds. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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.3.11: The W3C encrypted media extensions API [66] shall be supported for encrypted content delivered via broadband as defined in clause B.3 of the present document. Use of this API [nn] with a DRM system is outside the scope of the present document. HBBTV,section B.3: The “Clear Key” key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). EME,section 9: 9. Common Key Systems All user agents MUST support the common key systems described in this section. ... 9.1 Clear Key The "org.w3.clearkey" Key System uses plain-text clear (unencrypted) key(s) to decrypt the source. No additional client-side content protection is required. This Key System is described below. EME,section 3.1.1: requestMediaKeySystemAccess ... Requests access to the specified Key System. EME,section 4.2: createMediaKeys: Creates a new MediaKeys object for keySystem. EME,section 7.2: setMediaKeys Provides the MediaKeys to use when decrypting media data during playback. ... When this method is invoked, the user agent must run the following steps: 1. If mediaKeys and the mediaKeys attribute are the same object, return a resolved promise. 2. If this object's attaching media keys value is true, return a promise rejected with an InvalidStateError. 3. Let this object's attaching media keys value be true. 4. Let promise be a new promise. 5. Run the following steps in parallel: 1. If mediaKeys is not null, the CDM instance represented by mediaKeys is already in use by another media element, and the user agent is unable to use it with this element, let this object's attaching media keys value be false and reject promise with a QuotaExceededError. 2. If the mediaKeys attribute is not null, run the following steps: 1. If the user agent or CDM do not support removing the association, let this object's attaching media keys value be false and reject promise with a NotSupportedError. 2. If the association cannot currently be removed, let this object's attaching media keys value be false and reject promise with an InvalidStateError. Note For example, some implementations may not allow removal during playback. 3. Stop using the CDM instance represented by the mediaKeys attribute to decrypt media data and remove the association with the media element. 4. If the preceding step failed, let this object's attaching media keys value be false and reject promise with a the appropriate error name. 3. If mediaKeys is not null, run the following steps: 1. Associate the CDM instance represented by mediaKeys with the media element for decrypting media data. 2. If the preceding step failed, run the following steps: 1 .Set the mediaKeys attribute to null. 2. Let this object's attaching media keys value be false. 3. Reject promise with a new DOMException whose name is the appropriate error name. 3. Queue a task to run the Attempt to Resume Playback If Necessary algorithm on the media element. The user agent MAY choose to skip this step if it knows resuming will fail. 4. Set the mediaKeys attribute to mediaKeys. 5. Let this object's attaching media keys value be false. 6. Resolve promise. 6. Return promise. | ||
| org.hbbtv_EME0040 | 1 | Clear Key: successful call to createSession method | An application that has created a MediaKeys object for the Clear Key system and a video element and has set the source of the video element to refer to an MPEG DASH MPD then calls the createSession method to create a session for the key system. The method call succeeds. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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.3.11: The W3C encrypted media extensions API [66] shall be supported for encrypted content delivered via broadband as defined in clause B.3 of the present document. Use of this API [nn] with a DRM system is outside the scope of the present document. HBBTV,section B.3: The “Clear Key” key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). EME,section 9: 9. Common Key Systems All user agents MUST support the common key systems described in this section. ... 9.1 Clear Key The "org.w3.clearkey" Key System uses plain-text clear (unencrypted) key(s) to decrypt the source. No additional client-side content protection is required. This Key System is described below. EME,section 3.1.1: requestMediaKeySystemAccess ... Requests access to the specified Key System. EME,section 4.2: createMediaKeys: Creates a new MediaKeys object for keySystem. EME,section 7.2: setMediaKeys Provides the MediaKeys to use when decrypting media data during playback. EME,section 5.1: createSession Returns a new MediaKeySession object. ... Return type: MediaKeySession When this method is invoked, the user agent must run the following steps: 1. If this object's supported session types value does not contain sessionType, throw a NotSupportedError. Note sessionType values for which the Is persistent session type? algorithm returns true will fail if this object's persistent state allowed value is false. 2. Let session be a new MediaKeySession object, and initialize it as follows: 1. Let the sessionId attribute be the empty string. 2. Let the expiration attribute be NaN. 3. Let the closed attribute be a new promise. 4. Let key status be a new empty MediaKeyStatusMap object, and initialize it as follows: 1. Let the size attribute be 0. 5. Let the session type value be sessionType. 6. Let the uninitialized value be true. 7. Let the callable value be false. 8. Let the use distinctive identifier value be this object's use distinctive identifier value. 9. Let the cdm implementation value be this object's cdm implementation. 10. Let the cdm instance value be this object's cdm instance. 3. Return session. | ||
| org.hbbtv_EME0050 | 1 | Clear Key: successful call to generateRequest method | An application that has created a MediaKeys object for the Clear Key system, created a session for that MediaKeys object and provided the MediaKeys object to a video element then generates a license request based on init data for the Clear Key system. The handler for license request events is called. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.11: The W3C encrypted media extensions API [66] shall be supported for encrypted content delivered via broadband as defined in clause B.3 of the present document. Use of this API [nn] with a DRM system is outside the scope of the present document. HBBTV,section B.3: The “Clear Key” key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). EME,section 9: 9. Common Key Systems All user agents MUST support the common key systems described in this section. ... 9.1 Clear Key The "org.w3.clearkey" Key System uses plain-text clear (unencrypted) key(s) to decrypt the source. No additional client-side content protection is required. This Key System is described below. EME,section 3.1.1: requestMediaKeySystemAccess ... Requests access to the specified Key System. EME,section 4.2: createMediaKeys: Creates a new MediaKeys object for keySystem. EME,section 7.2: setMediaKeys Provides the MediaKeys to use when decrypting media data during playback. EME,section 5.1: createSession Returns a new MediaKeySession object. EME,section 6.2: generateRequest Generates a license request based on the initData. A message of type "license-request" will always be queued if the algorithm succeeds and the promise is resolved. Parameter Type Nullable Optional Description initDataType DOMString ✘ ✘ The Initialization Data Type of the initData. initData BufferSource ✘ ✘ Initialization Data Return type: Promise<void> When this method is invoked, the user agent must run the following steps: 1. If the Session Close algorithm has been run on this object, return a promise rejected with an InvalidStateError. 2. If this object's uninitialized value is false, return a promise rejected with an InvalidStateError. 3. Let this object's uninitialized value be false. 4. If initDataType is the empty string, return a promise rejected with a newly created TypeError. 5. If initData is an empty array, return a promise rejected with a newly created TypeError. 6. If the Key System implementation represented by this object's cdm implementation value does not support initDataType as an Initialization Data Type, return a promise rejected with a NotSupportedError. String comparison is case-sensitive. 7. Let init data be a copy of the contents of the initData parameter. 8. Let session type be this object's session type. 9. Let promise be a new promise. 10. Run the following steps in parallel: 1. If the init data is not valid for initDataType, reject promise with a newly created TypeError. 2. Let sanitized init data be a validated and sanitized version of init data. The user agent MUST thoroughly validate the Initialization Data before passing it to the CDM. This includes verifying that the length and values of fields are reasonable, verifying that values are within reasonable limits, and stripping irrelevant, unsupported, or unknown data or fields. It is RECOMMENDED that user agents pre-parse, sanitize, and/or generate a fully sanitized version of the Initialization Data. If the Initialization Data format specified by initDataType supports multiple entries, the user agent SHOULD remove entries that are not needed by the CDM. The user agent MUST NOT re-order entries within the Initialization Data. 3. If the preceding step failed, reject promise with a newly created TypeError. 4. If sanitized init data is empty, reject promise with a NotSupportedError. 5. Let session id be the empty string. 6. Let message be null. 7. Let cdm be the CDM instance represented by this object's cdm instance value. 8. Use the cdm to execute the following steps: 1. If the sanitized init data is not supported by the cdm, reject promise with a NotSupportedError. 2. Follow the steps for the value of session type from the following list: "temporary" Let requested license type be a temporary non-persistable license. Note The returned license must not be persistable or require persisting information related to it. "persistent-usage-record" 1. Initialize this object's record of key usage as follows. Set the list of key IDs known to the session to an empty list. Set the first decrypt time to null. Set the latest decrypt time to null. 2. Let requested license type be a non-persistable license that will persist a record of key usage. "persistent-license" Let requested license type be a persistable license. 3. Let session id be a unique Session ID string. If the result of running the Is persistent session type? algorithm on session type is true, the ID MUST be unique within the origin of this object's Document over time, including across Documents and browsing sessions. 4. Let message be a license request for the requested license type generated based on the sanitized init data, which is interpreted per initDataType. The cdm MUST NOT use any stream-specific data, including media data, not provided via the sanitized init data. The cdm SHOULD NOT store session data, including the session ID, at this point. See Session Storage and Persistence. 9. If any of the preceding steps failed, reject promise with a new DOMException whose name is the appropriate error name. 10. Set the sessionId attribute to session id. 11. Let this object's callable value be true. 12. Run the Queue a "message" Event algorithm on the session, providing "license-request" and message. 13. Resolve promise. 11. Return promise. | |||
| org.hbbtv_EME0060 | 1 | Clear Key: content is decrypted | An application sets a video element to point to a DASH MPD where the content is encrypted using the Clear Key system and then calls the play method. In the callback of the 'message' event, the application is asked for the key to decrypt the content and after providing the correct key to the update method, the content is successfully decrypted and presented. | 2024-1 2023-3 2023-2 2023-1 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.3.11: The W3C encrypted media extensions API [66] shall be supported for encrypted content delivered via broadband as defined in clause B.3 of the present document. Use of this API [nn] with a DRM system is outside the scope of the present document. HBBTV,section B.3: The “Clear Key” key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). EME,section 9: 9. Common Key Systems All user agents MUST support the common key systems described in this section. ... 9.1 Clear Key The "org.w3.clearkey" Key System uses plain-text clear (unencrypted) key(s) to decrypt the source. No additional client-side content protection is required. This Key System is described below. EME,section 3.1.1: requestMediaKeySystemAccess ... Requests access to the specified Key System. EME,section 4.2: createMediaKeys: Creates a new MediaKeys object for keySystem. EME,section 7.2: setMediaKeys Provides the MediaKeys to use when decrypting media data during playback. EME,section 5.1: createSession Returns a new MediaKeySession object. EME,section 6.2: generateRequest Generates a license request based on the initData. A message of type "license-request" will always be queued if the algorithm succeeds and the promise is resolved. EME,section 6.2: update Provides messages, including licenses, to the CDM. Parameter Type Nullable Optional Description response BufferSource ✘ ✘ A message to be provided to the CDM. The contents are Key System-specific. It MUST NOT contain executable code. Return type: Promise<void> When this method is invoked, the user agent must run the following steps: 1. If the Session Close algorithm has been run on this object, return a promise rejected with an InvalidStateError. 2. If this object's callable value is false, return a promise rejected with an InvalidStateError. 3. If response is an empty array, return a promise rejected with a newly created TypeError. 4. Let response copy be a copy of the contents of the response parameter. 5. Let promise be a new promise. 6. Run the following steps in parallel: 1. Let sanitized response be a validated and/or sanitized version of response copy. Note The user agent should thoroughly validate the response before passing it to the CDM. This may include verifying values are within reasonable limits, stripping irrelevant data or fields, pre-parsing it, sanitizing it, and/or generating a fully sanitized version. The user agent should check that the length and values of fields are reasonable. Unknown fields should be rejected or removed. 2. If the preceding step failed, or if sanitized response is empty, reject promise with a newly created TypeError. 3. Let message be null. 4. Let message type be null. 5. Let cdm be the CDM instance represented by this object's cdm instance value. 6. Use the cdm to execute the following steps: 1. If the format of sanitized response is invalid in any way, reject promise with a newly created TypeError. 2. Process sanitized response, following the stipulation for the first matching condition from the following list: .... 3. If the set of keys known to the CDM for this object changed or the status of any key(s) changed, run the Update Key Statuses algorithm on the session, providing each known key's key ID along with the appropriate MediaKeyStatus. Should additional processing be necessary to determine with certainty the status of a key, use "status-pending". Once the additional processing for one or more keys has completed, run the Update Key Statuses algorithm again with the actual status(es). 4. If the expiration time for the session changed, run the Update Expiration algorithm on the session, providing the new expiration time. 5. If a message needs to be sent to the server, execute the following steps: 1. Let message be that message. 2. Let message type be the appropriate MediaKeyMessageType for the message. 7. If any of the preceding steps failed, reject promise with a new DOMException whose name is the appropriate error name. 8. If message is not null, run the Queue a "message" Event algorithm on the session, providing message type and message. 9. Resolve promise. 7. Return promise. | |||
| org.hbbtv_EME0070 | 1 | Clear Key: HTML5 transition from encrypted DASH HEAAC/AVC_HD_25 to preloaded unencrypted MP4 with HEAAC/AVC_HD_25 media in less than 250ms | When a currently playing HTMLMediaElement referencing DASH content with HEAAC/AVC_HD_25 media encrypted with Clear Key is paused and play is called on a preloaded HTMLMediaElement referencing MP4 content with unencrypted 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-1 2023-3 2023-2 2023-1 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 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 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 [...] 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 A.3.11: The W3C encrypted media extensions API [66] shall be supported for encrypted content delivered via broadband as defined in clause B.3 of the present document. Use of this API with a DRM system is outside the scope of the present document. HBBTV,section B.3: The “Clear Key” key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). 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 [...] EME,section 9: 9. Common Key Systems All user agents MUST support the common key systems described in this section. ... 9.1 Clear Key The "org.w3.clearkey" Key System uses plain-text clear (unencrypted) key(s) to decrypt the source. No additional client-side content protection is required. This Key System is described below. | ||
| org.hbbtv_EME0080 | 1 | Clear Key: HTML5 transition from MP4 with HEAAC/AVC_HD_25 to paused encrypted DASH HEAAC/AVC_HD_25 media | Content is presented without artefacts or glitches when a currently playing HTMLMediaElement referencing DASH content with Clear Key encrypted HEAAC/AVC_HD_25 media is paused and a preloaded HTMLMediaElement referencing MP4 content with HEAAC/AVC_HD_25 media is played to completion, and then play is then called on the first HTMLMediaElement. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 in the playing state together with at least two HTML5 media elements in a paused state [...] HBBTV,section A.3.11: The W3C encrypted media extensions API [66] shall be supported for encrypted content delivered via broadband as defined in clause B.3 of the present document. Use of this API with a DRM system is outside the scope of the present document. HBBTV,section B.3: The “Clear Key” key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). 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 [...] EME,section 9: 9. Common Key Systems All user agents MUST support the common key systems described in this section. ... 9.1 Clear Key The "org.w3.clearkey" Key System uses plain-text clear (unencrypted) key(s) to decrypt the source. No additional client-side content protection is required. This Key System is described below. | |||
| org.hbbtv_EME0090 | 1 | Clear key: HTML5 pre-roll advert insertion, unencrypted DASH HEAAC/AVC_HD_25 to preloaded Clear Key encrypted DASH HEAAC/AVC_HD_25 | Content is presented without artefacts or glitches when a DASH stream with unencrypted HEAAC/AVC_HD_25 media is played in its entirety and then an HTML5 media element, for which the readyState attribute has reached HAVE_FUTURE_DATA or greater, referencing DASH with Clear Key encrypted HEAAC/AVC_HD_25 media is played. | 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 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, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. [...] HBBTV,section A.3.11: The W3C encrypted media extensions API [66] shall be supported for encrypted content delivered via broadband as defined in clause B.3 of the present document. Use of this API with a DRM system is outside the scope of the present document. HBBTV,section B.3: The “Clear Key” key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). 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 [...] EME,section 9: 9. Common Key Systems All user agents MUST support the common key systems described in this section. ... 9.1 Clear Key The "org.w3.clearkey" Key System uses plain-text clear (unencrypted) key(s) to decrypt the source. No additional client-side content protection is required. This Key System is described below. | |||
| org.hbbtv_GAPFILLING0010 | 1 | Channel changing using P+ with broadcast-related app presenting broadband-delivered video | When a broadcast-related application is presenting broadband-delivered content and the P+ key is pressed, the terminal changes to the next channel in the channel list relative to the one whose application signalling is controlling the lifecycle of the broadcast-related application. | 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 6.2.2.2: The channel change mechanisms offered by the terminal (e.g. P+/P- keys, number keys) shall remain functional at all times while broadcast related applications are running, regardless of whether media is being presented and whether that originates from broadcast or broadband. HBBTV,section 10.2.2.1: Implementations shall provide a mechanism for the end user to generate key events as defined in Table 12 .. 2 program selection buttons (e.g. P+ and P-), Not available to applications, Optional | +CHANNEL_CHANGE_BY_P_PLUS | ||
| org.hbbtv_GAPFILLING0020 | 1 | Channel changing using number keys with broadcast-related app presenting broadband-delivered video | A broadcast-related application is presenting broadband-delivered content and does not have number keys in its keyset. When a channel is selected using the number keys, the terminal changes to that channel. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-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 6.2.2.2: The channel change mechanisms offered by the terminal (e.g. P+/P- keys, number keys) shall remain functional at all times while broadcast related applications are running, regardless of whether media is being presented and whether that originates from broadcast or broadband. | +CHANNEL_CHANGE_BY_NUMBER | ||
| org.hbbtv_GAPFILLING0030 | 1 | Presentation of broadcast video stops when broadcast-independent application is started | A broadcast-related application is running and displayed simultaneously with broadcast video. When the application successfully starts a broadcast-independent application, the presentation of the broadcast video is stopped. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-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.1: 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. The new application shall not have access to broadcast resources. When a broadcast service ceases to be selected, the terminal shall stop the presentation of any component of that broadcast service. When a broadcast-independent application is running, the terminal shall not present components of a broadcast service. | |||
| org.hbbtv_GAPFILLING0040 | 1 | service_bound_flag from broadcast signalling for application originally started as broadcast-independent | An application originally launched as broadcast-independent successfully transitions to become broadcast-related in a service where it is signalled in the broadcast AIT with the service_bound_flag set to 1. The application changes to another service where it is signalled as PRESENT with the same transport protocol. The application is killed as required by the broadcast AIT of the first service. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 6.2.2.6.1: 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. and hence the broadcast signalling in the successfully selected service shall be obeyed thereafter . HBBTV,section 7.2.3.2: The semantics of the fields and elements in the XML AIT file shall be as defined in Table 7. .. applicationDescriptor/ serviceBound Shall be false. Values other than false are outside the scope of the present document. HBBTV,section 6.2.2.2: Was it signalled a service bound on the previous service ... Yes ... Kill currently running application | ||
| org.hbbtv_GAPFILLING0060 | 1 | HTML5 mid-roll advert insertion with 3 video elements, DASH HEAAC/AVC_HD_25, DASH 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 DASH 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-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 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. The terminal shall support each of the following scenarios; • all three HTML5 media elements refer to DASH content • all three HTML5 media elements refer to ISOBMFF content • two of the three HTML5 media elements refer to DASH content and one refers to ISOBMFF content • two of the three HTML5 media elements refer to ISOBMFF content and one refers to DASH content | |||
| org.hbbtv_GAPFILLING0070 | 1 | HTML5 mid-roll advert insertion with 3 video elements, MP4 HEAAC/AVC_HD_25, MP4 HEAAC/AVC_HD_25, MP4 HEAAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing MP4 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 MP4 with HEAAC/AVC_HD_25 media is played. | 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 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. The terminal shall support each of the following scenarios; • all three HTML5 media elements refer to DASH content • all three HTML5 media elements refer to ISOBMFF content • two of the three HTML5 media elements refer to DASH content and one refers to ISOBMFF content • two of the three HTML5 media elements refer to ISOBMFF content and one refers to DASH content | |||
| org.hbbtv_GAPFILLING0080 | 1 | Buffering broadband video while playing broadcast | An application presents broadcast video using a video/broadcast object. The application creates an HTML5 video element with the src attribute referring to some content and calls the load method. The content starts to be loaded. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 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 9.6.2: Buffering of video in an HTML5 media element shall be possible while broadcast video is presented in a video broadcast object or by the terminal. | ||
| org.hbbtv_GAPFILLING0090 | 1 | Graphics co-ordinate system seen by application is always 1280x720 | An application presents graphics at 1280x720. These cover the full graphics area of the terminal. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HbbTV® application graphic plane resolution 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. The terminal shall have at least this graphics resolution. The graphics plane may have a higher resolution but the co-ordinate system as seen by applications shall always be 1 280 x 720. Note: this allows for higher resolution rendering of application text and images but limits the granularity with which an application can position graphics. Clause A.3.9 describes APIs that allow applications to exploit the available resolution. HBBTV,section 10.2.1: Hybrid Broadcast Broadband TV application graphic plane resolution 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. The terminal shall have at least this graphics resolution. The graphics plane may have a higher resolution but the co-ordinate system as seen by applications shall always be 1 280 x 720. Note: this allows for higher resolution rendering of application text and images but limits the granularity with which an application can position graphics. | |||
| org.hbbtv_GAPFILLING0100 | 1 | Data stored through web storage API persists across power outage | When an application stores some data using the Web Storage API and the terminal is turned off and on again the data is still available to the application | 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 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.1: Cookie support: Cookies with an expiry date shall be stored in persistent memory. Terminals shall respect the expiry date of the cookie. [...] HBBTV,section 10.2.1: Web Storage: The data stored through the Web Storage API shall be stored in persistent memory. The present document is intentionally silent about the amount of storage available through the Web Storage API. | ||
| org.hbbtv_GAPFILLING0210 | 1 | Video via HTTP in page delivered via HTTPS - HTML5 video element | An application loaded via HTTPS requests playback of video using the HTML5 video element where the video is non-adaptive streaming and delivered by HTTP (not HTTPS). The playback succeeds. | 2024-1 2023-3 2023-2 2023-1 2022-3 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,section A.3.13: An HbbTV terminal that implements the Mixed Content specification [i.18] shall not consider video or audio loaded via <video> or <audio> elements or the A/V control object as blockable content for the purposes of protecting against mixed content. | |||
| org.hbbtv_GAPFILLING0220 | 1 | DASH MPD via HTTP in page delivered via HTTPS - HTML5 video element | An application loaded via HTTPS requests playback of video using the HTML5 video element where the video is DASH with both the MPD and the content delivered using HTTP (not HTTPS). The playback succeeds. | 2024-1 2023-3 2023-2 2023-1 2022-3 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,section A.3.13: An HbbTV terminal that implements the Mixed Content specification [i.18] shall not consider video or audio loaded via <video> or <audio> elements or the A/V control object as blockable content for the purposes of protecting against mixed content. | |||
| org.hbbtv_GAPFILLING0500 | 1 | Additional tables on object carousel PID - general | A service includes an autostart application launched from an object carousel. The elementary stream(s) carrying the object carousel sections also carry data using a number of other table_ids (e.g. 0x3e, 0x7d, 0xfe). When the service is selected, the autostart application is successfully launched from the carousel. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: The elementary streams used to carry DSM-CC object carousel sections may additionally carry information using other table_ids. When acquiring and monitoring for DSM-CC object carousel sections, terminals shall silently ignore table_ids not supported for carriage of DSM-CC object carousel information. NOTE: The present document only requires support for table_id 0x3b, 0x3c or 0x3d as defined in ISO/IEC 13818-6 [i.12]. HBBTV,section 7.2.2: The elementary streams used to carry DSM-CC object carousel sections may additionally carry information using other table_ids. When acquiring and monitoring for DSM-CC object carousel sections, terminals shall silently ignore table_ids not supported for carriage of DSM-CC object carousel information. NOTE: The present document only requires support for table_id 0x3b, 0x3c or 0x3d as defined in ISO/IEC 13818-6. ISO/IEC-13818-6,section 9.2.2.1: table_id DSMCC Section Type ....................................... 0x3E DSM-CC Sections containing private data EN-300-468,section 5.1.3: Table 2 lists the values which shall be used for table_id for the service information, defined in the present document. .... 0x7B to 0x7D reserved for future use ..... 0x80 to 0xFE user defined | |||
| org.hbbtv_GAPFILLING0510 | 1 | Additional tables on object carousel PID - 0x7b | A service includes an autostart application launched from an object carousel. The elementary stream(s) carrying the object carousel sections also carry data using a number of other table_ids (e.g. 0x7b). When the service is selected, the autostart application is successfully launched from the carousel. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: The elementary streams used to carry DSM-CC object carousel sections may additionally carry information using other table_ids. When acquiring and monitoring for DSM-CC object carousel sections, terminals shall silently ignore table_ids not supported for carriage of DSM-CC object carousel information. NOTE: The present document only requires support for table_id 0x3b, 0x3c or 0x3d as defined in ISO/IEC 13818-6 [i.12]. HBBTV,section 7.2.2: The elementary streams used to carry DSM-CC object carousel sections may additionally carry information using other table_ids. When acquiring and monitoring for DSM-CC object carousel sections, terminals shall silently ignore table_ids not supported for carriage of DSM-CC object carousel information. NOTE: The present document only requires support for table_id 0x3b, 0x3c or 0x3d as defined in ISO/IEC 13818-6. | -DVBMITM | ||
| org.hbbtv_GAPFILLING0520 | 1 | Additional tables on AIT PID - general | The elementary stream that carries the AIT for a service also carries data using a number of other table_ids (e.g. 0x3e, 0x7d, 0xfe). An autostart application signalled in the AIT is successfully started when the service is selected. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: Elementary streams that are used to carry an application information table may additionally carry information using other table_ids. When acquiring and monitoring for AIT elementary streams, terminals shall silently ignore table_ids not supported for carriage of AIT information. HBBTV,section 7.2.3.1: Elementary streams that are used to carry an application information table may additionally carry information using other table_ids. When acquiring and monitoring for AIT elementary streams, terminals shall silently ignore table_ids not supported for carriage of AIT information. NOTE: The present document only requires support for table_id 0x74 as defined in TS 102 809. TS-102-809,section 5.3.4.6: table_id: This 8 bit integer with value 0x74 identifies this table. ISO/IEC-13818-6,section 9.2.2.1: table_id DSMCC Section Type ....................................... 0x3E DSM-CC Sections containing private data EN-300-468,section 5.1.3: Table 2 lists the values which shall be used for table_id for the service information, defined in the present document. .... 0x7B to 0x7D reserved for future use ..... 0x80 to 0xFE user defined | |||
| org.hbbtv_GAPFILLING0530 | 1 | Additional tables on AIT PID - 0x7b | The elementary stream that carries the AIT for a service also carries data using a number of other table_ids (e.g. 0x7b). An autostart application signalled in the AIT is successfully started when the service is selected. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: Elementary streams that are used to carry an application information table may additionally carry information using other table_ids. When acquiring and monitoring for AIT elementary streams, terminals shall silently ignore table_ids not supported for carriage of AIT information. HBBTV,section 7.2.3.1: Elementary streams that are used to carry an application information table may additionally carry information using other table_ids. When acquiring and monitoring for AIT elementary streams, terminals shall silently ignore table_ids not supported for carriage of AIT information. NOTE: The present document only requires support for table_id 0x74 as defined in TS 102 809. TS-102-809,section 5.3.4.6: table_id: This 8 bit integer with value 0x74 identifies this table. | -DVBMITM | ||
| org.hbbtv_GAPFILLING0600 | 1 | Subtitles disabled by terminal UI | An application reads the subtitlesEnabled property and it returns false. The application plays some broadband video including subtitles and uses the component selection API to attempt to display the subtitles. The subtitles are not displayed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: A.2.20.1 Extensions to Represent Subtitle Presentation This class shall be extended with the following additional property. readonly Boolean subtitlesEnabled Shall be set to false if subtitles are disabled by the terminal and applications cannot enable subtitles using the component selection API of the supported media objects i.e. A/V Control object, video/broadcast object and HTML5 media elements. Otherwise shall be set to true. | |||
| org.hbbtv_GAPFILLING0610 | 1 | Subtitles enabled by terminal UI | An application reads the subtitlesEnabled property and it returns true. The application plays some broadband video including subtitles and uses the component selection API to attempt to display the subtitles. The subtitles are displayed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: A.2.20.1 Extensions to Represent Subtitle Presentation This class shall be extended with the following additional property. readonly Boolean subtitlesEnabled Shall be set to false if subtitles are disabled by the terminal and applications cannot enable subtitles using the component selection API of the supported media objects i.e. A/V Control object, video/broadcast object and HTML5 media elements. Otherwise shall be set to true. | |||
| org.hbbtv_GAPFILLING0900 | 1 | Event not available to applications - TEXT | A service contains a broadcast-related autostart application and a digital teletext application. While the broadcast-related autostart application is running, the mechanism to start a digital teletext application is activated (e.g. the TEXT button is pressed) and no other buttons are pressed. The autostart application does not receive any key events before it is killed. | 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,section 10.2.2.1: TEXT or TXT or comparable button Not available to applications mandatory HBBTV,section 6.2.2.3: Terminals shall include a mechanism to start and stop digital teletext applications, for example, the TEXT key on an RCU could be used to start the digital teletext application (which would require any other running application to be killed); pressing the TEXT key again causes the running application to be stopped as long as it is signalled as a digital teletext application. Digital teletext applications are identified with an application_usage_descriptor in the AIT with usage_type equal to 1. NOTE 54: The digital teletext application is intended to be distinct from the autostart application(s) in the AIT. Care is needed if a teletext application is started by means other than the TEXT key. | |||
| org.hbbtv_GAPFILLING0910 | 1 | Event not available to applications - P+ | A running broadcast-related application is bound to the currently selected channel/service. It is not signalled as service-bound. It is signalled as either present or autostart in the next channel in the channel list. The P+ key is pressed (and no other). The channel changes to the next channel in the channel list. The application continues to run. No key event is received. | 2024-1 2023-3 2023-2 2023-1 2022-3 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,section 10.2.2.1: 2 program selection buttons (e.g. P+ and P-) Not available to applications Optional HBBTV,section 5.2: Table 2 lists the buttons or key events which are relevant for the end user when using interactive applications. Requirements on implementations are found in Table 12 in clause 10.2.2. ... 2 program selection buttons (e.g. P+ and P-) If available: selects the next or previous broadcast service in the internal channel list which may lead to the termination of the running application as described in clause 6. These functions remain active at all times while broadcast-related applications are running – see clause 6.2.2.2. HBBTV,section 5.2: Table 2 lists the buttons or key events which are relevant for the end user when using interactive applications. Requirements on implementations are found in table 12 in clause 10.2.2. .... 2 program selection buttons (e.g. P+ and P-) If available: selects the next or previous broadcast service in the internal channel list which may lead to the termination of the running application as described in clause 6 HBBTV,section 10.2.2.1: 2 program selection buttons (e.g. P+ and P-) Not available to applications Optional | +CHANNEL_CHANGE_BY_P_PLUS | ||
| org.hbbtv_GAPFILLING0920 | 1 | Event not available to applications - P- | A running broadcast-related application is bound to the currently selected channel/service. It is not signalled as service-bound. It is signalled as either present or autostart in the previous channel in the channel list. The P- key is pressed (and no other). The channel changes to the previous channel in the channel list. The application continues to run. No key event is received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 2021-3 2021-2 2020-3 2020-2 2020-1 2019-3 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,section 10.2.2.1: 2 program selection buttons (e.g. P+ and P-) Not available to applications Optional HBBTV,section 5.2: Table 2 lists the buttons or key events which are relevant for the end user when using interactive applications. Requirements on implementations are found in Table 12 in clause 10.2.2. ... 2 program selection buttons (e.g. P+ and P-) If available: selects the next or previous broadcast service in the internal channel list which may lead to the termination of the running application as described in clause 6. These functions remain active at all times while broadcast-related applications are running – see clause 6.2.2.2. HBBTV,section 5.2: Table 2 lists the buttons or key events which are relevant for the end user when using interactive applications. Requirements on implementations are found in table 12 in clause 10.2.2. .... 2 program selection buttons (e.g. P+ and P-) If available: selects the next or previous broadcast service in the internal channel list which may lead to the termination of the running application as described in clause 6 HBBTV,section 10.2.2.1: 2 program selection buttons (e.g. P+ and P-) Not available to applications Optional | +CHANNEL_CHANGE_BY_P_PLUS | |
| org.hbbtv_GAPFILLING1110 | 1 | Channel.idType for DVB-S channel | An application obtains an instance of the Channel class for a channel carried on DVB-S and reads the idType property. The value is ID_DVB_S. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: Channel class 7.13.11 M(*) The following properties shall be supported: - channelType - ccid - dsd - idType OIPF-DAE,section 7.13.11.1: ID_DVB_S 11 Used in the idType property to indicate a DVB-S channel identified by the three properties: ‘onid’, ‘tsid’, ‘sid’. OIPF-DAE,section 7.13.11.2: readonly Integer idType The type of identification for the channel, as indicated by one of the ID_* constants defined above | +DVB_S | ||
| org.hbbtv_GAPFILLING1120 | 1 | Channel.idType for DVB-T channel | An application obtains an instance of the Channel class for a channel carried on DVB-T and reads the idType property. The value is ID_DVB_T. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: Channel class 7.13.11 M(*) The following properties shall be supported: - channelType - ccid - dsd - idType OIPF-DAE,section 7.13.11.1: ID_DVB_T 12 Used in the idType property to indicate a DVB-T channel identified by the three properties: ‘onid’, ‘tsid’, ‘sid’.. OIPF-DAE,section 7.13.11.2: readonly Integer idType The type of identification for the channel, as indicated by one of the ID_* constants defined above | +DVB_T | ||
| org.hbbtv_GAPFILLING1140 | 1 | Channel.idType for DVB-S2 channel | An application obtains an instance of the Channel class for a channel carried on DVB-S2 and reads the idType property. The value is ID_DVB_S2. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: Channel class 7.13.11 M(*) The following properties shall be supported: - channelType - ccid - dsd - idType OIPF-DAE,section 7.13.11.1: ID_DVB_S2 15 Used in the idType property to indicate a DVB-S or DVB-S2 channel identified by the three properties: ‘onid’, ‘tsid’, ‘sid’. OIPF-DAE,section 7.13.11.2: readonly Integer idType The type of identification for the channel, as indicated by one of the ID_* constants defined above | +DVB_S2 | ||
| org.hbbtv_GAPFILLING1150 | 1 | Channel.idType for DVB-T2 channel | An application obtains an instance of the Channel class for a channel carried on DVB-T2 and reads the idType property. The value is ID_DVB_T2. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: Channel class 7.13.11 M(*) The following properties shall be supported: - channelType - ccid - dsd - idType OIPF-DAE,section 7.13.11.1: ID_DVB_T2 16 Used in the idType property to indicate a DVB-T or DVB-T2 channel identified by the three properties: ‘onid’, ‘tsid’, ‘sid’. OIPF-DAE,section 7.13.11.2: readonly Integer idType The type of identification for the channel, as indicated by one of the ID_* constants defined above | +DVB_T2 | ||
| org.hbbtv_GAPFILLING1420 | 1 | Tuning to channel not listed in SDT actual - DVB-T | An HbbTV terminal is able to receive a DVB-T multiplex with a number of MPEG programs where some but not all are listed in the SDT actual. A broadcast-related application on a regular channel populates a DVB-SI delivery system descriptor with the values for this multiplex and then creates a locally defined Channel object for one of the MPEG programs not listed in the SDT actual. The application selects the locally defined channel and the video and audio are presented. The application keeps running. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 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.2.4.4: The definitions of the createChannelObject(Integer idType, String dsd, Integer sid) method on the video/broadcast object, and the dsd attribute on the returned Channel object, both refer to the “delivery system descriptor”. This “delivery system descriptor” shall be as follows: For a DVB-T channel, the “delivery system descriptor” shall be a terrestrial_delivery_system_descriptor. For a DVB-T2 channel, the “delivery system descriptor” shall be a T2_delivery_system_descriptor which shall include at least one centre_frequency field. For a DVB-S channel, the “delivery system descriptor” shall be a satellite_delivery_system_descriptor. For a DVB-S2 channel the “delivery system descriptor” shall be either a satellite_delivery_system_descriptor, or the concatenation of an S2_satellite_delivery_system_descriptor and a satellite_delivery_system_descriptor, in that order. For a DVB-S2X channel, the “delivery system descriptor” shall be an S2X_satellite_delivery_system_descriptor. For a DVB-C channel, the “delivery system descriptor” shall be a cable_delivery_system_descriptor. For a DVB-C2 channel that does not use channel bundling, the “delivery system descriptor” shall be a C2_delivery_system_descriptor. For a DVB-C2 channel that uses channel bundling, the “delivery system descriptor” shall be the concatenation of one or more C2_bundle_delivery_system_descriptor. The descriptors referred to above are all defined in clause 6.2.13 and clause 6.4.5 of EN 300 468 [165]. HBBTV,section A.2.4.4: The definitions of the createChannelObject(Integer idType, String dsd, Integer sid) method on the video/broadcast object, and the dsd attribute on the returned Channel object, both refer to the “delivery system descriptor”. This “delivery system descriptor” shall be as follows: For a DVB-T channel, the “delivery system descriptor” shall be a terrestrial_delivery_system_descriptor. For a DVB-T2 channel, the “delivery system descriptor” shall be a T2_delivery_system_descriptor which shall include at least one centre_frequency field. For a DVB-S channel, the “delivery system descriptor” shall be a satellite_delivery_system_descriptor. For a DVB-S2 channel that is in NBC-BS mode (as that term is used in [16]), the “delivery system descriptor” shall be a satellite_delivery_system_descriptor. For a DVB-S2 channel that is not in NBC-BS mode, the “delivery system descriptor” shall be the concatenation of a S2_satellite_delivery_system_descriptor and a satellite_delivery_system_descriptor, in that order. For a DVB-C channel, the “delivery system descriptor” shall be a cable_delivery_system_descriptor. For a DVB-C2 channel that does not use channel bundling, the “delivery system descriptor” shall be a C2_delivery_system_descriptor. For a DVB-C2 channel that uses channel bundling, the “delivery system descriptor” shall be the concatenation of one or more C2_bundle_delivery_system_descriptor. The descriptors referred to above are all defined in EN 300 468 [16]. OIPF-DAE,section 7.13.1.3: Channel createChannelObject( Integer idType, String dsd, Integer sid ) Description Creates a Channel object of the specified idType. This method is typically used to create a Channel object of type ID_DVB_SI_DIRECT. The Channel object can subsequently be used by the setChannel() method to switch a tuner to this channel, which may or may not be part of the channel list in the OITF. The resulting Channel object represents a locally defined channel which, if not already present there, does not get added to the channel list accessed through the ChannelConfig class (see section 7.13.9). Valid value for idType include: ID_DVB_SI_DIRECT. For other values this behaviour is not specified. If the channel of the given type cannot be created or the delivery system descriptor is not valid, the method SHALL return null. If the channel of the given type can be created and the delivery system descriptor is valid, the method SHALL return a Channel object whereby at a minimum the properties with the same names (i.e. idType, dsd and sid) are given the same value as argument idType, dsd and sid of the createChannelObject method. Arguments idType The type of channel, as indicated by one of the ID_* constants defined in section 7.13.11.1. Valid values for idType include: ID_DVB_SI_DIRECT. For other values this behaviour is not specified. dsd The delivery system descriptor (tuning parameters) represented as a string whose characters shall be restricted to the ISO Latin-1 character set. Each character in the dsd represents a byte of a delivery system descriptor as defined by DVB-SI [EN 300 468] section 6.2.13, such that a byte at position "i" in the delivery system descriptor is equal the Latin-1 character code of the character at position "i" in the dsd. sid The service ID, which must be within the range of 1 to 65535. OIPF-DAE,section 7.13.1.3: Channel createChannelObject( Integer idType, String dsd, Integer sid ) Description Creates a Channel object of the specified idType. This method is typically used to create a Channel object of type ID_DVB_SI_DIRECT. The Channel object can subsequently be used by the setChannel() method to switch a tuner to this channel, which may or may not be part of the channel list in the OITF. The resulting Channel object represents a locally defined channel which, if not already present there, does not get added to the channel list accessed through the ChannelConfig class (see 7.13.9). Valid value for idType include: ID_DVB_SI_DIRECT. For other values this behaviour is not specified. If the channel of the given type cannot be created or the delivery system descriptor is not valid, the method SHALL return null. If the channel of the given type can be created and the delivery system descriptor is valid, the method SHALL return a Channel object whereby at a minimum the properties with the same names (i.e. idType, dsd and sid) are given the same value as argument idType, dsd and sid of the createChannelObject method. Arguments idType The type of channel, as indicated by one of the ID_* constants defined in section 7.13.11.1. Valid value for idType include: ID_DVB_SI_DIRECT. For other values this behaviour is not specified. dsd The delivery system descriptor (tuning parameters) represented as a string whose characters shall be restricted to the ISO Latin-1 character set. Each character in the dsd represents a byte of a delivery system descriptor as defined by DVB-SI [EN300468] section 6.2.13, such that a byte at position "i" in the delivery system descriptor is equal the Latin-1 character code of the character at position "i" in the dsd. sid The service ID, which must be within the range of 1 to 65535. HBBTV,section 6.2.2.2: Figure 13 shall not apply when selecting an MPEG program which is not a broadcast DVB service. If a transport stream does not include an SDT actual then none of the MPEG programs in that stream are broadcast DVB services. If the SDT actual in a transport stream does not include an entry corresponding to a PMT in that transport stream then the MPEG program described by that PMT is not a broadcast DVB service. There is no requirement for a terminal to check again either for an SDT or that a service is listed in the SDT if it has already done so, e.g. in order to acquire the service name when creating the channel list. NOTE 3: If broadcasters or operators change programs in a multiplex from being a broadcast service to a non-broadcast service or vice-versa, they should use new program numbers/service_ids and should not re-use the old program numbers/service_ids. As a consequence of selecting such an MPEG program: - No applications shall be started. - No applications shall be stopped except for broadcast-related applications with service_bound_flag set to '1' which are stopped when leaving the current broadcast service. -The value of the currentChannel property on the video/broadcast object and the ApplicationPrivateData.currentChannel property shall reflect the MPEG program selected. - Figure 13 shall not apply when selecting an MPEG program that is not a broadcast DVB service. HBBTV,section 6.2.2.2: Figure 13 shall not apply when selecting an MPEG program which is not a broadcast DVB service. If a transport stream does not include an SDT actual then none of the MPEG programs in that stream are broadcast DVB services. If the SDT actual in a transport stream does not include an entry corresponding to a PMT in that transport stream then the MPEG program described by that PMT is not a broadcast DVB service. There is no requirement for a terminal to check again either for an SDT or that a service is listed in the SDT if it has already done so, e.g. in order to acquire the service name when creating the channel list. NOTE: If broadcasters or operators change programs in a multiplex from being a broadcast service to a nonbroadcast service or vice-versa, they should use new program numbers/service_ids and should not re-use the old program numbers/service_ids. As a consequence of selecting such an MPEG program: - No applications shall be started. - No applications shall be stopped except for broadcast-related applications with service_bound_flag set to '1' which are stopped when leaving the current broadcast service. -The value of the currentChannel property on the video/broadcast object and the ApplicationPrivateData.currentChannel property shall reflect the MPEG program selected. - Figure 13 shall not apply when selecting an MPEG program that is not a broadcast DVB service. | +DVB_T | |
| org.hbbtv_GAPFILLING1520 | 1 | DSD tune to regular service - DVB-T | A broadcast-related HbbTV application creates a locally defined Channel object for a service in a different DVB-T multiplex specifying the delivery system descriptor and service_id. The application is signalled as PRESENT in that other service. The application selects the other service. The video and audio from the other service are presented and the application keeps running. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 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.4: The definitions of the createChannelObject(Integer idType, String dsd, Integer sid) method on the video/broadcast object, and the dsd attribute on the returned Channel object, both refer to the “delivery system descriptor”. This “delivery system descriptor” shall be as follows: For a DVB-T channel, the “delivery system descriptor” shall be a terrestrial_delivery_system_descriptor. For a DVB-T2 channel, the “delivery system descriptor” shall be a T2_delivery_system_descriptor which shall include at least one centre_frequency field. For a DVB-S channel, the “delivery system descriptor” shall be a satellite_delivery_system_descriptor. For a DVB-S2 channel the “delivery system descriptor” shall be either a satellite_delivery_system_descriptor, or the concatenation of an S2_satellite_delivery_system_descriptor and a satellite_delivery_system_descriptor, in that order. For a DVB-S2X channel, the “delivery system descriptor” shall be an S2X_satellite_delivery_system_descriptor. For a DVB-C channel, the “delivery system descriptor” shall be a cable_delivery_system_descriptor. For a DVB-C2 channel that does not use channel bundling, the “delivery system descriptor” shall be a C2_delivery_system_descriptor. For a DVB-C2 channel that uses channel bundling, the “delivery system descriptor” shall be the concatenation of one or more C2_bundle_delivery_system_descriptor. The descriptors referred to above are all defined in clause 6.2.13 and clause 6.4.5 of EN 300 468 [165]. HBBTV,section A.2.4.4: The definitions of the createChannelObject(Integer idType, String dsd, Integer sid) method on the video/broadcast object, and the dsd attribute on the returned Channel object, both refer to the “delivery system descriptor”. This “delivery system descriptor” shall be as follows: For a DVB-T channel, the “delivery system descriptor” shall be a terrestrial_delivery_system_descriptor. For a DVB-T2 channel, the “delivery system descriptor” shall be a T2_delivery_system_descriptor which shall include at least one centre_frequency field. For a DVB-S channel, the “delivery system descriptor” shall be a satellite_delivery_system_descriptor. For a DVB-S2 channel that is in NBC-BS mode (as that term is used in [16]), the “delivery system descriptor” shall be a satellite_delivery_system_descriptor. For a DVB-S2 channel that is not in NBC-BS mode, the “delivery system descriptor” shall be the concatenation of a S2_satellite_delivery_system_descriptor and a satellite_delivery_system_descriptor, in that order. For a DVB-C channel, the “delivery system descriptor” shall be a cable_delivery_system_descriptor. For a DVB-C2 channel that does not use channel bundling, the “delivery system descriptor” shall be a C2_delivery_system_descriptor. For a DVB-C2 channel that uses channel bundling, the “delivery system descriptor” shall be the concatenation of one or more C2_bundle_delivery_system_descriptor. The descriptors referred to above are all defined in EN 300 468 [16]. OIPF-DAE,section 7.13.1.3: Channel createChannelObject( Integer idType, String dsd, Integer sid ) Description Creates a Channel object of the specified idType. This method is typically used to create a Channel object of type ID_DVB_SI_DIRECT. The Channel object can subsequently be used by the setChannel() method to switch a tuner to this channel, which may or may not be part of the channel list in the OITF. The resulting Channel object represents a locally defined channel which, if not already present there, does not get added to the channel list accessed through the ChannelConfig class (see section 7.13.9). Valid value for idType include: ID_DVB_SI_DIRECT. For other values this behaviour is not specified. If the channel of the given type cannot be created or the delivery system descriptor is not valid, the method SHALL return null. If the channel of the given type can be created and the delivery system descriptor is valid, the method SHALL return a Channel object whereby at a minimum the properties with the same names (i.e. idType, dsd and sid) are given the same value as argument idType, dsd and sid of the createChannelObject method. Arguments idType The type of channel, as indicated by one of the ID_* constants defined in section 7.13.11.1. Valid values for idType include: ID_DVB_SI_DIRECT. For other values this behaviour is not specified. dsd The delivery system descriptor (tuning parameters) represented as a string whose characters shall be restricted to the ISO Latin-1 character set. Each character in the dsd represents a byte of a delivery system descriptor as defined by DVB-SI [EN 300 468] section 6.2.13, such that a byte at position "i" in the delivery system descriptor is equal the Latin-1 character code of the character at position "i" in the dsd. sid The service ID, which must be within the range of 1 to 65535. OIPF-DAE,section 7.13.1.3: Channel createChannelObject( Integer idType, String dsd, Integer sid ) Description Creates a Channel object of the specified idType. This method is typically used to create a Channel object of type ID_DVB_SI_DIRECT. The Channel object can subsequently be used by the setChannel() method to switch a tuner to this channel, which may or may not be part of the channel list in the OITF. The resulting Channel object represents a locally defined channel which, if not already present there, does not get added to the channel list accessed through the ChannelConfig class (see 7.13.9). Valid value for idType include: ID_DVB_SI_DIRECT. For other values this behaviour is not specified. If the channel of the given type cannot be created or the delivery system descriptor is not valid, the method SHALL return null. If the channel of the given type can be created and the delivery system descriptor is valid, the method SHALL return a Channel object whereby at a minimum the properties with the same names (i.e. idType, dsd and sid) are given the same value as argument idType, dsd and sid of the createChannelObject method. Arguments idType The type of channel, as indicated by one of the ID_* constants defined in section 7.13.11.1. Valid value for idType include: ID_DVB_SI_DIRECT. For other values this behaviour is not specified. dsd The delivery system descriptor (tuning parameters) represented as a string whose characters shall be restricted to the ISO Latin-1 character set. Each character in the dsd represents a byte of a delivery system descriptor as defined by DVB-SI [EN300468] section 6.2.13, such that a byte at position "i" in the delivery system descriptor is equal the Latin-1 character code of the character at position "i" in the dsd. sid The service ID, which must be within the range of 1 to 65535. | +DVB_T | ||
| org.hbbtv_GAPFILLING2810 | 1 | A/V control object presentation from the first to the last frame | An HbbTV application has video/broadcast object in the 'stopped' state and an A/V control object not obscured by graphics. When the application calls to play(1) method of the A/V control object, then the video content is played from the first frame to the last one, the first frames of video are visible, the first samples of audio are audible, the last frames of video are visible, the last samples of audio are audible. | 2024-1 2023-3 2023-2 2023-1 2022-3 2021-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.2.5.7: When video/audio content is presented from the beginning by an A/V control object that is not obscured by graphics, the first frames of video shall be visible and the first samples of audio shall be audible. When video/audio content is presented upto the end by an A/V control object that is not obscured by graphics, the last frames of video shall be visible and the last samples of audio shall be audible. The only occasion when video frames might not be visible is if an application is not fast enough to remove a graphic overlay when video presentation starts or is too quick to add a graphic overlay when video presentation finishes. | |||
| org.hbbtv_GAPFILLING2820 | 1 | HTML5 video element presentation from the first to the last frame | An HbbTV application has video/broadcast object in the 'stopped' state and an HTML5 video element not obscured by graphics. When the application calls to play() method of the video element, then the video content is played from the first frame to the last frame, the first frames of video are visible, the first samples of audio are audible, the last frames of video are visible, the last samples of audio are audible. | 2024-1 2023-3 2023-2 2023-1 2020-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 9.6.10: When video/audio content is presented from the beginning by an HTML5 <video> element that is not obscured by graphics, the first frames of video shall be visible and the first samples of audio shall be audible. When video/audio content is presented upto the end by an HTML5 <video> element that is not obscured by graphics, the last frames of video shall be visible and the last samples of audio shall be audible. The only occasion when video frames might not be visible is if an application is not fast enough to remove a graphic overlay when video presentation starts or is too quick to add a graphic overlay when video presentation finishes. | ||
| org.hbbtv_GAPFILLING2840 | 1 | Single stream event is not dispatched after application re-launching | A broadcast carries a stream event, delivered only at a certain time and no more. An autostart broadcast-related application at the start adds stream event listener. The single stream event appears, and 5 s after that the application is killed by user e.g. by pressing EXIT. When the application is re-launched and the stream event listener is added again with the same targetURL eventName and listener name then in the next 60s the listener is not run. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-2 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 7.2.4: The terminal shall support "do-it-now" events as defined in clause 8 of ETSI TS 102 809 [3]. Support of events synchronized to a DVB timeline as referred to in that document is not included. Broadcasters shall place all "do-it-now" stream descriptors to be monitored simultaneously by an application on a single PID. This may be the same PID as is used for other DSM-CC sections. HBBTV,section 8.2.1.1: void addStreamEventListener(String targetURL, String eventName, EventListener listener) Description ... Listeners are not unregistered when transitioning to the Connecting state due to a transient error that does not result in a change of channel. | |||
| org.hbbtv_GAPFILLING2850 | 1 | Stream events after broadband content being presented after transition to broadcast independent | An autostart broadcast-related application starts in a service that contains stream events. The application registers to receive stream events and these are received correctly. The application then: transitions to broadcast-independent, starts to present MPEG2-TS content over broadband using an A/V control object. When the A/V playback ends, the application transitions back to broadcast-related. Once that succeeds, the application re-subscribes to the stream events and then the correct stream events for that point in the broadcast stream are received. This process is repeated at least 3 times. | 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 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. NOTE: Applications that wish to become broadcast-independent and later transition back to broadcast-related should remember the current channel before transitioning to broadcast-independent. ... 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: HBBTV,section 7.2.4: The terminal shall support "do-it-now" events as defined in clause 8 of ETSI TS 102 809 [3]. Support of events synchronized to a DVB timeline as referred to in that document is not included. Broadcasters shall place all "do-it-now" stream descriptors to be monitored simultaneously by an application on a single PID. This may be the same PID as is used for other DSM-CC sections. HBBTV,section 8.2.1.1: The following additional methods on the video/broadcast object (as defined in the OIPF DAE specification [1]) shall be supported for synchronization to broadcast events as defined in clause 7.2.4. void addStreamEventListener(String targetURL, String eventName, EventListener listener) Description Add a listener for the specified DSM-CC stream event. ... When a broadcaster transmits different events using the same event name id (i.e. with different version numbers), one StreamEvent event shall be dispatched for each different stream event descriptor received. void removeStreamEventListener(String targetURL, String eventName, EventListener listener) Description Remove a stream event listener for the specified stream event name. HBBTV,section 8.2.1.2: interface StreamEvent : Event { readonly attribute String name; readonly attribute String data; readonly attribute String text; readonly attribute DOMString status name The name of the DSM-CC StreamEvent's event. data Data of the DSM-CC StreamEvent's event encoded in hexadecimal. EXAMPLE: "0A10B81033" (for a payload 5 bytes long). text Text data of the DSM-CC StreamEvent's event as a string assuming UTF-8 as the encoding for the DSM-CC StreamEvent's event. Characters that cannot be transcoded are skipped. status Equal to "trigger" when the event is dispatched in response to a trigger in the stream or "error" when an error occurred (e.g. attempting to add a listener for an event that does not exist, or when a StreamEvent object with registered listeners is removed from the carousel). Circumstances under which an event shall be dispatched with an error status include: ... the elementary stream which contains the StreamEvent event descriptor is no longer being monitored | |||
| org.hbbtv_GAPFILLING2870 | 1 | Stream events after broadband content being presented, v/b object in stopped state | An autostart broadcast-related application starts in a service that contains stream events. The application registers to receive stream events and these are received correctly. The application then calls stop() on the video broadcast object and presents MP4 content over broadband using an A/V control object. After the broadband content presentation has ended with 'finished' state, the application returns to the broadcast by calling bindToCurrentChannel. The terminal if it had paused monitoring of stream events resumes stream event monitoring. The correct stream events for that point in the broadcast stream are received. This process is repeated at least 3 times. | 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 6.2.2.7: Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular, the following examples shall apply: ... * DSM-CC stream event monitoring shall continue. HBBTV,section 6.2.2.7: Attempting to present broadband delivered video using the AV Control object may result in suspension of access to broadcast resources, including but not limited to: ... * DSM-CC stream event monitoring being paused. ... Suspension of access to broadcast resources shall be treated as a transient error as defined in table 11 - "State transitions for the video/broadcast embedded object" of the OIPF DAE specification [1]. The PlayStateChange Event that is dispatched shall have the error code 11. When playback of broadband delivered video terminates for any reason and no broadband-delivered media item is queued and access to broadcast resources was previously suspended due to the presentation of broadband-delivered video, the following actions shall be taken by the terminal: ... * DSM-CC stream event monitoring shall resume. HBBTV,section 7.2.4: The terminal shall support "do-it-now" events as defined in clause 8 of ETSI TS 102 809 [3]. Support of events synchronized to a DVB timeline as referred to in that document is not included. Broadcasters shall place all "do-it-now" stream descriptors to be monitored simultaneously by an application on a single PID. This may be the same PID as is used for other DSM-CC sections. HBBTV,section 8.2.1.1: The following additional methods on the video/broadcast object (as defined in the OIPF DAE specification [1]) shall be supported for synchronization to broadcast events as defined in clause 7.2.4. void addStreamEventListener(String targetURL, String eventName, EventListener listener) Description Add a listener for the specified DSM-CC stream event. ... When a broadcaster transmits different events using the same event name id (i.e. with different version numbers), one StreamEvent event shall be dispatched for each different stream event descriptor received. void removeStreamEventListener(String targetURL, String eventName, EventListener listener) Description Remove a stream event listener for the specified stream event name. HBBTV,section 8.2.1.2: interface StreamEvent : Event { readonly attribute String name; readonly attribute String data; readonly attribute String text; readonly attribute DOMString status name The name of the DSM-CC StreamEvent's event. data Data of the DSM-CC StreamEvent's event encoded in hexadecimal. EXAMPLE: "0A10B81033" (for a payload 5 bytes long). text Text data of the DSM-CC StreamEvent's event as a string assuming UTF-8 as the encoding for the DSM-CC StreamEvent's event. Characters that cannot be transcoded are skipped. status Equal to "trigger" when the event is dispatched in response to a trigger in the stream or "error" when an error occurred (e.g. attempting to add a listener for an event that does not exist, or when a StreamEvent object with registered listeners is removed from the carousel). Circumstances under which an event shall be dispatched with an error status include: ... the elementary stream which contains the StreamEvent event descriptor is no longer being monitored | |||
| org.hbbtv_GAPFILLING2880 | 1 | Multiple stream events with different names - correctness of transmitting events by event listener | A broadcast-related autostart application starts in a broadcast service that includes stream events with two different event names N1 and N2 and different payloads transmitted on the same PID. The application adds event listener to receive events with name N1 to event listener L1 and then receives the correct events for the name N1 and no others. After that when the application removes the stream event listener from the N1 and adds event listener L2 to receive events with name N2, then receives the correct events corresponding to N2 on the L2 listener and no others. If then re-registers to receive events from the N1 without removing for the second name and receives the correct events for both names, each on the correct listener. | 2024-1 2023-3 2023-2 2023-1 2022-2 2021-3 2021-2 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 7.2.4: The terminal shall support "do-it-now" events as defined in clause 8 of ETSI TS 102 809 [3]. Support of events synchronized to a DVB timeline as referred to in that document is not included. Broadcasters shall place all "do-it-now" stream descriptors to be monitored simultaneously by an application on a single PID. This may be the same PID as is used for other DSM-CC sections. HBBTV,section 8.2.1.1: The following additional methods on the video/broadcast object (as defined in the OIPF DAE specification [1]) shall be supported for synchronization to broadcast events as defined in clause 7.2.4. void addStreamEventListener(String targetURL, String eventName, EventListener listener) Description Add a listener for the specified DSM-CC stream event. ... When a broadcaster transmits different events using the same event name id (i.e. with different version numbers), one StreamEvent event shall be dispatched for each different stream event descriptor received. void removeStreamEventListener(String targetURL, String eventName, EventListener listener) Description Remove a stream event listener for the specified stream event name. HBBTV,section 8.2.1.2: interface StreamEvent : Event { readonly attribute String name; readonly attribute String data; readonly attribute String text; readonly attribute DOMString status name The name of the DSM-CC StreamEvent's event. data Data of the DSM-CC StreamEvent's event encoded in hexadecimal. EXAMPLE: "0A10B81033" (for a payload 5 bytes long). text Text data of the DSM-CC StreamEvent's event as a string assuming UTF-8 as the encoding for the DSM-CC StreamEvent's event. Characters that cannot be transcoded are skipped. status Equal to "trigger" when the event is dispatched in response to a trigger in the stream | |||
| org.hbbtv_GAPFILLING2890 | 1 | Multiple stream events with the same name - correctness of received data | A broadcast-related autostart application registers to receive stream events from the current broadcast service. The broadcast service includes stream events with the same event name, different version numbers, varying payloads including binary data, text data and mixtures. The binary data includes all values from 0 to 255 inclusive, with repetitions and random positions. The text data uses UTF-8 encoding and includes values outside 7-bit ASCII. All stream events are received in the correct order with the correct encoding of data and text property. | 2024-1 2023-3 2023-2 2023-1 2022-3 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.4: The terminal shall support "do-it-now" events as defined in clause 8 of ETSI TS 102 809 [3]. Support of events synchronized to a DVB timeline as referred to in that document is not included. Broadcasters shall place all "do-it-now" stream descriptors to be monitored simultaneously by an application on a single PID. This may be the same PID as is used for other DSM-CC sections. HBBTV,section 8.2.1.1: The following additional methods on the video/broadcast object (as defined in the OIPF DAE specification [1]) shall be supported for synchronization to broadcast events as defined in clause 7.2.4. void addStreamEventListener(String targetURL, String eventName, EventListener listener) Description Add a listener for the specified DSM-CC stream event. ... When a broadcaster transmits different events using the same event name id (i.e. with different version numbers), one StreamEvent event shall be dispatched for each different stream event descriptor received. HBBTV,section 8.2.1.2: interface StreamEvent : Event { readonly attribute String name; readonly attribute String data; readonly attribute String text; readonly attribute DOMString status name The name of the DSM-CC StreamEvent's event. data Data of the DSM-CC StreamEvent's event encoded in hexadecimal. EXAMPLE: "0A10B81033" (for a payload 5 bytes long). text Text data of the DSM-CC StreamEvent's event as a string assuming UTF-8 as the encoding for the DSM-CC StreamEvent's event. If the data of the event is not valid UTF-8 then then the value of this property is implementation specific. status Equal to "trigger" when the event is dispatched in response to a trigger in the stream | |||
| org.hbbtv_GAPFILLING2910 | 1 | Multiple stream events with the same name - order reliability | A broadcast-related autostart application registers to receive stream events from the current broadcast service. The broadcast service includes 100 stream events distributed at varying intervals over 5 minutes with the same event name id, varying payloads, different version numbers. All stream events are received in the correct order. | 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.2.4: The terminal shall support "do-it-now" events as defined in clause 8 of ETSI TS 102 809 [3]. Support of events synchronized to a DVB timeline as referred to in that document is not included. Broadcasters shall place all "do-it-now" stream descriptors to be monitored simultaneously by an application on a single PID. This may be the same PID as is used for other DSM-CC sections. HBBTV,section 8.2.1.1: The following additional methods on the video/broadcast object (as defined in the OIPF DAE specification [1]) shall be supported for synchronization to broadcast events as defined in clause 7.2.4. void addStreamEventListener(String targetURL, String eventName, EventListener listener) Description Add a listener for the specified DSM-CC stream event. ... When a broadcaster transmits different events using the same event name id (i.e. with different version numbers), one StreamEvent event shall be dispatched for each different stream event descriptor received. | |||
| org.hbbtv_GAPFILLING2920 | 1 | HTML5 audio element presenting ISOBMFF mp4, return to broadcast | A broadcast service includes AVC HD video + HEAAC audio + broadcast subtitles. A broadcast related HbbTV application has a video/broadcast object covering whole screen (fullScreen equal to false) presenting broadcast content, an HTML5 audio element, visibility:hidden, src referring to ISOBMFF mp4 HEAAC (audio only) in readyState bigger than HAVE_CURRENT_DATA. The application moves video/broadcast to stopped state and sets CSS visibility to hidden. Next, the application sets the audio element CSS visibility to visible, and starts playback. Before playout reaches the end of media, the application removes the audio element from the DOM tree, and moves the video/broadcast to presenting state and sets its CSS visibilty back to visible. After that, the video/broadcast presents broadcast video, audio and subtitles. | 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 9.6.2: Hardware resources shall also be released if the HTML5 media element is removed from the DOM and no other references to it exist HBBTV,section A.1: video/broadcast embedded object 7.13.1 M(*) | |||
| org.hbbtv_GAPFILLING2930 | 1 | HTML5 video element presenting ISOBMFF mp4, return to broadcast | A broadcast service includes MPEG-2 SD video + MPEG-1 layer 2 audio + broadcast subtitles. A broadcast related HbbTV application has a video/broadcast object covering whole screen (fullScreen equal to false) presenting broadcast content, an HTML5 video element with size 1/4x1/4 of screen size, visibility:hidden, src referring to ISOBMFF mp4 in readyState bigger than HAVE_CURRENT_DATA. The application moves video/broadcast to stopped state and sets CSS visibility to hidden. Next, the application sets the video element CSS visibility to visible, and starts playback. Before playout reaches the end of media, the application removes the video element from the DOM tree, and moves the video/broadcast to presenting state and sets its CSS visibility back to visible. After that, the video/broadcast presents broadcast video, audio and subtitles. | 2024-1 2023-3 2023-2 2023-1 2022-3 2021-3 2020-3 2020-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 9.6.2: Hardware resources shall also be released if the HTML5 media element is removed from the DOM and no other references to it exist HBBTV,section A.1: video/broadcast embedded object 7.13.1 M(*) | ||
| org.hbbtv_GAPFILLING2940 | 1 | HTML5 video element presenting DASH, return to broadcast | A broadcast service has AVC HD video + HEAAC audio + broadcast subtitles. A broadcast related HbbTV application has a video/broadcast object with full screen mode presenting broadcast content, an HTML5 video element covering whole screen, behind the video/broadcast object (on z-axis). The application moves video/broadcast to stopped state, sets CSS to move the video/broadcast behind the video element (on z-axis) and starts playback of static MPEG DASH using the video element. When the playout reaches end of media (ended event), the application removes the video element from the DOM tree, moves the video/broadcast to presenting state. After that, the video/broadcast presents broadcast video, audio and subtitles. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-3 2020-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.2: Hardware resources shall also be released if the HTML5 media element is removed from the DOM and no other references to it exist HBBTV,section A.1: video/broadcast embedded object 7.13.1 M(*) | |||
| org.hbbtv_GAPFILLING2950 | 1 | A/V control object presenting DASH, return to broadcast | A broadcast service has AVC HD video + HEAAC audio + broadcast subtitles. A broadcast related HbbTV application has a video/broadcast object in full screen mode, an A/V control object with data attribute referring to a static MPEG-DASH MPD. The video/broadcast is in the stopped state, hidden, and the A/V control plays content. When the playout ends with playState 'finished', the application hides A/V control object and calls to 'bindToCurrentChannel' of the video/broadcast. After that, at the same time: the video/broadcast object enters the presenting state(2), the presentation appears on video/broadcast screen area and the audio is rendered. | 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 A.1: video/broadcast embedded object 7.13.1 M(*) OIPF-DAE,section 7.13.1.2: Old State Connecting Trigger The terminal successfully connected to the broadcast or IP multicast stream and presented its contents. New State Presenting ... Old State Stopped Trigger bindToCurrentChannel() New State Connecting OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object SHALL be released when state 6 (‘error’) or 0 (‘stopped’) or 5 (‘finished’) are reached | |||
| org.hbbtv_GAPFILLING2960 | 1 | video/broadcast presentation and receiving play state presenting (after stopped) are at the same time | A broadcast service has AVC HD video + EAC-3 audio + broadcast subtitles. A broadcast related HbbTV application has a video/broadcast object with full screen mode presenting broadcast content, an A/V control object with full screen mode, behind the video/broadcast object (on z-axis). The application moves video/broadcast to stopped state, sets CSS to move the video/broadcast behind A/V control object (on z-axis) and starts playback of static MPEG DASH using the A/V control object. When the playout reaches end of media (state finished), the application moves video/broadcast to presenting state and sets CSS to move the video/broadcast behind the A/V control object. After that, the video/broadcast presents broadcast video, audio and subtitles and the playState event on the video/broadcast object is received at the application when broadcast video gets visible and audio gets audible and not earlier or later than that. | 2024-1 2023-3 2023-2 2023-1 2022-3 2020-3 2020-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.1: video/broadcast embedded object 7.13.1 M(*) The A/V Control object 7.14.1 M(*) OIPF-DAE,section 7.13.1.2: Old State Connecting Trigger The terminal successfully connected to the broadcast or IP multicast stream and presented its contents. New State Presenting ... Old State Stopped Trigger bindToCurrentChannel() New State Connecting OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object SHALL be released when state 6 (‘error’) or 0 (‘stopped’) or 5 (‘finished’) are reached | +EAC3 | ||
| org.hbbtv_GAPFILLING2970 | 1 | video/broadcast presentation and setting stopped state (from presenting) are at the same time | A broadcast service has MPEG-2 SD video + MPEG-1 layer 2 audio + broadcast subtitles. A broadcast related HbbTV application has a video/broadcast object in full screen mode. The video/broadcast is in the presenting state. When the application calls to 'stop', then at the same time: the video/broadcast objects enters the stopped state(3), the video/broadcast screen area become opaque black and the audio become muted. | 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 A.1: video/broadcast embedded object 7.13.1 M(*) OIPF-DAE,section 7.13.1.2: Old State Connecting or Presenting Trigger stop() New State Stopped OIPF-DAE,section 7.13.1.2: readonly Integer playState 0 unrealized; the application has not made a request to start presenting a channel or has stopped presenting a channel and released any resources. The content of the video/broadcast object should be transparent but if not shall be an opaque black rectangle. Control of media presentation is under the control of the OITF, as defined in section H.2. 1 connecting; the terminal is connecting to the media source in order to begin playback. Objects in this state may be buffering data in order to start playback. Control of media presentation is under the control of the application, as defined in section H.2. The content of the video/broadcast object is implementation dependent. 2 presenting; the media is currently being presented to the user. The object is in this state regardless of whether the media is playing at normal speed, paused, or playing in a trick mode (e.g. at a speed other than normal speed). Control of media presentation is under the control of the application, as defined in section H.2. The video/broadcast object contains the video being presented. 3 stopped; the terminal is not presenting media, either inside the video/broadcast object or in the logical video plane. The logical video plane is disabled. The content of the video/broadcast object SHALL be an opaque black rectangle. Control of media presentation is under the control of the application, as defined in section H.2 | |||
| org.hbbtv_GAPFILLING2980 | 1 | video/broadcast presentation and setting playing state (from unrealised) are at the same time | A broadcast service has AVC HD video + HEAAC audio + broadcast subtitles. A broadcast related HbbTV application has a video/broadcast object scaled to 1/2x1/2 of the screen size. The video/broadcast is in undefined state, presentation of service is under terminal control. When the application calls to 'bindToCurrentChannel', then at the same time: the video/broadcast objects enters the presenting state(2), and the presentation of video appears on video/broadcast screen area. | 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 A.1: video/broadcast embedded object 7.13.1 M(*) OIPF-DAE,section 7.13.1.2: Old State Unrealized Trigger bindToCurrentChannel() when at least one channel is currently being presented by the OITF and binding to the necessary resources does not fail New State Presenting OIPF-DAE,section 7.13.1.2: readonly Integer playState 0 unrealized; the application has not made a request to start presenting a channel or has stopped presenting a channel and released any resources. The content of the video/broadcast object should be transparent but if not shall be an opaque black rectangle. Control of media presentation is under the control of the OITF, as defined in section H.2. 1 connecting; the terminal is connecting to the media source in order to begin playback. Objects in this state may be buffering data in order to start playback. Control of media presentation is under the control of the application, as defined in section H.2. The content of the video/broadcast object is implementation dependent. 2 presenting; the media is currently being presented to the user. The object is in this state regardless of whether the media is playing at normal speed, paused, or playing in a trick mode (e.g. at a speed other than normal speed). Control of media presentation is under the control of the application, as defined in section H.2. The video/broadcast object contains the video being presented. 3 stopped; the terminal is not presenting media, either inside the video/broadcast object or in the logical video plane. The logical video plane is disabled. The content of the video/broadcast object SHALL be an opaque black rectangle. Control of media presentation is under the control of the application, as defined in section H.2 | |||
| org.hbbtv_GAPFILLING2990 | 1 | video/broadcast object changes state, no terminal UI | A broadcast-related HbbTV application includes a video broadcast object presenting MPEG-2 SD video + MPEG-1 layer 2 audio + broadcast subtitles (Aspect Ratio 4:3). When the application calls to 'stop', then terminal does not display any UI. When after that application calls to bindToCurrentChannel, then the terminal does not display any UI. | 2024-1 2023-3 2023-2 2023-1 2022-3 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 A.2.4.5: Terminals shall not show any UI (e.g. an indication of video or audio properties or attributes such as “16:9”) when a video broadcast object successfully changes either from the Stopped state to the Connecting state or from the Connecting state to the Presenting state when the previous state change was from Stopped to Connecting. OIPF-DAE,section 7.13.1.1: Table 8 ... Connecting or Presenting stop() Stopped PlayStateChange ... Stopped bindToCurrentChannel() Connecting PlayStateChange Video and audio presentation is enabled. | |||
| org.hbbtv_GAPFILLING3010 | 1 | Stream event monitoring when playing DASH via IP | A broadcast-related application starts presenting A/V delivered over broadband using MPEG DASH. The application registers to listen to DSM-CC stream events in the broadcast. When the stream events are received by the terminal, events are dispatched to the application. | 2024-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 6.2.2.7: Terminals shall be able to present broadband delivered A/V at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular the following examples shall apply:- DSM-CC stream event monitoring shall continue. HBBTV,section 7.2.4: The terminal shall support "do-it-now" events as defined in clause 8 of ETSI TS 102 809 [3]. HBBTV,section 8.2.1.1: The following additional methods on the video/broadcast object (as defined in the OIPF DAE specification [1]) shall be supported for synchronization to broadcast events as defined in clause 7.2.4. void addStreamEventListener(String targetURL, String eventName, EventListener listener) | |||
| org.hbbtv_GAPFILLING3100 | 1 | Play HTML5 media object - static DASH MPD - server supports IPv4 and IPv6 | The code of a test (HTML, JavaScript, CSS), as well as the DASH MPD and DASH media segments are all hosted one or more test servers supporting both IPv6 and IPv4. The DNS servers for the test server(s) include both an A record and a AAAA record for the domain name(s) of the test server(s). The test application is launched and has an HTML5 media element referencing a DASH MPD where MPD@type is static. When play() is called on the media element, this triggers 'play' and 'playing' events, sets the 'paused' property to false and starts the video playback. | 2024-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.1: Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD. HBBTV,section 4.8.19: In clause 10.2.1, in Table 11: "Minimum terminal capabilities", the following row is added. Value | Additional Information | IP protocol support Terminals shall support IPv4 [91] and may support IPv6[i.33]. Note that different reference numbers apply in each of TS 102 796 V1.4.1, V1.5.1 and V1.6.1. HBBTV,section 4.8.19: In clause 10.2.1, in Table 11: "Minimum terminal capabilities", the following row is added. Value | Additional Information | IP protocol support Terminals shall support IPv4 [91] and may support IPv6[i.33]. Note that different reference numbers apply in each of TS 102 796 V1.4.1, V1.5.1 and V1.6.1. HBBTV,section 4.8.19: In clause 10.2.1, in Table 11: "Minimum terminal capabilities", the following row is added. Value | Additional Information | IP protocol support Terminals shall support IPv4 [91] and may support IPv6[i.33]. Note that different reference numbers apply in each of TS 102 796 V1.4.1, V1.5.1 and V1.6.1. HBBTV,section 10.2.1: IP protocol support | Terminals shall support IPv4 [91] and may support IPv6 [i.33]. HTML5,section 4.7.10.8: The paused attribute represents whether the media element is paused or not. The attribute must initially be true. [...] When the play() method on a media element is invoked, the user agent must run the following steps. [...] 4. If the media element's paused attribute is true, run the following sub-steps: 1. Change the value of paused to false. [...] 3. Queue a task to fire a simple event named play at the element. | |||
| org.hbbtv_GRAPHICS0010 | 1 | Graphics co-ordinate system seen by application is 1280x720 with no GraphicsConstraints AIT element | An application launched from a broadcast AIT with no graphics constraints AIT descriptor presents graphics at 1280x720. These cover the full graphics area of the terminal and window.innerWidth is 1280 and window.innerHeight is 720. | 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.9: Terminals shall not present a co-ordinate system other than 1 280 x 720 CSS pixels to an application unless application support for such a co-ordinate system is indicated by one of the following means: • a graphics constraints descriptor for the application in the broadcast AIT from which the application was started (see clause 7.2.3.1) HBBTV,section 7.2.3.1: 5.2.9 Graphics constraints | 21 | O | This descriptor is optional to support for terminals that only support a graphics coordinate system of 1 280 x 720. ... If this descriptor is present, the list of graphics_configuration_byte shall include all the graphics co-ordinate systems that the application supports. CSSOMView,section 4: The innerWidth attribute must return the viewport width including the size of a rendered scroll bar (if any), or zero if there is no viewport. The innerHeight attribute must return the viewport height including the size of a rendered scroll bar (if any), or zero if there is no viewport. | |||
| org.hbbtv_GRAPHICS0020 | 1 | Graphics co-ordinate system seen by application is 1280x720 with no GraphicsConstraints XML AIT element | An application launched from an XML AIT with no GraphicsConstraints AIT element presents graphics at 1280x720. These cover the full graphics area of the terminal and window.innerWidth is 1280 and window.innerHeight is 720. | 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.9: Terminals shall not present a co-ordinate system other than 1 280 x 720 CSS pixels to an application unless application support for such a co-ordinate system is indicated by one of the following means: ... • a graphics constraints element for the application in the XML AIT from which the application was started (see clause 7.2.3.2) HBBTV,section 7.2.3.2: • Where applications are able to take advantage of graphics co-ordinate system resolutions higher than 1 280 x 720, the inclusion of a <GraphicsConstraints> element as shown below in the extended format of the application's <ApplicationDescriptor> element indicates the graphics constraints for that application. CSSOMView,section 4: The innerWidth attribute must return the viewport width including the size of a rendered scroll bar (if any), or zero if there is no viewport. The innerHeight attribute must return the viewport height including the size of a rendered scroll bar (if any), or zero if there is no viewport. | |||
| org.hbbtv_HD0010 | 1 | Window.devicePixelRatio property | An application contains three img elements with height 600 pixels. The first element is used to display a PNG image of height 600 pixels, with black and white alternating pixels in the vertical dimension. The second element is used to display a PNG image of height 900 pixels, with black and white alternating pixels in the vertical dimension. The third element is used to display a PNG image of height 1800 pixels, with black and white alternating pixels in the vertical dimension. The first image is rendered without loss of resolution, and the second image is rendered without loss of resolution if Window.devicePixelRatio is 1.5 or greater, and the third image is rendered without loss of resolution if Window.devicePixelRatio is 3 or greater. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HbbTV application graphic plane resolution 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. The terminal shall have at least this graphics resolution. The graphics plane may have a higher resolution but the co-ordinate system as seen by applications shall always be 1 280 x 720. Note: this allows for higher resolution rendering of application text and images but limits the granularity with which an application can position graphics. Clause A.3.9 describes APIs that allow applications to exploit the available resolution. HBBTV,section A.3.9: In addition to the properties required by clause 6.3 of the Web Standards TV Profile [i.6], terminals shall support the devicePixelRatio property of the Window interface. The value returned shall reflect the physical pixel resolution at which the HbbTV application is rendered and displayed. [...] If the terminal uses a graphics plane resolution other than 1 280 x 720 then: When an img element is used to present an image at a particular target size such that for each axis, the size of the image asset in pixels is less than or equal to the number of device pixels present within the rendering region for the img element, the image shall be rendered without loss of resolution. | |||
| org.hbbtv_HD0020 | 1 | High resolution graphics - srcset contains 1x pixel density descriptor | An application contains an img element with a src attribute and a srcset attribute that includes multiple different pixel density descriptors and one of the descriptors is equal to Window.devicePixelRatio. If Window.devicePixelRatio is not 1, the image displayed is the one referenced by the pixel density descriptor equal to Window.devicePixelRatio. If Window.devicePixelRatio is 1, the image displayed is either the one referenced by the pixel density descriptor equal to 1 or the one referenced by the src attribute. | 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 10.2.1: HbbTV application graphic plane resolution 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. The terminal shall have at least this graphics resolution. The graphics plane may have a higher resolution but the co-ordinate system as seen by applications shall always be 1 280 x 720. Note: this allows for higher resolution rendering of application text and images but limits the granularity with which an application can position graphics. Clause A.3.9 describes APIs that allow applications to exploit the available resolution. HBBTV,section A.3.9: If the terminal uses a graphics plane resolution other than 1 280 x 720 then: The srcset and sizes attributes of the img element shall be supported as defined by HTML 5.1 [51]. [...] In general, the algorithm for selecting the most appropriate image source from a srcset is outside the scope of the present document. However, when an img element has a valid srcset attribute that includes an entry with a pixel density descriptor that matches the device pixel ratio, the image source corresponding to that entry shall be selected. | |||
| org.hbbtv_HD0030 | 1 | High resolution graphics - srcset contains width descriptors and sizes attribute | An application contains an img element with a src attribute and a srcset attribute that includes multiple different width descriptors and one of the descriptors is equal to (640 x Window.devicePixelRatio). The sizes attribute is "640px" and the width attribute is "640". If Window.devicePixelRatio is not 1, the image displayed is the one referenced by the width descriptor equal to (640 x Window.devicePixelRatio). If Window.devicePixelRatio is 1, the image displayed is either the one referenced by the width descriptor equal to 640 or the one referenced by the src attribute. | 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 10.2.1: HbbTV application graphic plane resolution 1 280 pixels horizontally by 720 pixels vertically with a 16:9 aspect ratio. The terminal shall have at least this graphics resolution. The graphics plane may have a higher resolution but the co-ordinate system as seen by applications shall always be 1 280 x 720. Note: this allows for higher resolution rendering of application text and images but limits the granularity with which an application can position graphics. Clause A.3.9 describes APIs that allow applications to exploit the available resolution. HBBTV,section A.3.9: If the terminal uses a graphics plane resolution other than 1 280 x 720 then: The srcset and sizes attributes of the img element shall be supported as defined by HTML 5.1 [51]. [...] In general, the algorithm for selecting the most appropriate image source from a srcset is outside the scope of the present document. However, when an img element has a valid srcset attribute that includes an entry with a pixel density descriptor that matches the device pixel ratio, the image source corresponding to that entry shall be selected. Similarly, if the sizes attribute is present and an image listed in the srcset attribute has an effective pixel density that matches the device pixel ratio, that image shall be selected. | |||
| org.hbbtv_HTML50010 | 1 | HTML5 video element and non-adaptively streamed A/V (HTTP URL - MPEG-2 TS) | The video/audio shall be presented when the 'src' attribute of an HTML5 video element is an HTTP URL referring to non-adaptively streamed video/audio in MPEG-2 TS format and the play() method is called | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.1: 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 either directly referring to the content or referring to a content access streaming descriptor that in turn refers to the content | |||
| org.hbbtv_HTML50020 | 1 | HTML5 video element and non-adaptively streamed A/V (HTTP URL - ISOBMFF) | The video/audio shall be presented when the 'src' attribute of an HTML5 video element is an HTTP URL referring to non-adaptively streamed video/audio in ISOBMFF format and the play() method is called | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.1: 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 either directly referring to the content or referring to a content access streaming descriptor that in turn refers to the content | |||
| org.hbbtv_HTML50030 | 1 | HTML5 video element and non-adaptively streamed A/V (Content Access Streaming Descriptor - MPEG-2 TS) | The audio/video shall be presented when the 'src' attribute of an HTML5 video element is an HTTP URL referring to a Content Access Streaming Descriptor whose 'ContentURL' element is an HTTP URL that refers to non-adaptively streamed audio/video in MPEG-2 TS format and the play() method is called | 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 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.6.1: 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 either directly referring to the content or referring to a content access streaming descriptor that in turn refers to the content | |||
| org.hbbtv_HTML50040 | 1 | HTML5 video element and non-adaptively streamed A/V (Content Access Streaming Descriptor - ISOBMFF) | The audio/video shall be presented when the 'src' attribute of an HTML5 video element is an HTTP URL referring to a Content Access Streaming Descriptor whose 'ContentURL' element is an HTTP URL that refers to non-adaptively streamed audio/video in ISOBMFF format and the play() method is called | 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 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.6.1: 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 either directly referring to the content or referring to a content access streaming descriptor that in turn refers to the content | |||
| org.hbbtv_HTML50050 | 1 | HTML5 video element and adaptively streamed A/V (HTTP URL - MPEG DASH MPD) | The MPEG DASH content shall be presented when the 'src' attribute of an HTML5 video element is set to an HTTP URL referring to an MPEG DASH MPD and the play() method is called | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.1: Terminals shall support presenting content using the video element as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD | |||
| org.hbbtv_HTML50055 | 1 | HTML5 video element and adaptively streamed A/V - CASD | When the src attribute of an HTML5 video element is set to an HTTP URL referring to a content access streaming descriptor that in turn refers to a MPEG DASH MPD and the play method is called, the MPEG DASH content is presented. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 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.6.1: Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. | |||
| org.hbbtv_HTML50060 | 1 | HTML5 video element and downloaded content | When the src attribute of an HTML5 video element is set to a URI returned by an instance of the Download class in the completed state and the play method is called, the downloaded content is presented. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.1: If the download option is supported then presenting downloaded content shall be supported with that content identified by a URL returned by the uri property of the Download class. | +DL | ||
| org.hbbtv_HTML50070 | 1 | HTML5 video and recorded content | When the src attribute of an HTML5 video element is set to a URI returned by an instance of the Recording class and the play method is called, the recorded content is presented. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.1: If the PVR option is supported then presenting recorded content shall be supported with that content identified by a URL returned by the uri property of the Recording class. | +PVR | ||
| org.hbbtv_HTML50080 | 1 | Support buffered attribute of HTML5 video element - MPEG DASH | When an application starts to present video using the HTML5 video element and delivered via MPEG DASH, the end of the TimeRange returned by the 'buffered' attribute shall be within +/- the segment duration of the time corresponding to the last data loaded from the network | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.4: The terminal shall provide information on the amount of data that is buffered for each HTML5 media element by providing a TimeRanges object via the "buffered" attribute of the HTML5 media element. The accuracy of the range (or ranges) in the TimeRanges object shall be within +/-T seconds of the actual amount of media that has been buffered by the terminal, where T is:- the segment duration, when playing fragmented content (such as DASH)- 5 seconds, otherwise | |||
| org.hbbtv_HTML50110 | 1 | HTML5 video element and parental access control | When an application is presenting video using the HTML5 video element and this is blocked due to parental access control, the application receives a MediaError with the code set to MEDIA_ERR_DECODE. | 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-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 9.6.8: If an application attempts to present content using an HTML5 video element and this is blocked due to parental access control, the application shall receive a MediaError with the code set to MEDIA_ERR_DECODE. | |||
| org.hbbtv_HTML50120 | 1 | HTML5 video element and playable_download content - registerDownloadURL | When an application starts a download using registerDownloadURL, sets the source of an HTML5 video element to the URI of that download and then calls play, the downloaded content starts being loaded and, once enough data has been downloaded and then loaded, played. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.9: If the download was triggered using registerDownloadURL with a contentType other than “application/vnd.oipf.ContentAccessDownload+xml” or the download was triggered using a Content Access Download Descriptor with <TransferType> value "playable_download" as defined in Annex E.1 and if the play() method is called before sufficient data has been download to initiate playback then the HTML5 specification shall be followed as written with the readyState set and updated as required in that specification. | +DL | ||
| org.hbbtv_HTML50130 | 1 | HTML5 video element and playable_download content - CADD | When an application starts a download using a Content Access Download descriptor with <TransferType> "playable_download", sets the source of an HTML5 video element to the URI of that download and then calls play, the downloaded content starts being loaded and, once enough data has been downloaded and then loaded, played. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.9: If the download was triggered using registerDownloadURL with a contentType other than “application/vnd.oipf.ContentAccessDownload+xml” or the download was triggered using a Content Access Download Descriptor with <TransferType> value "playable_download" as defined in Annex E.1 and if the play() method is called before sufficient data has been download to initiate playback then the HTML5 specification shall be followed as written with the readyState set and updated as required in that specification. | +DL | ||
| org.hbbtv_HTML50140 | 1 | HTML5 video element and full_download content | When an application starts a download using a Content Access Download descriptor with <TransferType> "full_download", sets the source of an HTML5 video element to the URI of that download and then calls play before the download has finished, the application receives a MediaError with the code set of MEDIA_ERR_NETWORK. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.9: If the downloaded content was triggered using a Content Access Download Descriptor with <TransferType> value "full_download" as defined in Annex E.1, and if the play() method is called whilst the content is still downloading and has not yet successfully completed, then the method shall fail and a MediaError sent with the code set to MEDIA_ERR_NETWORK. | +DL | ||
| org.hbbtv_HTML50160 | 1 | Primary Audio Language and Multiple Language Audio Tracks - MP4 - English | When an application starts playing a media file (ISO BMFF) using the HTML5 media element delivered using basic HTTP streaming and that media file contains audio tracks in multiple languages, the one in the user preferred language is selected even if this is not first in the file. | 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 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). HTML5,section 4.7.10.5: If either the media resource or the address of the current media resource indicate a particular set of audio or video tracks to enable, or if the user agent has information that would enable it to select specific tracks to improve the user's experience, then the relevant audio tracks must be enabled in the element's audioTracks object, and, of the relevant video tracks, the one that is listed first in the element's videoTracks object must be selected. All other tracks must be disabled. | |||
| org.hbbtv_HTML50165 | 2 | Primary Audio Language and Multiple Language Audio Tracks - MPEG-DASH (HbbTV ISOBMFF Live Profile) - English | When English is selected as the primary audio language and an application starts playing MP4 audio/video, delivered using MPEG-DASH via the HTML5 media element where: the MPD uses the HbbTV ISOBMFF Live profile; the MPD contains AAC-encoded, French and English language audio AdaptationSet elements; the French audio AdaptationSet element has a lower index than the English audio AdaptationSet element; the MPD contains an accompanying AVC_SD_25 video AdaptationSet element — then the English language audio is presented | 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 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). HTML5,section 4.7.10.5: If either the media resource or the address of the current media resource indicate a particular set of audio or video tracks to enable, or if the user agent has information that would enable it to select specific tracks to improve the user's experience, then the relevant audio tracks must be enabled in the element's audioTracks object, and, of the relevant video tracks, the one that is listed first in the element's videoTracks object must be selected. All other tracks must be disabled. | |||
| org.hbbtv_HTML50170 | 1 | enabling audio and video tracks as selected by the media player - preferred audio track in a downloaded media file | When an application starts playing a downloaded media file (ISO BMFF) using the HTML5 media element and that media file contains audio tracks in multiple languages, the one in the user preferred language is selected even if this is not first in the file. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.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). HTML5,section 4.7.10.5: If either the media resource or the address of the current media resource indicate a particular set of audio or video tracks to enable, or if the user agent has information that would enable it to select specific tracks to improve the user's experience, then the relevant audio tracks must be enabled in the element's audioTracks object, and, of the relevant video tracks, the one that is listed first in the element's videoTracks object must be selected. All other tracks must be disabled. | +DL | ||
| org.hbbtv_HTML50180 | 1 | enabling audio and video tracks as selected by the media player - preferred audio track in a recording | When an application starts playing a recording using the HTML5 media element and that recording contains audio tracks in multiple languages, the one in the user preferred language is selected even if this is not first in the file. | 2024-1 2023-3 2023-2 2023-1 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.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 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). HTML5,section 4.7.10.5: If either the media resource or the address of the current media resource indicate a particular set of audio or video tracks to enable, or if the user agent has information that would enable it to select specific tracks to improve the user's experience, then the relevant audio tracks must be enabled in the element's audioTracks object, and, of the relevant video tracks, the one that is listed first in the element's videoTracks object must be selected. All other tracks must be disabled. | +PVR | ||
| org.hbbtv_HTML50190 | 1 | HTML5 video element always behaves as full screen mode false - same aspect ratio, no cropping | When an application presents video (without AFD, bar data or default display window) using an HTML5 video element and the video element has the same aspect ratio as the video then the four corners of the video match exactly the corners of the video element. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.11: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. OIPF-DAE,section H.2: 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 HBBTV,section A.2.14: If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. | |||
| org.hbbtv_HTML50200 | 1 | HTML5 video element always behaves as full screen mode false - different aspect ratio, no cropping | When an application presents video (without AFD, bar data or default display window) using an HTML5 video element and the video element does not have the same aspect ratio as the video then one side of the video fully fills the video element without cropping and the other side is centred and the area of the video plane not containing video is opaque black. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 9.6.11: Video presented by an HTML5 <video> element shall always be presented according to the requirements for full screen mode being false as defined in clause H.2 of the OIPF DAE specification [1] and modified by clause A.2.14 of the present document. OIPF-DAE,section H.2: 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 HBBTV,section A.2.14: If the video is cropped or scaled as indicated by either of the indications referred to above then the original requirements defined in clause H.2 of the OIPF DAE specification [1] (quoted above) shall apply to the video after that processing has been performed. | ||
| org.hbbtv_HTML50230 | 1 | HTML5 video element and downloaded content blocked by parental access control | When an application requests downloaded video be presented using an HTML5 video element and this is denied due to the parental rating in the CADD used to download the content being above the current parental rating system threshold, a MediaError is sent to the HTML5 video element with the code set to MEDIA_ERR_DECODE. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.3: When playing back a downloaded content item, terminals shall compare the value in the <parentalRating> element in the content access descriptor used to download the content item with the current parental rating system threshold and only play appropriate content. If the playback was initiated using an HTML5 video element then the error property of the video element shall be set to a MediaError with the code set to MEDIA_ERR_DECODE and fire an error event at the media element. | +DL | ||
| org.hbbtv_HTML50240 | 1 | HTML5 video element and recorded content blocked by parental access control | When an application requests recorded video be presented using an HTML5 video element and this is denied due to the parental rating of the recording being above the current parental rating system threshold, a MediaError is sent to the HTML5 video element with the code set to MEDIA_ERR_DECODE. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.4: Before playing back a recording, terminals shall compare the parental rating stored with the recording with the current parental rating system threshold and shall only play appropriate content. If the playback was initiated using an HTML5 video element then the error property of the video element shall be set to a MediaError with the code set to MEDIA_ERR_DECODE and fire an error event at the media element. | +PVR | ||
| org.hbbtv_HTML50250 | 1 | HTML5 in XML capabilities | When the XML capabilities are read, they include an element whose name is "html5_media" and whose value is "true". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 video [...] 9.3.17 [...] M OIPF-DAE,section 9.3.17: The OITF SHALL indicate support for HTML5 video through the base profile and UI profile name fragment strings as defined in section 9.2 and the <html5_media> element as defined in Annex F: <xs:element name="html5_media" type="xs:boolean"/> If included, the value of this element SHALL be: (true | |||
| org.hbbtv_HTML50400 | 1 | AudioTrack.id with MPEG-2 TS | When an application requests an MPEG-2 transport stream be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an Audio elementary stream in that transport stream, the id property of the AudioTrack is the component_tag in the stream_identifier_descriptor of the Audio elementary stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 AudioTrack and the MPEG-2 transport stream and ISO BMFF system layers. readonly attribute DOMString id; MPEG-2 TS: The contents of the component_tag field in the stream_identifier_descriptor in PMT. | |||
| org.hbbtv_HTML50410 | 1 | AudioTrack.kind with MPEG-2 TS - iso_639_language_descriptor | When an application requests an MPEG-2 transport stream be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an Audio elementary stream in that transport stream and the audio elementary stream has an ISO_639_language_descriptor in the PMT with the audio_type field set to 0x03 then the kind property is "description" | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 AudioTrack and the MPEG-2 transport stream and ISO BMFF system layers. readonly attribute DOMString kind; MPEG-2 Transport stream: "" unless the audioDescription property of an AVComponent instance for this track would be set to true in which case "description". OIPF-DAE,section 8.4.2: audioDescription Type: Boolean - True if is component is an audio description Only defined for audio components. True if any of the following is true: There is an audio component with an ISO_639_language_descriptor in the PMT with the audio_type field set to 0x03 [...] Otherwise false | |||
| org.hbbtv_HTML50420 | 1 | AudioTrack.kind with MPEG-2 TS - supplementary_audio_descriptor | When an application requests an MPEG-2 transport stream be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an Audio elementary stream in that transport stream and the audio elementary stream has an supplementary_audio_descriptor in the PMT with the editorial_classification field set to 0x01 then the kind property is "description" | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 AudioTrack and the MPEG-2 transport stream and ISO BMFF system layers. readonly attribute DOMString kind; MPEG-2 Transport stream: "" unless the audioDescription property of an AVComponent instance for this track would be set to true in which case "description". OIPF-DAE,section 8.4.2: audioDescription Type: Boolean - True if is component is an audio description Only defined for audio components. True if any of the following is true: [...] There is a supplementary_audio_descriptor with the editorial_classification field set to 0x01 [...] Otherwise false | |||
| org.hbbtv_HTML50430 | 1 | AudioTrack.kind with MPEG-2 TS - e-ac3 audio descriptor | When an application requests an MPEG-2 transport stream be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an Audio elementary stream in that transport stream and the audio elementary stream has an enhanced_ac-3_descriptor in the PMT with a component_type field with the service_type flags set to Visually Impaired then the kind property is "description" | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 AudioTrack and the MPEG-2 transport stream and ISO BMFF system layers. readonly attribute DOMString kind; MPEG-2 Transport stream: "" unless the audioDescription property of an AVComponent instance for this track would be set to true in which case "description". OIPF-DAE,section 8.4.2: audioDescription Type: Boolean - True if is component is an audio descriptionOnly defined for audio components. True if any of the following is true: [...] There is an ac-3_descriptor or an enhanced_ac-3_descriptor with a component_type field with the service_type flags set to Visually Impaired. Otherwise false | +EAC3 | ||
| org.hbbtv_HTML50450 | 1 | AudioTrack.language with MPEG2-TS - supplementary_audio_descriptor | When an application requests an MPEG-2 transport stream be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an Audio elementary stream in that transport stream and the ES loop of the PMT contains a supplementary_audio_descriptor and an ISO_639_language_descriptor for that ES then the language property shall be the contents of the ISO_639_language_code field in the supplementary_audio_descriptor in the ES loop of the PMT for that ES. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 AudioTrack and the MPEG-2 transport stream and ISO BMFF system layers. readonly attribute DOMString language MPEG-2 TS: as defined in section 8.4.2 above for the language property of AVComponent OIPF-DAE,section 8.4.2: the contents of the ISO_639_language_code field in the ISO_639_language_descriptor In the ES loop of the PMT unless overridden by the ISO_639_language_code field in the supplementary_audio_descriptor. | |||
| org.hbbtv_HTML50500 | 1 | AudioTrack.id with ISOBMFF | When an application requests an ISOBMFF file be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an Audio track in that file, the id property of the AudioTrack is the track_id of the Audio track. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: "The following table defines the mapping that SHALL be used between the HTML5 AudioTrack and the MPEG-2 transport stream and ISO BMFF system layers. readonly attribute DOMString id; ISO BMFF track_id | |||
| org.hbbtv_HTML50600 | 2 | AudioTrack.id with MPEG DASH | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an audio AdaptationSet in the MPD, the id property of the AudioTrack is the id attribute in the AdaptationSet. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping - 8.4.6 - M(*) - See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 AudioTrack and the MPEG-2 transport stream and ISO BMFF system layers [...] readonly attribute DOMString id [... MPEG DASH:] The value of the id attribute in the AdaptationSet (if provided) | |||
| org.hbbtv_HTML50610 | 2 | AudioTrack.kind with MPEG DASH - main | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an audio AdaptationSet in the MPD, and the AdaptationSet has @role equals "main" and nothing else then the kind property of the AudioTrack is "main". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document HBBTV,section A.2.12.3: The definition of the kind property of a VideoTrack and AudioTrack in the MPEG DASH system layer shall be replaced with the following; Given a role scheme of "urn:mpeg:dash:role:2011", determine the 'kind' attribute from the value of the role descriptors in the <AdaptationSet> element. - "alternative": if the role is "alternate" but not also "main" or "commentary", or "dub" - "captions": if the role is "caption" and also "main" - "descriptions": if the role is "description" and also "supplementary" - "main": if the role is "main" but not also "caption", "subtitle", or "dub" - "main-desc": if the role is "main" and also "description" - "sign": not used - "subtitles": if the role is "subtitle" and also "main" - "translation": if the role is "dub" and also "main" - "commentary": if the role is "commentary" but not also "main" - "": otherwise | |||
| org.hbbtv_HTML50620 | 2 | AudioTrack.kind with MPEG DASH - main and dub | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an audio AdaptationSet in the MPD, and if the AdaptationSet has @role elements for both "dub" and "main" then the kind property of the AudioTrack is "translation". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document HBBTV,section A.2.12.3: The definition of the kind property of a VideoTrack and AudioTrack in the MPEG DASH system layer shall be replaced with the following; Given a role scheme of "urn:mpeg:dash:role:2011", determine the 'kind' attribute from the value of the role descriptors in the <AdaptationSet> element. - "alternative": if the role is "alternate" but not also "main" or "commentary", or "dub" - "captions": if the role is "caption" and also "main" - "descriptions": if the role is "description" and also "supplementary" - "main": if the role is "main" but not also "caption", "subtitle", or "dub" - "main-desc": if the role is "main" and also "description" - "sign": not used - "subtitles": if the role is "subtitle" and also "main" - "translation": if the role is "dub" and also "main" - "commentary": if the role is "commentary" but not also "main" - "": otherwise | |||
| org.hbbtv_HTML50625 | 1 | AudioTrack.kind with MPEG DASH - descriptions | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an audio Adaptation Set in the MPD, and the Adaptation Set has a role element set to "descriptions" and also a role element set to "supplementary" then the kind property of the AudioTrack is "descriptions". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document HBBTV,section A.2.12.3: The definition of the kind property of a VideoTrack and AudioTrack in the MPEG DASH system layer shall be replaced with the following; Given a role scheme of "urn:mpeg:dash:role:2011", determine the 'kind' attribute from the value of the role descriptors in the AdaptationSet element. - "alternative": if the role is "alternate" but not also "main" or "commentary", or "dub" - "captions": if the role is "caption" and also "main" - "descriptions": if the role is "description" and also "supplementary" - "main": if the role is "main" but not also "caption", "subtitle", or "dub" - "main-desc": if the role is "main" and also "description" - "sign": not used - "subtitles": if the role is "subtitle" and also "main" - "translation": if the role is "dub" and also "main" - "commentary": if the role is "commentary" but not also "main" - "": otherwise | |||
| org.hbbtv_HTML50630 | 2 | AudioTrack.kind with MPEG DASH - alternate | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an audio AdaptationSet in the MPD, and the AdaptationSet has an @role element for "alternate" and does not have @role elements for "main", "commentary" or "dub" then the kind property of the AudioTrack is "alternative". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document HBBTV,section A.2.12.3: The definition of the kind property of a VideoTrack and AudioTrack in the MPEG DASH system layer shall be replaced with the following; Given a role scheme of "urn:mpeg:dash:role:2011", determine the 'kind' attribute from the value of the role descriptors in the <AdaptationSet> element. - "alternative": if the role is "alternate" but not also "main" or "commentary", or "dub" - "captions": if the role is "caption" and also "main" - "descriptions": if the role is "description" and also "supplementary" - "main": if the role is "main" but not also "caption", "subtitle", or "dub" - "main-desc": if the role is "main" and also "description" - "sign": not used - "subtitles": if the role is "subtitle" and also "main" - "translation": if the role is "dub" and also "main" - "commentary": if the role is "commentary" but not also "main" - "": otherwise | |||
| org.hbbtv_HTML50635 | 1 | AudioTrack.kind with MPEG DASH - main-desc | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an audio Adaptation Set in the MPD, and the Adaptation Set has a role element set to "description" and also a role element set to "main" then the kind property of the AudioTrack is "main-desc". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document HBBTV,section A.2.12.3: The definition of the kind property of a VideoTrack and AudioTrack in the MPEG DASH system layer shall be replaced with the following; Given a role scheme of "urn:mpeg:dash:role:2011", determine the 'kind' attribute from the value of the role descriptors in the AdaptationSet element. - "alternative": if the role is "alternate" but not also "main" or "commentary", or "dub" - "captions": if the role is "caption" and also "main" - "descriptions": if the role is "description" and also "supplementary" - "main": if the role is "main" but not also "caption", "subtitle", or "dub" - "main-desc": if the role is "main" and also "description" - "sign": not used - "subtitles": if the role is "subtitle" and also "main" - "translation": if the role is "dub" and also "main" - "commentary": if the role is "commentary" but not also "main" - "": otherwise | |||
| org.hbbtv_HTML50640 | 2 | AudioTrack.kind with MPEG DASH - commentary | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an audio AdaptationSet in the MPD, and the AdaptationSet has a role element set to "commentary" and does not have a role element set to "main" then the kind property of the AudioTrack is "commentary". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document HBBTV,section A.2.12.3: The definition of the kind property of a VideoTrack and AudioTrack in the MPEG DASH system layer shall be replaced with the following; Given a role scheme of "urn:mpeg:dash:role:2011", determine the 'kind' attribute from the value of the role descriptors in the <AdaptationSet> element. - "alternative": if the role is "alternate" but not also "main" or "commentary", or "dub" - "captions": if the role is "caption" and also "main" - "descriptions": if the role is "description" and also "supplementary" - "main": if the role is "main" but not also "caption", "subtitle", or "dub" - "main-desc": if the role is "main" and also "description" - "sign": not used - "subtitles": if the role is "subtitle" and also "main" - "translation": if the role is "dub" and also "main" - "commentary": if the role is "commentary" but not also "main" - "": otherwise | |||
| org.hbbtv_HTML50650 | 1 | AudioTrack.language with MPEG DASH - Explicit | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an audio AdaptationSet in the MPD, the audio AdaptationSet has a @lang attribute and the language field in the "mdhd" of the track has a different language then the language property of the AudioTrack is the value of that @lang attribute. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 AudioTrack and the MPEG-2 transport stream and ISO BMFF system layers. readonly attribute DOMString language | Language of the track | The primary language subtag in the BCP47 string SHALL be set as defined in section 8.4.2 above for the language property of AVComponent. OIPF-DAE,section 8.4.2: Defined by the value of the '@lang' attribute in the MPD, whether set explicitly or inherited. The contents of the language field in the 'mdhd' of the track SHALL be ignored. | |||
| org.hbbtv_HTML50651 | 1 | AudioTrack.language with MPEG DASH - Explicit 2-letter language code | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the AudioTrack corresponding to an audio AdaptationSet in the MPD, the audio AdaptationSet has a @lang attribute with a 2-letter language code and the language field in the "mdhd" of the track has a different language then the language property of the AudioTrack is the value of that @lang attribute. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 AudioTrack and the MPEG-2 transport stream and ISO BMFF system layers. readonly attribute DOMString language | Language of the track | The primary language subtag in the BCP47 string SHALL be set as defined in section 8.4.2 above for the language property of AVComponent. OIPF-DAE,section 8.4.2: Defined by the value of the '@lang' attribute in the MPD, whether set explicitly or inherited. The contents of the language field in the 'mdhd' of the track SHALL be ignored. | |||
| org.hbbtv_HTML50675 | 1 | AudioTrack deselection with HTML5 | An MPEG DASH stream containing a video AdaptationSet and an audio AdaptationSet is being presented by an HTML5 media object. When the application sets the enabled attribute of the AudioTrack that maps to the audio AdaptationSet to false, the terminal stops presenting audio and, when the switch is completed, video is presented correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document HBBTV,section 10.2.7.3: Applications may change the terminal-derived component selection and discover the presentation status using the methods defined in [...] clauses 4.7.10.10.1 [...] of HTML5 [54]. HTML5,section 4.7.10.10.1: audioTrack.enabled [ = value ] Returns true if the given track is active, and false otherwise. Can be set, to change whether the track is enabled or not. If multiple audio tracks are enabled simultaneously, they are mixed. [...] An AudioTrackList object represents a dynamic list of zero or more audio tracks, of which zero or more can be enabled at a time. Each audio track is represented by an AudioTrack object. [...] The AudioTrack.enabled attribute, on getting, must return true if the track is currently enabled, and false otherwise. On setting, it must enable the track if the new value is true, and disable it otherwise. | |||
| org.hbbtv_HTML50680 | 1 | AudioTrack multiple selection with HTML5 - mixing supported | An MPEG DASH stream containing a video AdaptationSet and two audio AdaptationSets - A and B - is being presented by an HTML5 media object, and initially only audio AdaptationSet A is being presented. When the application sets the enabled attribute of the AudioTrack that maps to B to true, the terminal presents both audio AdaptationSets mixed and the enabled attribute of the AudioTrack that maps to A remains true and, when the switch is completed, video is presented correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document HBBTV,section 10.2.7.3: Applications may change the terminal-derived component selection and discover the presentation status using the methods defined in [...] clauses 4.7.10.10.1 [...] of HTML5 [54]. HBBTV,section A.3.7: There is no requirement to support multiple simultaneously enabled audio tracks on an HTML5 media element. Enabling a new audio track shall automatically disable the previous one on terminals that are unable to decode multiple audio tracks and mix them. HTML5,section 4.7.10.10.1: audioTrack.enabled [ = value ] Returns true if the given track is active, and false otherwise. Can be set, to change whether the track is enabled or not. If multiple audio tracks are enabled simultaneously, they are mixed. [...] An AudioTrackList object represents a dynamic list of zero or more audio tracks, of which zero or more can be enabled at a time. Each audio track is represented by an AudioTrack object. [...] The AudioTrack.enabled attribute, on getting, must return true if the track is currently enabled, and false otherwise. On setting, it must enable the track if the new value is true, and disable it otherwise. | +HTML_MIX | ||
| org.hbbtv_HTML50685 | 1 | AudioTrack multiple selection with HTML5 - mixing not supported | An MPEG DASH stream containing a video AdaptationSet and two audio AdaptationSets - A and B - is being presented by an HTML5 media object, and initially only audio AdaptationSet A is being presented. When the application sets the enabled attribute of the AudioTrack that maps to B to true, the terminal stops presenting audio AdaptationSet A and presents audio AdaptationSet B and the enabled attribute of the AudioTrack that maps to A changes to false and, when the switch is completed, video is presented correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document HBBTV,section 10.2.7.3: Applications may change the terminal-derived component selection and discover the presentation status using the methods defined in [...] clauses 4.7.10.10.1 [...] of HTML5 [54]. HBBTV,section A.3.7: There is no requirement to support multiple simultaneously enabled audio tracks on an HTML5 media element. Enabling a new audio track shall automatically disable the previous one on terminals that are unable to decode multiple audio tracks and mix them. HTML5,section 4.7.10.10.1: audioTrack.enabled [ = value ] Returns true if the given track is active, and false otherwise. Can be set, to change whether the track is enabled or not. If multiple audio tracks are enabled simultaneously, they are mixed. [...] An AudioTrackList object represents a dynamic list of zero or more audio tracks, of which zero or more can be enabled at a time. Each audio track is represented by an AudioTrack object. [...] The AudioTrack.enabled attribute, on getting, must return true if the track is currently enabled, and false otherwise. On setting, it must enable the track if the new value is true, and disable it otherwise. | -HTML_MIX | ||
| org.hbbtv_HTML50700 | 1 | VideoTrack.id with MPEG-2 TS | When an application requests an MPEG-2 transport stream be presented by an HTML5 video element and then obtains the VideoTrack corresponding to an video elementary stream in that transport stream, the id property of the VideoTrack is the component_tag in the stream_identifier_descriptor of the Video elementary stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 VideoTrack and the MPEG-2 transport stream and ISO BMFF system layers. readonly attribute DOMString id; The contents of the component_tag field in the stream_identifier_descriptor in PMT | |||
| org.hbbtv_HTML50710 | 1 | VideoTrack.id with ISOBMFF | When an application requests an ISOBMFF file be presented by an HTML5 video element and then obtains the VideoTrack corresponding to a video track in that file, the id property of the VideoTrack is the track_id of the video track. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 VideoTrack and the MPEG-2 transport stream and ISO BMFF system layers. readonly attribute DOMString id; track_id | |||
| org.hbbtv_HTML50720 | 1 | VideoTrack.id with MPEG DASH | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the VideoTrack corresponding to a video Adaptation Set in the MPD, the id property of the VideoTrack is the id attribute in the Adaptation Set. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 VideoTrack and the MPEG-2 transport stream and ISO BMFF system layers. readonly attribute DOMString id; The value of the id attribute in the AdaptationSet (if provided) | |||
| org.hbbtv_HTML50730 | 1 | VideoTrack.kind with MPEG DASH - alternative | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the VideoTrack corresponding to a video Adaptation Set in the MPD and the Adaptation Set has a role of "alternate" without also having a role of "main", "commentary" or "dub" then the kind property of the VideoTrack is "alternative" | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.3: The definition of the kind property of a VideoTrack and AudioTrack in the MPEG DASH system layer shall be replaced with the following; Given a role scheme of "urn:mpeg:dash:role:2011", determine the 'kind' attribute from the value of the role descriptors in the AdaptationSet element. - "alternative": if the role is "alternate" but not also "main" or "commentary", or "dub" - "captions": if the role is "caption" and also "main" - "descriptions": if the role is "description" and also "supplementary" - "main": if the role is "main" but not also "caption", "subtitle", or "dub" - "main-desc": if the role is "main" and also "description" - "sign": not used - "subtitles": if the role is "subtitle" and also "main" - "translation": if the role is "dub" and also "main" - "commentary": if the role is "commentary" but not also "main" - "": otherwise | |||
| org.hbbtv_HTML50740 | 1 | VideoTrack.kind with MPEG DASH - captions | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the VideoTrack corresponding to a video Adaptation Set in the MPD and the Adaptation Set has roles of "caption" and "main" then the kind property of the VideoTrack is "captions" | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.3: The definition of the kind property of a VideoTrack and AudioTrack in the MPEG DASH system layer shall be replaced with the following; Given a role scheme of "urn:mpeg:dash:role:2011", determine the 'kind' attribute from the value of the role descriptors in the AdaptationSet element. - "alternative": if the role is "alternate" but not also "main" or "commentary", or "dub" - "captions": if the role is "caption" and also "main" - "descriptions": if the role is "description" and also "supplementary" - "main": if the role is "main" but not also "caption", "subtitle", or "dub" - "main-desc": if the role is "main" and also "description" - "sign": not used - "subtitles": if the role is "subtitle" and also "main" - "translation": if the role is "dub" and also "main" - "commentary": if the role is "commentary" but not also "main" - "": otherwise | |||
| org.hbbtv_HTML50750 | 1 | VideoTrack.kind with MPEG DASH - main | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the VideoTrack corresponding to a video Adaptation Set in the MPD and the Adaptation Set has a role of "main" without also having a role of "caption", "subtitle" or "dub" then the kind property of the VideoTrack is "main" | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.3: The definition of the kind property of a VideoTrack and AudioTrack in the MPEG DASH system layer shall be replaced with the following; Given a role scheme of "urn:mpeg:dash:role:2011", determine the 'kind' attribute from the value of the role descriptors in the AdaptationSet element. - "alternative": if the role is "alternate" but not also "main" or "commentary", or "dub" - "captions": if the role is "caption" and also "main" - "descriptions": if the role is "description" and also "supplementary" - "main": if the role is "main" but not also "caption", "subtitle", or "dub" - "main-desc": if the role is "main" and also "description" - "sign": not used - "subtitles": if the role is "subtitle" and also "main" - "translation": if the role is "dub" and also "main" - "commentary": if the role is "commentary" but not also "main" - "": otherwise | |||
| org.hbbtv_HTML50760 | 1 | VideoTrack.kind with MPEG DASH - subtitle | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the VideoTrack corresponding to a video Adaptation Set in the MPD and the Adaptation Set has roles of both "subtitle" and "main" then the kind property of the VideoTrack is "subtitles" | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.3: The definition of the kind property of a VideoTrack and AudioTrack in the MPEG DASH system layer shall be replaced with the following; Given a role scheme of "urn:mpeg:dash:role:2011", determine the 'kind' attribute from the value of the role descriptors in the AdaptationSet element. - "alternative": if the role is "alternate" but not also "main" or "commentary", or "dub" - "captions": if the role is "caption" and also "main" - "descriptions": if the role is "description" and also "supplementary" - "main": if the role is "main" but not also "caption", "subtitle", or "dub" - "main-desc": if the role is "main" and also "description" - "sign": not used - "subtitles": if the role is "subtitle" and also "main" - "translation": if the role is "dub" and also "main" - "commentary": if the role is "commentary" but not also "main" - "": otherwise | |||
| org.hbbtv_HTML50780 | 1 | VideoTrack deselection with HTML5 | An MPEG DASH stream containing an audio AdaptationSet and a video AdaptationSet is being presented by an HTML5 media object. When the application sets the enabled attribute of the the VideoTrack that maps to the video AdaptationSet to false, the terminal stops presenting video and, when the switch is completed, audio is presented correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) | See clause A.2.12 of the present document HBBTV,section 10.2.7.3: Applications may change the terminal-derived component selection and discover the presentation status using the methods defined in [...] clauses 4.7.10.10.1 [...] of HTML5 [54]. HTML5,section 4.7.10.10.1: videoTrack.selected [ = value ] Returns true if the given track is active, and false otherwise. Can be set, to change whether the track is selected or not. Either zero or one video track is selected; selecting a new track while a previous one is selected will unselect the previous one. [...] A VideoTrackList object represents a dynamic list of zero or more video tracks, of which zero or one can be selected at a time. Each video track is represented by a VideoTrack object. [...] The VideoTrack.selected attribute, on getting, must return true if the track is currently selected, and false otherwise. On setting, it must select the track if the new value is true, and unselect it otherwise. If the track is in a VideoTrackList, then all the other VideoTrack objects in that list must be unselected. | |||
| org.hbbtv_HTML50800 | 1 | TextTrack.id with MPEG-2 TS | When an application requests an MPEG-2 transport stream be presented by an HTML5 video element and then obtains the TextTrack corresponding to an subtitle elementary stream in that transport stream, the id property of the TextTrack is the component_tag in the stream_identifier_descriptor of that elementary stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 TextTrack and the MPEG-2 transport stream, ISO BMFF and MPEG DASH system layers for streams where the type property of an AVComponent would be COMPONENT_TYPE_SUBTITLE as defined above. readonly attribute DOMString id; The contents of the component_tag field in the stream_identifier_descriptor in PMT | |||
| org.hbbtv_HTML50810 | 1 | TextTrack.kind with MPEG-2 TS - subtitles | When an application requests an MPEG-2 transport stream be presented by an HTML5 video element and then obtains the TextTrack corresponding to an subtitle elementary stream in that transport stream and the elementary stream has a subtitling_descriptor with the subtitling_type field set to 0x10 then the kind property of the TextTrack is "subtitles" | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 TextTrack and the MPEG-2 transport stream, ISO BMFF and MPEG DASH system layers for streams where the type property of an AVComponent would be COMPONENT_TYPE_SUBTITLE as defined above. readonly attribute TextTrackKind kind "subtitles" unless the hearingImpaired property of an AVComponent instance for this track would be set to true in which case "caption". OIPF-DAE,section 8.4.2: Name: encoding Type: A string identifying the video or audio format as defined in section 3 of [OIPF_MEDIA2] or the subtitle format as defined in section 7.16.5.2.1 [...] Property type is COMPONENT_TYPE_SUBTITLE A value of 0x10 or 0x11 or 0x12 or 0x14 in the subtitling_type field of the subtitling_descriptor in the ES loop of the PMT -> “DVB-SUBT”. A value of 0x20 or 0x21 or 0x22 or 0x24 in the subtitling_type field of the subtitling_descriptor in the ES loop of the PMT -> “DVB_SUBT” (the hearingImpaired property in the derived AVSubtitleComponent would be set to true). [...] Name: hearingImpaired Type: Boolean - Has value true if the stream is intended for the hearing-impaired (e.g. contains a written description of the sound effects), false otherwise. Only defined for subtitle components. True if one of the following is true: - There is a subtitling_descriptor with the subtitling_type field set to 0x20, 0x21, 0x22, 0x23 or 0x24. - There is a teletext_descriptor with a teletext_type field with a value of 0x05. | |||
| org.hbbtv_HTML50840 | 1 | TextTrack.language with MPEG-2 TS - teletext_descriptor | When an application requests an MPEG-2 transport stream be presented by an HTML5 video element and then obtains the TextTrack corresponding to an subtitle elementary stream in that transport stream and the elementary stream has a teletext_descriptor then the language property of the TextTrack is the ISO_639_language_code field in that descriptor | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 TextTrack and the MPEG-2 transport stream, ISO BMFF and MPEG DASH system layers for streams where the type property of an AVComponent would be COMPONENT_TYPE_SUBTITLE as defined above. readonly attribute DOMString language The primary language subtag in the BCP47 string SHALL be set as defined in section 8.4.2 above for the language property of AVComponent. OIPF-DAE,section 8.4.2: For subtitles, the contents of the ISO_639_language_code field in the subtitling_descriptor or teletext_descriptor, as appropriate. | |||
| org.hbbtv_HTML50940 | 1 | TextTrack.id with MPEG DASH | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the TextTrack corresponding to a subtitle Adaptation Set in the MPD, the id property of the TextTrack is the id attribute in the Adaptation Set. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 TextTrack and the MPEG-2 transport stream, ISO BMFF and MPEG DASH system layers for streams where the type property of an AVComponent would be COMPONENT_TYPE_SUBTITLE as defined above. readonly attribute DOMString id; The value of the id attribute in the AdaptationSet (if provided) | |||
| org.hbbtv_HTML50950 | 1 | TextTrack.kind with MPEG DASH - role is main and no accessibility scheme specified | When an application requests that MPEG DASH content be presented by an HTML5 video element and then obtains the TextTrack corresponding to a subtitle Adaptation Set in the MPD that has @role as "main" and does not have an accessibility scheme, the kind property of the TextTrack is "subtitles". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: HTML5 Media Element Mapping [...] 8.4.6 [...] M(*) [...] See clause A.2.12 of the present document HBBTV,section A.2.12.3: The definition of the value of the kind property of a TextTrack in the MPEG DASH system layer shall be replaced with the following: - "captions": if (role is "main" AND the MPD contains an audio Adaptation Set with role "main" and the same language as the subtitle track AND an accessibility descriptor is present with the schemeIdUri set to "urn:tva:metadata:cs:AudioPurposeCS:2007" and a value 2 [for the hard of hearing]) OR (role is "commentary"); - "subtitles": if (role is "alternate") OR (role is "main" AND no accessibility scheme is specified); - "metadata": otherwise. OIPF-DAE,section 8.4.6: The following table defines the mapping that SHALL be used between the HTML5 TextTrack and the MPEG-2 transport stream, ISO BMFF and MPEG DASH system layers for streams where the type property of an AVComponent would be COMPONENT_TYPE_SUBTITLE as defined above. readonly attribute TextTrackKind kind "subtitles" | |||
| org.hbbtv_HTML51000 | 1 | Graphics Performance 1 - Frame/background-color | At least 4 simultaneous animations of the background-color CSS property of a Frame (where the colour is opaque) shall be presented at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] background-color [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51010 | 1 | Graphics Performance 1 - Frame/background-color, opacity | The terminal shall support at least 4 simultaneous animations of the background-color CSS property of a Frame (where the colour includes opacity) at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] background-color, opacity [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51020 | 1 | Graphics Performance 1 - Frame/left,top | The terminal shall support at least 4 simultaneous animations of the left and top CSS properties of a Frame at a frame rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] left, top [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51030 | 1 | Graphics Performance 1 - Frame/opacity | The terminal shall support at least 4 simultaneous animations of the opacity property of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] opacity [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51040 | 1 | Graphics Performance 1 - Frame/transform: scale | The terminal shall support at least 4 simultaneous animations of the CSS transform "scale" property of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] transform: scale [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51050 | 1 | Graphics Performance 1 - Frame/border-radius | The terminal shall support at least 4 simultaneous animations of the CSS border-radius property of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] border-radius [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51060 | 1 | Graphics Performance 1 - Frame/width,height | The terminal shall support at least 4 simultaneous animations of the CSS width and height properties of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] width, height [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51070 | 1 | Graphics Performance 1 - Frame/linear-gradient | The terminal shall support at least 4 simultaneous animations of a linear gradient assigned to the CSS background-image property of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] linear-gradient [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51080 | 1 | Graphics Performance 1 - Image/left,top | The terminal shall support at least 4 simultaneous animations of the left and top CSS properties of an Image at a frame rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Image [...] left, top [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51090 | 1 | Graphics Performance 1 - Image/opacity | The terminal shall support at least 4 simultaneous animations of the opacity property of an Image at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Image [...] opacity [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51100 | 1 | Graphics Performance 1 - Image/transform:scale | The terminal shall support at least 4 simultaneous animations of the CSS transform "scale" property of an Image at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Image [...] transform: scale [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51110 | 1 | Graphics Performance 1 - Text/left,top | The terminal shall support at least 4 simultaneous animations of the left and top CSS properties of a Text at a frame rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Text [...] left, top [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51120 | 1 | Graphics Performance 1 - Text/opacity | The terminal shall support at least 4 simultaneous animations of the opacity property of Text at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Text [...] opacity [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51130 | 1 | Graphics Performance 1 - Text/transform: scale | The terminal shall support at least 4 simultaneous animations of the CSS transform "scale" property of Text at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Text [...] transform: scale [...] 3 | +GRAPHICS_01 | ||
| org.hbbtv_HTML51200 | 1 | Graphics Performance 2 - Frame/background-color | At least 16 simultaneous animations of the background-color CSS property of a Frame (where the colour is opaque) shall be presented at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] background-color [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51210 | 1 | Graphics Performance 2 - Frame/background-color, opacity | The terminal shall support at least 16 simultaneous animations of the background-color CSS property of a Frame (where the colour includes opacity) at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] background-color, opacity [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51220 | 1 | Graphics Performance 2 - Frame/left,top | The terminal shall support at least 16 simultaneous animations of the left and top CSS properties of a Frame at a frame rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] left, top [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51230 | 1 | Graphics Performance 2 - Frame/opacity | The terminal shall support at least 16 simultaneous animations of the opacity property of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] opacity [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51240 | 1 | Graphics Performance 2 - Frame/transform: rotate | The terminal shall support at least 16 simultaneous animations of the CSS transform "rotate" property of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] transform: rotate [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51250 | 1 | Graphics Performance 2 - Frame/transform: scale | The terminal shall support at least 16 simultaneous animations of the CSS transform "scale" property of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] transform: scale [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51260 | 1 | Graphics Performance 2 - Frame/transform: skew | The terminal shall support at least 16 simultaneous animations of the CSS transform "skew" property of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] transform: skew [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51270 | 1 | Graphics Performance 2 - Frame/transform: matrix | The terminal shall support at least 16 simultaneous animations of the CSS transform "matrix" property of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] transform: matrix [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51280 | 1 | Graphics Performance 2 - Frame/border-radius | The terminal shall support at least 16 simultaneous animations of the CSS border-radius property of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] border-radius [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51290 | 1 | Graphics Performance 2 - Frame/width,height | The terminal shall support at least 16 simultaneous animations of the CSS width and height properties of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] width, height [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51300 | 1 | Graphics Performance 2 - Frame/linear-gradient | The terminal shall support at least 16 simultaneous animations of a linear gradient assigned to the CSS background-image property of a Frame at a update rate of at least 25Hz | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Frame [...] linear-gradient [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51310 | 1 | Graphics Performance 2 - Image/left,top | The terminal shall support at least 16 simultaneous animations of the left and top CSS properties of an Image at a frame rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Image [...] left, top [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51320 | 1 | Graphics Performance 2 - Image/opacity | The terminal shall support at least 16 simultaneous animations of the opacity property of an Image at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Image [...] opacity [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51330 | 1 | Graphics Performance 2 - Image/transform:rotate | The terminal shall support at least 16 simultaneous animations of the CSS transform "rotate" property of an Image at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Image [...] transform: rotate [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51340 | 1 | Graphics Performance 2 - Image/transform:scale | The terminal shall support at least 16 simultaneous animations of the CSS transform "scale" property of an Image at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Image [...] transform: scale [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51350 | 1 | Graphics Performance 2 - Image/transform:skew | The terminal shall support at least 16 simultaneous animations of the CSS transform "skew" property of an Image at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Image [...] transform: skew [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51360 | 1 | Graphics Performance 2 - Image/transform:matrix | The terminal shall support at least 16 simultaneous animations of the CSS transform "matrix" property of an Image at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Image [...] transform: matrix [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51370 | 1 | Graphics Performance 2 - Text/left,top | The terminal shall support at least 16 simultaneous animations of the left and top CSS properties of a Text at a frame rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Text [...] left, top [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51380 | 1 | Graphics Performance 2 - Text/opacity | The terminal shall support at least 16 simultaneous animations of the opacity property of Text at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Text [...] opacity [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51390 | 1 | Graphics Performance 2 - Text/transform: rotate | The terminal shall support at least 16 simultaneous animations of the CSS transform "rotate" property of Text at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Text [...] transform: rotate [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51400 | 1 | Graphics Performance 2 - Text/transform: scale | The terminal shall support at least 16 simultaneous animations of the CSS transform "scale" property of Text at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Text [...] transform: scale [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML51410 | 1 | Graphics Performance 2 - Text/transform: skew | The terminal shall support at least 16 simultaneous animations of the CSS transform "skew" property of Text at a update rate of at least 25Hz | 2024-1 2023-3 2023-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 | OIPF-DAE,section 12.1: The following table defines the minimum performance that SHALL be supported for animations using CSS transitions of the properties listed in order for an OITF to advertise support for levels 1 and 2 respectively.Values in this table indicate the number of elements of the specified target being animated simultaneously. The number is expressed as a power of 2, i.e. a value of 3 SHALL mean 4 simultaneous animations, a value of 5 SHALL mean 16 simultaneous animations. HBBTV,section A.2.16: Table 17, "Minimum 2D graphics performance" is modified as follows; [...] Text [...] transform: skew [...] 5 | +GRAPHICS_02 | ||
| org.hbbtv_HTML52000 | 1 | Existence within DOM of one playing HTML5 media element together with two paused HTML5 media elements | Given one HTML5 media element is in the playing state and its data condition meets readyState of HAVE_ENOUGH_DATA, and two HTML5 media elements are in paused state and their data condition meet readyState of HAVE_ENOUGH_DATA, then the terminal shall successfully present the playing media. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 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.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, where each HTML5 media element may be in a readyState of HAVE_CURRENT_DATA or higher. HTML5,section 4.7.10.7: Ready states * media . readyState Returns a value that expresses the current state of the element with respect to rendering the current playback position, from the codes in the list below HAVE_NOTHING (numeric value 0) [...] HAVE_METADATA (numeric value 1) [...] HAVE_CURRENT_DATA (numeric value 2) [...] HAVE_FUTURE_DATA (numeric value 3) [...] HAVE_ENOUGH_DATA (numeric value 4) [...] | |||
| org.hbbtv_HTML52010 | 1 | Forced transition of HTML5 media element to paused state by another HTML5 media element | When one HTML5 media element is in playing state, and one HTML5 media element is in paused state, then the transition to the playing state of the paused element shall force the playing element to transition to the paused state. | 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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.2: If a terminal supports only one HTML5 media element in the playing state, and multiple media elements exist within the DOM, the transition to the playing state of one HTML5 media element shall cause all other media elements to transition to the paused state [...] | -2DECODER | ||
| org.hbbtv_HTML52020 | 1 | Deferred playing state of HTML5 media element when forcing transition of another HTML5 media element to paused state | When a paused HTML5 media element A forces a playing HTML5 media element B into the paused state, then the HTML5 media element A shall not transition to the playing state until HTML5 media element B has entered the paused state. | 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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.2: [...] The transition to the playing state shall be deferred until all other HTML5 media elements have entered the paused state and released their hardware resources. | -2DECODER | ||
| org.hbbtv_HTML52030 | 1 | HTML5 media element pause event and attribute when forced into paused state | When a playing HTML5 media element is forced into the paused state, then it shall emit a "pause" event and set the "paused" attribute to true. | 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 1.7.1 | HBBTV,section 9.6.2: HTML5 media elements that are forced in to the paused state shall emit a "pause" event and set the "paused" attribute to true. | -2DECODER | ||
| org.hbbtv_HTML52040 | 1 | Play/Pause Responsiveness when Switching Media using Multiple HTML5 audio Elements - MPEG-DASH - E-AC-3 (audio-only) | Given an unplayed HTML5 media element referencing MP4 with HE-AAC that begins on an IDR access unit and for which a "canplay" or "canplaythrough" event has already been received; when a playing DASH with E-AC-3 element is paused due to the MP4 HE-AAC starting playing, then the delay between pausing the E-AC-3 element and playing the HE-AAC element shall be less than 250ms. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.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 * the “length” property of the “played” attribute of the second HTML5 media element equals zero (i.e. the second media element has not been played) * the readyState of the second HTML5 media element has reached HAVE_FUTURE_DATA or greater (as indicated by the “canplay” event) * the start position in the media stream of the second video element is a random access point. In the case of H.264 video, a random access point is an instantaneous decoding refresh (IDR) access unit; for AAC audio only streams, a random access point is the start of any access unit. HTML5,section 4.7.10.16: The following events fire on media elements as part of the processing model described above: [...] canplay Event - The user agent can resume playback of the media data, but estimates that if playback were to be started now, the media resource could not be rendered at the current playback rate up to its end without having to stop for further buffering of content. readyState newly increased to HAVE_FUTURE_DATA or greater. canplaythrough Event - The user agent estimates that if playback were to be started now, the media resource could be rendered at the current playback rate all the way to its end without having to stop for further buffering. readyState is newly equal to HAVE_ENOUGH_DATA. [...] play Event - The element is no longer paused. Fired after the play() method has returned, or when the autoplay attribute has caused playback to begin. paused is newly false. pause Event - The element has been paused. Fired after the pause() method has returned. paused is newly true. | +EAC3 | ||
| org.hbbtv_HTML52050 | 1 | Play/Pause Responsiveness when Switching Media using Multiple HTML5 Video Elements - MPEG-DASH - AVC | Given an unplayed HTML5 media element referencing MP4 with AVC that begins on an IDR access unit and for which a "canplay" or "canplaythrough" event has already been received; when a playing DASH with HEVC element is paused due to the MP4 AVC starting playing, then the delay between pausing the HEVC element playing the AVC element shall be less than 250ms. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 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 * the “length” property of the “played” attribute of the second HTML5 media element equals zero (i.e. the second media element has not been played) * the readyState of the second HTML5 media element has reached HAVE_FUTURE_DATA or greater (as indicated by the “canplay” event) * the start position in the media stream of the second video element is a random access point. In the case of H.264 video, a random access point is an instantaneous decoding refresh (IDR) access unit; for AAC audio only streams, a random access point is the start of any access unit. HTML5,section 4.7.10.16: The following events fire on media elements as part of the processing model described above: [...] canplay Event - The user agent can resume playback of the media data, but estimates that if playback were to be started now, the media resource could not be rendered at the current playback rate up to its end without having to stop for further buffering of content. readyState newly increased to HAVE_FUTURE_DATA or greater. canplaythrough Event - The user agent estimates that if playback were to be started now, the media resource could be rendered at the current playback rate all the way to its end without having to stop for further buffering. readyState is newly equal to HAVE_ENOUGH_DATA. [...] play Event - The element is no longer paused. Fired after the play() method has returned, or when the autoplay attribute has caused playback to begin. paused is newly false. pause Event - The element has been paused. Fired after the pause() method has returned. paused is newly true. | -2DECODER +HEVC_HD_8 | |
| org.hbbtv_HTML52060 | 1 | Playback of paused audio HTML5 media element from next frame | When resuming the playback of a HTML5 media element referencing E-AC-3 that has previously been paused, the terminal shall start playback at or before the frame following the pause position. | 2024-1 2023-3 2023-2 2023-1 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 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. | +EAC3 | ||
| org.hbbtv_HTML52070 | 1 | Playback of paused video HTML5 media element from next frame | When resuming the playback of a HTML5 media element referencing HEVC that has previously been paused, the terminal shall start playback at or before the IDR following the pause position. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 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 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. | +HEVC_HD_8 | ||
| org.hbbtv_HTML52080 | 1 | HTTP Chunked Transfer Coding - HTML5 - HEVC - Video Playback | When requested to present a HEVC HTML5 media element referencing a Unicast stream over HTTP 1.1, and the content is delivered using HTTP Chunked Transfer Coding, then the whole content is successfully played without artefacts. | 2024-1 2023-3 2023-2 2022-3 2022-2 2022-1 2021-3 2020-2 2019-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 7.3.2.1: Unicast streaming using HTTP 1.1 shall be supported [...] HTTP chunked transfer coding shall be supported [...] HBBTV,section 9.6.1: 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 [...] | +HEVC_HD_8 | ||
| org.hbbtv_HTML52090 | 1 | HTML5 media element seek using Content-range header | When requested to seek to an unbuffered position in a HEAAC HTML5 media element referencing a large (much greater than 10 seconds) Unicast stream over HTTP 1.1, then the terminal shall make a Content-range header request that encompasses the seek position. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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. 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. 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 [...] | |||
| org.hbbtv_HTML54000 | 1 | HTML5 delivered by DSM-CC | The first page of a broadcast-related application is an HTML5 page carried in an object carousel. When the application is launched, the page is loaded and processed as an HTML5 page (and not as an HTML4/XHTML page). | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: Terminals shall support the DOCTYPE defined for HTML5 in the HTML5 specification as profiled by the OIPF Web Standards TV Profile [i.6] ... Terminals shall use the DOCTYPE to determine the type of documents loaded from a carousel or CICAM. | |||
| org.hbbtv_HTML5-DASH001 | 1 | getStartDate HTML5 media object and static DASH MPD | The terminal shall use a relative origin of media timeline for a HTML5 media object with a static MPD. Call of getStartDate() shall return NaN. | 2024-1 2023-3 2022-3 2022-2 2022-1 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,section 9.4.2: For a static MPD or a dynamic MPD containing no regular Period, getStartDate() shall return a Date object that represents the time value NaN, in the same manner as required by HTML5 when no explicit date and time is available HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL ... referring to an MPD. | ||
| org.hbbtv_HTML5-DASH002 | 1 | getStartDate HTML5 media object and dynamic DASH MPD | The terminal shall correctly set the origin of media timeline of an HTML5 media object with a dynamic MPD. Call of getStartDate() shall return the @availabilityStartTime of the MPD. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: For a dynamic MPD, getStartDate() shall return a Date object representing the value of MPD@availabilityStartTime plus the PeriodStart time (see clause 5.3.2.1 of MPEG DASH ISO/IEC 23009-1 [29]) of the first regular Period when the MPD was first loaded. NOTE 2: This provides an absolute time reference for the start of the media timeline used by the HTML5 media element. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL ... referring to an MPD. | |||
| org.hbbtv_HTML5-DASH003 | 1 | getStartDate HTML5 media object and dynamic DASH MPD: when 1st period is removed | The terminal shall correctly set the origin of media timeline of an HTML5 media object with a dynamic MPD, after an MPD update where the first period is removed. Call of getStartDate() shall return the start time of the first (removed) Period. | 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 9.4.2: The origin of the media timeline used by HTML5 media elements (i.e. the <audio> and <video> elements) 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 HTML5 media element source is changed or the load() method is called. Note 1: implementations must be able to handle past periods being removed from a dynamic MPD without changing the origin of the HTML5 media element’s timeline. [...] For a dynamic MPD, getStartDate() shall return a Date oject representing the value of MPD@availabilityStartTime plus the PeriodStart time (see clause 5.3.2.1 of MPEG DASH ISO/IEC 23009-1 [29]) of the first regular Period when the MPD was first loaded. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL ... referring to an MPD. | |||
| org.hbbtv_HTML5-DASH004 | 1 | getStartDate HTML5 media object and change the source to new DASH MPD. | The terminal shall update the origin of media timeline of an HTML5 media object with a dynamic MPD, when the src attribute of the video changes to a different MPD. Call of getStartDate() shall return the @availabilityStartTime of the new MPD. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: The origin of the media timeline used by HTML5 media elements (i.e. the <audio> and <video> elements) 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 HTML5 media element source is changed or the load() method is called. Note 1: implementations must be able to handle past periods being removed from a dynamic MPD without changing the origin of the HTML5 media element’s timeline. [...] For a dynamic MPD, getStartDate() shall return a Date oject representing the value of MPD@availabilityStartTime plus the PeriodStart time (see clause 5.3.2.1 of MPEG DASH ISO/IEC 23009-1 [29]) of the first regular Period when the MPD was first loaded. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL ... referring to an MPD. | |||
| org.hbbtv_HTML5-DASH005 | 1 | getStartDate HTML5 media object and call "load", src points to DASH MPD. | The terminal shall update the origin of the media timeline of an HTML5 media object with a dynamic MPD, when load() is called to update the MPD. Call of getStartDate() shall return the @availabilityStartTime of the new MPD. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: The origin of the media timeline used by HTML5 media elements (i.e. the <audio> and <video> elements) 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 HTML5 media element source is changed or the load() method is called. Note 1: implementations must be able to handle past periods being removed from a dynamic MPD without changing the origin of the HTML5 media element’s timeline. [...] For a dynamic MPD, getStartDate() shall return a Date oject representing the value of MPD@availabilityStartTime plus the PeriodStart time (see clause 5.3.2.1 of MPEG DASH ISO/IEC 23009-1 [29]) of the first regular Period when the MPD was first loaded. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL ... referring to an MPD. | |||
| org.hbbtv_HTML5-DASH010 | 1 | duration parameter of HTML5 media object and static DASH MPD | The terminal shall set duration of media timeline of the HTML5 media object to MPD@mediaPresentationDuration. MPD@type is static. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: For a static MPD, the duration attribute shall be the value of MPD@mediaPresentationDuration if present or the PeriodStart time of the last Period determined according to clause 5.3.2.1 of MPEG DASH [29] plus the value of Period@duration for the last Period. The duration shall be calculated after resolution of any xlink references with @xlink:actuate set to "onLoad". HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL [...] referring to an MPD | |||
| org.hbbtv_HTML5-DASH011 | 1 | duration parameter of HTML5 media object and dynamic DASH MPD | The terminal shall set duration of media timeline of the HTML5 media object to MPD@mediaPresentationDuration. MPD@type is dynamic. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4.2: For a dynamic MPD, the duration attribute shall be the value of MPD@mediaPresentationDuration if present, otherwise it shall be reported as positive infinity (indicating an indeterminate duration) HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL [...] referring to an MPD | |||
| org.hbbtv_HTML5-DASH012 | 1 | duration parameter of HTML5 media object and updating @mediaPresentationDuration in dynamic DASH MPD | The duration parameter of HTML5 media object shall be updated when @mediaPresentationDuration is changed. MPD@type is dynamic. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4.2: For a dynamic MPD, the duration attribute shall be the value of MPD@mediaPresentationDuration if present, otherwise it shall be reported as positive infinity (indicating an indeterminate duration) HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL [...] referring to an MPD | |||
| org.hbbtv_HTML5-DASH013 | 1 | duration parameter of HTML5 media object equals positive infinity if dynamic DASH MPD does not contain @mediaPresentationDuration | The duration parameter of HTML5 media object shall be positive infinity when the MPD does not contain @mediaPresentationDuration. MPD@type is dynamic. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4.2: For a dynamic MPD, the duration attribute shall be the value of MPD@mediaPresentationDuration if present, otherwise it shall be reported as positive infinity (indicating an indeterminate duration) HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL [...] referring to an MPD | |||
| org.hbbtv_HTML5-DASH014 | 1 | duration parameter of HTML5 media object and removing @mediaPresentationDuration in dynamic DASH MPD | The duration parameter of HTML5 media object shall be changed to positive infinity, when @mediaPresentationDuration is not present after the MPD update. MPD@type is dynamic. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4.2: For a dynamic MPD, the duration attribute shall be the value of MPD@mediaPresentationDuration if present, otherwise it shall be reported as positive infinity (indicating an indeterminate duration) HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL [...] referring to an MPD | |||
| org.hbbtv_HTML5-DASH015 | 1 | duration parameter of HTML5 media object undefined and adding @mediaPresentationDuration in dynamic DASH MPD | The duration parameter of HTML5 media object shall be correctly set, when before update the @mediaPresentationDuration is not present and after MPD update @mediaPresentationDuration contains valid value. MPD@type is dynamic. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.4.2: For a dynamic MPD, the duration attribute shall be the value of MPD@mediaPresentationDuration if present, otherwise it shall be reported as positive infinity (indicating an indeterminate duration) HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL [...] referring to an MPD | |||
| org.hbbtv_HTML5-DASH016 | 1 | seekable parameter of HTML5 media object and dynamic DASH MPD with @timeShiftBufferDepth | The seekable parameter of HTML5 media object shall be set accordingly to MPD@timeShiftBufferDepth. MPD@type is dynamic. | 2024-1 2023-3 2023-2 2023-1 2022-3 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 | TS-103-285,section 10.9.2: If there is no MPD Anchor and the MPD@type attribute is set to "dynamic": [...] If the MPD@suggestedPresentationDelay attribute is present then the Player shall begin playback from a point such that the media is being presented no more than the greater of the value of the @suggestedPresentationDelay attribute and 45 seconds behind the time at which it becomes available. NOTE: The value of 45 seconds used in the above bullet points has been deliberately chosen to be three times the maximum segment duration for audio or video segments specified in clause 4.5. HBBTV,section 9.4.2: When a dynamic MPD contains an MPD@timeShiftBufferDepth attribute, the media element’s seekable attribute shall take values that map to the full range of the segments available in the time shift buffer taking into account any safety margins (see [45] clause 4.7). HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. | |||
| org.hbbtv_HTML5-DASH017 | 1 | seekable parameter of HTML5 media object and dynamic DASH MPD with updated @timeShiftBufferDepth | The seekable parameter of HTML5 media object shall be updated accordingly to change of MPD@timeShiftBufferDepth. MPD@type is dynamic. | 2024-1 2023-3 2023-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 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.9.2: If there is no MPD Anchor and the MPD@type attribute is set to "dynamic": [...] If the MPD@suggestedPresentationDelay attribute is present then the Player shall begin playback from a point such that the media is being presented no more than the greater of the value of the @suggestedPresentationDelay attribute and 45 seconds behind the time at which it becomes available. NOTE: The value of 45 seconds used in the above bullet points has been deliberately chosen to be three times the maximum segment duration for audio or video segments specified in clause 4.5. HBBTV,section 9.4.2: When a dynamic MPD contains an MPD@timeShiftBufferDepth attribute, the media element’s seekable attribute shall take values that map to the full range of the segments available in the time shift buffer taking into account any safety margins (see [45] clause 4.7). HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. TS-103-285,section 9.1.4: If the MPD@type attribute is set to 'dynamic' and the MPD contains a @minimumUpdatePeriod attribute, then this permits the server to update the MPD. Detailed MPD update procedures are provided in ISO/IEC 23009-1 [1], clause 5.4. | ||
| org.hbbtv_HTML5-DASH018 | 1 | seekable parameter of HTML5 media object and static DASH MPD | The seekable parameter of HTML5 media object shall reflect the full content. MPD@type is static. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: For a static MPD [...] the seekable attribute shall reflect the full extent of the media timeline currently defined by the MPD. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. | |||
| org.hbbtv_HTML5-DASH019 | 1 | seekable parameter of HTML5 media object and dynamic DASH MPD without MPD@timeShiftBufferDepth | The seekable parameter of HTML5 media object shall reflect the full content if MPD@timeShiftBufferDepth is not present. MPD@type is dynamic. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: [...] where no MPD@timeShiftBufferDepth attribute is present in a dynamic MPD, the seekable attribute shall reflect the full extent of the media timeline currently defined by the MPD. Note that for a dynamic MPD, this range may not begin at time zero if Periods have been removed since the MPD was first retrieved. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. | |||
| org.hbbtv_HTML5-DASH020 | 1 | seekable parameter of HTML5 media object and dynamic DASH MPD without MPD@timeShiftBufferDepth, removing period | The seekable parameter of HTML5 media object shall reflect the removing of period if MPD@timeShiftBufferDepth is not present. MPD@type is dynamic. | 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 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.2: [...] where no MPD@timeShiftBufferDepth attribute is present in a dynamic MPD, the seekable attribute shall reflect the full extent of the media timeline currently defined by the MPD. Note that for a dynamic MPD, this range may not begin at time zero if Periods have been removed since the MPD was first retrieved. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. TS-103-285,section 9.1.4: If the MPD@type attribute is set to 'dynamic' and the MPD contains a @minimumUpdatePeriod attribute, then this permits the server to update the MPD. Detailed MPD update procedures are provided in ISO/IEC 23009-1 [1], clause 5.4. | |||
| org.hbbtv_HTML5-DASH021 | 1 | seekable parameter of HTML5 media object and static DASH MPD, two periods | The seekable parameter of HTML5 media object shall reflect the full content, if MPD contains two periods. MPD@type is static. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: For a static MPD [...] the seekable attribute shall reflect the full extent of the media timeline currently defined by the MPD. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. | |||
| org.hbbtv_HTML5-DASH022 | 1 | Pause HTML5 media object - static DASH MPD | Calling pause() method of HTML5 media object shall trigger 'pause' event, set 'paused' property to true and pause the video playback when MPD@type is static | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.1: Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD. HTML5,section 4.7.10.8: When the pause() method is invoked, and when the user agent is required to pause the media element, the user agent must run the following steps: [...] 3. If the media element's paused attribute is false, run the following steps: 1.Change the value of paused to true. [...] 3.Queue a task to fire a simple event named pause at the element. | |||
| org.hbbtv_HTML5-DASH023 | 1 | Play paused HTML5 media object - static DASH MPD | Calling play() method of HTML5 media object shall trigger 'play' event, set 'paused' property to false and start the video playback when playback was previously paused and MPD type is static. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.1: Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD. HTML5,section 4.7.10.8: When the play() method on a media element is invoked, the user agent must run the following steps. [...] 4. If the media element's paused attribute is true, run the following sub-steps: 1. Change the value of paused to false. [...] 3. Queue a task to fire a simple event named play at the element. | |||
| org.hbbtv_HTML5-DASH024 | 1 | Play HTML5 media object - static DASH MPD | Calling play() method of HTML5 media object shall trigger 'play' and 'playing' events, set 'paused' property to false and start the video playback when MPD@type is static | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.1: Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD. HTML5,section 4.7.10.8: The paused attribute represents whether the media element is paused or not. The attribute must initially be true. [...] When the play() method on a media element is invoked, the user agent must run the following steps. [...] 4. If the media element's paused attribute is true, run the following sub-steps: 1. Change the value of paused to false. [...] 3. Queue a task to fire a simple event named play at the element. | |||
| org.hbbtv_HTML5-DASH025 | 1 | Play paused HTML5 media object - dynamic DASH MPD | Calling play() method of HTML5 media object shall trigger 'play' event, set 'paused' property to false and start the video playback when playback was previously paused and MPD type is dynamic. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 9.6.1: Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD. HTML5,section 4.7.10.8: When the play() method on a media element is invoked, the user agent must run the following steps. [...] 4. If the media element's paused attribute is true, run the following sub-steps: 1. Change the value of paused to false. [...] 3. Queue a task to fire a simple event named play at the element. | |||
| org.hbbtv_HTML5-DASH026 | 1 | play paused HTML5 media object and dynamic DASH MPD, play position outside time shift buffer | MPEG DASH content with MPD@type=dynamic is being presented in an HTML5 media element and playback is paused and the current play position is no longer in the time shift buffer defined by MPD@timeShiftBufferDepth. When the play() method is called, an error Event with code MEDIA_ERR_NETWORK is raised. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: After a live DASH stream is paused, if the current play position (the currentTime attribute) is no longer in the time shift buffer (as determined by the MPD@timeShiftBufferDepth) when the video playback is attempted to be resumed, then an error Event with code MEDIA_ERR_NETWORK shall be raised. The application can then determine the new seekable range and act accordingly. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. | |||
| org.hbbtv_HTML5-DASH027 | 1 | play paused HTML5 media object and dynamic DASH MPD, play position in removed period | MPEG DASH content with MPD@type=dynamic is being presented in an HTML5 media element and playback is paused and the current play position is inside the removed period (no longer in the time shift buffer defined by MPD@timeShiftBufferDepth). When the play() method is called, an error Event with code MEDIA_ERR_NETWORK is raised. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: NOTE 4: For a dynamic MPD, this range may not begin at time zero if Periods have been removed since the MPD was first retrieved. ... After a live DASH stream is paused, if the current play position (the currentTime attribute) is no longer in the time shift buffer (as determined by the MPD@timeShiftBufferDepth) when the video playback is attempted to be resumed, then an error Event with code MEDIA_ERR_NETWORK shall be raised. The application can then determine the new seekable range and act accordingly. HBBTV,section 9.6.1: The media elements from HTML5 [54] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. | |||
| org.hbbtv_HTML5-DASH035 | 1 | Start Position of HTML5 media object - MPD DASH Anchor with 'period' key only | HTML5 media object shall begin playback at the requested position when 'period' key of MPD Anchor is used, 't' key is not present and MPD@type is static. | 2024-1 2023-3 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 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,section 9.4.2: Start Position: The start position shall be determined according to the requirements laid out in ETSI TS 103 285 [45], clause 10.9.2. [...] This is consistent with the requirements of HTML5 [54] which includes the following step when processing media data: "If either the media resource or the address of the current media resource indicate a particular start time, then set the initial playback position to that time" HBBTV,section 9.6.1: The media element from HTML5 [54] is included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the video element as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD. TS-103-285,section 10.9.2: If an MPD Anchor is present, the Player shall begin playback at the position indicated by that Anchor. DASH,section C.4.1: An MPD anchor is [...] a time offset from the start of a period on the media timeline. These are expressed using URI fragment syntax. DASH,section C.4.2: t - Time or time range in the same format as defined in Media Fragments URI - Time since the beginning of the period indicated by the period parameter. If the t parameter is not present, its default value is 0. DASH,section C.4.2: period - String - Period@id. If period parameter is not present, the default value is the ID of the Period with the earliest PeriodStart. | |||
| org.hbbtv_HTML5-DASH036 | 1 | Start Position of HTML5 media object - MPD DASH Anchor with 'period' and 't' keys | HTML5 media object shall begin playback at the requested position when 'period' and 't' keys of MPD Anchor are used together and MPD@type is static | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 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 9.4.2: Start Position: The start position shall be determined according to the requirements laid out in ETSI TS 103 285 [45], clause 10.9.2. [...] This is consistent with the requirements of HTML5 [54] which includes the following step when processing media data: "If either the media resource or the address of the current media resource indicate a particular start time, then set the initial playback position to that time" HBBTV,section 9.6.1: The media element from HTML5 [54] is included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the video element as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD. TS-103-285,section 10.9.2: If an MPD Anchor is present, the Player shall begin playback at the position indicated by that Anchor. DASH,section C.4.1: An MPD anchor is [...] a time offset from the start of a period on the media timeline. These are expressed using URI fragment syntax. DASH,section C.4.2: t - Time or time range in the same format as defined in Media Fragments URI - Time since the beginning of the period indicated by the period parameter. If the t parameter is not present, its default value is 0. DASH,section C.4.2: period - String - Period@id. If period parameter is not present, the default value is the ID of the Period with the earliest PeriodStart. | ||
| org.hbbtv_HTML5-DASH037 | 1 | Start Position of HTML5 media object, static MPD DASH | HTML5 media object shall begin playback at the beginning of the MPD, if there is no MPD Anchor and MPD@type is static. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-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.2: Start Position: The start position shall be determined according to the requirements laid out in ETSI TS 103 285 [45], clause 10.9.2. [...] This is consistent with the requirements of HTML5 [54] which includes the following step when processing media data: "If either the media resource or the address of the current media resource indicate a particular start time, then set the initial playback position to that time" HBBTV,section 9.6.1: The media element from HTML5 [54] is included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the video element as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD. TS-103-285,section 10.9.2: If there is no MPD Anchor and the MPD@type attribute is set to "static" the Player shall begin playback at the beginning of the MPD | |||
| org.hbbtv_HTML5-DASH038 | 1 | Start Position of HTML5 media object, dynamic MPD DASH, MPD@suggestedPresentationDelay not present | HTML5 media object shall begin playback from a point such that the media is being presented no more than 45 seconds behind the time at which it becomes available. There is no MPD Anchor, MPD@suggestedPresentationDelay not present. MPD@type is 'dynamic'. | 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 9.4.2: Start Position The start position shall be determined according to the requirements laid out in [45] clause 10.9.2. For some content, playback will start at the 'live edge'. This is consistent with the requirements of HTML5 [3] which includes the following step when processing media data: "If either the media resource or the address of the current media resource indicate a particular start time, then set the initial playback position to that time" HBBTV,section 9.6.1: The media elements from HTML5 [3] are included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the media elements as follows; ..... Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL either directly referring to an MPD or referring to a content access streaming descriptor that in turn refers to the MPD. TS-103-285,section 10.9.2: The position from which a Player begins playback depends upon the MPD attributes @type and @suggestedPresentationDelay, together with any signalling in an MPD Anchor. Specifically: ....... * If there is no MPD Anchor and the MPD@type attribute is set to "dynamic": - If the MPD@suggestedPresentationDelay attribute is not present, then the Player shall begin playback from a point such that the media is being presented no more than 45 seconds behind the time at which it becomes available. | |||
| org.hbbtv_HTML5-DASH134 | 1 | Start Position of HTML5 media object - MPD DASH Anchor with 't' key only, dynamic MPD | HTML5 media object shall begin playback at the requested position when 't' key of MPD Anchor is used and 'period' key is not present and MPD@type is 'dynamic'. | 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 9.4.2: Start Position: The start position shall be determined according to the requirements laid out in ETSI TS 103 285 [45], clause 10.9.2. [...] This is consistent with the requirements of HTML5 [54] which includes the following step when processing media data: "If either the media resource or the address of the current media resource indicate a particular start time, then set the initial playback position to that time" HBBTV,section 9.6.1: The media element from HTML5 [54] is included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the video element as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD. TS-103-285,section 10.9.2: If an MPD Anchor is present, the Player shall begin playback at the position indicated by that Anchor. DASH,section C.4.1: An MPD anchor is [...] a time offset from the start of a period on the media timeline. These are expressed using URI fragment syntax. DASH,section C.4.2: t - Time or time range in the same format as defined in Media Fragments URI - Time since the beginning of the period indicated by the period parameter. If the t parameter is not present, its default value is 0. DASH,section C.4.2: period - String - Period@id. If period parameter is not present, the default value is the ID of the Period with the earliest PeriodStart. | |||
| org.hbbtv_HTML5-DASH135 | 1 | Start Position of HTML5 media object - MPD DASH Anchor with 'period' key only, dynamic MPD | HTML5 media object shall begin playback at the requested position when 'period' key of MPD Anchor is used, 't' key is not present and MPD@type is 'dynamic'. | 2024-1 2023-3 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-3 2020-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.4.2: Start Position: The start position shall be determined according to the requirements laid out in ETSI TS 103 285 [45], clause 10.9.2. [...] This is consistent with the requirements of HTML5 [54] which includes the following step when processing media data: "If either the media resource or the address of the current media resource indicate a particular start time, then set the initial playback position to that time" HBBTV,section 9.6.1: The media element from HTML5 [54] is included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the video element as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD. TS-103-285,section 10.9.2: If an MPD Anchor is present, the Player shall begin playback at the position indicated by that Anchor. DASH,section C.4.1: An MPD anchor is [...] a time offset from the start of a period on the media timeline. These are expressed using URI fragment syntax. DASH,section C.4.2: t - Time or time range in the same format as defined in Media Fragments URI - Time since the beginning of the period indicated by the period parameter. If the t parameter is not present, its default value is 0. DASH,section C.4.2: period - String - Period@id. If period parameter is not present, the default value is the ID of the Period with the earliest PeriodStart. | |||
| org.hbbtv_HTML5-DASH136 | 1 | Start Position of HTML5 media object - MPD DASH Anchor with 'period' and 't' keys, dynamic MPD | HTML5 media object shall begin playback at the requested position when 'period' and 't' keys of MPD Anchor are used together and MPD@type is 'dynamic'. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-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 9.4.2: Start Position: The start position shall be determined according to the requirements laid out in ETSI TS 103 285 [45], clause 10.9.2. [...] This is consistent with the requirements of HTML5 [54] which includes the following step when processing media data: "If either the media resource or the address of the current media resource indicate a particular start time, then set the initial playback position to that time" HBBTV,section 9.6.1: The media element from HTML5 [54] is included in the present document through the reference to the OIPF DAE specification [1]. Terminals shall support presenting content using the video element as follows; [...] Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported identified by an HTTP URL referring to an MPD. TS-103-285,section 10.9.2: If an MPD Anchor is present, the Player shall begin playback at the position indicated by that Anchor. DASH,section C.4.1: An MPD anchor is [...] a time offset from the start of a period on the media timeline. These are expressed using URI fragment syntax. DASH,section C.4.2: t - Time or time range in the same format as defined in Media Fragments URI - Time since the beginning of the period indicated by the period parameter. If the t parameter is not present, its default value is 0. DASH,section C.4.2: period - String - Period@id. If period parameter is not present, the default value is the ID of the Period with the earliest PeriodStart. | ||
| org.hbbtv_HTTP0010 | 1 | HTTP - If-Modified-Since | When an application makes two HTTP requests for content, and the first request is for content with a modification time more recent than the specified time, and the second request is for content with a modification time older than the specified time, and the terminal has cached both items of content, the terminal retrieves the first content from the server and the second content from its cache. | 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.2.6: Terminals shall observe the caching rules defined in HTTP/1.1 [6] including support for issuing requests for cached content using the "If-Modified-Since" header (where a server provides a Last-Modified header) and the "If-None-Match" HTTP header (where a server provides an ETag header). | |||
| org.hbbtv_HTTP0020 | 1 | HTTP - If-None-Match - content matches | When an application makes an HTTP request for content, and the terminal has cached the content with an ETag value, and the specified ETag value matches the requested content, the terminal retrieves the content from its cache. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-1 2020-3 2020-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 7.3.2.6: Terminals shall observe the caching rules defined in HTTP/1.1 [6] including support for issuing requests for cached content using the "If-Modified-Since" header (where a server provides a Last-Modified header) and the "If-None-Match" HTTP header (where a server provides an ETag header). | |||
| org.hbbtv_HTTP0030 | 1 | HTTP - If-None-Match - content does not match | When an application makes an HTTP request for content, and the terminal has cached the content with an ETag value, and the server has been updated so that the specified ETag value no longer matches the requested content, the terminal retrieves the content from the server. | 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.3.2.6: Terminals shall observe the caching rules defined in HTTP/1.1 [6] including support for issuing requests for cached content using the "If-Modified-Since" header (where a server provides a Last-Modified header) and the "If-None-Match" HTTP header (where a server provides an ETag header). | |||
| org.hbbtv_HTTP0050 | 1 | HTTP - 301 Moved Permanently | When an application makes an HTTP request for an http: URI and receives a response of 301 Moved Permanently with a Location header indicating an http: URI, the terminal follows the redirect. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The terminal shall support responses with a status code of "301 Moved Permanently", "302 Found", "303 See Other" and "307 Temporary Redirect" by using the temporary URL given in the Location field. [...] For the avoidance of doubt, these requirements shall apply to both http: and https: URIs and redirects between these. | |||
| org.hbbtv_HTTP0060 | 1 | HTTP - 302 Found | When an application makes an HTTP request for an http: URI and receives a response of 302 Found with a Location header indicating an https: URI, the terminal follows the redirect. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The terminal shall support responses with a status code of "301 Moved Permanently", "302 Found", "303 See Other" and "307 Temporary Redirect" by using the temporary URL given in the Location field. [...] For the avoidance of doubt, these requirements shall apply to both http: and https: URIs and redirects between these. | |||
| org.hbbtv_HTTP0070 | 1 | HTTP - 303 See Other | When an application is loaded from an http: URI and then makes an HTTP request for an https: URI and receives a response of 303 See Other with a Location header indicating an http: URI, the terminal follows the redirect. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The terminal shall support responses with a status code of "301 Moved Permanently", "302 Found", "303 See Other" and "307 Temporary Redirect" by using the temporary URL given in the Location field. [...] For the avoidance of doubt, these requirements shall apply to both http: and https: URIs and redirects between these. | |||
| org.hbbtv_HTTP0080 | 1 | HTTP - 307 Temporary Redirect | When an application makes an HTTP request for an https: URI and receives a response of 307 Temporary Redirect with a Location header indicating an https: URI, the terminal follows the redirect. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The terminal shall support responses with a status code of "301 Moved Permanently", "302 Found", "303 See Other" and "307 Temporary Redirect" by using the temporary URL given in the Location field. [...] For the avoidance of doubt, these requirements shall apply to both http: and https: URIs and redirects between these. | |||
| org.hbbtv_HTTP0090 | 1 | HTTP redirections - browser | When an application is loaded from an http: URI and then the browser requests content which results in a chain of 10 HTTP redirects, including both http: and https: URIs, the content is retrieved. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The terminal shall support at least 10 redirections for requests made from the browser, and 3 redirections for requests made by media player functions. [...] For the avoidance of doubt, these requirements shall apply to both http: and https: URIs and redirects between these. | |||
| org.hbbtv_HTTP0100 | 1 | HTTP redirections - media player | When the media player requests content which results in a chain of 3 HTTP redirects, including both http: and https: URIs, the content is retrieved. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The terminal shall support at least 10 redirections for requests made from the browser, and 3 redirections for requests made by media player functions. [...] For the avoidance of doubt, these requirements shall apply to both http: and https: URIs and redirects between these. | |||
| org.hbbtv_HTTP0110 | 1 | HTTP - infinite loop detection | When an application makes an HTTP request which results in an infinite loop of redirects, including both http: and https: URIs, the terminal terminates the request. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: Infinite loops shall be detected. Terminals shall not follow them indefinitely. This may be achieved by detecting more than 10 redirects from an original request. [...] For the avoidance of doubt, these requirements shall apply to both http: and https: URIs and redirects between these. | |||
| org.hbbtv_HTTP0120 | 1 | HTTP cookies over TLS | When an application makes an HTTP request which includes a cookie with the Secure attribute set, and the request results in a non-TLS connection, the cookie is not transmitted. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.8: The following requirements apply to HTTP cookies that have the Secure attribute set as defined in RFC 6265 [24] and are stored by the browser. [...] Such cookies shall only be transmitted over a TLS connection. | |||
| org.hbbtv_HTTP0130 | 1 | Simultaneous HTTP connections | An application has an open HTTP connection for media streaming. When the application makes two additional HTTP requests, and the first request takes a long time to complete, the second request is not delayed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.7: Terminals shall support at least two simultaneous HTTP connections for application content in addition to any connections required for HTTP-based media streaming. Specifically, an HTTP request to one server that takes time to complete shall not delay a second HTTP request to a different server if no other application-initiated HTTP requests (other than for media streaming purposes) are in progress. For the avoidance of doubt, these requirements shall apply to HTTP requests using any combination of http: and https: URIs. | |||
| org.hbbtv_HTTP0140 | 1 | HTTP cookie store | A broadcast-related application makes an HTTP request which results in a cookie being stored by the terminal. When a broadcast-independent application makes an HTTP request to a server with the same origin, the cookie is transmitted. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: Subject to the requirements of the same origin policy, the same store of cookies shall be accessible to an HbbTV application regardless of whether it is broadcast-related or broadcast-independent, and regardless of the mechanism by which the application was launched, such as any of the mechanisms listed in clause 6.2.2.6.2. | |||
| org.hbbtv_INLINE0010 | 1 | Inline images - HTML | An HTML document contains an img element, where the src attribute is a data: URL containing Base64 characters and whitespace and represents an image. The image is presented. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The data: URL scheme defined in RFC 2397 [62] shall be supported for inline images in HTML and CSS. | |||
| org.hbbtv_INLINE0020 | 1 | Inline images - CSS | A CSS stylesheet contains a rule applying the background-image property to an element, where the property value is a data: URL containing Base64 characters and whitespace and represents an image. The image is presented. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The data: URL scheme defined in RFC 2397 [62] shall be supported for inline images in HTML and CSS. | |||
| org.hbbtv_INLINE0030 | 1 | Inline images - URI size limit | An HTML document contains an img element, where the src attribute is a data: URL with length 22 000 characters. The image is presented. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The data: URL scheme defined in RFC 2397 [62] shall be supported for inline images in HTML and CSS. [...] Terminals shall support data: URLs of at least 22 000 characters conveying images that are up to 16 384 bytes in size. | |||
| org.hbbtv_INLINE0040 | 1 | Inline images - image size limit | An HTML document contains an img element, where the src attribute is a data: URL representing an image with size 16 384 bytes. The image is presented. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The data: URL scheme defined in RFC 2397 [62] shall be supported for inline images in HTML and CSS. [...] Terminals shall support data: URLs of at least 22 000 characters conveying images that are up to 16 384 bytes in size. | |||
| org.hbbtv_JSON-RPC-WSS0010 | 1 | The JSON-RPC WebSocketServer is available on localhost and is secure | An application confirms that only a single <json_rpc_server> element exists in the xmlCapabilities. Then the application confirms that the location of the JSON-RPC WebSocket service endpoint is only available on a potentially trustworthy localhost network binding. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 15.2.1: The communication path between the application and TV OS is realised by JSON-RPC messages (defined in clause 9.9.3) being carried over a WebSocket connection between the HbbTV application and a local WebSocket Server (defined in clause 9.9.2), which acts on behalf of the terminal. HBBTV,section 15.2.1: Terminals shall: - provide a JSON-RPC WebSocket server as defined in clause 9.9.2 HBBTV,section 9.9.2.1: Terminals with an internal JSON-RPC WebSocket server for either the Accessibility Control APIs (see clause 15) or Voice Interaction (see clause 16) shall include in the xmlCapabilities one element of the following form to indicate the presence of the WebSocket server, and its location: <json_rpc_server url="ws-url" version="spec-version" /> HBBTV,section 9.9.2.2.1: The terminal shall provide a WebSocket server URL which is a potentially trustworthy URL which shall be based on a localhost origin as explained above. HBBTV,section 9.9.2.2.2: To prevent the possibility of connections from devices on the local network, the JSON-RPC WebSocket server shall not be accessible from the local network. HBBTV,section 10.2.4.7: Terminals supporting the JSON-RPC WebSocket server shall include one and only one <json_rpc_server> element: <json_rpc_server url="ws-url" version="spec-version"/> Where ws-url is the URL of the local JSON-RPC WebSocketServer and spec-version is the specification version that the server supports as described in 9.9.2.1. | |||
| org.hbbtv_JSON-RPC-WSS0020 | 1 | The JSON-RPC WSS endpoint URL is static for the lifetime of an application and also regenerated at terminal startup | An application determines the JSON-RPC WSS endpoint location within 5 seconds of starting, then does some other activities for a period of over 30 seconds, and then successfully confirms that the JSON-RPC WSS endpoint location is the same as previously determined. Then the terminal is restarted and the application is run a second time, and the JSON-RPC WSS endpoint shall be different from the previously determined value obtained during the first run. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 15.2.1: Terminals shall: - provide a JSON-RPC WebSocket server as defined in clause 9.9.2 HBBTV,section 10.2.4.7: Terminals supporting the JSON-RPC WebSocket server shall include one and only one <json_rpc_server> element: <json_rpc_server url="ws-url" version="spec-version"/> Where ws-url is the URL of the local JSON-RPC WebSocketServer and spec-version is the specification version that the server supports as described in 9.9.2.1. HBBTV,section 11.7: All WebSocket endpoint URLs for JSON-RPC, application to application communication and inter-device synchronization shall include a randomly-generated part. The URLs shall be static for at least the lifetime of an HbbTV® application and shall be regenerated every time the terminal starts. | |||
| org.hbbtv_JSON-RPC-WSS0110 | 1 | JSON-RPC message batching is prohibited | An application connects to the JSON-RPC WSS server and arranges for the required capability negotiations (for the messages to be transmitted later in the test) to be successfully conducted. Then, the application transmits a rapid sequence of 8 (eight) individual (i.e. not batched) conformant and valid JSON-RPC request messages to the terminals JSON-RPC WSS server. Corresponding messages returned from the terminal are inspected to successfully confirm that the responses are not batched. | 2024-1 | HBBTV 1.7.1 | JSON-RPC,section 6: To send several Request objects at the same time, the Client MAY send an Array filled with Request objects. The Server should respond with an Array containing the corresponding Response objects, after all of the batch Request objects have been processed. A Response object SHOULD exist for each Request object, except that there SHOULD NOT be any Response objects for notifications. The Server MAY process a batch rpc call as a set of concurrent tasks, processing them in any order and with any width of parallelism. The Response objects being returned from a batch call MAY be returned in any order within the Array. The Client SHOULD match contexts between the set of Request objects and the resulting set of Response objects based on the id member within each Object. If the batch rpc call itself fails to be recognized as an valid JSON or as an Array with at least one value, the response from the Server MUST be a single Response object. If there are no Response objects contained within the Response array as it is to be sent to the client, the server MUST NOT return an empty Array and should return nothing at all. HBBTV,section 9.9.3.2: JSON-RPC messages sent from terminal to application shall consist of single messages that are not batched. The terminal shall support receiving single messages and is not be required to support receiving batched JSON-RPC messages from the application. HBBTV,section 15.2.1: Terminals shall: - provide a JSON-RPC WebSocket server as defined in clause 9.9.2 | |||
| org.hbbtv_JSON-RPC-WSS0120 | 1 | JSON-RPC Notifications are only transmitted if subscribed for | An application is connected to the JSON-RPC WSS server and the subscribe and unsubscribe methods have been successfully negotiated using the capability negotiation mechanism. The application has not subscribed for any notifications. When actions are triggered that would cause a notification should it have been subscribed for, the application successfully confirms that no notifications are received within 5 seconds. Then the application subscribes for a notification message of a particular type by sending a conformant and valid message, successfully confirming that the subscribe response message is correctly received and conformant. When the corresponding action that triggers the subscribed notification, the application receives a notification message within 5 seconds. Then the application unsubscribes to the notification message by sending a conformant and valid message, successfully confirming that the unsubscribe response message is correcly received and conformant. When the same action that would trigger the notification occurs, the application successfully confirms that no notifications are received. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 15.2.1: Terminals shall: - provide a JSON-RPC WebSocket server as defined in clause 9.9.2 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. HBBTV,section 9.9.4.1: 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. Notification messages from the terminal shall not be sent to the HbbTV Application after the specific notification messages have been unsubscribed to using the unsubscribe API defined in 9.9.4.3. HBBTV,section 9.9.4.3: HbbTV terminals shall support the Subscribe Response API as defined in ATSC A/344 [95] clause 9.3.1.1, with the following modifications as defined in this clause. HBBTV,section 9.9.4.4: HbbTV terminals shall support the Unsubscribe Response API as defined in ATSC A/344 [95] section 9.3.1.2, with the following modifications as defined in this clause. | |||
| org.hbbtv_JSON-RPC-WSS0210 | 1 | Malformed JSON-RPC messages produce correct error responses from the terminal | An application is connected to the JSON-RPC WSS server and negotiates the capability for the org.hbbtv.subscribe method. Then the application transmits a series of malformed org.hbbtv.subscribe JSON-RPC messages to the terminal and confirms that a valid and correct error response is received within 6 seconds. The following list of malformed org.hbbtv.subscribe JSON-RPC messages must all be correctly responded to as indicated here: (1) An otherwise valid JSON-RPC message (with no trailing whitespace) that is missing that last 5 characters will result in a "Parse Error" with error code 32700. (2) The Method property is missing from an otherwise valid JSON-RPC request will result in an "Invalid request" with error code 32600. (3) The jsonrpc property is missing from an otherwise valid JSON-RPC request will result in an "Invalid request" with an error code 32600. (4) An invalid method e.g. "abcdefghijklm" is used will result in a "Method not found" with an error code 32601. (5) A message with an incorrect property type will result in an "Invalid params" with an error code 32602. | 2024-1 | HBBTV 1.7.1 | HBBTV,section 15.2.1: Terminals shall: - provide a JSON-RPC WebSocket server as defined in clause 9.9.2 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. HBBTV,section 9.9.4.3: HbbTV terminals shall support the Subscribe Request API ... HBBTV,section 9.9.7: HbbTV defined error codes from the terminal to the application shall be as defined in Table 10e. | |||
| org.hbbtv_KEYREQCON0010 | 1 | Loss of focus | If another feature of the terminal takes any of the mandatory keys away from an HbbTV application then the application loses focus and a blur event is sent to the application's window object to indicate the loss of focus. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: When an HbbTV application has input focus, the browser shall have "system focus" and the document corresponding to the HbbTV application shall have input focus within the browser. If either or both of these cease to apply then the HbbTV application shall lose input focus until either the application terminates or both apply. If an HbbTV application loses input focus then a blur event shall be sent to the application's window object HBBTV,section 10.2.2.1: If any other feature of the terminal needs to use any of those key events then diverting any of those key events to that feature shall result in loss of input focus for the HbbTV application. The HbbTV application shall lose focus even if the other feature of the terminal concerned only uses, for example, left, right and enter or green. | +REMOVEKEYS | ||
| org.hbbtv_KEYREQCON0020 | 1 | Regaining focus | If an HbbTV application that has lost input focus regains it then a focus event is sent to the application's window object and all the mandatory input keys will be available to the application. Remote control is equipped with separate buttons VK_PAUSE and VK_PLAY, VK_PLAY_PAUSE is not required to be supported. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: When an HbbTV application has input focus, the browser shall have "system focus" and the document corresponding to the HbbTV application shall have input focus within the browser. HBBTV,section 10.2.2.1: If an HbbTV application that has lost input focus regains it then a focus event shall be sent to the application's window object.While an HbbTV application has input focus, it shall receive all of the key events shown as "mandatory" in Table 12: "Key events and their status" above that it has requested in its keyset. HBBTV,section 10.2.2.1: If the other feature of the terminal only uses those key events temporarily and all the "mandatory" key events in Table 12 become available to the HbbTV application then this shall result in the HbbTV application regaining focus. Some examples of such a temporary loss of focus by the HbbTV application could include conditional access UI dialogues, parental access control UI dialogues and trailer booking UI dialogues. | +REMOVEKEYS +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_KEYREQCON0021 | 1 | Regaining focus | If an HbbTV application that has lost input focus regains it then a focus event is sent to the application's window object and all the mandatory input keys will be available to the application. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: When an HbbTV application has input focus, the browser shall have "system focus" and the document corresponding to the HbbTV application shall have input focus within the browser. HBBTV,section 10.2.2.1: If an HbbTV application that has lost input focus regains it then a focus event shall be sent to the application's window object.While an HbbTV application has input focus, it shall receive all of the key events shown as "mandatory" in Table 12: "Key events and their status" above that it has requested in its keyset. HBBTV,section 10.2.2.1: If the other feature of the terminal only uses those key events temporarily and all the "mandatory" key events in Table 12 become available to the HbbTV application then this shall result in the HbbTV application regaining focus. Some examples of such a temporary loss of focus by the HbbTV application could include conditional access UI dialogues, parental access control UI dialogues and trailer booking UI dialogues. | +REMOVEKEYS +VK_PLAY_PAUSE | ||
| org.hbbtv_KEYREQCON0100 | 1 | Back button before activation - broadcast-related autostart app | When a broadcast-related autostart application starts and requests the back key, the request is granted and the key event is delivered when the key is pressed | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]BACK button[.....]Always available to applications | |||
| org.hbbtv_KEYREQCON0110 | 1 | Back button before activation - b-i app | When a broadcast-independent application starts and requests the back key, this request is granted and the key event received when the key is pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]BACK button[.....]Always available to applications | |||
| org.hbbtv_KEYREQCON0120 | 1 | Back button before activation - broadcast-related present app | When an application starts a broadcast-related application signalled as present, and the newly started application requests the BACK key event, this request is granted and the key event received when the key is pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]BACK button[.....]Always available to applications | |||
| org.hbbtv_KEYREQCON0130 | 1 | Record key before activation - broadcast-related autostart app | When a broadcast-related autostart application starts and requests the record key, the request is refused and no key event is delivered if the key is pressed | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Record[.....]Only available to applications once activated HBBTV,section A.1: The Keyset class 7.2.5 M(*) For terminals making the VK_RECORD key event available to HbbTV applications, the otherKeys and maximumOtherKeys properties shall be supported and applications shall be able to request the VK_RECORD key event using them. | +PVR | ||
| org.hbbtv_KEYREQCON0140 | 1 | Record key before activation - b-i app | When a broadcast-independent application starts and requests the record key, this request is granted and the key event received when the key is pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Record[.....]Only available to applications once activated | +PVR | ||
| org.hbbtv_KEYREQCON0150 | 1 | Record key before activation - broadcast-related present app | When an application starts a broadcast-related application signalled as present, and the newly started application requests the record key event, this request is granted and the key event received when the key is pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Record[.....]Only available to applications once activated HBBTV,section A.1: The Keyset class 7.2.5 M(*) For terminals making the VK_RECORD key event available to HbbTV applications, the otherKeys and maximumOtherKeys properties shall be supported and applications shall be able to request the VK_RECORD key event using them. | +PVR | ||
| org.hbbtv_KEYREQCON0160 | 1 | Fast forwards and rewind before activation - broadcast-related autostart app | When a broadcast-related autostart application starts and requests the fast forwards and fast rewind keys, the request is refused and no key events are delivered if the keys are pressed | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Fast forward and fast rewind[.....]Only available to applications once activated | |||
| org.hbbtv_KEYREQCON0170 | 1 | Fast forwards and rewind before activation - b-i app | When a broadcast-independent application starts and requests the fast forwards and fast rewind keys, this request is granted and the key events received when the keys are pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Fast forward and fast rewind[.....]Only available to applications once activated | |||
| org.hbbtv_KEYREQCON0180 | 1 | Fast forwards and rewind before activation - broadcast-related present app | When an application starts a broadcast-related application signalled as present, and the newly started application requests the fast forwards and fast rewind key events, this request is granted and the key events received when the keys concerned are pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Fast forward and fast rewind[.....]Only available to applications once activated | |||
| org.hbbtv_KEYREQCON0300 | 1 | play, stop, pause keys before activation - broadcast-related autostart app | When a broadcast-related autostart application starts and requests the play, stop and pause keys, the request is refused and these key events are not delivered if the keys are pressed | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Play, stop, pause[.....]Only available to applications once activated | +VK_PAUSE +VK_PLAY | |
| org.hbbtv_KEYREQCON0310 | 1 | play, stop, pause keys before activation - broadcast-independent app | When a broadcast-independent application starts and requests the play, stop and pause keys, this request is granted and the key events received when the keys are pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Play, stop, pause[.....]Only available to applications once activated | +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_KEYREQCON0320 | 1 | play, stop, pause keys before activation - broadcast-related present app | When an application starts a broadcast-related application signalled as present, and the newly started application requests the play, stop and pause key events, this request is granted and the key events received when the keys concerned are pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Play, stop, pause[.....]Only available to applications once activated | +VK_PAUSE +VK_PLAY | |
| org.hbbtv_KEYREQCON0330 | 1 | play-pause, stop keys before activation - broadcast-related autostart app | When a broadcast-related autostart application starts and requests the play-pause and stop keys, the request is refused and these key events are not delivered if the keys are pressed | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Play, stop, pause[.....]Only available to applications once activated | +VK_PLAY_PAUSE | |
| org.hbbtv_KEYREQCON0340 | 1 | play-pause, stop keys before activation - broadcast-independent app | When a broadcast-independent application starts and requests the play-pause and stop keys, this request is granted and the key events received when the keys are pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Play, stop, pause[.....]Only available to applications once activated | +VK_PLAY_PAUSE | ||
| org.hbbtv_KEYREQCON0350 | 1 | play-pause, stop keys before activation - broadcast-related present app | When an application starts a broadcast-related application signalled as present, and the newly started application requests the play-pause and stop key events, this request is granted and the key events received when the keys concerned are pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Fast forward and fast rewind[.....]Only available to applications once activated | +VK_PLAY_PAUSE | |
| org.hbbtv_KEYREQCON0500 | 1 | red key activates an autostart broadcast-related application (+VK_PLAY_PAUSE) | When an autostart broadcast-related application starts and the first key event it receives is red, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-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 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. | +VK_PLAY_PAUSE | ||
| org.hbbtv_KEYREQCON0501 | 1 | red key activates an autostart broadcast-related application (+PVR) | When an autostart broadcast-related application starts and the first key event it receives is red, it is activated. If the application then requests to receive the key VK_RECORD that is only available to applications once activated then that request is granted and the key VK_RECORD can be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. HBBTV,section A.1: The Keyset class 7.2.5 M(*) For terminals making the VK_RECORD key event available to HbbTV applications, the otherKeys and maximumOtherKeys properties shall be supported and applications shall be able to request the VK_RECORD key event using them. | +PVR | ||
| org.hbbtv_KEYREQCON0505 | 1 | red key activates an autostart broadcast-related application (+VK_PAUSE+VK_PLAY) | When an autostart broadcast-related application starts and the first key event it receives is red, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-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 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. | +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_KEYREQCON0510 | 1 | green key activates an autostart broadcast-related application (+VK_PLAY_PAUSE) | When an autostart broadcast-related application starts and the first key event it receives is green, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-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 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. | +VK_PLAY_PAUSE | ||
| org.hbbtv_KEYREQCON0511 | 1 | green key activates an autostart broadcast-related application (+PVR) | When an autostart broadcast-related application starts and the first key event it receives is GREEN, it is activated. If the application then requests to receive the key VK_RECORD that is only available to applications once activated then that request is granted and the key VK_RECORD can be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. HBBTV,section A.1: The Keyset class 7.2.5 M(*) For terminals making the VK_RECORD key event available to HbbTV applications, the otherKeys and maximumOtherKeys properties shall be supported and applications shall be able to request the VK_RECORD key event using them. | +PVR | ||
| org.hbbtv_KEYREQCON0515 | 1 | green key activates an autostart broadcast-related application (+VK_PAUSE+VK_PLAY) | When an autostart broadcast-related application starts and the first key event it receives is green, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. | +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_KEYREQCON0520 | 1 | yellow key activates an autostart broadcast-related application (+VK_PLAY_PAUSE) | When an autostart broadcast-related application starts and the first key event it receives is yellow, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-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 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. | +VK_PLAY_PAUSE | ||
| org.hbbtv_KEYREQCON0521 | 1 | yellow key activates an autostart broadcast-related application (+PVR) | When an autostart broadcast-related application starts and the first key event it receives is yellow, it is activated. If the application then requests to receive the key VK_RECORD that is only available to applications once activated then that request is granted and the key VK_RECORD can be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. HBBTV,section A.1: The Keyset class 7.2.5 M(*) For terminals making the VK_RECORD key event available to HbbTV applications, the otherKeys and maximumOtherKeys properties shall be supported and applications shall be able to request the VK_RECORD key event using them. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. | +PVR | ||
| org.hbbtv_KEYREQCON0525 | 1 | yellow key activates an autostart broadcast-related application (+VK_PAUSE+VK_PLAY) | When an autostart broadcast-related application starts and the first key event it receives is yellow, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. | +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_KEYREQCON0530 | 1 | blue key activates an autostart broadcast-related application (+VK_PLAY_PAUSE) | When an autostart broadcast-related application starts and the first key event it receives is blue, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-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 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. | +VK_PLAY_PAUSE | ||
| org.hbbtv_KEYREQCON0531 | 1 | blue key activates an autostart broadcast-related application (+PVR) | When an autostart broadcast-related application starts and the first key event it receives is blue, it is activated. If the application then requests to receive the key VK_RECORD that is only available to applications once activated then that request is granted and the key VK_RECORD can be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. HBBTV,section A.1: The Keyset class 7.2.5 M(*) For terminals making the VK_RECORD key event available to HbbTV applications, the otherKeys and maximumOtherKeys properties shall be supported and applications shall be able to request the VK_RECORD key event using them. | +PVR | ||
| org.hbbtv_KEYREQCON0535 | 1 | blue key activates an autostart broadcast-related application (+VK_PAUSE+VK_PLAY) | When an autostart broadcast-related application starts and the first key event it receives is blue, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-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 10.2.2.1: 4 colour buttons (red, green, yellow, blue) [...] Always available to applications [...] The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...] When an application becomes activated, the key set shall not automatically change, the application needs to call KeySet.setValue() in order to receive key events that were not previously available to it but now are. HBBTV,section A.3.3: Clause 6.2 of the Web Standards TV Profile [i.6] does not apply in the present document. Instead “keydown”, “keypress” and “keyup” events shall be supported as defined by annex B of the Open IPTV Forum DAE specification release 1 [53] under the heading “Add keypress events to Requirement 5.4.1.a in the following way:”. OIPF-DAE,section B: [Req. 5.4.1.a] Every Remote UI Client SHALL support the DOM event types "keydown", "keypress" and "keyup" and the following subset of the KeyEvent interface as specified in [18], which SHALL inherit from the UIEvent interface: 1) Properties: [...] readonly Number keyCode; [...] 3) Constants: A subset of the VK_* constants as specified in Annex F, corresponding to the keys that are supported by the Remote UI Client (i.e. SHALL at least include the keys as specified by the client in the capability profile). [¶] Key constant values defined in Annex F are OPTIONAL for this specification. An OITF SHALL map VK_* constants to an internal OITF specific value. A DAE application SHALL NOT rely on the internal OITF specific key code and SHALL use the VK_* key constant literals instead. | +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_KEYREQCON0540 | 1 | up key activates an autostart broadcast-related application | When an autostart broadcast-related application starts and the first key event it receives is up, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. Remote control is equipped with separate buttons VK_PAUSE and VK_PLAY, VK_PLAY_PAUSE is not required to be supported. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...]4 arrow buttons (up, down, left, right)[.....]Always available to applications | +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_KEYREQCON0541 | 1 | up key activates an autostart broadcast-related application | When an autostart broadcast-related application starts and the first key event it receives is up, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...]4 arrow buttons (up, down, left, right)[.....]Always available to applications | +VK_PLAY_PAUSE | ||
| org.hbbtv_KEYREQCON0550 | 1 | down key activates an autostart broadcast-related application | When an autostart broadcast-related application starts and the first key event it receives is down, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. Remote control is equipped with separate buttons VK_PAUSE and VK_PLAY, VK_PLAY_PAUSE is not required to be supported. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...]4 arrow buttons (up, down, left, right)[.....]Always available to applications | +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_KEYREQCON0551 | 1 | down key activates an autostart broadcast-related application | When an autostart broadcast-related application starts and the first key event it receives is down, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...]4 arrow buttons (up, down, left, right)[.....]Always available to applications | +VK_PLAY_PAUSE | ||
| org.hbbtv_KEYREQCON0560 | 1 | left key activates an autostart broadcast-related application | When an autostart broadcast-related application starts and the first key event it receives is left, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. Remote control is equipped with separate buttons VK_PAUSE and VK_PLAY, VK_PLAY_PAUSE is not required to be supported. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...]4 arrow buttons (up, down, left, right)[.....]Always available to applications | +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_KEYREQCON0561 | 1 | left key activates an autostart broadcast-related application | When an autostart broadcast-related application starts and the first key event it receives is left, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...]4 arrow buttons (up, down, left, right)[.....]Always available to applications | +VK_PLAY_PAUSE | ||
| org.hbbtv_KEYREQCON0570 | 1 | right key activates an autostart broadcast-related application | When an autostart broadcast-related application starts and the first key event it receives is right, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. Remote control is equipped with separate buttons VK_PAUSE and VK_PLAY, VK_PLAY_PAUSE is not required to be supported. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...]4 arrow buttons (up, down, left, right)[.....]Always available to applications | +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_KEYREQCON0571 | 1 | right key activates an autostart broadcast-related application | When an autostart broadcast-related application starts and the first key event it receives is right, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...]4 arrow buttons (up, down, left, right)[.....]Always available to applications | +VK_PLAY_PAUSE | ||
| org.hbbtv_KEYREQCON0580 | 1 | enter key activates an autostart broadcast-related application | When an autostart broadcast-related application starts and the first key event it receives is enter, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. Remote control is equipped with separate buttons VK_PAUSE and VK_PLAY, VK_PLAY_PAUSE is not required to be supported. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...]4 arrow buttons (up, down, left, right)[.....]Always available to applications | +VK_PAUSE +VK_PLAY | ||
| org.hbbtv_KEYREQCON0581 | 1 | enter key activates an autostart broadcast-related application | When an autostart broadcast-related application starts and the first key event it receives is enter, it is activated. If the application then requests to receive the keys that are only available to applications once activated then that request is granted and those keys can be received. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. [...]4 arrow buttons (up, down, left, right)[.....]Always available to applications | +VK_PLAY_PAUSE | ||
| org.hbbtv_KEYREQCON0600 | 1 | Number keys before activation - broadcast-related autostart app | When a broadcast-related autostart application starts and requests the number keys, the request is refused and no key events are delivered if the keys are pressed | 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 10.2.2.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Number keys[.....]Only available to applications once activated | |||
| org.hbbtv_KEYREQCON0610 | 1 | Number keys before activation - b-i app | When a broadcast-independent application starts and requests the number keys, this request is granted and the key events received when the keys are pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Number keys[.....]Only available to applications once activated | |||
| org.hbbtv_KEYREQCON0620 | 1 | Number keys before activation - broadcast-related present app | When an application starts a broadcast-related application signalled as present, and the newly started application requests the number key events, this request is granted and the key events received when the keys concerned are pressed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The availability column indicates if the key events are always available to applications or only once the application has been activated. Key events listed as "Only available to applications once activated" shall be available to applications only once the user has activated the application. Applications AUTOSTARTed by the terminal shall be activated when they have received a key event. Other applications (e.g. broadcast-independent applications or ones signalled as PRESENT) shall be activated when launched. In all cases, applications shall only receive key events when they have focus as defined below.[...]Play, stop, pause[.....]Only available to applications once activated | |||
| org.hbbtv_KEYREQCON1000 | 1 | Key events while application has no focus | If all mandatory keys of table 12 are pressed sequentially after an activated application, that requested all mandatory keys from table 12, has lost focus, the terminal does not deliver any key event to the application. Remote control is equipped with separate buttons VK_PAUSE and VK_PLAY, VK_PLAY_PAUSE is not required to be supported. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 10.2.2.1: If any other feature of the terminal needs to use any of those key events then diverting any of those key events to that feature shall result in loss of input focus for the HbbTV application. The HbbTV application shall lose focus even if the other feature of the terminal concerned only uses, for example, left, right and enter or green. | +REMOVEKEYS +VK_PAUSE +VK_PLAY | |
| org.hbbtv_KEYREQCON1001 | 1 | Key events while application has no focus | If all mandatory keys of table 12 are pressed sequentially after an activated application, that requested all mandatory keys from table 12, has lost focus, the terminal does not deliver any key event to the application. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 10.2.2.1: If any other feature of the terminal needs to use any of those key events then diverting any of those key events to that feature shall result in loss of input focus for the HbbTV application. The HbbTV application shall lose focus even if the other feature of the terminal concerned only uses, for example, left, right and enter or green. | +REMOVEKEYS +VK_PLAY_PAUSE | |
| org.hbbtv_MDEVSYNC0011 | 1 | The master terminal allows multiple CSS-TS connections from the same CSA | A HbbTV application has initialised a MediaSynchroniser, enabled inter-device synchronisation causing the terminal to become a master terminal. After a CSA has established a connection of the CSS-TS protocol with the master terminal and the master terminal receives a websocket connection request from the same CSA on the same CSS-TS service end-point, the master terminal will accept such connection request. | 2024-1 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 13.8.2.1: When the terminal is a master terminal, it shall implement an MSAS function that implements a CSS-TS service end point as defined in Clause 9 of [47]. TS-103-286-2,section 9.2: The MSAS shall allow a CSA to have multiple open sessions to a single CSS-TS service endpoint. | |||
| org.hbbtv_MDEVSYNC0016 | 1 | Synchronisation timeline requested by CSA is TEMI and becomes available | A HbbTV application has initialised a MediaSynchroniser, passed to it a media object representing a DVB broadcast, and enabled inter-device synchronisation causing the terminal to become a master terminal. After a newly connected CSA has requested a MPEG-TS TEMI timeline for synchronisation, but no frame with a TEMI timeline has yet been received by the master terminal since the request from the CSA, and then the master terminal receives, from the DVB broadcast, a frame containing a TEMI timestamp, the master terminal will send out a Control Timestamp whose contentTime property is different from null. | 2024-1 2021-2 2021-1 2020-3 2020-2 2020-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.8.2.1: When the terminal is a master terminal, it shall implement an MSAS function that implements a CSS-TS service end point as defined in Clause 9 of [47]. TS-103-286-2,section 9.2: The MSAS shall send an updated Control Timestamp message to the SC if any of the following conditions occur: - The Timeline becomes available. HBBTV,section 13.4.2: For multi-stream and inter-device synchronisation, the terminal shall support the use of the following the types of timeline (defined in this clause and clause 5.3 of ETSI TS 103-286-2 [47]) for multi-stream and inter-device synchronisation for the types of broadcast or broadband content shown in Table 18 Table 18: Multi-stream and inter-device synchronisation timeline support - MPEG-TS Timed External Media Information (TEMI) TS-103-286-2,section 5.7.5: • contentTime is a string value representing the content time part of a Control Timestamp and is in the format defined in clause 5.7.1. However if the content time is unknown (because the timeline is unavailable) then contentTime shall be a null value instead. | |||
| org.hbbtv_MDEVSYNC0017 | 1 | Synchronisation timeline from a DVB service requested by CSA is MPEG-TS PTS timeline that becomes available | A HbbTV application has initialised a MediaSynchroniser, passed to it a media object representing one service from a DVB broadcast (consisting of two services) and enabled inter-device synchronisation causing the terminal to become a master terminal. A newly connected CSA has sent a setup-data message with contentIdStem matching that of the other service of the above mentioned DVB broadcast (but not the one represented in the media object) and with timelineSelector indicating a MPEG-TS PTS timeline for synchronisation. After the HBBTV application on the master terminal has instructed the video object to change to the other service contained within the DVB broadcast stream and this timeline becomes available, the master terminal will send out, to the above mentioned CSA, a Control Timestamp whose contentTime propery is different from null. | 2024-1 2023-3 2023-2 2023-1 2022-2 2022-1 2021-3 2021-2 2021-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.8.2.1: When the terminal is a master terminal, it shall implement an MSAS function that implements a CSS-TS service end point as defined in Clause 9 of [47]. TS-103-286-2,section 9.2: The MSAS shall send an updated Control Timestamp message to the SC if any of the following conditions occur: - The Timeline becomes available. HBBTV,section 13.4.2: For multi-stream and inter-device synchronisation, the terminal shall support the use of the following the types of timeline (defined in this clause and clause 5.3 of ETSI TS 103-286-2 [47]) for multi-stream and inter-device synchronisation for the types of broadcast or broadband content shown in Table 18 Table 18: Multi-stream and inter-device synchronisation timeline support - MPEG-TS Presentation Timestamps (PTS) TS-103-286-2,section 5.5.9.4: - contentIdStem is a string value. Its value is a CI stem that defines the circumstances in which the Synchronisation Timeline is available as defined in clause 5.2.2. TS-103-286-2,section 5.7.5: - contentTime is a string value representing the content time part of a Control Timestamp and is in the format defined in clause 5.7.1. However if the content time is unknown (because the timeline is unavailable) then contentTime shall be a null value instead. | ||
| org.hbbtv_MDEVSYNC0020 | 1 | Synchronisation timeline requested by CSA is DASH p-r and becomes unavailable | A HbbTV application has initialised a MediaSynchroniser, passed to it a media object representing a live broadband stream which contains a MPEG DASH service, and enabled inter-device synchronisation causing the terminal to become a master terminal. After a newly connected CSA has requested a DASH p-r timeline for sychronisation, and the periodId specified in the timelineSelector property of the setup-data message sent by the CSA is present in the current MPD at the master terminal, and then the master terminal updates the MPD and the new MPD does not contain anymore the period whose periodId was specified in the setup-data message sent by the CSA, the master terminal will send out a Control Timestamp whose "contentTime" property has value null. | 2024-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.8.2.1: When the terminal is a master terminal, it shall implement an MSAS function that implements a CSS-TS service end point as defined in Clause 9 of [47]. TS-103-286-2,section 9.2: The MSAS shall send an updated Control Timestamp message to the SC if any of the following conditions occur: - The Timeline becomes unavailable. HBBTV,section 13.4.2: For multi-stream and inter-device synchronisation, the terminal shall support the use of the following the types of timeline (defined in this clause and clause 5.3 of ETSI TS 103-286-2 [47]) for multi-stream and inter-device synchronisation for the types of broadcast or broadband content shown in Table 18 Table 18: Multi-stream and inter-device synchronisation timeline support - MPEG DASH Period Relative TS-103-286-2,section 5.7.5: - contentTime is a string value representing the content time part of a Control Timestamp and is in the format defined in clause 5.7.1. However if the content time is unknown (because the timeline is unavailable) then contentTime shall be a null value instead. TS-103-286-2,section 5.3.7.3: A Timeline indicated by a given Timeline Selector shall be available if it is possible to determine a Time Value on that Timeline that corresponds to the point currently being presented by the TV Device. It is possible to do this if: - the TV Device is presenting an MPEG DASH presentation - and the Period ID in the Timeline Selector corresponds to the value of any Period@ID currently in the MPD. | |||
| org.hbbtv_MDEVSYNC0029 | 1 | Synchronisation timeline functionality becoming unavailable because the master terminal is no longer presenting Timed Content | A HbbTV application has initialised a MediaSynchroniser, and enabled inter-device synchronisation causing the terminal to become a master terminal. When the presentation of timed content stops, then the terminal will close the WebSocket connections, sending a WebSocket Close control frame with status code 1001 to all connected clients (slave terminals and/or CSAs) on the CSS-TS interface | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2020-3 2020-2 2020-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.8.2.1: When the terminal is a master terminal, it shall implement an MSAS function that implements a CSS-TS service end point as defined in Clause 9 of [47]. HBBTV,section 13.3.4: A terminal shall cease to be a master terminal if: - there is a permanent error of the MediaSynchroniser object (see clause 13.3.8) HBBTV,section 13.3.8: A permanent error of the MediaSynchroniser can occur if any of the following occurs: - • the master media stream not being in a suitable state to participate in synchronisation, including the media stream transitioning to a stopped, unrealised or finished state TS-103-286-2,section 9.2: If the Timeline Synchronization functionality is to become unavailable, the MSAS shall initiate the termination of the established session. The CSA may teardown an established session at any time. TS-103-286-2,section 9.3: The MSAS shall teardown the session of protocol exchanges by closing the connection as described in the WebSocket protocol specification [8] section 7. If the MSAS is tearing down the connection because the CSS-TS service endpoint is to become unavailable, then the MSAS shall provide the reason code for closure of 1001 indicating that the service endpoint is "going away". TS-103-286-2,section 9.3: The MSAS shall teardown the session of protocol exchanges by closing the connection as described in the WebSocket protocol specification [8] section 7. | |||
| org.hbbtv_MDEVSYNC0035 | 1 | Master terminal tearing down a CSS-TS session terminated by the CSA | A HbbTV application has initialised a MediaSynchroniser, and enabled inter-device synchronisation causing the terminal to become a master terminal. The terminal has two connections of the CSS-TS protocol with two distinct CSAs. After the terminal receives a Close control frame from one of the CSAs, the master terminal will send a Close control frame to the CSA from which it received the first Close control frame, and subsequently it will close the underlying TCP connection with it. The terminal sends none of these messages to the other connection from the other CSA as a result of this and that connection remains open. | 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 13.8.2.1: When the terminal is a master terminal, it shall implement an MSAS function that implements a CSS-TS service end point as defined in Clause 9 of [47]. TS-103-286-2,section 9.3: The MSAS shall teardown the session of protocol exchanges by closing the connection as described in the WebSocket protocol specification [8] section 7. | |||
| org.hbbtv_MDEVSYNC0070 | 1 | The master terminal accepts simultaneous sessions of the CSS-TS protocol until its supported limit | A HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. After the terminal has established 9 sessions of the CSS-TS protocol, and then the terminal receives a continuous sequence of new CSS-TS connection requests from a CSA, at least one request will succeed. | 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 13.8.2.1: The MSAS function of the master terminal [...] shall allow slave terminals and CSAs to connect to this service end point until the MSAS function of the master terminal has reached the limit of the number of simultaneous sessions it can support. | |||
| org.hbbtv_MDEVSYNC0091 | 1 | Master terminal ceasing to be a master due to destruction of the MediaSynchroniser object | A HbbTV application has initialised a MediaSynchroniser, enabled inter-device synchronisation causing the terminal to become a master terminal and 3 sessions of the CSS-TS protocol have been established. When this media synchroniser object is destroyed, then the master terminal will send a WebSocket Close control frame with status code 1001 to all connected clients (slave terminals and/or CSAs) on the CSS-TS interface. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.8.2.1: When the terminal ceases to be a master terminal, it shall close any connections to the CSS-TS service end point from slave terminals or CSAs, following the process described in clause 9 of ETSI TS 103 286-2 [47]. HBBTV,section 13.3.4: A terminal shall cease to be a master terminal if: [] or the MediaSynchroniser object is destroyed, | |||
| org.hbbtv_MDEVSYNC0092 | 1 | Master terminal ceasing to be a master due to replacement of the MediaSynchroniser object | A HbbTV application has initialised a MediaSynchroniser, enabled inter-device synchronisation causing the terminal to become a master terminal and 3 sessions of the CSS-TS protocol have been established. When this media synchroniser object is replaced (e.g. by initialising another MediaSynchroniser ), then the master terminal will send a WebSocket Close control frame with status code 1001 to all connected clients (slave terminals and/or CSAs) on the CSS-TS interface. The HbbTV application on the terminal tries to add a new media object to the MediaSynchroniser. The error event with code '13' will be thrown. | 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 13.8.2.1: When the terminal ceases to be a master terminal, it shall close any connections to the CSS-TS service end point from slave terminals or CSAs, following the process described in clause 9 of ETSI TS 103 286-2 [47]. HBBTV,section 13.3.4: A terminal shall cease to be a master terminal if: [] or there is a permanent error of the MediaSynchroniser object (see clause 13.3.8), HBBTV,section 13.3.8: A permanent error of the MediaSynchroniser can occur if any of the following occurs: [] - the MediaSynchroniser being replaced because another MediaSynchroniser has subsequently been initialised (see initMediaSynchroniser and initSlaveMediaSynchroniser methods in clause 8.2.3.2.2). HBBTV,section 8.2.3.2.4: Error codes Value: 13 Description: The method call failed because the MediaSynchroniser is in a permanent error state or because it has been replaced by a newer initialised MediaSynchroniser. Permanent or Transient: Transient | |||
| org.hbbtv_MDEVSYNC0100 | 1 | Synchronisation timeline requested by the CSA is PTS and is available | A HbbTV application has initialised a MediaSynchroniser, passed to it a media object representing a service from a DVB broadcast (consisting of that one service), and enabled inter-device synchronisation causing the terminal to become a master terminal. When a newly connected CSA requests a MPEG-TS PTS timeline for synchronisation (referring to the same service of the same DVB broadcast), then the master terminal will send out a control timestamp to that CSA. | 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 13.8.2.2: The requested Synchronisation Timeline shall be available if the requirements for determining the availability defined in clause 9.7.3 of the present document and in clause 9.2 of ETSI TS 103 286-2 [47] are met and the requested Timeline is supported by the master terminal (see clause 13.4.2). | |||
| org.hbbtv_MDEVSYNC0102 | 1 | Synchronisation timeline requested by the CSA is CT and is available | A HbbTV application has initialised a MediaSynchroniser, passed to it a media object representing a ISOBMFF service (using ISOBMFF Composition Time - CT - timeline), and enabled inter-device synchronisation causing the terminal to become a master terminal. When a newly connected CSA requests a ISOBMFF CT timeline for synchronisation (referring to the same service the master terminal is presenting), then the master terminal will send out a control timestamp to that CSA. | 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 13.8.2.2: The requested Synchronisation Timeline shall be available if the requirements for determining the availability defined in clause 9.7.3 of the present document and in clause 9.2 of ETSI TS 103 286-2 [47] are met and the requested Timeline is supported by the master terminal (see clause 13.4.2). | |||
| org.hbbtv_MDEVSYNC0110 | 1 | Timing of the Control Timestamp message sent out by a master terminal | A HbbTV application has initialised a MediaSynchroniser, enabled inter-device synchronisation causing the terminal to become a master terminal. When the master terminal receives a setup-data message on the CSS-TS service end point, then the master terminal will send out a Control Timestamp within 500 milliseconds. | 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 13.8.2.3: The MSAS function of the master terminal shall send its first Control Timestamp within 500ms of receiving the setup-data message. | |||
| org.hbbtv_MDEVSYNC0130 | 1 | The master terminal handles 2 Actual, Earliest and Latest Presentation timestamps received with 0.5s distance | A HbbTV application has initialised a MediaSynchroniser, and enabled inter-device synchronisation causing the terminal to become a master terminal. After the terminal has established a connection with a CSA, received an "Actual, Earliest and latest Presentation timestamp", and after 0.5 seconds another "Actual, Earliest and latest Presentation timestamp" from that CSA, the master terminal will maintain the CSS-TS connections with that CSA | 2024-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,section 13.8.2.3: The MSAS function of the master terminal shall be able to handle receiving a minimum of 2 Actual, Earliest and Latest Presentation timestamp messages per session per second. | |||
| org.hbbtv_MDEVSYNC018 | 1 | Synchronisation timeline requested by CSA is DASH p-r and becomes available | A HbbTV application has initialised a MediaSynchroniser, passed to it a media object representing a live broadband stream which contains a MPEG DASH service, and enabled inter-device synchronisation causing the terminal to become a master terminal. After a newly connected CSA has requested a DASH p-r timeline for sychronisation, but the periodId specified in the timelineSelector property of the setup-data message sent by the CSA is not yet present in the current MPD at the master terminal, and then the master terminal updates the MPD and the new MPD contains the period whose periodId was specified in the setup-data message sent by the CSA, the master terminal will send out a Control Timestamp whose "contentTime" property is different from null. | 2024-1 2022-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8.2.1: When the terminal is a master terminal, it shall implement an MSAS function that implements a CSS-TS service end point as defined in Clause 9 of ETSI TS 103 286-2. HBBTV,section 13.4.2: For multi-stream and inter-device synchronisation, the terminal shall support the use of the following the types of timeline (defined in this clause and clause 5.3 of ETSI TS 103-286-2 [47]) for multi-stream and inter-device synchronisation for the types of broadcast or broadband content shown in Table 18. ... Type of timeline: MPEG DASH Period Relative TS-103-286-2,section 5.3.7.3: A Timeline indicated by a given Timeline Selector shall be available if it is possible to determine a Time Value on that Timeline that corresponds to the point currently being presented by the TV Device. It is possible to do this if: - the TV Device is presenting an MPEG DASH presentation - and the Period ID in the Timeline Selector corresponds to the value of any Period@ID currently in the MPD. TS-103-286-2,section 5.7.5: - contentTime is a string value representing the content time part of a Control Timestamp and is in the format defined in clause 5.7.1. However if the content time is unknown (because the timeline is unavailable) then contentTime shall be a null value instead. TS-103-286-2,section 9.2: The MSAS shall send an updated Control Timestamp message to the SC if any of the following conditions occur: - The Timeline becomes available. | |||
| org.hbbtv_MDEVSYNC0201 | 1 | timelineSpeedMultiplier value when playback moving at rate X for a MPEG-TS HD stream) | A HbbTV application has initialised a MediaSynchroniser, passed to it a HTML5 media object (MPEG-TS in HD format, video on demand), enabled inter-device synchronisation causing the terminal to become a master terminal. After the playbackRate of the video object being currently displayed on the master terminal has been changed to X, the timelineSpeedMultiplier property of the following Control Timestamp sent out from the master terminal will have value X | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-2 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.8.2.4: When presentation is moving at any other rate, the value shall be the approximate intended playback speed of the presentation (e.g. a value of 2 corresponds to x2 fast-forward) | ||
| org.hbbtv_MDEVSYNC0202 | 1 | timelineSpeedMultiplier value when playback moving at rate X for a MPEG-TS 4K UHD 60fps stream) | A HbbTV application has initialised a MediaSynchroniser, passed to it HTML5 media object representing a broadband service (MPEG-TS in 4K UHD 50fps format, video on demand), enabled inter-device synchronisation causing the terminal to become a master terminal. After the playbackRate of the video object being currently displayed on the master terminal has been changed to X, the timelineSpeedMultiplier property of the following Control Timestamp sent out from the master terminal will have value X | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-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.8.2.4: When presentation is moving at any other rate, the value shall be the approximate intended playback speed of the presentation (e.g. a value of 2 corresponds to x2 fast-forward) | ||
| org.hbbtv_MDEVSYNC0203 | 1 | timelineSpeedMultiplier value when playback moving at rate X for a broadcast stream (MPEG2 and HEAAC codecs) | A HbbTV application has initialised a MediaSynchroniser (using the initMediaSynchroniser), passed to it a media object consisting of a video/broadcast object with MPEG2 video codec and HEAAC audio codec representing a broadcast service in SD distributed via MPEG-TS and enabled inter-device synchronisation causing the terminal to become a master terminal and that media object to become the master media. After the playSpeed of the master media has been changed to X, the timelineSpeedMultiplier property of the following Control Timestamp sent out from the master terminal will have value X. | 2024-1 2023-3 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.8.2.4: When presentation is moving at any other rate, the value shall be the approximate intended playback speed of the presentation (e.g. a value of 2 corresponds to x2 fast-forward) | +TIMESHIFT | |
| org.hbbtv_MDEVSYNC0206 | 1 | timelineSpeedMultiplier value when playback moving at rate X for a broadband DASH HD stream (AVC and HEAAC codecs) | A HbbTV application has initialised a MediaSynchroniser (using the initMediaSynchroniser), passed to it a media object consisting of a HTML5 video element with AVC video codec and HE-AAC audio codec representing a video-on-demand service in HD distributed via MPEG DASH and enabled inter-device synchronisation causing the terminal to become a master terminal and that media object to become the master media. After the playSpeed of the master media has been changed to X, the timelineSpeedMultiplier property of the following Control Timestamp sent out from the master terminal will have value X. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 2021-3 2021-2 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.7.2.4: When presentation is moving at any other rate, the value shall be the approximate intended playback speed of the presentation (e.g. a value of 2 corresponds to x2 fast-forward) HBBTV,section 7.3.1.1: 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. | +TIMESHIFT | ||
| org.hbbtv_MDEVSYNC032 | 1 | Master terminal refusing a CSS-TS connection when the CSS-TS service endpoint is unavailable | When a HbbTV application has disabled inter-device synchronisation for a master terminal, and the terminal receives a websocket client handshake on its CSS-TS endpoint, it will respond with an HTTP response code of 403 "Forbidden". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.2: void disableInterDeviceSync (function callback) | Disables the inter device synchronisation of a master or slave terminal. ... Once the terminal is no longer a master terminal then the callback function shall be called. HBBTV,section 13.3.3: If inter-device synchronisation is enabled for a MediaSynchroniser object ... then the terminal shall ensure that the following protocol endpoints are active: a DVB CSS-CII protocol endpoint ...; a DVB CSS-WC protocol endpoint ...; and a DVB CSS-TS protocol endpoint ... HBBTV,section 13.3.4: A terminal shall cease to be a master terminal if: the disableInterDeviceSync() method is called on the MediaSynchroniser object ... then the terminal shall disable inter-device synchronisation by disabling the DVB CSS-TS protocol endpoint. TS-103-286-2,section 9.3: If the CSS-TS service endpoint is currently unavailable then the MSAS function of the TV Device shall refuse the connection request by responding with an HTTP response code of 403 "Forbidden". | |||
| org.hbbtv_MDEVSYNC071 | 1 | The master terminal does not accept a number of sessions of the CSS-TS protocol higher than its supported limit | A HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. After the terminal has established 9 sessions of the CSS-TS protocol, and then the terminal receives a continuous sequence of 400 new CSS-TS connection requests, these requests will either succeed or fail, and for those that failed the master terminal will refuse the connection and respond with an HTTP response code 503 "Service Unavailable". | 2024-1 2023-3 2023-2 2023-1 2022-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,section 13.8.2.1: The MSAS function of the master terminal shall support a minimum of 10 simultaneous sessions of the Timeline Synchronisation Protocol at the CSS-TS service endpoint and shall allow slave terminals and CSAs to connect to this service endpoint until the MSAS function of the master terminal has reached the limit of the number of simultaneous sessions it can support. TS-103-286-2,section 9.3: If the MSAS function of the TV Device has reached the limit of the number of simultaneous connections to the CSS-TS service endpoint that it can handle, then it shall refuse the connection request by returning the HTTP response code 503 "Service Unavailable". | ||
| org.hbbtv_MDEVSYNC080 | 1 | MSAS ignoring Origin header | A HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. When the master terminal receives a websocket connection request with an Origin header, which shall be validly formatted, and contain a URL that is not associated with (or representative of) the master, the client or the applications running on either (or the sources of any of these), from a CSA to connect on the CSS-TS protocol service endpoint, it will accept the connection. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8.2.1: CSS-TS service endpoint [...] The MSAS function of the master terminal shall ignore the Origin header if it is present in the client handshake of the connection request. TS-103-286-2,section 9.3: The MSAS may examine the "Origin" header if it is present in the client handshake used in the WebSocket protocol to establish the connection. On the basis of the value of the "Origin" header, the MSAS may choose to refuse to establish the connection and respond with a 403 "Forbidden" response code, as described in section 10.2 of IETF RFC 6455 [8]. | |||
| org.hbbtv_MDEVSYNC090 | 1 | Master terminal ceasing to be a master due to call to disableInterDevSync method | A HbbTV application has initialised a MediaSynchroniser, enabled inter-device synchronisation causing the terminal to become a master terminal and 3 sessions of the CSS-TS protocol have been established. When the disableInterDevSync method is called on the initialised MediaSynchroniser object, then the master terminal will send a WebSocket Close control frame with status code 1001 to all connected clients (slave terminals and/or CSAs) on the CSS-TS interface. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.4: A terminal shall cease to be a master terminal if: - the disableInterDeviceSync method is called on the MediaSynchroniser object (see clause 8.2.3.2.2), HBBTV,section 13.8.2.1: When the terminal ceases to be a master terminal, it shall close any connections to the CSS-TS service end point from slave terminals or CSAs, following the process described in clause 9 of ETSI TS 103 286-2 [47]. | |||
| org.hbbtv_MDEVSYNC1000 | 1 | Master Terminal: Implements CSS-CII endpoint on the broadband interface | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal receives a WebSocket "connection request" message from a CSA on the CSS-CII endpoint on its broadband interface. The master terminal in turn responds to the connection request with a CII message in the form of a WebSocket data frame. | 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. TS-103-286-2,section 6.3: The TV Device shall implement a CSS-CII service endpoint that implements the server side of the WebSocket protocol version 13 as defined in RFC 6455 [8]. | |||
| org.hbbtv_MDEVSYNC1002 | 1 | Master Terminal: Supports >5 concurrent connections to CSS-CII service endpoint | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal has 4 open connections on the same CSS-CII protocol service endpoint. When the master terminal receives a request from a CSA to connect on the same CSS-CII protocol service endpoint, it will accept the connection. | 2024-1 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 13.6.2: The master terminal shall support a minimum of 5 concurrent connections to the CSS-CII service endpoint and shall allow slave terminals and CSAs to connect to this service endpoint until the master terminal has reached the limit of the number of simultaneous sessions it can support. | |||
| org.hbbtv_MDEVSYNC1003 | 1 | Master Terminal: Allows connection until limit is reached. | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal has 5 open connections to the same CSS-CII protocol service endpoint. A CSA is set to initiate an additional sequence of 395 connections to the same CSS-CII protocol service point. The CSA starts sending the first connection request in the sequence. Every time a new connection from the CSA is received, the master terminal will accept the new connection until the total number of 400 simultaneous connections is reached, or until its own upper bound limit is reached. For requests that fail, the master terminal refuses the connection and responds with an HTTP response code of 503 "Service Unavailable". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: The master terminal shall support a minimum of 5 concurrent connections to the CSS-CII service endpoint and shall allow slave terminals and CSAs to connect to this service endpoint until the master terminal has reached the limit of the number of simultaneous sessions it can support. TS-103-286-2,section 6.3: If the TV Device has reached the limit of the number of simultaneous connections to the CSS-CII service endpoint that it can handle, then the TV Device shall refuse the connection request by returning the HTTP response code 503 "Service Unavailable". | |||
| org.hbbtv_MDEVSYNC1004 | 1 | Master Terminal: Ignores Origin header | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. When the master terminal receives a websocket connection request with an Origin header, which shall be validly formatted, and contain a URL that is not associated with (or representative of) the master, the client or the applications running on either (or the sources of any of these), from a CSA to connect on the CSS-CII protocol service endpoint, it will accept the connection. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: The master terminal shall ignore the Origin header if it is present in the client handshake of the connection request. TS-103-286-2,section 6.3: The TV Device may examine the "Origin" header if it is present in the HTTP Request header from the CSA used in the WebSocket protocol to establish the connection. On the basis of the value of the "Origin" header, the TV Device may choose to refuse to establish the connection and respond with a 403 "Forbidden" response code, as described in section 10.2 of RFC 6455 [8]. | |||
| org.hbbtv_MDEVSYNC1007 | 1 | presentationStatus is for master media | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The primary aspect of the presentationStatus sent by the master terminal once a connection to a CSA is made is either 'okay', 'transitioning' or 'fault' | 2024-1 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 13.6.2: The presentationStatus property shall describe the presentation status of the master media. TS-103-286-2,section 5.6.4: If the primary aspect of status is one of the following lower-case string values then it shall convey the corresponding described meaning: • okay: The TV Device is presenting Timed Content to the user. Some portion of the Timed Content (such as video and/or audio) is being presented at any play speed, including paused, faster than normal, slower than normal or reverse. • transitioning: The TV Device is in the process of starting or changing what Timed Content is being presented to the user but has not yet begun presenting the Timed Content it is changing to. • fault : The TV Device is not currently presenting Timed Content to the user due to a problem either in receiving the Timed Content or in trying to present it. | |||
| org.hbbtv_MDEVSYNC1009 | 1 | Master Terminal: presentationStatus derived as transitioning for a video/broadcast object in connecting state after channel change | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal receives a WebSocket "connection request" message from a CSA and responds with a CII message via a connection to the CSS-CII service endpoint. The master terminal calls 'nextChannel()' invoking a channel change. This causes the current state of the video/broadcast object presenting the master media to become 'connecting'. The primary aspect of the presentationStatus in the CII message sent by the master terminal to the CSA is 'transitioning'. | 2024-1 2023-3 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: CII messages sent by the master terminal via a connection to the CSS-CII service endpoint shall convey the following: ... The primary aspect of presentation status shall be derived from the state of the media object presenting the master media. For a video/broadcast object this shall be according to Table 21. | |||
| org.hbbtv_MDEVSYNC101 | 1 | Synchronisation timeline requested by the CSA is TEMI and is available | A HbbTV application has initialised a MediaSynchroniser, passed to it a media object presenting a service from a DVB broadcast (consisting of that one service and using MPEG-TS Timed External Media Information - TEMI- timeline), and enabled inter-device synchronisation causing the terminal to become a master terminal. A newly connected CSA requests a MPEG-TS TEMI timeline for synchronisation, referring to the same service of the same DVB broadcast. Within 3 seconds from the receipt of the request from the CSA, the master terminal will send out a control timestamp to that CSA. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8.2.2: The requested Synchronisation Timeline shall be available if the requirements for determining the availability defined in clause 9.7.3 of the present document and in clause 9.2 of ETSI TS 103 286-2 [47] are met and the requested Timeline is supported by the master terminal (see clause 13.4.2). HBBTV,section 13.8.2.3: The MSAS function of the master terminal shall send its first Control Timestamp within 500ms of receiving the setup-data message and having determined the availability of the timeline. NOTE: This means that the master terminal sends the first Control Timestamp at most 500ms after having played 2.5 seconds of the broadcast or SPTS stream subsequent to the request for a TEMI timeline being made, or within 500ms for all other types of timeline defined in the present document. For a TEMI timeline, if the content is not yet playing then this period will be longer. HBBTV,section 9.7.3: If the requested timeline is an MPEG TEMI timeline (see clause 13.4) then the terminal shall look for the temi_timeline_descriptor in the media for 2.5 seconds while the media is in the playing state [] | |||
| org.hbbtv_MDEVSYNC1010 | 1 | Master Terminal: presentationStatus derived as okay for a video/broadcast object in connecting state after a transient error | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal receives a WebSocket "connection request" message from a CSA and responds with a CII message via a connection to the CSS-CII service endpoint. There is a temporary loss of broadcast signal causing a transient error that causes the video/broadcast object presenting the master media to temporarily be in the state 'connecting'. While this is the case, the primary aspect of the presentationStatus sent by the master terminal (via the connection from a CSA to the CSS-CII endpoint) is 'okay' | 2024-1 2021-2 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.6.2: CII messages sent by the master terminal via a connection to the CSS-CII service endpoint shall convey the following: ... The primary aspect of presentation status shall be derived from the state of the media object presenting the master media. For a video/broadcast object this shall be according to Table 21. | |||
| org.hbbtv_MDEVSYNC1011 | 1 | Master Terminal: presentationStatus derived as okay for a video/broadcast object in presenting state | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal receives a WebSocket "connection request" message from a CSA and responds with a CII message via a connection to the CSS-CII service endpoint. When the current state of the video/broadcast object presenting the master media is 'presenting', then the primary aspect of the presentationStatus in the CII message sent by the master terminal to the CSA is 'okay'. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: CII messages sent by the master terminal via a connection to the CSS-CII service endpoint shall convey the following: ... The primary aspect of presentation status shall be derived from the state of the media object presenting the master media. For a video/broadcast object this shall be according to Table 21. [...] Table 21 | Transition to this state of the v/b object | any transition | Current v/b object state | Presenting | Primary aspect of CSS-CII presentationStatus | okay | |||
| org.hbbtv_MDEVSYNC1017 | 1 | Master Terminal: presentationStatus derived as transitioning for a HTML5 media element < HAVE_CURRENT_DATA | An HbbTV application has successfully initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal receives a WebSocket "connection request" message from a CSA and responds with a CII message via a connection to the CSS-CII service endpoint with primary aspect of presentationStatus as 'okay'. When the application seeks ahead in HTML5 media element to a time index outside what is currently buffered, causing the HTML5 media element to stall and the readyState of the HTML5 media element presenting the master media to become < HAVE_CURRENT_DATA (2), then the next CII message sent by the master terminal to the CSA has the primary aspect of the presentationStatus as 'transitioning'. | 2024-1 2023-3 2023-2 2023-1 2022-3 2020-2 2020-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: CII messages sent by the master terminal via a connection to the CSS-CII service endpoint shall convey the following: ... For an HTML5 media element that shall be according to Table 23. | ||
| org.hbbtv_MDEVSYNC1018 | 1 | Master Terminal: presentationStatus derived as okay for a HTML5 media element >= HAVE_CURRENT_DATA | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal receives a WebSocket "connection request" message from a CSA and responds with a CII message via a connection to the CSS-CII service endpoint. The readyState of the HTML5 media element presenting the master media (passed as an argument to initMediaSynchroniser) is >= HAVE_CURRENT_DATA (2). The primary aspect of the presentationStatus in the CII message sent by the master terminal to the CSA is 'okay' | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: CII messages sent by the master terminal via a connection to the CSS-CII service endpoint shall convey the following: ... For an HTML5 media element that shall be according to Table 23. [...] State of HTML5 media element | readyState ≥ HAVE_CURRENT_DATA | Primary aspect of CSS-CII presentationStatus | okay | |||
| org.hbbtv_MDEVSYNC103 | 1 | Synchronisation timeline requested by the CSA is DASH p-r and is available | A HbbTV application has initialised a MediaSynchroniser, passed to it a media object representing a DASH service (using DASH p-r timeline), and enabled inter-device synchronisation causing the terminal to become a master terminal. A newly connected CSA requests a DASH p-r timeline for synchronisation, which refers to the same service the master terminal is presenting and whose specified period-id is present in the MPD at the master terminal. Upon receipt of this request from the CSA, the master terminal will send out a control timestamp to that CSA. | 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 13.8.2.2: The requested Synchronisation Timeline shall be available if the requirements for determining the availability defined in clause 9.7.3 of the present document and in clause 9.2 of ETSI TS 103 286-2 [47] are met and the requested Timeline is supported by the master terminal (see clause 13.4.2). HBBTV,section 9.7.3: If the requested timeline is an MPEG DASH Period Relative timeline (see clause 13.4) then the terminal shall have determined the availability of the timeline once the MPD has been loaded when starting presentation (or updated during presentation) and the id attribute of all Periods in the presentation are known. TS-103-286-2,section 5.3.7.1: A Timeline indicated by a given Timeline Selector shall be available if it is possible to determine a Time Value on that Timeline that corresponds to the point currently being presented by the TV Device. It is possible to do this if: - the TV Device is presenting an MPEG DASH presentation - and the Period ID in the Timeline Selector corresponds to the value of any Period@ID currently in the MPD. | |||
| org.hbbtv_MDEVSYNC1033 | 1 | Master Terminal: CSS-CII: TV Device shall include properties defined in 5.6 of [47] in CSS message first time it is sent | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The first CII message sent by the master terminal once a connection to a CSA is made, which contains a JSON object matching the schema defined in Annex A.1.4 of ETSI TS 103 286-2 [47], has the value of the property protocolVersion set to 1.1 and the primary aspect of the property presentationStatus set to 'okay' or 'transitioning'. The values of the properties contentId, contentIdStatus, tsUrl and wcUrl are set to non-null values. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: As described in clause 5.6 of ETSI TS 103 286-2 [47], a slave terminal (or CSA) assumes initial values for all properties of null until a first CII message is received from the master terminal. An active CSS-CII service endpoint is always accompanied by active CSS-WC and CSS-TS service endpoints and there is always a designated master media object that will be connecting to or playing a source of media. The first CII message shall therefore define non-null values for the following properties: protocolVersion, contentId, contentIdStatus, presentationStatus, tsUrl and wcUrl. As described in clause 5.6 of ETSI TS 103 286-2 [47], properties may be omitted from CII messages if the value of the property has not changed since the last time a CII message was sent to the same slave. TS-103-286-2,section 6.2: Clause 5.6 defines this message and which properties shall be included in the first of these messages that is sent over the connection. TS-103-286-2,section 5.6.1: CII consists of the following pieces of information: The protocol version implemented by the TV Device ... The Content Identifier corresponding to the Timed Content currently being presented by the TV Device ... The status of the Content Identifier ... The status of presentation of Timed Content by the TV Device as defined in clause 5.6.4. The URL of the Wall Clock Service endpoint ... The URL of the Timeline Synchronization Service endpoint ... TS-103-286-2,section 5.6.4: If the primary aspect of status is one of the following lower-case string values then it shall convey the corresponding described meaning: okay: The TV Device is presenting Timed Content to the user ... transitioning: The TV Device is in the process of starting or changing what Timed Content is being presented to the user ... TS-103-286-2,section A.1.4: This schema will validate a correctly formed JSON representation of a Content Identification and other Information (CII) message: [...] | |||
| org.hbbtv_MDEVSYNC1036 | 1 | Master Terminal: CSS-CII: TV Device shall send a new CII message if presentationStatus changes - video/broadcast object | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal receives WebSocket "connection request" messages from two CSAs and responds with a CII message via a connection to the same CSS-CII service endpoint. The master terminal calls 'setChannel()' invoking a channel change. This causes the current state of the video/broadcast object presenting the master media to become 'connecting'. The primary aspect of the presentationStatus in the CII message sent by the master terminal to the CSA is 'transitioning'. The master terminal successfully connects to the channel and presents its content. The current state of the video/broadcast object presenting the master media changes to 'presenting'. Then the primary aspect of the presentationStatus in the CII message sent by the master terminal to the CSA changes to 'okay'. The next CII message sent by the master terminal to all connected CSAs is updated to include the new value of presentationStatus property. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface... CII messages sent by the master terminal via a connection to the CSS-CII service endpoint shall convey the following: ... The primary aspect of presentation status shall be derived from the state of the media object presenting the master media. For a video/broadcast object this shall be according to Table 21... NOTE: The contentId and other properties can change during inter-device synchronisation even though the master media is derived from the same Media Object. The master terminal pushes updates when any property of the CII message changes. TS-103-286-2,section 6.2: When the TV Device detects a change that would result in a change to one or more of the properties included in the Content Identification and other Information message, the TV Device shall send to all connected CSAs a message containing updated Content Identification and other Information. | |||
| org.hbbtv_MDEVSYNC1039 | 1 | Master Terminal: CSS-CII: TV Device shall send a new CII message if timeline changes (TEMI) | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The media object passed to the initMediaSynchroniser is a video/broadcast object presenting an MPEG-TS broadcast. The TEMI timeline signalled in the MPEG TS for the broadcast service being presented has a tick rate of 100 ticks per second. The master terminal receives WebSocket "connection request" messages from two CSAs and responds with a CII message via a connection to the same CSS-CII service endpoint. The timelines property of the CII message sent to the slave when it connected to the CSS-CII endpoint had a tick rate of 100 ticks per second. The master terminal calls 'setChannel()' invoking a channel change to one in which another MPEG Transport Stream is being delivered via broadcast at a tick rate of 50 ticks per second. This causes a change in the timeline property of the next CII message to a tick rate of 50 ticks per second. | 2024-1 2023-3 2023-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface... NOTE: The contentId and other properties can change during inter-device synchronisation even though the master media is derived from the same Media Object. The master terminal pushes updates when any property of the CII message changes. TS-103-286-2,section 6.2: When the TV Device detects a change that would result in a change to one or more of the properties included in the Content Identification and other Information message, the TV Device shall send to all connected CSAs a message containing updated Content Identification and other Information. | ||
| org.hbbtv_MDEVSYNC1044 | 1 | Master Terminal: CSS-CII: TV Device shall provide status code in a close frame when closing connection due to a client "going away" | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal closes the connection. The master terminal provides a status code of 1001 to indicate that the reason for a connection closure as "going away" as prescribed in the WebSocket protocol specification (Section 7 of RFC6455 [40] | 2024-1 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47]... TS-103-286-2,section 6.3: This is not considered a normal closure, and so the TV Device shall provide an appropriate status code in the Close Frame to indicate the reason for the connection closure. | |||
| org.hbbtv_MDEVSYNC1048 | 1 | Master Terminal: CSS-CII: presentationStatus in CII is primary aspect followed by optional extended aspects | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The status of presentation of Timed Content is represented by a primary aspect of the status, which is sent by the master terminal once a connection to a CSA is made, followed by zero or more extended aspects. | 2024-1 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 13.6.2: The presentationStatus property shall describe the presentation status of the master media. TS-103-286-2,section 5.6.4: The status of presentation shall be represented by a primary aspect of status followed by zero or more extended aspects. | |||
| org.hbbtv_MDEVSYNC1055 | 1 | Master Terminal: CSS-CII: protocolVersion in CII shall never change | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The media object passed to the initMediaSynchroniser is a video/broadcast object. The master terminal receives a WebSocket "connection request" message from a CSA and responds with a CII message (including a protocolVersion property) via a connection to the CSS-CII service endpoint. The master terminal calls 'nextChannel()' invoking a channel change. The master terminal successfully connects to the channel and presents its content. This causes a CII message to be sent by the master terminal to the CSA with the new value of presentationStatus property. The protocolVersion property, if present in a CII JSON object, has the same value as sent when the connection was established. | 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 13.6.2: As described in clause 5.6 of ETSI TS 103 286-2 [47], properties may be omitted from CII messages if the value of the property has not changed since the last time a CII message was sent to the same slave. TS-103-286-2,section 5.6.7: Within a protocol transport connection the value of protocolVersion property shall not change but may optionally be repeated with the same value or the property may be omitted from all but the initial CII JSON object. | |||
| org.hbbtv_MDEVSYNC1056 | 1 | Master Terminal: CSS-CII: presentationStatus in CII shall never be null | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The presentationStatus property is present in the CII message sent by the master terminal to a CSA, and is set to a non-null value. | 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 13.6.2: The presentationStatus property shall describe the presentation status of the master media. TS-103-286-2,section 5.6.7: The presentationStatus property shall never have the value null. | |||
| org.hbbtv_MDEVSYNC1057 | 1 | Master terminal: timeline information sent in the CII message is correct (MPEG-TS PTS: Presentation Time Stamp) | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal receives a WebSocket "connection request" message from a CSA and responds with a CII message via a connection to the CSS-CII service endpoint. The media object passed as an object to the initMediaSynchroniser is a MPEG Transport Stream delivered via broadcast or a Single program MPEG Transport Stream streamed via broadband. A MPEG Transport Stream PTS is used as the Timeline. The value of the Timeline Selector is 'urn:dvb:css:timeline:pts', the unitsPerTick of the timeline is 1 and the unitsPerSecond is 90,000. The timelines property sent, in the CII message, by the master terminal contains a list in which the first item is a timeline options JSON object which matches the Synchronisation Timeline passed as an argument to initMediaSynchroniser. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: CII messages sent by the master terminal via a connection to the CSS-CII service endpoint shall convey the following: ... While the MediaSynchroniser API timeline is available (see clause 9.7.3) the timelines property shall convey a list where the first item in the list is a timeline options JSON object (as defined in clause 5.6 of ETSI TS 103 286-2 [47]) that describes the MediaSynchroniser API Timeline (as defined in clause 13.4.3). HBBTV,section 13.4.2: 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() or addMediaObject() methods of a MediaSynchroniser object. TS-103-286-2,section 5.3.3: ...The Timeline Selector is a URI that specifies the source of a Timeline by indicating its type and information needed to locate the signalling that conveys Time Values on it... Table 5.3.3.1 indicates the values of Timeline Selector ("urn:dvb:css:timeline:pts") that are defined in the present document along with the reference to the Clause (5.3.4) that describes how that particular type of Timeline is signalled and how to locate the signalling. TS-103-286-2,section 5.3.4: The unitsPerTick of the timeline shall be 1 and the unitsPerSecond shall be 90 000, corresponding to the tick rate of clock underpinning PTS. | |||
| org.hbbtv_MDEVSYNC1059 | 1 | Master terminal: timeline information sent in the CII message is correct (TEMI) | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. After at least 2.5 seconds from sending a WebSocket "connection request" message to the master terminal, a CII message via the CSS-CII service endpoint is received. The media object passed as an object to the initMediaSynchroniser is a MPEG Transport Stream delivered via broadcast or a Single program MPEG Transport Stream streamed via broadband. The MPEG-TS Timed External Media Information (TEMI) is used as the Timeline. The master terminal searches for the temi_timeline_descriptor in the media. The value of the Timeline Selector is "urn:dvb:css:timeline:temi:<component_tag>:<timeline_id>" where <component_tag> corresponds to the stream of the broadcast service that carries the temi timeline and <timeline_id> corresponds to the timeline id of the temi_timeline_descriptor. The unitsPerTick of the timeline is 1 and the unitsPerSecond is as signalled by the Timeline Tick Rate value carried in the transport stream adaptation layer. The timelines property sent, in the CII message, by the master terminal contains a list in which the first item is a timeline options JSON object which matches the Synchronisation Timeline passed as an argument to initMediaSynchroniser | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: CII messages sent by the master terminal via a connection to the CSS-CII service endpoint shall convey the following: ... While the MediaSynchroniser API timeline is available (see clause 9.7.3) the timelines property shall convey a list where the first item in the list is a timeline options JSON object (as defined in clause 5.6 of ETSI TS 103 286-2 [47]) that describes the MediaSynchroniser API Timeline (as defined in clause 13.4.3). HBBTV,section 13.4.2: 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() or addMediaObject() methods of a MediaSynchroniser object. HBBTV,section 9.7.3: If the requested timeline is an MPEG TEMI timeline (see clause 13.4) then the terminal shall look for the temi_timeline_descriptor in the media for 2.5 seconds while the media is in the playing state... TS-103-286-2,section 5.3.3: ...The Timeline Selector is a URI that specifies the source of a Timeline by indicating its type and information needed to locate the signalling that conveys Time Values on it... Table 5.3.3.1 indicates the values of Timeline Selector ("urn:dvb:css:timeline:temi:<component_tag>:<timeline_id>") that are defined in the present document along with the reference to the Clause (5.3.6) that describes how that particular type of Timeline is signalled and how to locate the signalling. TS-103-286-2,section 5.3.6: The unitsPerTick of the timeline shall be 1 and the unitsPerSecond shall be as signalled by the Timeline Tick Rate value carried in the transport stream adaptation layer. | |||
| org.hbbtv_MDEVSYNC1060 | 1 | Master Terminal: timelines provided, listing Media Synchroniser timeline (MPEG DASH : Period relative Timeline) | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal receives a WebSocket "connection request" message from a CSA and responds with a CII message via a connection to the CSS-CII service endpoint. The media object passed as an object to the initMediaSynchroniser is a MPEG DASH streamed via broadband. The MPEG DASH Period Relative Timeline is used as the Timeline. The Media Presentation Description (MPD) has been loaded, the id attribute of all Periods in the presentation is known and the availability of the timeline is determined. The value of the Timeline Selector is "urn:dvb:css:timeline:mpd:period:rel:<ticks-per-second>'. The unitsPerTick of the timeline is 1 and the unitsPerSecond of the timeline is the value of <ticks-per-second>. The timelines property sent, in the CII message, by the master terminal contains a list in which the first item is a timeline options JSON object which matches the Synchronisation Timeline passed as an argument to initMediaSynchroniser | 2024-1 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 13.6.2: CII messages sent by the master terminal via a connection to the CSS-CII service endpoint shall convey the following: ... While the MediaSynchroniser API timeline is available (see clause 9.7.3) the timelines property shall convey a list where the first item in the list is a timeline options JSON object (as defined in clause 5.6 of ETSI TS 103 286-2 [47]) that describes the MediaSynchroniser API Timeline (as defined in clause 13.4.3). HBBTV,section 13.4.2: 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() or addMediaObject() methods of a MediaSynchroniser object. HBBTV,section 9.7.3: If the requested timeline is an MPEG DASH Period Relative timeline (see clause 13.4) then the terminal shall have determined the availability of the timeline once the MPD has been loaded when starting presentation (or updated during presentation) and the id attribute of all Periods in the presentation are known. TS-103-286-2,section 5.3.3: ...The Timeline Selector is a URI that specifies the source of a Timeline by indicating its type and information needed to locate the signalling that conveys Time Values on it... Table 5.3.3.1 indicates the values of Timeline Selector ("urn:dvb:css:timeline:mpd:period:rel:<ticks-per-second>") that are defined in the present document along with the reference to the Clause (5.3.7) that describes how that particular type of Timeline is signalled and how to locate the signalling. TS-103-286-2,section 5.3.7: The unitsPerTick of the Timeline shall be 1. The unitsPerSecond of the Timeline shall be value of <ticks-per-second>. | |||
| org.hbbtv_MDEVSYNC1061 | 1 | Master Terminal: timelines provided, listing Media Synchroniser timeline (MPEG DASH : Period relative Timeline) with period-id | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. The master terminal receives a WebSocket "connection request" message from a CSA and responds with a CII message via a connection to the CSS-CII service endpoint. The media object passed as an object to the initMediaSynchroniser is a MPEG DASH streamed via broadband. The MPEG DASH Period Relative Timeline is used as the Timeline. The Media Presentation Description (MPD) has been loaded, the id attribute of all Periods in the presentation is known and the availability of the timeline is determined. The value of the Timeline Selector is "urn:dvb:css:timeline:mpd:period:rel:<ticks-persecond>:<period-id>" where <period-id> corresponds to the the value of Period@ID currently in the MPEG DASH Presentation Description (MPD), the unitsPerTick of the timeline is 1 and the unitsPerSecond of the timeline is the value of <ticks-per-second>. The timelines property sent, in the CII message, by the master terminal contains a list in which the first item is a timeline options JSON object which matches the Synchronisation Timeline passed as an argument to initMediaSynchroniser | 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 13.6.2: CII messages sent by the master terminal via a connection to the CSS-CII service endpoint shall convey the following: ... While the MediaSynchroniser API timeline is available (see clause 9.7.3) the timelines property shall convey a list where the first item in the list is a timeline options JSON object (as defined in clause 5.6 of ETSI TS 103 286-2 [47]) that describes the MediaSynchroniser API Timeline (as defined in clause 13.4.3). HBBTV,section 13.4.2: 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() or addMediaObject() methods of a MediaSynchroniser object. HBBTV,section 13.4.3.1: The Timeline to be used by the MediaSynchroniser API within a master terminal is the timeline selected for the master media in the call to the initMediaSynchroniser() method of the MediaSynchroniser object. HBBTV,section 9.7.3: If the requested timeline is an MPEG DASH Period Relative timeline (see clause 13.4) then the terminal shall have determined the availability of the timeline once the MPD has been loaded when starting presentation (or updated during presentation) and the id attribute of all Periods in the presentation are known. TS-103-286-2,section 5.3.3: ...The Timeline Selector is a URI that specifies the source of a Timeline by indicating its type and information needed to locate the signalling that conveys Time Values on it... Table 5.3.3.1 indicates the values of Timeline Selector ("urn:dvb:css:timeline:mpd:period:rel:<ticks-persecond>:<period-id>") that are defined in the present document along with the reference to the Clause (5.3.7) that describes how that particular type of Timeline is signalled and how to locate the signalling. TS-103-286-2,section 5.3.7.2: The unitsPerTick of the Timeline shall be 1. The unitsPerSecond of the Timeline shall be value of <ticks-per-second>. | |||
| org.hbbtv_MDEVSYNC1062 | 1 | Master Terminal: presentationStatus derived as transitioning for a video/broadcast object in connecting state after bind | An HbbTV application has created a video/broadcast object and transitioned it to the STOPPED state, causing the terminal to cease presenting broadcast. The application calls 'setChannel()' to instruct the terminal to resume presenting a broadcast channel. This causes the video/broadcast object to enter the CONNECTING state. As soon as this happens, the application immediately initialises a MediaSynchroniser with the video/broadcast object; and then as quickly as possible the application enables inter-device synchronisation; and then as quickly as possible after this has happened, the terminal's CSS-CII endpoint is connected to by a CSA. The primary aspect of the presentationStatus in the first CII message received by the CSA shall be either "transitioning" or "okay". After the transition to the CONNECTING state occurs, the subsequent steps are performed as quickly as is reliably possible to maximise the chance of the video/broadcast object still being in the CONNECTING state. The video/broadcast may transition from the CONNECTING state to the PRSENTING state at any point during these steps, but the call to initMediaSynchroniser() and the enabling of inter-device synchronisation and the connection of a CSA to the CSS-CII service endpoint shall all succeed without error. | 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 13.6.2: CII messages sent by the master terminal via a connection to the CSS-CII service endpoint shall convey the following: ... The primary aspect of presentation status shall be derived from the state of the media object presenting the master media. For a video/broadcast object this shall be according to Table 21. | |||
| org.hbbtv_MDEVSYNC1500 | 1 | Master Terminal: Wall Clock protocol response message reported measurement precision | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. When receiving a Wall Clock request message on the CSS-WC endpoint, the terminal will respond with a Wall Clock response message where the precision of the transmit_timevalue and receive_timevalue fields is 1ms or better (smaller) as indicated by the precision field being a value less than or equal to -9. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.7.2: Measurements of the Wall Clock (or clock from which the Wall Clock is derived) by the terminal shall have a measurement precision (as defined in clause 8.2.2 of ETSI TS 103 286-2 [47]) of 1ms or better (smaller) for the purposes of: [...] the master terminal setting the value of the receive_timevalue in a Wall Clock Synchronisation response message with message_type 1, 2 or 3; [...] the master terminal setting the value of the transmit_timevalue in a Wall Clock Synchronisation response message with message_type 1 or 3; HBBTV,section 13.7.3: In Wall Clock response messages (where the message_type field has value 1, 2 or 3) sent by a master terminal the precision field shall have a value equal to or less than -9 [...] | |||
| org.hbbtv_MDEVSYNC1501 | 1 | Master Terminal: Wall Clock protocol response message reported max frequency error | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. After having received a Wall Clock request message on the CSS-WC endpoint, the terminal will respond with a Wall Clock response message where the value of the max_freq_error field is less than or equal to 128000. | 2024-1 2023-3 2023-2 2023-1 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,section 13.7.2: The maximum frequency error of the Wall Clock (or clock from which the Wall Clock is derived), as defined in clause 8.2.3 of ETSI TS 103 286-2 [47], shall be 500ppm or better (smaller). HBBTV,section 13.7.3: In Wall Clock response messages (where the message_type field has value 1, 2 or 3) sent by a master terminal [...] the max_freq_error field shall have a value equal to or less than 128000. | |||
| org.hbbtv_MDEVSYNC1504 | 1 | Master Terminal: CSS-WC endpoint can service 25 requests per second | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. When 25 Wall Clock request messages are sent (5 message sent by 5 entities representing individual CSAs or slave terminals) spread evenly over a period of 1 second to a master terminal, a response (consisting of a single message of message type 1 or two messages the first with type 2 and the second with type 3) is sent to each request within 200ms of it being received by the master terminal. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.7.3: The WC-Server shall respond in a timely fashion to a minimum of 25 requests per second. Responding in a timely fashion is defined as sending all responses within 200ms or less of receiving any request, given uncongested network conditions on the terminal's broadband interface. HBBTV,section 13.7.3: If the WC-Server responds to a request by sending both a response and a follow-up response then the follow-up response shall also be sent by the terminal within 200ms of the request being received, given uncongested network conditions on the terminal's broadband interface. TS-103-286-2,section 8.3: If a WC Server is capable of determining a more accurate value for the transmit_timevalue after a response has been sent, then the response message message_type shall be 2 otherwise it shall be 1. [...] If a WC Server is capable of determining a more accurate value for the transmit_timevalue after a response has been sent, then the WC Server shall also send a follow-up message back to the sender. The follow-up message shall contain the same field values as the response message except the message_type shall be 3 and the transmit_timevalue shall be the more accurate value that has been determined. | |||
| org.hbbtv_MDEVSYNC1514 | 1 | Master Terminal: CSS-WC message nanosecond values within allowed range. | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. Upon receiving a Wall Clock protocol request message, the master terminal will send at least one response message within 200ms. The transmit_timevalue_nanos and receivetimevalue_nanos fields in these response messages have values between 0 and 999 999 999. | 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.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.7.3: When the terminal is a master terminal, it shall implement a WC-Server as defined in Clause 8 of ETSI TS 103 286-2 [47]. HBBTV,section 13.7.3: The WC-Server shall respond in a timely fashion [...]. Responding in a timely fashion is defined as sending all responses within 200ms or less of receiving any request, given uncongested network conditions on the terminal's broadband interface. TS-103-286-2,section 8.3: The value of the second field shall be within the range 0 to 999 999 999 inclusive for receive_timevalue and transmit_timevalue, | |||
| org.hbbtv_MDEVSYNC1515 | 1 | Master Terminal: CSS-WC message sent by master has correct version | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. The value of the version field is 0 in a Wall Clock protocol message with message_type of 1, 2 or 3 sent by a master terminal in response to receiving a wall clock protocol request message. | 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 13.7.3: When the terminal is a master terminal, it shall implement a WC-Server as defined in Clause 8 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 8.3: version identifies the protocol version and shall have the value 0 | |||
| org.hbbtv_MDEVSYNC1517 | 1 | Master Terminal: CSS-WC message sent by master has correct message_type | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. 10 Wall Clock protocol message requests are sent to the master terminal. After each request, the master terminal responds with a Wall Clock protocol response message where the value of the message_type field is 1, 2 or 3. | 2024-1 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 13.7.3: When the terminal is a master terminal, it shall implement a WC-Server as defined in Clause 8 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 8.3: The WC Server shall only send messages with message_type 1, 2 or 3 to a CSA. | |||
| org.hbbtv_MDEVSYNC1519 | 1 | Master Terminal: CSS-WC message sent by master has correct reserved bits | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. The value of the reserved bits are 0 in a Wall Clock protocol message sent by a master terminal in response to receiving a Wall Clock protocol request message. | 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 13.7.3: When the terminal is a master terminal, it shall implement a WC-Server as defined in Clause 8 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 8.3: 8 bits are reserved and shall be set to zero. | |||
| org.hbbtv_MDEVSYNC1521 | 1 | Master Terminal: CSS-WC response includes originate_timevalue from request | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. The value of the originate_timevalue field in a Wall Clock protocol message sent by a master terminal in response to receiving a Wall Clock protocol request message is the same as the value in the request message, where in the request message, the originate_timevalue_nanos sub-field is a value greater than 999 999 999. | 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 13.7.3: When the terminal is a master terminal, it shall implement a WC-Server as defined in Clause 8 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 8.3: originate_timevalue is a time value of the clock at the WC Client at the time a message_type 0 request message was sent. A WC Server shall include it, unmodified in message_type 1, 2 or 3 response messages. TS-103-286-2,section 8.3: Time values in this syntax are conveyed as a 64 bit field comprising two 32 bit unsigned integer most significant byte first sub fields. The first is a number of seconds and the second field is a number of nanoseconds. The value of the second field shall be within the range 0 to 999 999 999 inclusive for receive_timevalue and transmit_timevalue, but not for originate_timevalue. | |||
| org.hbbtv_MDEVSYNC1522 | 1 | Master Terminal: CSS-WC response includes originate_timevalue from request, where nanos field is greater than 999 999 999 | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. A Wall Clock protocol request message is received with the originate_timevalue_nanos field containing a value greater than 999 999 999. The Wall Clock protocol response message (type 1 or 2 and 3 as appropriate) sent by a master terminal contains a value of the originate_timevalue field the same as the value of the originate_timevalue field in the request message | 2024-1 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 13.7.3: When the terminal is a master terminal, it shall implement a WC-Server as defined in Clause 8 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 8.3: originate_timevalue is a time value of the clock at the WC Client at the time a message_type 0 request message was sent. A WC Server shall include it, unmodified in message_type 1, 2 or 3 response messages. | |||
| org.hbbtv_MDEVSYNC1525 | 1 | Master Terminal: CSS-WC follow-up response has specific fields unchanged. | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. The master terminal sends a Wall Clock protocol response message with message_type 3 after sending a Wall Clock protocol response message with message_type 2, which in turn was sent in response to receiving a Wall Clock protocol request message with message_type 0. The values of the version, precision, reserved, max_freq_error, originate_timevalue and receive_timevalue fields are the same in both response messages. | 2024-1 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 13.7.3: When the terminal is a master terminal, it shall implement a WC-Server as defined in Clause 8 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 8.3: For message_type 3 [...] All other fields in a follow up message shall be the same values as they were for the previous response sent to the WC Client. | +CSS_WC_RESPONSE_TYPE_2 | ||
| org.hbbtv_MDEVSYNC1526 | 1 | Master Terminal: CSS-WC response sent in response to correctly formed request | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. When the master terminal receives a Wall Clock protocol request message where the message is 32 bytes and has version field equal to 0 and message_type equal to zero, the master terminal responds by sending back a Wall Clock protocol response message where the message_type is 1 or 2. | 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 13.7.3: When the terminal is a master terminal, it shall implement a WC-Server as defined in Clause 8 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 8.3: The WC Server function of the TV Device may ignore a received message where: the message is not 32 bytes in length, or the version is not equal to 0, or the message_type is not equal to 0. In all other cases, the WC Server shall respond to the sender of a message where the message_type is 0 with a response message where the message_type is 1 or 2 | |||
| org.hbbtv_MDEVSYNC1527 | 1 | Master Terminal: CSS-WC follow-up response sent if a message_type 2 response is sent | An HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation (using the enableInterDeviceSync() method) causing the terminal to become a master terminal. The master terminal sends a Wall Clock protocol response message with message_type 3 after sending a Wall Clock protocol response message with message_type 2, which in turn was sent in response to receiving a Wall Clock protocol request message with message_type 0. | 2024-1 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 13.7.3: When the terminal is a master terminal, it shall implement a WC-Server as defined in Clause 8 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 8.3: If a WC Server is capable of determining a more accurate value for the transmit_timevalue after a response has been sent, then the WC Server shall also send a follow-up message back to the sender. | +CSS_WC_RESPONSE_TYPE_2 | ||
| org.hbbtv_MDEVSYNC1531 | 1 | Master Terminal: CSS-CII mrsUrl derived from DVB broadcast URI_linkage_descriptor | An HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser method, passing it the video broadcast object that is presenting a DVB service. The application has also enabled inter device synchronisation causing the terminal to become a master terminal. The DVB service contains a URI_linkage_descriptor with uri_linkage_type of 2. The value of the descriptor is pushed in a CSS-CII message to a client connected to the CSS-CII endpoint within 2*N seconds where N is the period of repetition of the uri_linkage_descriptor in the broadcast transport stream. | 2024-1 2023-3 2023-2 2023-1 2022-1 2021-3 2021-2 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The mrsUrl property shall correspond to the URL of the MRS determined for the master media (see clause 5.6.2 of ETSI TS 103 286-2 [47]) for MPEG TS delivered via broadcast [...] TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.2: To determine the URL of the MRS for a DVB broadcast service, the TV Device shall look for a URI_linkage_descriptor (as defined in clause 6.4.14 of EN 300 468 ) corresponding to the DVB service currently being presented by the TV Device. EN-300-468,section 6.4.14: The URI linkage descriptor (see table 149) identifies a resource obtainable via an IP network. [table 149 defines descriptor syntax] uri_linkage_type: This is an 8-bit field specifying the type of URI linkage e.g. to information. It shall be encoded according to table 150. [table 150 row 3] uri_linkage_type 0x02 : Material Resolution Server (MRS) for companion screen applications | |||
| org.hbbtv_MDEVSYNC1532 | 1 | Master Terminal: CSS-CII mrsUrl derived from DVB broadcast URI_linkage_descriptor in NIT first loop when applying scoping rules. | An HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser method, passing it the video broadcast object that is presenting a DVB service. The application has also enabled inter device synchronisation causing the terminal to become a master terminal. The DVB service contains a URI_linkage_descriptor with uri_linkage_type of 2 in the following descriptor loops that relate to the DVB service being presented by the terminal: NIT first loop. The value of the descriptor is in the NIT first loop is pushed in a CSS-CII message to a client connected to the CSS-CII endpoint within N seconds where N is the period of repetition of that uri_linkage_descriptor in the broadcast transport stream. | 2024-1 2023-3 2023-2 2022-2 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The mrsUrl property shall correspond to the URL of the MRS determined for the master media (see clause 5.6.2 of ETSI TS 103 286-2 [47]) for MPEG TS delivered via broadcast and for MPEG DASH. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.2: If and when the URI_linkage_descriptor signals an MRS URL by using the appropriate uri_linkage_type (see clause 6.4.14 of EN 300 468 [13]), then it shall be interpreted under the scoping rules defined in clause 6.5 of EN 300 468 [13] EN-300-468,section 6.4.14: The URI linkage descriptor (see table 149) identifies a resource obtainable via an IP network. [table 149 defines descriptor syntax] uri_linkage_type: This is an 8-bit field specifying the type of URI linkage e.g. to information. It shall be encoded according to table 150. [table 150 row 3] uri_linkage_type 0x02 : Material Resolution Server (MRS) for companion screen applications EN-300-468,section 6.5: In increasing precedence order, the descriptor loops where a Scoping Descriptor may appear, if allowed by the type of scoping descriptor, are: 1) NIT first loop, 2) BAT first loop, 3) NIT TS loop, BAT 4) TS loop, 5) SDT 6) EIT. | |||
| org.hbbtv_MDEVSYNC1533 | 1 | Master Terminal: CSS-CII mrsUrl derived from DVB broadcast URI_linkage_descriptor in BAT first loop when applying scoping rules. | An HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser method and passing as a parameter the video broadcast object that is presenting a DVB service. The application has also enabled inter device synchronisation causing the terminal to become a master terminal. The DVB service contains a URI_linkage_descriptor with uri_linkage_type of 2 in the following descriptor loops that relate to the DVB service being presented by the terminal: NIT first loop and BAT first loop. It is expected that the value of the descriptor in the BAT first loop is pushed in a CSS-CII message to a client connected to the CSS-CII endpoint within N seconds where N is the period of repetition of that uri_linkage_descriptor in the broadcast transport stream. | 2024-1 2023-3 2022-3 2022-2 2022-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The mrsUrl property shall correspond to the URL of the MRS determined for the master media (see clause 5.6.2 of ETSI TS 103 286-2 [47]) for MPEG TS delivered via broadcast and for MPEG DASH. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.2: If and when the URI_linkage_descriptor signals an MRS URL by using the appropriate uri_linkage_type (see clause 6.4.14 of EN 300 468 [13]), then it shall be interpreted under the scoping rules defined in clause 6.5 of EN 300 468 [13] EN-300-468,section 6.4.14: The URI linkage descriptor (see table 149) identifies a resource obtainable via an IP network. [table 149 defines descriptor syntax] uri_linkage_type: This is an 8-bit field specifying the type of URI linkage e.g. to information. It shall be encoded according to table 150. [table 150 row 3] uri_linkage_type 0x02 : Material Resolution Server (MRS) for companion screen applications EN-300-468,section 6.5: In increasing precedence order, the descriptor loops where a Scoping Descriptor may appear, if allowed by the type of scoping descriptor, are: 1) NIT first loop, 2) BAT first loop, 3) NIT TS loop, BAT 4) TS loop, 5) SDT 6) EIT. | +BROADCAST_BAT | |
| org.hbbtv_MDEVSYNC1534 | 1 | Master Terminal: CSS-CII mrsUrl derived from DVB broadcast URI_linkage_descriptor in NIT TS loop when applying scoping rules. | An HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser method, passing as a parameter the video broadcast object that is presenting a DVB service. The application has also enabled inter device synchronisation causing the terminal to become a master terminal. The DVB service contains a URI_linkage_descriptor with uri_linkage_type of 2 in the following descriptor loops that relate to the DVB service being presented by the terminal: NIT first loop, BAT first loop and NIT TS loop. It is expected that the value of the descriptor in the NIT TS loop is pushed in a CSS-CII message to a client connected to the CSS-CII endpoint within N seconds where N is the period of repetition of that uri_linkage_descriptor in the broadcast transport stream. | 2024-1 2023-3 2023-2 2022-2 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The mrsUrl property shall correspond to the URL of the MRS determined for the master media (see clause 5.6.2 of ETSI TS 103 286-2 [47]) for MPEG TS delivered via broadcast and for MPEG DASH. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.2: If and when the URI_linkage_descriptor signals an MRS URL by using the appropriate uri_linkage_type (see clause 6.4.14 of EN 300 468 [13]), then it shall be interpreted under the scoping rules defined in clause 6.5 of EN 300 468 [13] EN-300-468,section 6.4.14: The URI linkage descriptor (see table 149) identifies a resource obtainable via an IP network. [table 149 defines descriptor syntax] uri_linkage_type: This is an 8-bit field specifying the type of URI linkage e.g. to information. It shall be encoded according to table 150. [table 150 row 3] uri_linkage_type 0x02 : Material Resolution Server (MRS) for companion screen applications EN-300-468,section 6.5: In increasing precedence order, the descriptor loops where a Scoping Descriptor may appear, if allowed by the type of scoping descriptor, are: 1) NIT first loop, 2) BAT first loop, 3) NIT TS loop, BAT 4) TS loop, 5) SDT 6) EIT. | |||
| org.hbbtv_MDEVSYNC1535 | 1 | Master Terminal: CSS-CII mrsUrl derived from DVB broadcast URI_linkage_descriptor in BAT TS loop when applying scoping rules. | An HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser method, passing as a parameter the video broadcast object that is presenting a DVB service. The application has also enabled inter device synchronisation causing the terminal to become a master terminal. The DVB service contains a URI_linkage_descriptor with uri_linkage_type of 2 in the following descriptor loops that relate to the DVB service being presented by the terminal: NIT first loop, BAT first loop, NIT TS loop and BAT TS loop. It is expected that the value of the descriptor in the BAT TS loop is pushed in a CSS-CII message to a client connected to the CSS-CII endpoint within N seconds where N is the period of repetition of that uri_linkage_descriptor in the broadcast transport stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2020-3 2020-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The mrsUrl property shall correspond to the URL of the MRS determined for the master media (see clause 5.6.2 of ETSI TS 103 286-2 [47]) for MPEG TS delivered via broadcast and for MPEG DASH. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.2: If and when the URI_linkage_descriptor signals an MRS URL by using the appropriate uri_linkage_type (see clause 6.4.14 of EN 300 468 [13]), then it shall be interpreted under the scoping rules defined in clause 6.5 of EN 300 468 [13] EN-300-468,section 6.4.14: The URI linkage descriptor (see table 149) identifies a resource obtainable via an IP network. [table 149 defines descriptor syntax] uri_linkage_type: This is an 8-bit field specifying the type of URI linkage e.g. to information. It shall be encoded according to table 150. [table 150 row 3] uri_linkage_type 0x02 : Material Resolution Server (MRS) for companion screen applications EN-300-468,section 6.5: In increasing precedence order, the descriptor loops where a Scoping Descriptor may appear, if allowed by the type of scoping descriptor, are: 1) NIT first loop, 2) BAT first loop, 3) NIT TS loop, BAT 4) TS loop, 5) SDT 6) EIT. | +BROADCAST_BAT | ||
| org.hbbtv_MDEVSYNC1536 | 1 | Master Terminal: CSS-CII mrsUrl derived from DVB broadcast URI_linkage_descriptor in SDT when applying scoping rules. | An HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser method, passing as a parameter the video broadcast object that is presenting a DVB service. The application has also enabled inter device synchronisation causing the terminal to become a master terminal. The DVB service contains a URI_linkage_descriptor with uri_linkage_type of 2 in the following descriptor loops that relate to the DVB service being presented by the terminal: NIT first loop, BAT first loop, NIT TS loop, BAT TS loop and SDT It is expected that the value of the descriptor in the SDT descriptor loop is pushed in a CSS-CII message to a client connected to the CSS-CII endpoint within N seconds where N is the period of repetition of that uri_linkage_descriptor in the broadcast transport stream. | 2024-1 2023-3 2023-2 2022-2 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The mrsUrl property shall correspond to the URL of the MRS determined for the master media (see clause 5.6.2 of ETSI TS 103 286-2 [47]) for MPEG TS delivered via broadcast and for MPEG DASH. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.2: If and when the URI_linkage_descriptor signals an MRS URL by using the appropriate uri_linkage_type (see clause 6.4.14 of EN 300 468 [13]), then it shall be interpreted under the scoping rules defined in clause 6.5 of EN 300 468 [13] EN-300-468,section 6.4.14: The URI linkage descriptor (see table 149) identifies a resource obtainable via an IP network. [table 149 defines descriptor syntax] uri_linkage_type: This is an 8-bit field specifying the type of URI linkage e.g. to information. It shall be encoded according to table 150. [table 150 row 3] uri_linkage_type 0x02 : Material Resolution Server (MRS) for companion screen applications EN-300-468,section 6.5: In increasing precedence order, the descriptor loops where a Scoping Descriptor may appear, if allowed by the type of scoping descriptor, are: 1) NIT first loop, 2) BAT first loop, 3) NIT TS loop, BAT 4) TS loop, 5) SDT 6) EIT. | |||
| org.hbbtv_MDEVSYNC1537 | 1 | Master Terminal: CSS-CII mrsUrl derived from DVB broadcast URI_linkage_descriptor in EIT when applying scoping rules. | An HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser method, passing as a parameter the video broadcast object that is presenting a DVB service. The application has also enabled inter device synchronisation causing the terminal to become a master terminal. The DVB service contains a URI_linkage_descriptor with uri_linkage_type of 2 in the following descriptor loops that relate to the DVB service being presented by the terminal: NIT first loop, BAT first loop, NIT TS loop, BAT TS loop, SDT and EIT It is expected that the value of the descriptor in the EIT descriptor loop for this is pushed in a CSS-CII message to a client connected to the CSS-CII endpoint within N seconds where N is the period of repetition of that uri_linkage_descriptor in the broadcast transport stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2020-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.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The mrsUrl property shall correspond to the URL of the MRS determined for the master media (see clause 5.6.2 of ETSI TS 103 286-2 [47]) for MPEG TS delivered via broadcast and for MPEG DASH. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.2: If and when the URI_linkage_descriptor signals an MRS URL by using the appropriate uri_linkage_type (see clause 6.4.14 of EN 300 468 [13]), then it shall be interpreted under the scoping rules defined in clause 6.5 of EN 300 468 [13] EN-300-468,section 6.4.14: The URI linkage descriptor (see table 149) identifies a resource obtainable via an IP network. [table 149 defines descriptor syntax] uri_linkage_type: This is an 8-bit field specifying the type of URI linkage e.g. to information. It shall be encoded according to table 150. [table 150 row 3] uri_linkage_type 0x02 : Material Resolution Server (MRS) for companion screen applications EN-300-468,section 6.5: In increasing precedence order, the descriptor loops where a Scoping Descriptor may appear, if allowed by the type of scoping descriptor, are: 1) NIT first loop, 2) BAT first loop, 3) NIT TS loop, BAT 4) TS loop, 5) SDT 6) EIT. | ||
| org.hbbtv_MDEVSYNC1538 | 1 | Master Terminal: CSS-CII mrsUrl derived from MPD | An HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser method, passing a media object presenting a DASH service. The application has also enabled inter device synchronisation causing the terminal to become a master terminal. The MPD for the DASH service contains an mrsUrl element. The value of the mrsUrl element in the MPD is pushed in a CSS-CII message to a client connected to the CSS-CII endpoint. | 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,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The mrsUrl property shall correspond to the URL of the MRS determined for the master media (see clause 5.6.2 of ETSI TS 103 286-2 [47]) for MPEG TS delivered via broadcast and for MPEG DASH. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.2: To determine the URL of the MRS for a DVB DASH service [16], the TV Device shall look for a mrsUrl element in the MPD (as defined in Annex E) that describes the content currently being presented by the TV Device. TS-103-286-2,section E.2.2: MRS URL: Where an MRS URL is to be carried for DASH delivered content, it shall be carried as the element mrsUrl, with a type mrsUrlType as a child of the MPD element. The MRS element shall use the namespace indicated in clause E.2.1. Any value carried shall comply with all constraints detailed in the present document and in clause 6.4.14 of ETSI EN 300 468 [13]. | |||
| org.hbbtv_MDEVSYNC1539 | 1 | Master Terminal: CSS-CII ci status for broadcast | An HbbTV application has initialised a MediaSynchroniser, passing a video broadcast object that is presenting a DVB broadcast service, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The value of a "contentIdStatus" property is "partial" or "final" in a CSS-CII message pushed from the terminal to a client connected to the CSS-CII endpoint. | 2024-1 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The status of the content identifier shall indicate whether the content identifier is "partial" or "final " according to the process defined in clause 5.2. | |||
| org.hbbtv_MDEVSYNC1540 | 1 | Master Terminal: CSS-CII ci status during broadcast service change | An HbbTV application has initialised a MediaSynchroniser, passing a video broadcast object that is presenting a DVB broadcast service, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The HbbTV application causes the video broadcast object to successfully retune to a different DVB broadcast service on a different multiplex (for which the HbbTV application is also permitted to run). From before the retune begins until after it has completed, the "contentIdStatus" property is either omitted or has the value "partial" or "final" in all CSS-CII message(s) pushed from the terminal to a client connected to the CSS-CII endpoint. | 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,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The status of the content identifier shall indicate whether the content identifier is "partial" or "final " according to the process defined in clause 5.2. TS-103-286-2,section 5.2.3.6.1: The TV Device may emit a sequence of zero or more "partial" CIs as the TV Device progressively acquires the signalling from which the CI is derived. | |||
| org.hbbtv_MDEVSYNC1542 | 1 | Master Terminal: CSS-CII ci status for DASH service is immediately final because CI is known | An HbbTV application has initialised a MediaSynchroniser, passing a media object that is presenting a DASH stream, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The value of a "contentIdStatus" property is "final" in the first CSS-CII message pushed from the terminal to a client that immediately connects to the CSS-CII endpoint after it becomes available. | 2024-1 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: Once the TV Device has acquired all of the signalling contributing to the CI or determined that the signalling is not present then the TV Device shall emit a "final" CI. | |||
| org.hbbtv_MDEVSYNC1543 | 1 | Master Terminal: CSS-CII ci status for MPEG2 TS progressive download is immediately final because CI is known | An HbbTV application has initialised a MediaSynchroniser, passing a media object that is presenting an MPEG2 TS media stream delivered via broadband, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The value of a "contentIdStatus" property is "final" in the first CSS-CII message pushed from the terminal to a client that immediately connects to the CSS-CII endpoint after it becomes available. | 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. [...] For ISOBMFF and MPEG2 TS delivered via broadband: [...] the contentIdStatus shall be "final". TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The status of the content identifier shall indicate whether the content identifier is "partial" or "final" | |||
| org.hbbtv_MDEVSYNC1544 | 1 | Master Terminal: CSS-CII ci status for ISOBMFF progressive download is immediately final because CI is known | An HbbTV application has initialised a MediaSynchroniser, passing a media object that is presenting an ISOBMFF media stream delivered via broadband, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The value of a "contentIdStatus" property is "final" in the first CSS-CII message pushed from the terminal to a client that immediately connects to the CSS-CII endpoint after it becomes available. | 2024-1 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. [...] For ISOBMFF and MPEG2 TS delivered via broadband: [...] the contentIdStatus shall be "final". TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The status of the content identifier shall indicate whether the content identifier is "partial" or "final" | |||
| org.hbbtv_MDEVSYNC1550 | 1 | Master Terminal: CSS-CII "broadcast" contentId begins "dvb" | An HbbTV application has initialised a MediaSynchroniser, passing a video broadcast object that is presenting a DVB broadcast service, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is a URI beginning with the scheme identifier "dvb". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.3.1: The CI URI scheme identifier is "dvb" and therefore the CI shall begin with the string "dvb" as lower case letters. | |||
| org.hbbtv_MDEVSYNC1551 | 1 | Master Terminal: CSS-CII "broadcast" contentId net path | An HbbTV application has initialised a MediaSynchroniser, passing a video broadcast object that is presenting a DVB broadcast service, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is a URI where the portion after the scheme is formatted correctly and corresponds to the DVB service currently being presented by the video broadcast object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.3.2: The net path of the CI for a DVB broadcast service shall comprise a pair of forward slashes "//" followed by the original network id, a full stop "." character, transport stream id, a full stop "." character and the service id. [...] The original network id, transport stream id, and service id shall all be expressed in hexadecimal as 4 digits where alphabetic characters are in lower case. Where the value of the id results in a hexadecimal number less than 4 digits long, this shall be padded to 4 digits by prefixing one or more zero "0" characters | |||
| org.hbbtv_MDEVSYNC1552 | 1 | Master Terminal: CSS-CII "broadcast" contentId event constraint present | An HbbTV application has initialised a MediaSynchroniser, passing a video broadcast object that is presenting a DVB broadcast service, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The broadcast service contains EIT p/f actual that signals a "present" event for the service being presented. The event does does not include a TVA_id_descriptor. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal, once the "contentIdStatus" property value is "final", is a string where the event-constraint part is formatted correctly and corresponds to the DVB event currently being signalled as the "present" event for this service in EIT present/following. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.3.1: The CI URI scheme identifier is "dvb" and therefore the CI shall begin with the string "dvb" as lower case letters. The hierarchical part of the CI URI includes a service path (defined in clauses 5.2.3.2 and 5.2.3.3) and an event constraint (defined in clause 5.2.3.4)[...] Table 5.2.3.1.1 summarizes the syntax of a CI for DVB broadcast TS-103-286-2,section 5.2.3.2: The net path of the CI for a DVB broadcast service shall comprise a pair of forward slashes "//" followed by the original network id, a full stop "." character, transport stream id, a full stop "." character and the service id: "//" original-network-id "." transport-stream-id "." service-id The original network id, transport stream id, and service id shall all be expressed in hexadecimal as 4 digits where alphabetic characters are in lower case. Where the value of the id results in a hexadecimal number less than 4 digits long, this shall be padded to 4 digits by prefixing one or more zero "0" characters. TS-103-286-2,section 5.2.3.4: The event constraint conveys the event-id, a TVA_id (if one is exists), and a time constraint describing the UTC start time and duration from the start_time and duration fields for this event (coming from EIT present/following actual): ";" event-id [ ";" tva-id ] "~" time-constraint [...] If there is EIT present in the DVB SI for the Timed Content being presented then the event constraint shall be included in the CI,[...] The time constraint begins with a tilde "~" character followed by the date and start time, as determined from the EIT signalling for the present event. For both start time and duration, the seconds are not included in this representation. Minutes shall not be rounded to the nearest minute irrespective of the value of the number of seconds | |||
| org.hbbtv_MDEVSYNC1553 | 1 | Master Terminal: CSS-CII "broadcast" contentID event constraint with tva_id | An HbbTV application has initialised a MediaSynchroniser, passing a video broadcast object that is presenting a DVB broadcast service, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The broadcast service contains EIT p/f actual that signals a "present" event for the service being presented. The event includes two or more TVA_id descriptors. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal, once the "contentIdStatus" property value is "final", is a string where the event-constraint part is formatted correctly and corresponds to the DVB event currently being signalled as the "present" event for this service in EIT present/following and using only the TVA_id conveyed in the first descriptor present in the event descriptor loop. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.3.4: If there are one or more TVA_ids carried in TVA_id_descriptor [2] descriptors in the EIT present/following actual, then the event constraint shall include the tva-id part (i.e. [ ";" TVA-id ]) in the CI and it shall correspond to the first TVA_id found in the first TVA_id_descriptor descriptor. | |||
| org.hbbtv_MDEVSYNC1554 | 1 | Master Terminal: CSS-CII "broadcast" contentId with no event constraint | An HbbTV application has initialised a MediaSynchroniser, passing a video broadcast object that is presenting a DVB broadcast service, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The broadcast service does not contain EIT p/f actual that signals a "present" event for the service being presented. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal, once the "contentIdStatus" property value is "final", is a string where the event-constraint part is not included. | 2024-1 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.3.4: If there is EIT present in the DVB SI for the Timed Content being presented then the event constraint shall be included in the CI, otherwise the event constraint shall not be included in the CI. | |||
| org.hbbtv_MDEVSYNC1555 | 1 | Master Terminal: CSS-CII "broadcast" contentId no query part | An HbbTV application has initialised a MediaSynchroniser, passing a video broadcast object that is presenting a DVB broadcast service, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The broadcast service does not feature a TV Anytime CRID for the present event or service. It does not feature a ci_ancillary_data_descriptor in the descriptor loop of the SDT for the present service. It does not feature a ci_ancillary_data_descriptor in the 1st descriptor loop of a BAT corresponding to this service. It does not feature a ci_ancillary_data_descriptor in the 1st descriptor loop of a NIT that applies to this service. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal, once the "contentIdStatus" property value is "final", is a string that does not include a "?" character. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.3.5: If there are to be no key-value pairs, then the query part of the CI, including the prefixed question mark character, shall be omitted. | |||
| org.hbbtv_MDEVSYNC1556 | 1 | Master Terminal: CSS-CII "broadcast" contentId episode CRID | An HbbTV application has initialised a MediaSynchroniser, passing a video broadcast object that is presenting a DVB broadcast service, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The broadcast service includes two or more TV Anytime episode CRIDs corresponding to what is currently being presented by the video/broadcast object. The value of the first episode CRID is different to that of the other episode CRIDs. The value of the first episode CRID includes the following characters in it: space (ASCII 32), underscore (ASCII 95), dash (ASCII 45), question mark (ASCII 63), ampersand (ASCII 38), equals (ASCII 61) and double quotemark (ASCII 34) as well as letters and numbers. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal, once the "contentIdStatus" property value is "final", includes a query part after a "?" that includes the key "ep_crid" with the value that is correctly formatted and corresponds to the first episode CRID. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.3.5: If there is one or more TV-Anytime episode CRIDs signalled in the manner described in Clause 12.1 of [2] for this event in EIT present/following for the actual TS, then the key "ep_crid" shall be included. The value corresponding with the key shall be the episode CRID. If the signalling defines multiple episode CRIDs for the event, then the first episode CRID shall be selected. The CRID shall include the authority but omit the "crid://" prefix. Number digits, lower and upper case alphabetic characters, dash "-", full-stop "." and underscore "_" shall be included unchanged. All other characters in a CRID shall be substituted with a percent "%" character followed the ASCII [28] value of that character formatted as two hex digits where alphabetic characters are uppercase. | ||
| org.hbbtv_MDEVSYNC1561 | 1 | Master Terminal: CSS-CII "broadcast" query part key order | An HbbTV application has initialised a MediaSynchroniser, passing a video broadcast object that is presenting a DVB broadcast service, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The broadcast service includes a TV Anytime episode CRID corresponding to what is currently being presented. The broadcast service contains EIT p/f actual for the service being presented where the descriptor loop of the present event includes a ci_ancillary_data descriptor. The descriptor loop for the SDT corresponding to the service being presented contains a ci_ancillary_data descriptor. The 1st descriptor loop of the BAT corresponding to the service being presented contains a ci_ancillary_data descriptor. The 1st descriptor loop for the NIT corresponding to the service being presented contains a ci_ancillary_data descriptor. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal, once the "contentIdStatus" property value is "final", includes a query part after a "?" where if any of the following keys are present they are in the order listed here: "ep_crid", "anc_eit", "anc_sdt", "anc_bat", "anc_nit" | 2024-1 2023-3 2023-2 2023-1 2022-3 2020-3 2020-2 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.3.5: The following key-value pairs are defined and shall be included in the query part in the same order as they are listed below: [...] ep_crid [...] anc_eit [...] anc_sdt [...] anc_bat [...] anc_nit | +BROADCAST_BAT | |
| org.hbbtv_MDEVSYNC1562 | 1 | Master Terminal: CSS-CII "broadcast" contentId reaches "final" form on init | An HbbTV application has created a video broadcast object that is presenting a DVB broadcast service. The application retunes that video broadcast object to a different DVB broadcast service. The application then immediately initialises a MediaSynchroniser, passing the video broadcast object, and then immediately enables inter-device synchronisation causing the terminal to become a master terminal. The value of the "contentIdStatus" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is the value "final" within N seconds of when the video broadcast object was tuned to the current DVB broadcast service where N is the longest repetition period of any of the SI tables in the broadcast: NIT, BAT, SDT, EIT. | 2024-1 2023-3 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The status of the content identifier shall indicate whether the content identifier is "partial" or "final " according to the process defined in clause 5.2. TS-103-286-2,section 5.2.3.6.1: The TV Device may emit a sequence of zero or more "partial" CIs as the TV Device progressively acquires the signalling from which the CI is derived. Once the TV Device has acquired all of the signalling contributing to the CI or determined that the signalling is not present then the TV Device shall emit a "final" CI. | |||
| org.hbbtv_MDEVSYNC1563 | 1 | Master Terminal: CSS-CII "broadcast" contentId reaches "final" form on channel change | An HbbTV application has initialised a MediaSynchroniser, passing a video broadcast object that is presenting a DVB broadcast service, and has enabled inter-device synchronisation causing the terminal to become a master terminal. When the HbbTV application instructs the video broadcast object to retune to a different DVB service for which the application is still permitted to execute, the value of the "contentIdStatus" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is the value "final" within N seconds of when the tuning of the video broadcast object to a different DVB service completes, where N is the longest repetition period of any of the SI tables in the broadcast: NIT, BAT, SDT, EIT. | 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,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The status of the content identifier shall indicate whether the content identifier is "partial" or "final " according to the process defined in clause 5.2. TS-103-286-2,section 5.2.3.6.1: The TV Device may emit a sequence of zero or more "partial" CIs as the TV Device progressively acquires the signalling from which the CI is derived. Once the TV Device has acquired all of the signalling contributing to the CI or determined that the signalling is not present then the TV Device shall emit a "final" CI. | |||
| org.hbbtv_MDEVSYNC1565 | 1 | Master Terminal: CSS-CII "DASH" contentId is an absolute URL matching the MPD location | An HbbTV application has initialised a MediaSynchroniser, passing a HTML5 media object that is presenting a DASH stream, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is a URI that matches, up to the point before any fragment separator ('#') the absolute URL from which the MPD for the DASH stream was initially retrieved. | 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.4: The CI URI shall consist of the absolute URL initially used to retrieve the MPD followed by an MPD anchor as defined in clause C.4 of the DASH specification [17] which uses the media fragments URI structure [18] DASH,section C.4.2: An MPD anchor is a set of Representations being presented and a time offset from the start of a period on the media timeline. These are expressed using URI fragment syntax. [...] URI fragment starts with the ‘#’ character, and is a string terminating the URI. | |||
| org.hbbtv_MDEVSYNC1566 | 1 | Master Terminal: CSS-CII "DASH" contentId fragment part is correctly formatted | An HbbTV application has initialised a MediaSynchroniser, passing a media object that is presenting a DASH presentation, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is a URI with a fragment part (after a '#') that is correctly formatted according to table 5.2.4.1 of TS-103-286-2. | 2024-1 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.4: The DASH CI as described above is shown in Table 5.2.4.1, as a formal specification expressed in Augmented BNF as defined in RFC 5234 [4] using the Core Rules defined in Appendix B.1 of [4] and the rules defined previously in table 5.2.3.1.1. | |||
| org.hbbtv_MDEVSYNC1567 | 1 | Master Terminal: CSS-CII "DASH" contentId fragment period parameter | An HbbTV application has initialised a MediaSynchroniser, passing a media object that is presenting a DASH presentation, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The MPD for the DASH presentation contains Period@id attributes for all periods in the MPD. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is a URI with a fragment part (after a '#') that includes a period parameter whose value matches the Period ID of the period that is currently presenting, and is updated when playback crosses a period boundary. | 2024-1 2023-3 2023-2 2023-1 2022-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,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.4: The period parameter [...] shall always follow the rules set out in clause C.4 of the DASH specification [17]. TS-103-286-2,section 6.2: When the TV Device detects a change that would result in a change to one or more of the properties included in the Content Identification and other Information message, the TV Device shall send to all connected CSAs a message containing updated Content Identification and other Information. This message shall include the properties that have changed and may omit properties that have not. | |||
| org.hbbtv_MDEVSYNC1568 | 1 | Master Terminal: CSS-CII "DASH" contentId fragment conveys mpd ancillary data | An HbbTV application has initialised a MediaSynchroniser, passing a media object that is presenting a DASH presentation, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The MPD for the DASH presentation contains a ciAncillaryData element as a child of the MPD element. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is a URI with a fragment part (after a '#') that includes a mpd_ci_ancillary key whose value matches the bytes carried in the ciAncillaryData element of the MPD. | 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.4: If present, the mpd_ci_ancillary parameter [...] shall carry exactly the bytes carried in the ciAncillaryData element of the MPD, as defined in clause E.2.3. TS-103-286-2,section E.2.3: Where ancillary data is to be provided, it shall be carried as the element ciAncillaryData with a type ciAncillaryDataType as a child of either the MPD or the Period element. The ciAncillaryData element shall use the namespace as indicated in clause E.2.1. | +DASH_MPD_CI_ANCILLARY_KEY | ||
| org.hbbtv_MDEVSYNC1569 | 1 | Master Terminal: CSS-CII "DASH" contentId fragment conveys period ancillary data for currently presenting period | An HbbTV application has initialised a MediaSynchroniser, passing a media object that is presenting a DASH presentation, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The MPD for the DASH presentation contains a ciAncillaryData element as a child of a period element corresponding to the period currently being presented. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is a URI with a fragment part (after a '#') that includes a period_ci_ancillary key whose value matches the bytes carried in the ciAncillaryData element of the MPD. | 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.4: If present, the period_ci_ancillary parameter [...] shall carry exactly the bytes carried in the ciAncillaryData element (as defined in clause E.2.3) of the Period signalled in the period parameter. TS-103-286-2,section E.2.3: Where ancillary data is to be provided, it shall be carried as the element ciAncillaryData with a type ciAncillaryDataType as a child of either the MPD or the Period element. The ciAncillaryData element shall use the namespace as indicated in clause E.2.1. | +DASH_PERIOD_CI_ANCILLARY_KEY | ||
| org.hbbtv_MDEVSYNC1570 | 1 | Master Terminal: CSS-CII "DASH" contentId fragment does not convey period ancillary data for a period not currently being presented | An HbbTV application has initialised a MediaSynchroniser, passing a media object that is presenting a DASH presentation, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The MPD for the DASH presentation contains a ciAncillaryData element as a child of a period element but this is not the same period as the one that is currently being presented. The MPD does not contain a ciAncillaryData element as a child of the period element corresponding to the period currently being presented. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is a URI with a fragment part (after a '#') that does not include a period_ci_ancillary key. | 2024-1 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.4: If present, the period_ci_ancillary parameter [...] shall carry exactly the bytes carried in the ciAncillaryData element (as defined in clause E.2.3) of the Period signalled in the period parameter. TS-103-286-2,section E.2.3: Where ancillary data is to be provided, it shall be carried as the element ciAncillaryData with a type ciAncillaryDataType as a child of either the MPD or the Period element. The ciAncillaryData element shall use the namespace as indicated in clause E.2.1. | |||
| org.hbbtv_MDEVSYNC1571 | 1 | Master Terminal: CSS-CII "DASH" contentId MPD URL does not change when MPD is updated | An HbbTV application has initialised a MediaSynchroniser, passing a media object that is presenting a dynamic DASH presentation, and has enabled inter-device synchronisation causing the terminal to become a master terminal. When the URL provided by the application that points to the MPD is fetched by the terminal, it redirects to another URL. The "contentId" property in the CII message sent by the master terminal via a connection to the CSS-CII service endpoint is a URI whose part before the fragment separator (before a '#') is the initial URL (prior to redirection) that was provided by the application. After the MPD is updated (triggered by DASH event or the @minimumUpdatePeriod attribute) and re-fetched by the terminal, the value of the "contentId" property is still a URI whose part before the fragment separator matches the initial URL provided by the application. | 2024-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-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.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. For DVB broadcast services and MPEG DASH streams this shall be as defined in clause 5.2 of ETSI TS 103 286-2 [47]. TS-103-286-2,section 6.1: The semantics, data model and representation of the Content Identification and other Information carried in the protocol are described in clause 5.6. TS-103-286-2,section 5.6.3: The format of the Content Identifier shall be defined according to clause 5.2 according to the type of Timed Content being presented by the TV Device. TS-103-286-2,section 5.2.4: Even if the MPD is updated or retrieved again, the URL used to retrieve the URL for the first time, prior to any redirections, shall always be used. | ||
| org.hbbtv_MDEVSYNC1580 | 1 | Master Terminal: CSS-CII "ISOBMFF" via broadband contentID | An HbbTV application has initialised a MediaSynchroniser, passing a media object that is presenting an ISOBMFF stream delivered via broadband, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The URL passed by the application as the source from which to obtain the broadband stream is redirected, via an HTTP 3xx redirect response, to a different URL from which the broadband stream is served. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is expected to match the URI provided by the HbbTV application to specify the location of the ISOBMFF media stream (not the different URL that the terminal was redirected to). | 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. [...] For ISOBMFF and MPEG2 TS delivered via broadband: the value of the "contentId" property shall be the absolute version of the URL provided by the HbbTV application to specify the location of the ISOBMFF media stream, before any redirect that may occur. | |||
| org.hbbtv_MDEVSYNC1581 | 1 | Master Terminal: CSS-CII "MPEG2TS" via broadband contentID | An HbbTV application has initialised a MediaSynchroniser, passing a media object that is presenting an MPEG2 TS stream delivered via broadband, and has enabled inter-device synchronisation causing the terminal to become a master terminal. The URL passed by the application as the source from which to obtain the broadband stream is redirected, via an HTTP 3xx redirect response, to a different URL from which the broadband stream is served. The value of the "contentId" property that is obtained by connecting to the CSS-CII endpoint of the master terminal is expected to match the URI provided by the HbbTV application to specify the location of the MPEG2 TS media stream (not the different URL that the terminal was redirected to). | 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 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. [...] The contentId and contentIdStatus properties shall correspond to the Content Identifier of the master media. [...] For ISOBMFF and MPEG2 TS delivered via broadband: the value of the "contentId" property shall be the absolute version of the URL provided by the HbbTV application to specify the location of the ISOBMFF media stream, before any redirect that may occur. | |||
| org.hbbtv_MDEVSYNC1780 | 1 | Master Terminal: Control Timestamp within minimum accuracy requirement 10ms in terms of a PTS synchronisation timeline when master media is a broadcast MPEG TS | The application on the terminal has initialised a MediaSynchroniser object using the initMediaSynchroniser method, providing a video/broadcast object presenting an MPEG-TS broadcast as the master media. The application has enabled inter-device synchronisation, and a connection has been established to the CSS-TS endpoint of the master terminal with where the initial setup-data message sent to the master terminal requested a PTS timeline and the master terminal has sent back a Control Timestamp indicating that the timeline is available. When the timing of presentation indicated by the value of the Control Timestamp is compared to the timing of presentation of the master media as observed by monitoring the light emitted then it is found to be accurate to within plus or minus the sum of 10ms and the current error bounds in estimating the Wall Clock of the master terminal (using the CSS-WC protocol) | 2024-1 2023-3 2020-2 2020-1 2019-3 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.8.2.4: Control Timestamps sent by the MSAS function of the master terminal to slave terminals and CSAs shall, when the synchronisation timeline is available, represent the timing of presentation of the master media by the master terminal. [...] When a Control Timestamp is representing a timing of presentation with respect to the reference point for timestamping, it shall do so to within plus or minus the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.4: The minimum accuracy for 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 the Synchronisation timeline (see clause 13.4.3.2). [...] If a video component is being presented for the master media, then the minimum accuracy for inter-device synchronisation shall be met for that video component when it is output via an integrated display. If an audio component but not video component is being presented for the master media, then the minimum accuracy for inter-device synchronization shall be met for that audio component when it is output via integrated speakers or headphone output. Minimum accuracy for inter-device synchronisation should be met with best-effort for audio and for video in all other situations. HBBTV,section 13.4.2: For multi-stream synchronization, inter-device synchronization, application to AV synchronization (see clause 13.11), and Targeted Advertising (see ETSI TS 103 736-1 [i.27]) the MediaSynchroniser object supports the use of the following types of timeline (defined in this clause and clause 5.3 of ETSI TS 103 286-2 [47]) for the types of broadcast or broadband content shown in Table 18. [row 1] MPEG-TS Presentation Timestamps (PTS) supported for MPEG Transport Stream delivered via broadcast. | ||
| org.hbbtv_MDEVSYNC1782 | 1 | Master Terminal: Control Timestamp within minimum accuracy requirement 10ms in terms of a CT synchronisation timeline when master media is ISOBMFF | The application on the terminal has initialised a MediaSynchroniser object using the initMediaSynchroniser method, providing a media object presenting an ISOBMFF (not DASH) media stream streamed via broadband as the master media. The application has enabled inter-device synchronisation, and a connection has been established to the CSS-TS endpoint of the master terminal with where the initial setup-data message sent to the master terminal requested a Composition Time timeline and the master terminal has sent back a Control Timestamp indicating that the timeline is available. The tick rate of the timeline is at least 100 ticks per second or faster, as determined by the timescale element of the movie header box and timescale element of the track header boxes in the ISOBMFF container. When the timing of presentation indicated by the value of the Control Timestamp is compared to the timing of presentation of the master media as observed by monitoring the light emitted then it is found to be accurate to within plus or minus the sum of 10ms and the current error bounds in estimating the Wall Clock of the master terminal (using the CSS-WC protocol) | 2024-1 2023-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8.2.4: Control Timestamps sent by the MSAS function of the master terminal to slave terminals and CSAs shall, when the synchronisation timeline is available, represent the timing of presentation of the master media by the master terminal. [...] When a Control Timestamp is representing a timing of presentation with respect to the reference point for timestamping, it shall do so to within plus or minus the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.4: The minimum accuracy for 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 the Synchronisation timeline (see clause 13.4.3.2). [...] If a video component is being presented for the master media, then the minimum accuracy for inter-device synchronisation shall be met for that video component when it is output via an integrated display. If an audio component but not video component is being presented for the master media, then the minimum accuracy for inter-device synchronization shall be met for that audio component when it is output via integrated speakers or headphone output. Minimum accuracy for inter-device synchronisation should be met with best-effort for audio and for video in all other situations. HBBTV,section 13.4.2: For multi-stream synchronization, inter-device synchronization, application to AV synchronization (see clause 13.11), and Targeted Advertising (see ETSI TS 103 736-1 [i.27]) the MediaSynchroniser object supports the use of the following types of timeline (defined in this clause and clause 5.3 of ETSI TS 103 286-2 [47]) for the types of broadcast or broadband content shown in Table 18. [row 2] ISOBMFF Composition Time (CT) supported for ISOBMFF streamed using HTTP via broadband (excluding MPEG DASH). TS-103-286-2,section 5.3.5: The unitsPerTick of the timeline shall be 1, and the unitsPerSecond shall be taken from the largest timescale value carried in either the timescale element of the movie header box (the box identified with the 4CC 'mvhd') or the timescale element of any track header box (the box identified with the 4CC 'tkhd'). | |||
| org.hbbtv_MDEVSYNC1784 | 1 | Master Terminal: Control Timestamp within minimum accuracy requirement 10ms in terms of a DASH Period Relative synchronisation timeline when master media is MPEG DASH | The application on the terminal has initialised a MediaSynchroniser object using the initMediaSynchroniser method, providing a media object presenting an MPEG DASH presentation as the master media. The application has enabled inter-device synchronisation, and a connection has been established to the CSS-TS endpoint of the master terminal with where the initial setup-data message sent to the master terminal requested a DASH Period Relative timeline and the master terminal has sent back a Control Timestamp indicating that the timeline is available. The timeline requested has a tick rate of 100 ticks per second or greater and includes the optional field 'period ID' in it. When the timing of presentation indicated by the value of the Control Timestamp is compared to the timing of presentation of the master media as observed by monitoring the light emitted then it is found to be accurate to within plus or minus the sum of 10ms and the current error bounds in estimating the Wall Clock of the master terminal (using the CSS-WC protocol) | 2024-1 2023-3 2020-2 2020-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.8.2.4: Control Timestamps sent by the MSAS function of the master terminal to slave terminals and CSAs shall, when the synchronisation timeline is available, represent the timing of presentation of the master media by the master terminal. [...] When a Control Timestamp is representing a timing of presentation with respect to the reference point for timestamping, it shall do so to within plus or minus the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.4: The minimum accuracy for 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 the Synchronisation timeline (see clause 13.4.3.2). [...] If a video component is being presented for the master media, then the minimum accuracy for inter-device synchronisation shall be met for that video component when it is output via an integrated display. If an audio component but not video component is being presented for the master media, then the minimum accuracy for inter-device synchronization shall be met for that audio component when it is output via integrated speakers or headphone output. Minimum accuracy for inter-device synchronisation should be met with best-effort for audio and for video in all other situations. HBBTV,section 13.4.2: For multi-stream synchronization, inter-device synchronization, application to AV synchronization (see clause 13.11), and Targeted Advertising (see ETSI TS 103 736-1 [i.27]) the MediaSynchroniser object supports the use of the following types of timeline (defined in this clause and clause 5.3 of ETSI TS 103 286-2 [47]) for the types of broadcast or broadband content shown in Table 18. [row 4] MPEG DASH Period Relative supported for MPEG DASH streamed via broadband. | ||
| org.hbbtv_MDEVSYNC1794 | 1 | Slave Terminal: Presentation timing within accuracy requirement of 10ms for an MPEG DASH stream with DASH Period Relative timeline as other media | The application on the terminal has initialised a MediaSynchroniser object using the initSlaveMediaSynchroniser method and has enabled inter-device sync. It has added a media object presenting an MPEG DASH presentation to the MediaSynchroniser with a tolerance specification of 0ms and specifying a DASH Period Relative timeline. The timeline requested has a tick rate of 100 ticks per second or greater. The timeline advertised to the slave terminal in the timelines property of the CII message sent to the slave when it connected to the CSS-CII endpoint had a tick rate of 100 ticks per second or greater. A Control Timestamp has been sent to the slave terminal to specify its presentation timing, via the connection it made using the CSS-TS protocol. When the timing of presentation indicated by the value of the Control Timestamp is compared to the timing of presentation of the media object at the slave terminal as observed by monitoring the light and sound emitted then it is found to be accurate to within plus or minus the sum of 10ms and the current value of the interDeviceSyncDispersion property of the MediaSynchroniser object at the time of the observation. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 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,section 13.8.3.5: For all Media Objects currently added to the slave terminal MediaSynchroniser, the SC function of the slave terminal shall adjust the presentation timing of the Media Object to match the timing expressed by the Control Timestamp to within plus or minus the greater of: the synchronisation tolerance (specified for that Media Object) and the minimum synchronisation accuracy specified in clause 9.7.4. The timing of presentation of the Media Object as observed at the reference point for timestamping shall differ from the timing of presentation expressed in the Control Timestamp by no more than plus or minus the sum of: * the value of the interDeviceSyncDispersion property of the MediaSynchroniser object (see clause 8.2.3.2.1) when it is next updated * and the greater of: the synchronisation tolerance and the minimum synchronisation accuracy. 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. HBBTV,section 13.4.2: For multi-stream and inter-device synchronisation, the terminal shall support the use of the following types of timeline (defined in this clause and clause 5.3 of ETSI TS 103 286-2 [47]) for the types of broadcast or broadband content shown in Table 18. [row 4] MPEG DASH Period Relative supported for MPEG DASH streamed via broadband. | +SYNC_SLAVE | ||
| org.hbbtv_MDEVSYNC180 | 1 | timelineSpeedMultiplier value when playback paused | A HbbTV application has initialised a MediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal. When the pause() function is called on the media element of the master content, the timelineSpeedMultiplier property of the following Control Timestamp sent out from the master terminal will have value 0 | 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 1.7.1 | HBBTV,section 13.8.2.4: The timelineSpeedMultiplier property in Control Timestamps shall represent the speed of presentation of the master media at the master terminal. The property shall have the value 1 under normal playback conditions. When presentation of the master content is paused (by the user or by the terminal when waiting for buffers to fill), the value shall be zero. | |||
| org.hbbtv_MDEVSYNC1800 | 1 | Effect of contentIdOverride property on CSS-CII when playing DASH | An HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser method, passing it a media object that is playing a DASH stream containing at least 2 Periods. The application has set the contentIdOverride property to a string that is different to the URL of the DASH MPD, after which the application then enabled inter-device synchronisation causing the terminal to become a master terminal. When a connection is made to the CSS-CII endpoint of the terminal and CII messages are received, the contentId property in all received messages matches the value of the contentIdOverride property of the MediaSynchroniser object; and the contentIdStatus property in all received messages has the value "final" during at least the first two Periods of the DASH presentation. | 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-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 13.6.2: When the contentIdOverride property of the MediaSynchroniser object is (or is set to) a non-null value then the contentId and contentIdStatus properties of the CII message shall be overridden as follows: * the value of the contentId property shall be the value of contentIdOverride, and * the contentIdStatus shall be “final”. HBBTV,section 8.2.3.2.1: String contentIdOverride : Description : This value overrides the content ID that would normally be reported to Companion Screen Applications and slave terminals during inter-device synchronisation. When the terminal is a master terminal and inter-device synchronisation functionality is enabled and the value of this property is a string then the content ID that the terminal uses for the CSS-CII service endpoint and the CSS-TS service endpoint is overridden and the value of this property is used instead. TS-103-286-2,section 5.7.5: A Control Timestamp consists of a Time Value in terms of the Synchronization Timeline (a content time), a Time Value in terms of the Wall Clock (a wall clock time) and a play speed. [...] If the Synchronization Timeline is currently unavailable then the contentTime and timeline speed multiplier shall both be unknown. [...] if the content time is unknown (because the timeline is unavailable) then contentTime shall be a null value [...] if the timeline speed multiplier is unknown (because the timeline is unavailable) then timelineSpeedMultiplier shall be a null value | |||
| org.hbbtv_MDEVSYNC1801 | 1 | Effect of contentIdOverride property on CSS-TS when playing DASH | An HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser method, passing it a media object that is playing a DASH stream. The application has set the contentIdOverride property to a string that is different to the URL of the DASH MPD, after which the application then enabled inter-device synchronisation causing the terminal to become a master terminal. When a connection is made to the CSS-TS endpoint of the terminal and a setup-data message is sent with a timeline selector for a DASH-PR timeline that is available for the DASH stream that is playing and with a contentIdStem string that matches the start of the contentIdOverride property string; the Control Timestamp messages received shall indicate that the timeline is available (by having non-null values for all properties in the message). When a connection is made to the CSS-TS endpoint of the terminal and a setup-data message is sent with a timeline selector for a DASH-PR timeline that is available for the DASH stream that is playing and with a contentIdStem string that does not match the start of the contentIdOverride property string but does match the start of the contentId that has been overridden; the Control Timestamp messages received shall indicate that the timeline is not available (by having null values for the 'contentTime' and 'timelineSpeedMultiplier' properties in the message). | 2024-1 2023-3 2023-2 2023-1 2022-3 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 13.8.2.2: When the contentIdOverride property of the MediaSynchroniser object is (or is set to) a non-null value the value of this property overrides the content ID of the master media and shall be used in its place when determining availability according to the process defined in clause 9.2 of ETSI TS 103 286-2. HBBTV,section 8.2.3.2.1: String contentIdOverride : Description : This value overrides the content ID that would normally be reported to Companion Screen Applications and slave terminals during inter-device synchronisation. When the terminal is a master terminal and inter-device synchronisation functionality is enabled and the value of this property is a string then the content ID that the terminal uses for the CSS-CII service endpoint and the CSS-TS service endpoint is overridden and the value of this property is used instead. TS-103-286-2,section 5.7.5: A Control Timestamp consists of a Time Value in terms of the Synchronization Timeline (a content time), a Time Value in terms of the Wall Clock (a wall clock time) and a play speed. [...] If the Synchronization Timeline is currently unavailable then the contentTime and timeline speed multiplier shall bothbe unknown. [...] if the content time is unknown (because the timeline is unavailable) then contentTime shall be a null value [...] if the timeline speed multiplier is unknown (because the timeline is unavailable) then timelineSpeedMultiplier shall be a null value | |||
| org.hbbtv_MEDIAPLAYER0010 | 1 | Seek while paused (not played previously) then call play | When an application creates an A/V control object, sets the source to some DASH content, goes straight from the stopped state to the paused state, seeks and then plays, the content is played from the point seeked to. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 A/V Control object [...] 7.14.1 [...] M HBBTV,section A.1: 5.7 addition to 5.7.1.f [...] B [...] M OIPF-DAE,section 7.14.1: If the player is in state 2 ('paused'), then the seek() method seeks to the new position, but the play state and the rendered image is not changed. OIPF-DAE,section 7.14.1: Boolean play(Number speed) [...] Plays the media referenced by data, starting at the current play position denoted by playPosition, at the supported speed closest to the value of attribute speed. OIPF-DAE,section B: If the player is in state 2 ('paused'), then the seek() method seeks to the new position, but the play state and the rendered image is not changed. OIPF-DAE,section B: Requirement 5.7.1.f bullet 11) ‘play’ SHALL be modified as follows; 1) Boolean play(Number speed) - plays the media referenced by data, starting at the current play position denoted by playPosition, at the supported speed closest to the value of attribute speed. | |||
| org.hbbtv_MEDIAPLAYER0020 | 1 | Seek while paused (played previously) then call play | When an application creates an A/V control object, sets the source to some DASH content, plays from the start for some time, pauses, seeks and then plays, the content is played from the point seeked to. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 A/V Control object [...] 7.14.1 [...] M HBBTV,section A.1: 5.7 addition to 5.7.1.f [...] B [...] M OIPF-DAE,section 7.14.1: If the player is in state 2 ('paused'), then the seek() method seeks to the new position, but the play state and the rendered image is not changed. OIPF-DAE,section 7.14.1: Boolean play(Number speed) [...] Plays the media referenced by data, starting at the current play position denoted by playPosition, at the supported speed closest to the value of attribute speed. OIPF-DAE,section B: If the player is in state 2 ('paused'), then the seek() method seeks to the new position, but the play state and the rendered image is not changed. OIPF-DAE,section B: Requirement 5.7.1.f bullet 11) ‘play’ SHALL be modified as follows; 1) Boolean play(Number speed) - plays the media referenced by data, starting at the current play position denoted by playPosition, at the supported speed closest to the value of attribute speed. | |||
| org.hbbtv_MEDIAPLAYER0030 | 1 | Seek while stopped - not played previously | When an application creates an A/V control object, sets the source to some DASH content, seeks to a point in the content and then plays, the content is played from the point seeked to. | 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-3 2019-2 2019-1 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 A/V Control object [...] 7.14.1 [...] M HBBTV,section A.1: 5.7 addition to 5.7.1.f [...] B [...] M HBBTV,section A.1: Using an A/V contol object to play streaming content [...] 7.14.1.2 [...] M OIPF-DAE,section 7.14.1: If the player is in states 0 ("stopped"), 5 ("finished") or 6 ("error"), then the new play position SHALL be retained and SHALL be used (if possible) as the starting position for playing back the content item indicated by the data property when the play() method is called. OIPF-DAE,section B: If the player is in states 0 ("stopped"), 5 ("finished") or 6 ("error"), then the new play position SHALL be retained and SHALL be used (if possible) as the starting position for playing back the content item indicated by the data property when the play() method is called. OIPF-DAE,section 7.14.1.2: If an A/V control object is used to play streamed content using either RTSP or HTTP the OITF then the following holds:- If play(0) is called in state 0 ('stopped'), the A/V object SHALL automatically go to play state 2 ('paused'). The necessary resources are secured and no external signalling is performed. OIPF-DAE,section 7.14.1.2: If play(0) is called in state 0 ('stopped'), the A/V object SHALL automatically go to play state 2 ('paused'). The necessary resources are secured and no external signalling is performed. OIPF-DAE,section 7.14.1.2: If play(0) is called in state 0 ('stopped'), the A/V Control object SHALL automatically go to play state 2 ('paused'). The necessary resources are secured and no external signalling is performed. | |||
| org.hbbtv_MEDIAPLAYER0040 | 1 | Seek while stopped -played previously | When an application creates an A/V control object, sets the source to some DASH content, plays the content, stops, seeks to a point in the content and then plays again, the content is played from the point seeked to. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-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 A/V Control object [...] 7.14.1 [...] M HBBTV,section A.1: 5.7 addition to 5.7.1.f [...] B [...] M HBBTV,section A.1: Using an A/V contol object to play streaming content [...] 7.14.1.2 [...] M OIPF-DAE,section 7.14.1: If the player is in states 0 ("stopped"), 5 ("finished") or 6 ("error"), then the new play position SHALL be retained and SHALL be used (if possible) as the starting position for playing back the content item indicated by the data property when the play() method is called. OIPF-DAE,section B: If the player is in states 0 ("stopped"), 5 ("finished") or 6 ("error"), then the new play position SHALL be retained and SHALL be used (if possible) as the starting position for playing back the content item indicated by the data property when the play() method is called. OIPF-DAE,section 7.14.1.2: If an A/V control object is used to play streamed content using either RTSP or HTTP the OITF then the following holds:- If play(0) is called in state 0 ('stopped'), the A/V object SHALL automatically go to play state 2 ('paused'). The necessary resources are secured and no external signalling is performed. OIPF-DAE,section 7.14.1.2: If play(0) is called in state 0 ('stopped'), the A/V object SHALL automatically go to play state 2 ('paused'). The necessary resources are secured and no external signalling is performed. OIPF-DAE,section 7.14.1.2: If play(0) is called in state 0 ('stopped'), the A/V Control object SHALL automatically go to play state 2 ('paused'). The necessary resources are secured and no external signalling is performed. | |||
| org.hbbtv_MEDIAPLAYER0050 | 1 | Video decoder transfer, MPEG-2 TS to ISOBMFF - different A/V control object | When an application creates an A/V control object, plays an MPEG-2 transport stream, stops it, creates a second A/V control object and plays an ISOBMFF file using the second A/V control object, the ISOBMFF file plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. | |||
| org.hbbtv_MEDIAPLAYER0060 | 1 | Video decoder transfer, MPEG-2 TS to DASH - different A/V control object | When an application creates an A/V control object, plays an MPEG-2 transport stream, stops it, creates a second A/V control object and plays MPEG DASH using the second A/V control object, the MPEG DASH plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. | |||
| org.hbbtv_MEDIAPLAYER0070 | 1 | Video decoder transfer, ISOBMFF to MPEG-2 TS - different A/V control object | When an application creates an A/V control object, plays an ISO BMFF file, stops it, creates a second A/V control object and plays an MPEG-2 transport stream using the second A/V control object, the MPEG-2 transport stream plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. | |||
| org.hbbtv_MEDIAPLAYER0080 | 1 | Video decoder transfer, ISOBMFF to MPEG-DASH - different A/V control object | When an application creates an A/V control object, plays an ISO BMFF file, stops it, creates a second A/V control object and plays some MPEG DASH using the second A/V control object, the MPEG DASH plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. | |||
| org.hbbtv_MEDIAPLAYER0090 | 1 | Video decoder transfer, MPEG-DASH to MPEG-2 TS - different A/V control object | When an application creates an A/V control object, plays some MPEG DASH, stops it, creates a second A/V control object and plays an MPEG-2 transport stream using the second A/V control object, the MPEG-2 transport stream plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. | |||
| org.hbbtv_MEDIAPLAYER0100 | 1 | Video decoder transfer, MPEG-DASH to ISOBMFF- different A/V control object | When an application creates an A/V control object, plays some MPEG DASH, stops it, creates a second A/V control object and plays an ISOBMFF file using the second A/V control object, the ISO BMFF file plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. | |||
| org.hbbtv_MEDIAPLAYER0110 | 1 | Video decoder transfer, MPEG-2 TS to ISOBMFF - same A/V control object | When an application creates an A/V control object, plays an MPEG-2 transport stream, stops it, changes the MIME type to "video/mp4", sets the source to an ISO BMFF file and calls play, the ISOBMFF file plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an A/V Control embedded object from video/mpeg to video/mp4 but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an AV Control embedded object from <video/mpeg> to <video/mp4> but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" | |||
| org.hbbtv_MEDIAPLAYER0120 | 1 | Video decoder transfer, MPEG-2 TS to DASH - same A/V control object | When an application creates an A/V control object, plays an MPEG-2 transport stream, stops it, sets the source to an MPEG DASH MPD, changes the MIME type to "application/dash+xml" and calls play, the MPEG DASH content plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an A/V Control embedded object from video/mpeg to video/mp4 but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an AV Control embedded object from <video/mpeg> to <video/mp4> but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" | |||
| org.hbbtv_MEDIAPLAYER0130 | 1 | Video decoder transfer, ISOBMFF to MPEG-2 TS - same A/V control object | When an application creates an A/V control object, plays an ISO BMFF file, stops it, sets the source to an MPEG-2 transport stream, changes the MIME type to "video/mpeg" and calls play, the MPEG-2 transport stream plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an A/V Control embedded object from video/mpeg to video/mp4 but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an AV Control embedded object from <video/mpeg> to <video/mp4> but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" | |||
| org.hbbtv_MEDIAPLAYER0140 | 1 | Video decoder transfer, ISOBMFF to MPEG-DASH - same A/V control object | When an application creates an A/V control object, plays an ISO BMFF file, stops it, sets the source to an MPEG DASH MPD, changes the MIME type to "application/dash+xml" and calls play, the MPEG DASH plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an A/V Control embedded object from video/mpeg to video/mp4 but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an AV Control embedded object from <video/mpeg> to <video/mp4> but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" | |||
| org.hbbtv_MEDIAPLAYER0150 | 1 | Video decoder transfer, MPEG-DASH to MPEG-2 TS - same A/V control object | When an application creates an A/V control object, plays some MPEG DASH, stops it, sets the source to an MPEG-2 transport stream, changes the MIME type to "video/mpeg" and calls play, the MPEG-2 transport stream plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an A/V Control embedded object from video/mpeg to video/mp4 but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an AV Control embedded object from <video/mpeg> to <video/mp4> but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" | |||
| org.hbbtv_MEDIAPLAYER0160 | 1 | Video decoder transfer, MPEG-DASH to ISOBMFF- same A/V control object | When an application creates an A/V control object, plays some MPEG DASH, stops it, sets the source to an ISOBMFF file, changes the MIME type to "video/mp4" and calls play, the ISO BMFF file plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 [..] M(*) HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M HBBTV,section A.1: State diagram for A/V control objects [...] 7.14.1.1 [...] M HBBTV,section A.1: Instantiating embedded object and claiming scarce system resources [...] 4.4.4 [..] M OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused') [..] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object, such as the MPEG decoder, are claimed during state 3 ('connecting'), state 4 ('buffering') or during state transitions from state 3 ('connecting') to state 4 ('buffering'), from state 4 ('buffering') to state 1 ('playing') or from state 0 ('stopped') or from state 3 ('connecting') to state 2 ('paused'). [...] Scarce resources for playback using the A/V Control object SHALL be released when state 6 ('error') or 0 ('stopped') or 5 ('finished') are reached. In addition, if the A/V object gets destroyed, e.g. because another URL is loaded into the containing window, scarce resources claimed for playback using the A/V object SHALL be released, except in cases described for the optional 'persist' property of A/V objects. OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an A/V Control embedded object from video/mpeg to video/mp4 but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" OIPF-DAE,section 4.4.4: Once an OIPF embedded object has been instantiated, dynamic change of its MIME type which could cause the properties and methods associated with the object to change SHALL be ignored.For instance, it is possible to change the MIME type of an AV Control embedded object from <video/mpeg> to <video/mp4> but it is not possible to change the MIME type of an OIPF embedded object from "application/oipfApplicationManager" to "application/oipfConfiguration" | |||
| org.hbbtv_MEDIAPLAYER0170 | 1 | No video presented when a newly created A/V control object goes straight to paused - DASH | When an application creates an A/V control object, sets the source to some DASH content, calls play(0), waits some time and then calls play(1), no video is displayed in response to the call to play(0) but only after the call to play(1) has been made. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: Using an A/V Control object to play streaming content [..] 7.14.1.2 [..] M HBBTV,section A.1: Using an A/V Control object to play streaming content [..] 7.14.1.2 [..] M OIPF-DAE,section 7.14.1.2: If play(0) is called in state 0 (‘stopped’), the A/V Control object SHALL automatically go to play state 2 (‘paused’). The necessary resources are secured and no external signalling is performed. OIPF-DAE,section 7.14.1.2: If play(0) is called in state 0 (‘stopped’), the A/V object SHALL automatically go to play state 2 ('paused'). The necessary resources are secured and no external signalling is performed. | |||
| org.hbbtv_MEDIAPLAYER0180 | 1 | No video presented when a newly created A/V control object goes straight to paused - non-adaptive HTTP streaming - ISOBMFF | When an application creates an A/V control object, sets the source to an HTTP URL of an ISOBMFF file suitable for non-adaptive HTTP streaming, calls play(0), waits some time and then calls play(1), no video is displayed in response to the call to play(0) but only after the call to play(1) has been made. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: Using an A/V Control object to play streaming content [..] 7.14.1.2 [..] M HBBTV,section A.1: Using an A/V Control object to play streaming content [..] 7.14.1.2 [..] M OIPF-DAE,section 7.14.1.2: If play(0) is called in state 0 (‘stopped’), the A/V Control object SHALL automatically go to play state 2 (‘paused’). The necessary resources are secured and no external signalling is performed. OIPF-DAE,section 7.14.1.2: If play(0) is called in state 0 (‘stopped’), the A/V object SHALL automatically go to play state 2 ('paused'). The necessary resources are secured and no external signalling is performed. | |||
| org.hbbtv_MEDIAPLAYER0190 | 1 | No video presented when a newly created A/V control object goes straight to paused - non-adaptive HTTP streaming - MPEG-2 transport stream | When an application creates an A/V control object, sets the source to an HTTP URL of an MPEG-2 transport stream file suitable for non-adaptive HTTP streaming, calls play(0), waits some time and then calls play(1), no video is displayed in response to the call to play(0) but only after the call to play(1) has been made. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: Using an A/V Control object to play streaming content [..] 7.14.1.2 [..] M HBBTV,section A.1: Using an A/V Control object to play streaming content [..] 7.14.1.2 [..] M OIPF-DAE,section 7.14.1.2: If play(0) is called in state 0 (‘stopped’), the A/V Control object SHALL automatically go to play state 2 (‘paused’). The necessary resources are secured and no external signalling is performed. OIPF-DAE,section 7.14.1.2: If play(0) is called in state 0 (‘stopped’), the A/V object SHALL automatically go to play state 2 ('paused'). The necessary resources are secured and no external signalling is performed. | |||
| org.hbbtv_MPEGH-ADAPTATION0010 | 4 | HbbTV ISOBMFF Live profile, MPEG-H Stereo MultiRate, Low to High | During HTMLVideoElement playout of a stream defined in a static MPD consisting of a single AdaptationSet in which each Representation has a unique MHASPacketLabel, in response to increased bandwidth availability the terminal shall transition seamlessly from an audio representation with a bitrate of 64kbps to an audio representation with a bitrate of 192kbps, both representations being encoded using MPEG-H. | 2024-1 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH 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 6.8.2: The elementary stream requirements are defined in Clause 6.8.2 of TS 101 154 [3] TS-103-285,section 6.8.3.2.5: The configuration change constraints are defined in Clause 6.8.5 of TS 101 154 [3]. [...] NOTE: Representations that belong to one Audio Programme use different configurations and a switch between two ISOBMFF segments also represents a configuration change. Thus, the MHASPacketLabel needs to have different values for all Representations that belong to one Audio Programme. Also, after a configuration change, the MHASPacketLabel needs to have different values for all Representations comprising an Audio Programme. TS-103-285,section 6.8.3.2.6: The MPEG-H Audio multi-stream constraints are defined in Clause 6.8.7 of TS 101 154 [3]. [...] NOTE: Representations that belong to one Adaptation Set need to use different MHASPacketLabel values within the same range of values associated to one stream, as specified in ISO/IEC 23008-3, Clause 14.6 [35]. For example, all ISOBMFF segments in the Adaptation Set for the main stream use different values between 1 and 16, all ISOBMFF segments in the Adaptation Set for the first auxiliary stream use values between 17 and 32, and so on. TS-101-154,section 6.8.3: Encoding: The MPEG-H Audio elementary streams shall be encapsulated in the MPEG-H Audio Stream Format (MHAS) according to ISO/IEC 23008-3 [47], clause 14, with further specification in ISO/IEC 13818-1 [1], clause 2.19.2. ISO/IEC-23008-3,section 20.6.1: Especially in streaming or broadcast environments based on, e.g. MPEG-DASH or MPEG-H MMT, the MPEG-H 3D Audio configuration may change at arbitrary positions of the stream and not necessarily only on fragment boundaries. To enable this use-case the ‘mhm1’ and ‘mhm2’ MHASampleEntry provides an in-band configuration mechanism for MPEG-H 3D Audio files. | +MPEG_H | ||
| org.hbbtv_MPEGH-ADAPTATION0020 | 4 | HbbTV ISOBMFF Live profile, MPEG-H Stereo MultiRate, High to Low | During HTMLVideoElement playout of a stream defined in a static MPD consisting of a single AdaptationSet in which each Representation has a unique MHASPacketLabel, in response to decreased bandwidth availability the terminal shall transition seamlessly from an audio representation with a bitrate of 192kbps to an audio representation with a bitrate of 64kbps, both representations being encoded using MPEG-H. | 2024-1 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH 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 6.8.2: The elementary stream requirements are defined in Clause 6.8.2 of TS 101 154 [3] TS-103-285,section 6.8.3.2.5: The configuration change constraints are defined in Clause 6.8.5 of TS 101 154 [3]. [...] NOTE: Representations that belong to one Audio Programme use different configurations and a switch between two ISOBMFF segments also represents a configuration change. Thus, the MHASPacketLabel needs to have different values for all Representations that belong to one Audio Programme. Also, after a configuration change, the MHASPacketLabel needs to have different values for all Representations comprising an Audio Programme. TS-103-285,section 6.8.3.2.6: The MPEG-H Audio multi-stream constraints are defined in Clause 6.8.7 of TS 101 154 [3]. [...] NOTE: Representations that belong to one Adaptation Set need to use different MHASPacketLabel values within the same range of values associated to one stream, as specified in ISO/IEC 23008-3, Clause 14.6 [35]. For example, all ISOBMFF segments in the Adaptation Set for the main stream use different values between 1 and 16, all ISOBMFF segments in the Adaptation Set for the first auxiliary stream use values between 17 and 32, and so on. TS-101-154,section 6.8.3: Encoding: The MPEG-H Audio elementary streams shall be encapsulated in the MPEG-H Audio Stream Format (MHAS) according to ISO/IEC 23008-3 [47], clause 14, with further specification in ISO/IEC 13818-1 [1], clause 2.19.2. ISO/IEC-23008-3,section 20.6.1: Especially in streaming or broadcast environments based on, e.g. MPEG-DASH or MPEG-H MMT, the MPEG-H 3D Audio configuration may change at arbitrary positions of the stream and not necessarily only on fragment boundaries. To enable this use-case the ‘mhm1’ and ‘mhm2’ MHASampleEntry provides an in-band configuration mechanism for MPEG-H 3D Audio files. | +MPEG_H | ||
| org.hbbtv_MPEGH-ADINS001 | 1 | HTML5 mid-roll advert insertion, DASH MPEG-H/HEVC and HEAAC/HEVC | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with MPEG-H/HEVC is paused, and preloaded DASH with HE-AAC/HEVC media is played in its entirety, and then the playing of the original DASH media is resumed. | 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 | 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 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 [...] 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. | +HEVC_HD_8 +MPEG_H | ||
| org.hbbtv_MPEGH-ADINS002 | 1 | HTML5 mid-roll advert insertion, DASH MPEG-H/HEVC and MP4 HEAAC/HEVC | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with MPEG-H/HEVC is paused, and preloaded MP4 with HE-AAC/HEVC media is played in its entirety, and then the playing of the DASH media is resumed. | 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 | 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 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: 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 [...] 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. | +HEVC_HD_8 +MPEG_H | ||
| org.hbbtv_MPEGH-ADINS003 | 1 | HTML5 mid-roll advert insertion, DASH MPEG-H/HEVC and HEAAC/AVC_SD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with MPEG-H/HEVC is paused, and preloaded DASH with HE-AAC/AVC_SD_25 media is played in its entirety, and then the playing of the original DASH media is resumed. | 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 | 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 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: 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 [...] 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. | +HEVC_HD_8 +MPEG_H | ||
| org.hbbtv_MPEGH-ADINS004 | 1 | HTML5 mid-roll advert insertion, DASH MPEG-H/HEVC and MP4 HEAAC/AVC_SD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH with MPEG-H/HEVC is paused, and preloaded MP4 with HE-AAC/AVC_SD_25 media is played in its entirety, and then the playing of the original DASH media is resumed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 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 [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.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: 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 [...] 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. | +HEVC_HD_8 +MPEG_H | ||
| org.hbbtv_MPEGH-ADINS005 | 1 | HTML5 mid-roll advert insertion, DASH MPEG-H audio only and HE-AAC audio only | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH MPEG-H audio only is paused, and preloaded DASH with HE-AAC audio only media is played in its entirety, and then the playing of the original DASH media is resumed. | 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 | 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 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: 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 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. | +MPEG_H | ||
| org.hbbtv_MPEGH-BROADBAND0010 | 1 | MP4_HEVC_HD_25_10_MPEGH_EBUTTD broadband capability reported correctly and is presented | When an HbbTV application queries the xmlCapabilities a <video_profile name="MP4_HEVC_HD_25_10_MPEGH_EBUTTD" type="video/mp4" transport="dash" sync_tl="dash_pr"/> element is present in the document returned. When play() is called on an HTMLVideoElement referencing an MPD containing HEVC_HD_25_10 video and MPEG-H audio, the video and audio are presented without glitches or decoding artefacts. | 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.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. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD requirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities MPEG-H Audio as defined in clause 6.8 | MPEG-H Audio as defined in clause 6.8 of TS 103 285 [45] | MPEGH HBBTV,section 10.2.4: Terminals that support NGA according to clause 6.7 of TS 103 285 [45] and either or both of clauses 6.3.2 or 6.8 of TS 103 285 [45] 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 table 10 of the present document. [...] | +HEVC_HD_10 +MPEG_H | ||
| org.hbbtv_MPEGH-BROADBAND0020 | 1 | Lack of MPEGH broadband capability reported correctly | When an HbbTV application queries the xmlCapabilities, no <video_profile> element with @name attribute containing the sub-string “MPEGH” is present in the document returned. | 2024-1 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 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. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD requirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities MPEG-H Audio as defined in clause 6.8 | MPEG-H Audio as defined in clause 6.8 of TS 103 285 [45] | MPEGH HBBTV,section 10.2.4: Terminals that support NGA according to clause 6.7 of TS 103 285 [45] and either or both of clauses 6.3.2 or 6.8 of TS 103 285 [45] 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 table 10 of the present document. [...] | -MPEG_H | ||
| org.hbbtv_MPEGH-BROADCAST0010 | 1 | MPEG-H broadcast capability reported correctly and A/V is presented | When an HbbTV application queries the xmlCapabilities object, a <broadcast>urn:dvb:broadcast:ird:audio:MPEG-H</broadcast> element is present in the document returned. When an MPEG-2 TS containing HEVC_HD_25_10 video and MPEG-H audio is signalled to the terminal, audio and video from that stream are presented without glitches or decoding artefacts. | 2024-1 2023-3 2021-3 2021-2 2021-1 2020-3 2020-2 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. [...] Table 10: Mapping from broadcast requirements to DASH requirements [...] Broadcast IRD reqirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities MPEG-H Audio as defined in clause 6.8 | MPEG-H Audio as defined in clause 6.8 of TS 103 285 [45] | MPEGH HBBTV,section 10.2.4: Terminals shall list the video and audio technologies that they support for the broadcast as a list of <broadcast> elements, one element per supported technology. The list shall be the same for both broadcast-related and broadcast-independent applications. HBBTV,section A.2.15: The value of the <broadcast> element shall be a URN that indicates a technology supported in the broadcast channel. For each broadcast video and audio technology listed in TS 101 154 [], the URN shall be the name of the corresponding term in the urn:dvb:metadata:cs:VideoConformancePointsCS:2017 and urn:dvb:metadata:cs:AudioConformancePointsCS:2017 classification scheme as defined in DVB Metadata []. | +HEVC_HD_10 +MPEG_H | |
| org.hbbtv_MPEGH-BROADCAST0020 | 1 | MPEG-H broadcast capability reported correctly | When an HbbTV application queries the xmlCapabilities object, a <broadcast>urn:dvb:broadcast:ird:audio:MPEG-H</broadcast> element is not present in the document returned. | 2024-1 2023-3 2023-2 2023-1 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 [45] and TS 101 154 [14]. 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 requirement from TS 101 154 | Related DASH Requirement | Labels in XML capabilities MPEG-H Audio as defined in clause 6.8 | MPEG-H Audio as defined in clause 6.8 of TS 103 285 [45] | MPEGH HBBTV,section 10.2.4: Terminals shall list the video and audio technologies that they support for the broadcast as a list of <broadcast> elements, one element per supported technology. The list shall be the same for both broadcast-related and broadcast-independent applications. HBBTV,section A.2.15: The value of the <broadcast> element shall be a URN that indicates a technology supported in the broadcast channel. For each broadcast video and audio technology listed in TS 101 154 [], the URN shall be the name of the corresponding term in the urn:dvb:metadata:cs:VideoConformancePointsCS:2017 and urn:dvb:metadata:cs:AudioConformancePointsCS:2017 classification scheme as defined in DVB Metadata []. | -MPEG_H | ||
| org.hbbtv_MPEGH-COMBINATION0010 | 1 | MPEG-H Playback Combinations: DASH / AVC_HD_25 | When play() is called on an HTMLVideoElement with its 'src' set to the absolute URL of an MPD referencing AVC_HD_25 video and MPEG-H audio, the audio and video are presented without decoding artefacts or glitches. | 2024-1 2023-3 2023-2 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 4. [...] For MPEG DASH, the following shall apply; [...] * For each of the technologies listed in table 4, 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 [...] | +MPEG_H | ||
| org.hbbtv_MPEGH-COMBINATION0020 | 1 | MPEG-H Playback Combinations: DASH / HEVC_HD_25_8 | When play() is called on an HTMLVideoElement with its 'src' set to the absolute URL of an MPD referencing HEVC_HD_25_8 video and MPEG-H audio, the audio and video are presented without decoding artefacts or glitches. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 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 [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.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_HD_8 +MPEG_H | ||
| org.hbbtv_MPEGH-COMBINATION0030 | 1 | MPEG-H Playback Combinations: DASH / HEVC_UHD_25 / PQ10 | When play() is called on an HTMLVideoElement with its 'src' set to the absolute URL of an MPD referencing HEVC_UHD_25 / PQ10 video and MPEG-H audio, the audio and video are presented without decoding artefacts or glitches. | 2024-1 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 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.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 +MPEG_H +PQ10 | ||
| org.hbbtv_MPEGH-COMBINATION0040 | 1 | MPEG-H Playback Combinations: DASH / HEVC_UHD_25 / HLG 10 | When play() is called on an HTMLVideoElement with its 'src' set to the absolute URL of an MPD referencing HEVC_UHD_25 / HLG10 video and MPEG-H audio, the audio and video are presented without decoding artefacts or glitches. | 2024-1 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 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.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 +MPEG_H | ||
| org.hbbtv_MPEGH-COMBINATION0050 | 1 | HTML5 static video element displaying DASH HEVC PQ10 with Temporal Layers with a higher frame rate (HFR) 100fps at Main 10, Level 5.1 and MPEG_H audio content | When the terminal loads an HbbTV Application including an HTML5 media object which references a static MPD defining a stream containing MPEG-H audio and DASH HEVC PQ10 with Temporal Layers with a higher frame rate (HFR) 100fps 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-1 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 5.2.8: [...] Where HEVC video has been encoded using temporal layers, every Representation shall include a SupplementalProperty Descriptor indicating the HighestTid (Highest Temporal ID) present in the Representation, either by explicit signalling on the Representation or inheritance from the containing Adaptation Set. DVB DASH defines the following scheme to signal the HighestTid and this scheme shall be used: @schemeIDUri: “urn:dvb:dash:highest_temporal_id:2017” @value: decimal representation of the Highest Temporal ID [...] HBBTV,section 7.3.1.1: Additional video 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. [...] 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.6.1: The media elements from HTML5 [...] Terminals shall support presenting content using media elements as follows: * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +DASH_HFR +HEVC_UHD +MPEG_H +PQ10 | ||
| org.hbbtv_MPEGH-COMPONENTS0010 | 1 | MPEG-H 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 MPEG-H audio AdaptationSet with its @lang attribute set to 'en', and one MPEG-H 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-1 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 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.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. | +HEVC_HD_10 +MPEG_H | ||
| org.hbbtv_MPEGH-COMPONENTS0020 | 1 | MPEG-H Role-based audio component selection | When the terminal has enabled Audio Description and an HTMLVideoElement plays an MPD referencing one MP4_HEVC_HD_25_10 video AdaptationSet, one MPEG-H audio AdaptationSet containing a Role element with its @schemeIdUri set to "urn:mpeg:dash:role:2011" and its @value set to "main", and one MPEG-H 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-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 | 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 Related 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 [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.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. | +HEVC_HD_10 +MPEG_H | ||
| org.hbbtv_MPEGH-DASH-PRESELECTION0010 | 1 | Expose MPEG-H DASH preselection to HTML5 AudioTrack in AudioTrackList | A DASH MPD contains multiple MPEG-H Preselection elements, where each MPEG-H Preselection references one individual Adaptation Set contained in the same Period. Additionally, the same Period contains one Adaptation Set that is not referenced by any of the MPEG-H Preselections. The AudioTrackList shall contain one HTML5 AudioTrack for each MPEG-H Preselection and one for the Adaptation Set that is not referenced by any of the MPEG-H Preselections. The order of AudioTracks in the AudioTrackList shall be the same as the order of the corresponding elements in the MPD. | 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 | HBBTV,section A.2.12.1: An AudioTrack object shall be created for each Preselection element in the MPD for which @profiles includes or is inferred to include a profile supported by the terminal. An AudioTrack object shall be created for each audio Adaptation Set in the MPD for which @profiles includes or is inferred to include a profile supported by the terminal and 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. | +MPEG_H | ||
| org.hbbtv_MPEGH-EME0010 | 1 | Clear Key: HTML5 transition from encrypted DASH MPEG-H/HEVC_HD_25_8 to preloaded unencrypted DASH MPEG-H/HEVC_HD_25_8 media in less than 250ms | When a currently playing HTMLMediaElement referencing DASH content with MPEG-H/HEVC_HD_25_8 media encrypted with Clear Key is paused and play is called on a preloaded HTMLMediaElement referencing DASH content with unencrypted MPEG-H/HEVC_HD_25_8 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-1 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: 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. [...] 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.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: 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 A.3.11: The W3C encrypted media extensions API [66] shall be supported for encrypted content delivered via broadband as defined in clause B.3 of the present document. Use of this API with a DRM system is outside the scope of the present document. HBBTV,section B.3: The “Clear Key” key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). HBBTV,section J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML5 media elements [...] EME,section 9: 9. Common Key Systems All user agents MUST support the common key systems described in this section. ... 9.1 Clear Key The "org.w3.clearkey" Key System uses plain-text clear (unencrypted) key(s) to decrypt the source. No additional client-side content protection is required. This Key System is described below. | +HEVC_HD_8 +MPEG_H | |
| org.hbbtv_MPEGH-HTML5-ACTIONS-0010 | 2 | Pause MPEG-H audio HTML5 media element | Pausing the playback of a HTML5 media element referencing MPEG_H that is currently playing, shall cause the video to freeze and the audio to suspend. | 2024-1 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 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. 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. | +MPEG_H | ||
| org.hbbtv_MPEGH-HTML5-ACTIONS-0020 | 2 | Playback of paused MPEG_H audio HTML5 media element from next Random Access Point | When resuming the playback of a HTML5 media element referencing MPEG-H that has previously been paused, the terminal shall start audio playback at or before the MPEG-H Random Access Point following the pause position. | 2024-1 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 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. HBBTV,section 9.6.3: When resuming the playback of an HTML5 media element that has previously been paused, [...] the terminal should start playback as close as possible to the pause position, preferably from the next frame following the pause position. | +MPEG_H | ||
| org.hbbtv_MPEGH-IMMERSIVE0010 | 1 | Playback of immersive (7.1+4H) MPEG-H channel-based, object-based and scene-based audio | An HTMLVideoElement is played, referencing a static MPD. The MPD comprises four Periods, each with a duration of 20 seconds and each Period contains an audio AdaptationSet referencing the same MPEH-H audio stream which contains channel-based content, object-based content and scene-based content which uses Higher Order Ambisonics. The AdaptationSet contains a SupplementalProperty element with @schemeIdUri set to "urn:mpeg:dash:preselection:2016"". All Preselection elements within the MPD have @preselectionComponents set to the value of the @id of the AdaptationSet. All AudioChannelConfiguration elements in the MPD have @schemeIdUri set to "urn:mpeg:mpegB:cicp:ChannelConfiguration" and @value set to "19" (7.1 + 4 Height channels). All Role elements have @schemeIdUri set to "urn:mpeg:dash:role:2011". Each period contains a single preselection element with the role "main". The preselection elements each have a different "tag" value indicating that the device should play back different content in each period. During the first period, only the channel-based content shall be played. The second period shall play both the channel-based content and the object-based content. The third period shall play back only the object-based content. The final period shall play back the scene-based content and the object-based content. During each Period, the tester confirms that the correct audio is presented without artefacts or glitches. | 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 | 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 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 6.7.3: DASH clients supporting SRMP or MRMP audio shall support the signaling of Preselections by means of Preselection elements. [...] The following rules apply to Adaptation Sets which are referenced by Preselection elements: * All Adaptation Sets that refer to Auxiliary Audio streams from an audio bundle shall include an EssentialProperty Preselection descriptor. 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. TS-103-285,section 6.8.2: The elementary stream requirements are defined in Clause 6.8.2 of TS 101 154 [3] TS-103-285,section 6.8.3.2.2: The sample entry "mhm1" shall be used in cases of SRSP and SRMP for encapsulation of MHAS packets into ISOBMFF segments, according to ISO/IEC 23008-3, Clause 20.6 [35]. TS-103-285,section 6.8.3.2.5: The configuration change constraints are defined in Clause 6.8.5 of TS 101 154 [3]. The following additional constraints apply: * A configuration change may happen at the beginning of a new ISOBMFF segment or at any position within the segment. In the latter case, the File Format sample that contains a configuration change shall be encoded as a sync sample (RAP) as defined above. * A sync sample that contains a configuration change and the last sample before such a sync sample may contain a truncation message (i.e., a PACTYP_AUDIOTRUNCATION packet in the MHAS stream) as defined in ISO/IEC 23008-3, Clause 14.4 [35]. NOTE: Representations that belong to one Audio Programme use different configurations and a switch between two ISOBMFF segments also represents a configuration change. Thus, the MHASPacketLabel needs to have different values for all Representations that belong to one Audio Programme. Also, after a configuration change, the MHASPacketLabel needs to have different values for all Representations comprising an Audio Programme. TS-103-285,section 6.8.4: The attributes and elements listed in table 16 below can be used on AdaptationSets as well as on Preselection element unless explicitly indicated. [...] AudioChannelConfiguration | For MPEG-H Audio, the Audio Channel Configuration descriptor shall use the "urn:mpeg:mpegB:cicp:ChannelConfiguration" scheme URI. The value shall be taken from the ChannelConfiguration table as defined in ISO/IEC 23001-8 [37]. Valid numbers for value are 1-7,9-12, 14-17 or 19 TS-103-285,section 10.18: Players shall support SRSP and SRMP use cases. [...] Players shall support the signaling of Preselections by means of Preselection elements and Preselection descriptors. [...] For Adaptation Sets that have an EssentialProperty or SupplementalProperty Preselection descriptor, players shall not evaluate elements and attributes from those Adaptation Sets but use only the Preselection parameters for selection of an AdaptationSet. TS-101-154,section 6.8.1: MPEG-H Audio offers methods for coding of channel-based content, coding of object-based content, and coding of scene-based content (using Higher Order Ambisonics [HOA] as a sound-field representation). TS-101-154,section 6.8.5: A configuration change takes place in an audio stream when the content setup or the Audio Scene Information changes (e.g. when changes occur in the channel layout, the number of objects, etc.) and, therefore, a new MHAS PACTYP_MPEGH3DACFG packet is required. Additionally, if the Audio Scene Information is present, a new MHAS PACTYP_AUDIOSCENEINFO packet is also required. Even though configuration changes usually happen at program boundaries, they are not restricted to that case and they may occur at any time within a program. [...] At each configuration change, the MHASPacketLabel shall be changed to a different value from the MHASPacketLabel in use before the configuration change occurred. [...] The configuration change can, for instance, be detected through the change of the MHASPacketLabel of the packet PACTYP_MPEGH3DACFG compared to the value of the MHASPacketLabel of previous MHAS packets. | +MPEG_H | ||
| org.hbbtv_MPEGH-MULTISTREAM0010 | 1 | MPEG-H Multiple Representations, Multiple Preselection | An HTMLVideoElement referencing a static MPD is played. The MPD comprises three AdaptationSets referencing MPEG-H with @id values of "1", "2" and "3" respectively, one AdaptationSet referencing HEVC_HD_10, and three Preselection elements. The 'main' audio AdaptationSet contains a SupplementalProperty element with @schemeIdUri set to "urn:mpeg:dash:preselection:2016". The other two AdaptationSets have an EssentialProperty element with @schemaIdUri set to "urn:mpeg:dash:preselection:2016". The first Preselection element has @preselectionComponents set to "1", @lang set to "en" and has a Role element with @value set to "main". The second Preselection element has @preselectionComponents set to "1, 2", @lang set to "en", has a Role element with @value set to "commentary" and has an Accessibility element with @value set to "1" ('Audio description for the visually impaired'). The third Preselection element has @preselectionComponents set to "1, 3", @lang set to "de" and has a Role element with @value set to "dub". When the HTMLVideoElement is played, confirm that audio from the AdaptationSets with @id of "1" and @id of "2" are heard. | 2024-1 2023-3 2023-2 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 [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.18: Players shall support SRSP and SRMP use cases. Players may support MRMP use cases. [...] If MRMP use cases are supported, players shall support the download of segments from at least 3 audio Representations from different Adaptation Sets from an audio bundle. TS-103-285,section 6.7.3: DASH clients supporting SRMP or MRMP 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]. The use of the @value attribute set to "main" for audio content indicates that the Preselection is the preferred audio Preselection by the content provider. If there is only one Preselection element with the Role "main", it identifies the default Preselection. TS-103-285,section 6.8.3.2.2: The sample entry “mhm2” shall be used in cases of MRMP as described in ISO/IEC 23008-3, Clause 14.6 [35]. | +HEVC_HD_10 +MPEG_H +MRMP | ||
| org.hbbtv_MPEGH-NOT-SUPPORTED0010 | 1 | Play an alternative Representation if MPEG-H is not supported. | When MPEG-H is not supported and the terminal is presented with an MPD comprising one Adaptation Set signalling profile "urn:dvb:dash:profile:dvb-dash:2017", MPEG-H audio codec and a Role element with @value='main', and a second Adaptation Set signalling profile "urn:dvb:dash:profile:dvb-dash:2014" and AAC audio codec, the terminal shall play the AAC audio. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | TS-103-285,section 10.1: Players shall support the 2014 DVB profile MPEG DASH as defined in the present document and indicated by "urn:dvb:dash:profile:dvb-dash:2014". ... 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 (where the DVB profile is defined in clause 4.1) (but not necessarily other Adaptation Sets or Representations in the MPD discarded as part of the process of deriving the profile-specific MPD). TS-103-285,section 10.10: Where there are multiple Adaptation Sets of the same component type (e.g. 2 x video Adaptation Sets), Players shall by default select the Adaptation Set that is signalled with a Role element with a value of "main" from the "urn:mpeg:dash:role:2011" scheme. 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: For MPEG DASH, the following shall apply; [...] * HE-AAC shall be supported for audio-only content and for audio/video content in combination with all supported video formats. | -MPEG_H | ||
| org.hbbtv_MPEGH-PERIOD-TRANS-0010 | 1 | DASH Stream containing 3 contiguous periods the first AVC_HD_25/HEAAC, the second AVC_HD_25/MPEG-H and the third AVC_HD_25/HEAAC plays and transitions between periods successfully. | The terminal shall correctly decode and present video and audio content from a stream defined by a static MPD containing a period containing AVC_HD_25/HEAAC media, followed by a period containing AVC_HD_25/MPEG-H media, followed by a period containing AVC_HD_25/HEAAC media. Video and audio from all three periods is played back without artifacts or glitches and the transitions are successful. | 2024-1 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 | DASH,section 5.3.2: @start [...] if present, specifies the PeriodStart time of the Period.The PeriodStart time is used as an anchor to determine the MPD start time of each Media Segment as well as to determine the presentation time of each each access unit in the Media Presentation timeline. [...] @duration [...] if present specifies the duration of the Period to determine the PeriodStart time of the next Period. TS-103-285,section 6.8.2: The elementary stream requirements are defined in Clause 6.8.2 of TS 101 154 [3] TS-103-285,section 6.8.3.2.5: The configuration change constraints are defined in Clause 6.8.5 of TS 101 154 [3]. [...] NOTE: Representations that belong to one Audio Programme use different configurations and a switch between two ISOBMFF segments also represents a configuration change. Thus, the MHASPacketLabel needs to have different values for all Representations that belong to one Audio Programme. Also, after a configuration change, the MHASPacketLabel needs to have different values for all Representations comprising an Audio Programme. TS-103-285,section 6.8.3.2.6: The MPEG-H Audio multi-stream constraints are defined in Clause 6.8.7 of TS 101 154 [3]. [...] NOTE: Representations that belong to one Adaptation Set need to use different MHASPacketLabel values within the same range of values associated to one stream, as specified in ISO/IEC 23008-3, Clause 14.6 [35]. For example, all ISOBMFF segments in the Adaptation Set for the main stream use different values between 1 and 16, all ISOBMFF segments in the Adaptation Set for the first auxiliary stream use values between 17 and 32, and so on. 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH 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-101-154,section 6.8.3: Encoding: The MPEG-H Audio elementary streams shall be encapsulated in the MPEG-H Audio Stream Format (MHAS) according to ISO/IEC 23008-3 [47], clause 14, with further specification in ISO/IEC 13818-1 [1], clause 2.19.2. TS-101-154,section 6.8.5: If MHAS packets of type PACTYP_AUDIOTRUNCATION are present, they shall be used as described in ISO/IEC 23008-3 [47], clause 14. ISO/IEC-23008-3,section 20.6.1: Especially in streaming or broadcast environments based on, e.g. MPEG-DASH or MPEG-H MMT, the MPEG-H 3D Audio configuration may change at arbitrary positions of the stream and not necessarily only on fragment boundaries. To enable this use-case the ‘mhm1’ and ‘mhm2’ MHASampleEntry provides an in-band configuration mechanism for MPEG-H 3D Audio files. | +MPEG_H | ||
| org.hbbtv_MPEGH-PERIOD-TRANS-0020 | 1 | DASH Stream containing 3 contiguous periods the first HEVC_HD_25_8/HEAAC, the second HEVC_HD_25_8/MPEG-H and the third HEVC_HD_25_8/HEAAC plays and transitions between periods successfully. | The terminal shall correctly decode and present video and audio content from a stream defined by a static MPD containing a period containing HEVC_HD_25_8/HEAAC media followed by a period containing HEVC_HD_25_8/MPEG-H media, followed by a period containing HEVC_HD_25_8/HEAAC media. Video and audio from all three periods is played back without artifacts or glitches and the transitions are successful. | 2024-1 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 | DASH,section 5.3.2: @start [...] if present, specifies the PeriodStart time of the Period.The PeriodStart time is used as an anchor to determine the MPD start time of each Media Segment as well as to determine the presentation time of each each access unit in the Media Presentation timeline. [...] @duration [...] if present specifies the duration of the Period to determine the PeriodStart time of the next Period. TS-103-285,section 6.8.2: The elementary stream requirements are defined in Clause 6.8.2 of TS 101 154 [3] TS-103-285,section 6.8.3.2.5: The configuration change constraints are defined in Clause 6.8.5 of TS 101 154 [3]. [...] NOTE: Representations that belong to one Audio Programme use different configurations and a switch between two ISOBMFF segments also represents a configuration change. Thus, the MHASPacketLabel needs to have different values for all Representations that belong to one Audio Programme. Also, after a configuration change, the MHASPacketLabel needs to have different values for all Representations comprising an Audio Programme. TS-103-285,section 6.8.3.2.6: The MPEG-H Audio multi-stream constraints are defined in Clause 6.8.7 of TS 101 154 [3]. [...] NOTE: Representations that belong to one Adaptation Set need to use different MHASPacketLabel values within the same range of values associated to one stream, as specified in ISO/IEC 23008-3, Clause 14.6 [35]. For example, all ISOBMFF segments in the Adaptation Set for the main stream use different values between 1 and 16, all ISOBMFF segments in the Adaptation Set for the first auxiliary stream use values between 17 and 32, and so on. 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH 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-101-154,section 6.8.3: Encoding: The MPEG-H Audio elementary streams shall be encapsulated in the MPEG-H Audio Stream Format (MHAS) according to ISO/IEC 23008-3 [47], clause 14, with further specification in ISO/IEC 13818-1 [1], clause 2.19.2. TS-101-154,section 6.8.5: If MHAS packets of type PACTYP_AUDIOTRUNCATION are present, they shall be used as described in ISO/IEC 23008-3 [47], clause 14. ISO/IEC-23008-3,section 20.6.1: Especially in streaming or broadcast environments based on, e.g. MPEG-DASH or MPEG-H MMT, the MPEG-H 3D Audio configuration may change at arbitrary positions of the stream and not necessarily only on fragment boundaries. To enable this use-case the ‘mhm1’ and ‘mhm2’ MHASampleEntry provides an in-band configuration mechanism for MPEG-H 3D Audio files. | +HEVC_HD_8 +MPEG_H | ||
| org.hbbtv_MPEGH-PERIOD-TRANS-0030 | 1 | DASH Stream containing 2 contiguous periods, with associated and period-continuous AdaptationSets containing HEVC_HD_25_8/MPEG-H, plays and transitions seamlessly between periods | The terminal shall correctly decode and present video and audio content from a stream defined by a static MPD containing two contiguous Periods, where each Period contains HEVC_HD_25_8/MPEG-H media. The two video AdaptationSets share the same @id value. The two audio AdaptationSets share the same @id value. Values for @lang, @contentType, @par, Role, Accessibility, ViewPoint attributes and properties are unchanged for associated AdaptationSets between periods. The audio AdaptationSets also share the same values for @mimeType, @codecs, @audioSamplingRate, @AudioChannelConfiguration attributes. The second Period contains a SupplementalProperty descriptor with the @schemeIdUri attribute set to "urn:dvb:dash:period_continuity:2014" and the @value attribute set to the @id of the first Period. Video and audio from both Periods is played back without artifacts or glitches and the transition is seamless. | 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 1.6.1 HBBTV 1.7.1 | DASH,section 5.3.2: @start [...] if present, specifies the PeriodStart time of the Period.The PeriodStart time is used as an anchor to determine the MPD start time of each Media Segment as well as to determine the presentation time of each each access unit in the Media Presentation timeline. [...] @duration [...] if present specifies the duration of the Period to determine the PeriodStart time of the next Period. TS-103-285,section 6.8.2: The elementary stream requirements are defined in Clause 6.8.2 of TS 101 154 [3] TS-103-285,section 6.8.3.2.5: The configuration change constraints are defined in Clause 6.8.5 of TS 101 154 [3]. [...] NOTE: Representations that belong to one Audio Programme use different configurations and a switch between two ISOBMFF segments also represents a configuration change. Thus, the MHASPacketLabel needs to have different values for all Representations that belong to one Audio Programme. Also, after a configuration change, the MHASPacketLabel needs to have different values for all Representations comprising an Audio Programme. TS-103-285,section 6.8.3.2.6: The MPEG-H Audio multi-stream constraints are defined in Clause 6.8.7 of TS 101 154 [3]. [...] NOTE: Representations that belong to one Adaptation Set need to use different MHASPacketLabel values within the same range of values associated to one stream, as specified in ISO/IEC 23008-3, Clause 14.6 [35]. For example, all ISOBMFF segments in the Adaptation Set for the main stream use different values between 1 and 16, all ISOBMFF segments in the Adaptation Set for the first auxiliary stream use values between 17 and 32, and so on. TS-103-285,section 10.5.2.2: The content provider may express that the media components contained in two Adaptation Sets in two different Periods are associated by assigning equivalent Asset Identifiers to both Periods and by identifying both Adaptation Sets with identical value for the attribute AdaptationSet@id. If Adaptation Sets in two different Periods are associated, then the following parameters shall be identical for the two Adaptation Sets: * the language as described by the @lang attribute, * the media component type described by the @contentType attribute, * the picture aspect ratio as described by the @par attribute, * any role properties as described by the Role elements, * any accessibility property as described by the Accessibility elements, * any viewpoint property as described by the Viewpoint elements, * for audio Adaptation Sets, all values and presence of all attributes and elements listed in Table 4. TS-103-285,section 10.5.2.3: Content providers may explicitly signal that Adaptation Sets across Periods are period-continuous. It may do this by providing the following signalling: * From the first Period: - PID means the Period@id attribute value. - AID means the value of the @id attribute of the Adaptation Set to be Period continuous. * In subsequent Periods: - The Period contains an Adaptation Set with the following: * the @id attribute set to AID. * a SupplementalProperty descriptor with the @schemeIdUri attribute set to "urn:dvb:dash:period_continuity:2014" and the @value attribute set to PID. If this is the case, then the following shall hold: * All Representations in the Adaptation Set in the first Period shall share the same value EPT1 for the earliest presentation time. * All Representations in the Adaptation Set in a subsequent Period shall share the same value EPT2 for the earliest presentation time. * The Adaptation Sets with the value of their @id attribute set to AID in the first and subsequent Periods shall be associated as defined in clause 10.5.2.2. * The presentation duration of each Representation in the Adaptation Set with the @id attribute set to AID in the first Period shall be EPT2 - EPT1, where the presentation duration of a Representation is identical to the difference between the end presentation time of the Representation and the earliest presentation time of any access unit. * If a Representation exists in Adaptation Sets that have their @id attribute set to AID in the first and subsequent Periods where these Representations share the same value for their @id attributes, then the following shall hold: - the Representations shall have functionally equivalent Initialization Segments, i.e. the Initialization Segment signalled for the Representation in the first Period may be used to continue the play-out of the Representation in subsequent Periods, and - the concatenation of the Initialization Segment for the Representation in the first Period and all Media Segments in the Representation in first Period and all Media Segments in the Representation in the subsequent Periods shall represent a conforming Segment sequence as defined in clause 4.5.4 of ISO/IEC 23009-1 [1]. Content providers should signal period-continuous Adaptation Sets. TS-103-285,section 11.11: AssetIdentifier descriptors identify the asset to which a period belongs and may be used for implementation of Player functionality that depends on distinguishing between adverts and main content. An AssetIdentifier, may be used, and if used has to be unique per asset within an MPD. 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 7.3.2.1: HTTP adaptive streaming shall be supported using MPEG DASH 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-101-154,section 6.8.3: Encoding: The MPEG-H Audio elementary streams shall be encapsulated in the MPEG-H Audio Stream Format (MHAS) according to ISO/IEC 23008-3 [47], clause 14, with further specification in ISO/IEC 13818-1 [1], clause 2.19.2. TS-101-154,section 6.8.5: If MHAS packets of type PACTYP_AUDIOTRUNCATION are present, they shall be used as described in ISO/IEC 23008-3 [47], clause 14. ISO/IEC-23008-3,section 20.6.1: Especially in streaming or broadcast environments based on, e.g. MPEG-DASH or MPEG-H MMT, the MPEG-H 3D Audio configuration may change at arbitrary positions of the stream and not necessarily only on fragment boundaries. To enable this use-case the ‘mhm1’ and ‘mhm2’ MHASampleEntry provides an in- band configuration mechanism for MPEG-H 3D Audio files. | +HEVC_HD_8 +MPEG_H | ||
| org.hbbtv_MPEGH-PLAYBACK0001 | 1 | Playback of Mono MPEG-H audio only HbbTV ISOBMFF Live profile in a HTML5 video object | The terminal shall correctly decode and present mono MPEG-H audio from an audio only HbbTV ISOBMFF Live profile DASH MPD when played in a HTML5 video object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 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 [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.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 [...] | +MPEG_H | ||
| org.hbbtv_MPEGH-PLAYBACK0002 | 1 | Playback of 2.0 MPEG-H audio only HbbTV ISOBMFF Live profile in a HTML5 video object | The terminal shall correctly decode and present 2.0 MPEG-H audio from an audio only HbbTV ISOBMFF Live profile DASH MPD when played in a HTML5 video object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 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 [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.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 [...] | +MPEG_H | ||
| org.hbbtv_MPEGH-PLAYBACK0003 | 1 | Playback of 5.1 MPEG-H audio only HbbTV ISOBMFF Live profile in a HTML5 video object | The terminal shall correctly decode and present 5.1 MPEG-H audio from an audio only HbbTV ISOBMFF Live profile DASH MPD when played in a HTML5 video object. | 2024-1 2023-3 2023-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 | 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 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 [...] | +MPEG_H | ||
| org.hbbtv_MPEGH-PLAYBACK0004 | 2 | Playback of 7.1 MPEG-H audio only HbbTV ISOBMFF Live profile in a HTML5 video object | The terminal shall correctly decode and present 7.1 MPEG-H audio from an audio only HbbTV ISOBMFF Live profile DASH MPD when played in a HTML5 video object. | 2024-1 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 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.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 [...] | +MPEG_H | ||
| org.hbbtv_MPEGH-PLAYBACK0005 | 2 | Playback of 2.0 MPEG-H audio only HbbTV ISOBMFF On Demand profile in a HTML5 video object | The terminal shall correctly decode and present 2.0 MPEG-H audio from an audio only HbbTV ISOBMFF On Demand profile DASH MPD when played in a HTML5 video object. | 2024-1 2023-3 2023-2 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 [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.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 [...] | +MPEG_H | ||
| org.hbbtv_MPEGH-PLAYBACK0010 | 2 | Playback of 7.1+4H MPEG-H audio only HbbTV ISOBMFF Live profile in a HTML5 video object | The terminal shall correctly decode and present 7.1+4H MPEG-H audio from an audio only HbbTV ISOBMFF Live profile DASH MPD when played in a HTML5 video object. | 2024-1 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 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.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 [...] TS-101-154,section 6.8.2: Decoding: The IRD shall be capable of decoding MPEG-H Audio LC Profile Level 1, Level 2 and Level 3 bitstreams ISO/IEC-23008-3,section 4.8.2.1: Table 3 — Levels and their corresponding restrictions for the Low Complexity Profile | Level | Max. Sampling rate | Max. no. of core ch. in compressed data stream | Max. no. of decoder processed core ch. | Max. no. of loudspeaker output ch. | Example of max. loudspeaker configuration | Max. no. of decoded objects | Example of a max. Config C+O | ... | 3 | 48000 | 32 | 16 | 12 | 11.1 | 16 | 12 ch. + 4 obj. | 6 | 6th order + 4 obj. | | +MPEG_H | ||
| org.hbbtv_MPEGH-PRESELECT0010 | 1 | MPEG-H Preselection of Role "main" | When an HTMLVideoElement is played, referencing a static MPD containing MPEG-H audio, and the MPD comprises a single AdaptationSet, a Preselection with Role@value set to "main", a second Preselection with Role@value set to "commentary" and a third Preselection with Role@value set to "supplementary", the terminal shall present the Preselection with Role@value set to "main". | 2024-1 2023-3 2023-2 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 [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.18: Players shall support SRSP and SRMP use cases. TS-103-285,section 6.7.3: DASH clients supporting SRMP or MRMP 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]. The use of the @value attribute set to "main" for audio content indicates that the Preselection is the preferred audio Preselection by the content provider. If there is only one Preselection element with the Role "main", it identifies the default Preselection. | +MPEG_H | ||
| org.hbbtv_MPEGH-PRESELECT0020 | 1 | MPEG-H Preselection of translated language | When the terminal's preferred language is set to French and an HTMLVideoElement is played, referencing a static MPD containing MPEG-H audio, and the MPD comprises a single 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 "main" and @lang set to "de", then the terminal shall present the Preselection with @lang set to "fr". | 2024-1 2023-3 2023-2 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 [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 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 or MRMP 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. | +MPEG_H | ||
| org.hbbtv_MPEGH-PRESELECT0030 | 1 | MPEG-H Preselection of Audio Description | When the terminal's audio preference is set to Audio Description and an HTMLVideoElement is played, referencing a static MPD containing MPEG-H audio, and the MPD comprises a single AdaptationSet, a Preselection with Role@value set to "main", a second Preselection with Role@value set to "commentary" and Accessibility@value set to 1 (indicating visually impaired), and a third Preselection with Role@value set to "alternate" and Accessibility@value set to 2 (indicating hard of hearing), where all Preselections signal @lang as "en", then the receiver shall present the second Preselection. | 2024-1 2023-3 2023-2 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 [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.18: Players shall support SRSP and SRMP use cases. TS-103-285,section 6.7.3: DASH clients supporting SRMP or MRMP 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]. TS-103-285,section 6.7.5: Preselection elements which enable accessibility features shall be signaled with a Role and Accessibility element according to clause 6.1.2, table 5. DASH,section 5.8.5.5: The URN "urn:mpeg:dash:role:2011" is defined to identify the role scheme defined in Table 22. [...] alternate - media content component(s) that is/are an alternative to (a) main media content component(s) of the same media component type (see note 2 below) [...] commentary - media content component with commentary (e.g. director’s commentary) (typically audio) | +MPEG_H | ||
| org.hbbtv_MPEGH-PRESELECT0031 | 1 | MPEG-H Preselection of Dialogue Enhancement | When the terminal's audio preference is set to Hard of Hearing and an HTMLVideoElement is played, referencing a static MPD containing MPEG-H audio, and the MPD comprises a single AdaptationSet, a Preselection with Role@value set to "main", a second Preselection with Role@value set to "commentary" and Accessibility@value set to 1 (indicating visually impaired), and a third Preselection with Role@value set to "alternate" and Accessibility@value set to 2 (indicating hard of hearing), where all Preselections signal @lang as "en", then the receiver shall present the third Preselection. | 2024-1 2023-3 2023-2 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. 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 or MRMP 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]. TS-103-285,section 6.7.5: Preselection elements which enable accessibility features shall be signaled with a Role and Accessibility element according to clause 6.1.2, table 5. DASH,section 5.8.5.5: The URN "urn:mpeg:dash:role:2011" is defined to identify the role scheme defined in Table 22. [...] alternate - media content component(s) that is/are an alternative to (a) main media content component(s) of the same media component type (see note 2 below) [...] commentary - media content component with commentary (e.g. director’s commentary) (typically audio) | +MPEG_H | ||
| org.hbbtv_MPEGH-PRESELECT0040 | 1 | MPEG-H Preselection of original language | When the terminal's preferred language is set to French and an HTMLVideoElement is played, referencing a static MPD containing MPEG-H audio, and the MPD comprises a single AdaptationSet, a Preselection with @lang set to "en" and Role@value set to "main", a second Preselection with @lang set to "fr" and Role@value set to "main", a third Preselection with @lang set to "en", Role@value set to "commentary" and Accessibility@value set to 1 (indicating visually impaired), and a fourth Preselection with @lang set to "en", Role@value set to "alternate" and Accessibility@value set to 2 (indicating hard of hearing), then the receiver shall present the second Preselection with @lang set to "fr". | 2024-1 2023-3 2023-2 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 [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 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 or MRMP 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 multiple Preselection elements have a Role element with a @value set to "main" then the Player will choose which one of these Preselections is the most appropriate to use and only if all of these are inappropriate, it may choose one with @value set to something other than "main". [...] If an audio bundle contains multiple audio Preselections with different original languages, all Preselection elements shall have the Role@value "main". An example is a sports game commentated by multiple commentators in multiple languages. The language contained in the Preselection element is given by the @lang attribute. | +MPEG_H | ||
| org.hbbtv_MPEGH-PRESELECT0050 | 1 | MPEG-H Preselection using switch group | When the terminal's language preference is set to English and an HTMLVideoElement is played, referencing a static MPD containing MPEG-H audio, and the MPD comprises a single AdaptationSet, a Preselection with Role@value set to "main" referencing an MPEG-H group signalling "complete main" content kind plus an MPEG-H switch group comprising three "dialogue" content kind groups indicating English (marked as default in mae_switchGroupDefaultGroupID), French and German respectively, a second Preselection with Role@value set to "commentary" and Accessibility@value set to 1 (indicating visually impaired), and a third Preselection with Role@value set to "alternate" and Accessibility@value set to 2 (indicating hard of hearing), where all Preselections signal @lang as "en", then the receiver shall select the first Preselection and present the "complete main" audio group plus English language audio from the switch group. No audio in other languages is heard. | 2024-1 2023-3 2023-2 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. 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 or MRMP 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]. TS-103-285,section 6.8.4: The attributes and elements listed in table 16 below can be used on AdaptationSets as well as on Preselection element unless explicitly indicated. [...] @lang | The language indicated should correspond to the information conveyed in mae_contentLanguage of the default dialog element: The maeGroup which is marked as default in mae_switchGroupDefaultGroupID and is tagged in mae_contentKind as dialogue. This information is carried in the AudioSceneInformation() of the MPEG-H Audio stream as defined in ISO/IEC 23008-3 [35]. | +MPEG_H | ||
| org.hbbtv_MPEGH-SEEKACCURACY0020 | 1 | Seek to start of HEVC_HD_25_8 video and MPEG-H audio subsegments in on-demand period | An application starts playback of a DASH MPD with HEVC_HD_25_8 video and MPEG-H audio and then seeks to a location that is in a on-demand period and is identifiable from the Segment Index as being the start of a subsegment. The seek is frame accurate. The position reported by the media player API reports the true media position after the seek. | 2024-1 2023-3 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-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 [45] and TS 101 154 [14]. The labels that shall be used for these formats are defined in table 10. HBBTV,section 9.1.3: MPEG DASH / ISO BMFF Seeks to a position shall be performed precisely if: [...] 2) the position is within an on-demand Period and is identifiable from the Segment Index as being the start of a subsegment [...] 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. | +HEVC_HD_8 +MPEG_H | ||
| org.hbbtv_MPEGH-SEEKACCURACY0030 | 1 | Seek to other positions in MPEG-H DASH content - live period - nearest position before target | An application starts DASH content playback with MPEG-H audio and then seeks forward to a position that is in a live Period but which is not identifiable from the MPD as being the start of a media segment and where the nearest identifiable position as a 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 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 [45] and TS 101 154 [14]. The labels that shall be used for these formats are defined in table 10. 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. | +MPEG_H | ||
| org.hbbtv_MPEGH-WEBAUDIO0010 | 1 | PCM audio from memory played in combination with broadcasted MPEG-H | A broadcast-related HbbTV application that is connected to the broadcast of the current channel loads 16-bit PCM audio via XMLHttpRequest and then plays it through the Web Audio API. The PCM audio is heard and the broadcast video playback is not interrupted. The audio is either mixed with the MPEG-H broadcast audio or temporarily replaces it. | 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 | 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 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 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.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. | +MPEG_H | ||
| org.hbbtv_MPEGH-WEBAUDIO0020 | 1 | MP3 Audio from memory mixed with broadcasted MPEG-H | A broadcast-related HbbTV application that is connected to the broadcast of the current channel loads MP3 audio via XMLHttpRequest, decodes it via AudioContext.decodeAudioData and then plays it through the Web Audio API. The MP3 audio is heard and the broadcast video playback is not interrupted. The audio is either mixed with the MPEG-H broadcast audio or temporarily replaces it. | 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 | 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 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 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. 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. | +MPEG_H | ||
| org.hbbtv_MSE0010 | 1 | AIT monitoring when playing broadband MSE video and audio | Terminal is playing a broadcast MPEG-2 transport stream and a broadcast-related application is running. When the application starts playback of a broadband MSE video and audio, they start presenting successfully. Later the AIT in the broadcast service changes such that the running app is removed from the AIT and a new autostart app is added. The running app is killed and the new autostart app is started. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 | HBBTV 1.6.1 | HBBTV-TA-1,section 6.2: The requirements in clause 6.2.2.7 of TS 102 796 defining that "Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast" shall also apply for video presented via MSE at the same time as demultiplexing MPEG-2 sections from the broadcast - including all the listed examples. HBBTV,section 6.2.2.7: Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular, the following examples shall apply: - AIT monitoring shall continue. HBBTV,section 6.2.2.3: AIT updated; Is an application already running?; Yes; Is it signalled in the new service with the same transport protocol?; No; Kill currently running application. HBBTV,section 6.2.2.7: Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular, the following examples shall apply: • AIT monitoring shall continue. • Files in a carousel shall be accessible including updates. • DSM-CC stream event monitoring shall continue. • ProgrammesChanged events shall be sent to any registered listeners. For the avoidance of doubt, this shall also be supported for an HTML5 media element whose source is a MediaSource object. | |||
| org.hbbtv_MSE0020 | 1 | DSMCC Stream Event fires while playing MSE video | When the terminal is presenting video and audio using MSE within an HbbTV application and it receives a DSM-CC stream event to which the application has subscribed, then the terminal passes the stream event to the application and the video and audio continue to play without interruption. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 | HBBTV 1.6.1 | HBBTV-TA-1,section 6.2: The requirements in clause 6.2.2.7 of TS 102 796 defining that "Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast" shall also apply for video presented via MSE at the same time as demultiplexing MPEG-2 sections from the broadcast - including all the listed examples. HBBTV,section 6.2.2.7: Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular, the following examples shall apply: [...] - DSM-CC stream event monitoring shall continue. HBBTV,section 8.2.1.1: The following additional methods on the video/broadcast object (as defined in the OIPF DAE specification [1]) shall be supported for synchronization to broadcast events as defined in clause 7.2.4. void addStreamEventListener(String targetURL, String eventName, EventListener listener) Description: Add a listener for the specified DSM-CC stream event. HBBTV,section 6.2.2.7: Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular, the following examples shall apply: • AIT monitoring shall continue. • Files in a carousel shall be accessible including updates. • DSM-CC stream event monitoring shall continue. • ProgrammesChanged events shall be sent to any registered listeners. For the avoidance of doubt, this shall also be supported for an HTML5 media element whose source is a MediaSource object. | |||
| org.hbbtv_MSE0030 | 1 | Carousel access when playing broadband MSE video and audio | Terminal is playing a broadcast MPEG-2 transport stream, and a broadcast-related application carried in a DSM-CC object carousel is running. When the application starts playback of a broadband MSE video and audio, they start presenting successfully. When a file in its carousel is updated, the running application is able to access the updated file. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 | HBBTV-TA-1,section 6.2: The requirements in clause 6.2.2.7 of TS 102 796 defining that "Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast" shall also apply for video presented via MSE at the same time as demultiplexing MPEG-2 sections from the broadcast - including all the listed examples. HBBTV,section 6.2.2.7: Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular, the following examples shall apply: [...] - Files in a carousel shall be accessible including updates. HBBTV,section 6.2.2.7: Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular, the following examples shall apply: • AIT monitoring shall continue. • Files in a carousel shall be accessible including updates. • DSM-CC stream event monitoring shall continue. • ProgrammesChanged events shall be sent to any registered listeners. For the avoidance of doubt, this shall also be supported for an HTML5 media element whose source is a MediaSource object. | |||
| org.hbbtv_MSE0040 | 1 | ProgrammesChanged event generation when playing broadband MSE video and audio | Terminal is playing a broadcast MPEG-2 transport stream and a broadcast-related application is running. The application registers to receive ProgrammesChanged events. When the application starts playback of a broadband MSE video and audio, they start presenting successfully. While the broadband delivered video and audio are playing, the DVB-SI event in the broadcast changes and a ProgrammesChanged event is sent to the registered listener. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-2 2021-1 2020-2 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV-TA-1,section 6.2: The requirements in clause 6.2.2.7 of TS 102 796 defining that "Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast" shall also apply for video presented via MSE at the same time as demultiplexing MPEG-2 sections from the broadcast - including all the listed examples. HBBTV,section 6.2.2.7: Terminals shall be able to present broadband delivered A/V at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular the following examples shall apply:- ProgrammesChanged events shall be sent to any registered listeners. HBBTV,section A.2.9: The Metadata APIs listed in table A.1 of the present document shall allow access to DVB-SI EIT event schedule information for the actual transport stream and for the other transport streams (as defined in ETSI EN 300 468) that are carried on the transport stream of the currently selected broadcast service. The terminal shall use EIT-present/following information and, if present, EIT-schedule information. If both EIT-schedule and EIT-present/following information are present, it is implementation dependent which shall be used in cases where there are conflicts. HBBTV,section 6.2.2.7: Terminals shall be able to present broadband delivered video at the same time as demultiplexing MPEG-2 sections from the broadcast. In particular, the following examples shall apply: • AIT monitoring shall continue. • Files in a carousel shall be accessible including updates. • DSM-CC stream event monitoring shall continue. • ProgrammesChanged events shall be sent to any registered listeners. For the avoidance of doubt, this shall also be supported for an HTML5 media element whose source is a MediaSource object. OIPF-DAE,section 7.13.3: function onProgrammesChanged() The function that is called when the programmes property has been updated with new programme information, e.g. when the current broadcast programme is finished and a new one has started. The specified function is called with no arguments. OIPF-DAE,section 7.13.3.1: For the intrinsic events listed in the table below, a corresponding DOM event shall be generated in the following manner: Intrinsic event; Corresponding DOM event; DOM Event properties; onProgrammesChanged; ProgrammesChanged; Bubbles: No Cancellable: No Context Info: None Note: this DOM event is directly dispatched to the event target, and will not bubble nor capture. Applications should not rely on receiving these events during the bubbling or the capturing phase. Applications that use DOM event handlers shall call the addEventListener() method on the video/broadcast object itself. The third parameter of addEventListener, i.e. "useCapture”, will be ignored. | |||
| org.hbbtv_MSE0150 | 1 | Inter-device sync master: MSE AVC video and audio | The application on the terminal has initialised a MediaSynchroniser object using the initMediaSynchroniser method, providing AVC MSE video and audio as the master media, and enabled inter-device synchronisation causing the terminal to become a master terminal and a connection has been established to the CSS-TS endpoint of the terminal. Using the analyzeAvNetSync() API check that the data emitted from the terminal is in sync with the terminal's presentation (as light and sound) of the master media. | 2024-1 2023-3 2023-2 2023-1 2022-3 2021-1 | HBBTV 1.6.1 | HBBTV-TA-1,section 9.1.3: Clause 9.7.1.2 of TS 102 796 shall apply to HTML5 media elements whose source is MSE [...]. The requirements defined in this clause apply to HTML5 media elements used: [...] as master media for inter-device synchronisation; HBBTV-TA-1,section 13.1.2: The Timeline Selector urn:hbbtv:sync:timeline:html-media-timeline shall refer to the media timeline of the media resource of an HTML media element [...]. The use of this Timeline Selector shall be supported for when an HTML media element is used: [...] - as the timeline for the master media for inter-device synchronisation HBBTV,section 9.6.1: The Media Source Extensions (MSE) shall be supported (as required by WMAS 2018 [76]) as a source, either via the srcObject attribute of the media element (where supported), or alternatively through the use of an object URL pointing to a MediaSource object. Unless otherwise stated, all requirements of the present document that apply to the HTML5 media element apply equally when MSE is used. HBBTV,section 13.4.4: The Timeline Selector urn:hbbtv:sync:timeline:html-media-timeline shall refer to the media timeline of the media resource of an HTML media element as defined in clause 4.8.12.6 of the HTML specification [54]. NOTE: The timeline specified by this Timeline Selector can be used with an HTML media element in the situation where the media resource is being provided by the application via Media Source Extensions. Other Timeline Selectors that depend on the container format of the media resource cannot be used in this situation. Values on the timeline represented by this Timeline Selector shall have a tick rate of 1000 Hz and therefore be expressed in units of milliseconds when used: • in CorrelationTimestamp objects (defined in the clause 8.2.3.3); and • in messages exchanged via the Timeline Synchronisation service endpoint (defined in clause 13.8). HBBTV,section 9.7.1.2: An HTML5 media element that is passed to the initMediaSynchroniser() [...] method [...]. | |||
| org.hbbtv_MSE0170 | 1 | Inter-device sync master: MSE data acquisition stalls | The application on the terminal has initialised a MediaSynchroniser object using the initMediaSynchroniser method, providing AVC MSE video and audio as the master media, and enabled inter-device synchronisation causing the terminal to become a master terminal and a connection has been established to the CSS-TS endpoint of the terminal. Using the analyzeAvNetSync() API check that the data emitted from the terminal is in sync with the master media. When later the MSE video and audio player is not provided sufficient data, then playback of the video and audio shall cease. When more video and audio are provided, the video and audio playback shall resume, and using the analyzeAvNetSync() API check that the data emitted from the terminal is in sync with the master media. | 2024-1 2023-3 2023-2 2023-1 2022-3 2021-1 | HBBTV 1.6.1 | HBBTV-TA-1,section 9.1.3: Clause 9.7.1.2 of TS 102 796 shall apply to HTML5 media elements whose source is MSE [...]. Specifically; * If the media element is potentially playing and the readyState transitions from HAVE_FUTURE_DATA or more to HAVE_CURRENT_DATA or less (i.e. the application does not append data to a SourceBuffer fast enough) then the terminal shall behave as defined in Clause 9.7.1.2 of TS 102 796 for when the terminal "is stalled while trying to fetch media data".; * If the readyState transitions from HAVE_CURRENT_DATA or less to HAVE_FUTURE_DATA or more (i.e. the application appends sufficient data to the SourceBuffer) then the terminal shall behave as defined in Clause 9.7.1.2 of TS 102 796 for when it is no longer stalled because sufficient data has become available.; [...] The requirements defined in this clause apply to HTML5 media elements used: [...] as master media for inter-device synchronisation HBBTV-TA-1,section 13.1.2: The Timeline Selector urn:hbbtv:sync:timeline:html-media-timeline shall refer to the media timeline of the media resource of an HTML media element [...]. The use of this Timeline Selector shall be supported for when an HTML media element is used: [...] - as the timeline for the master media for inter-device synchronisation HBBTV,section 9.6.1: The Media Source Extensions (MSE) shall be supported (as required by WMAS 2018 [76]) as a source, either via the srcObject attribute of the media element (where supported), or alternatively through the use of an object URL pointing to a MediaSource object. Unless otherwise stated, all requirements of the present document that apply to the HTML5 media element apply equally when MSE is used. HBBTV,section 13.4.4: The Timeline Selector urn:hbbtv:sync:timeline:html-media-timeline shall refer to the media timeline of the media resource of an HTML media element as defined in clause 4.8.12.6 of the HTML specification [54]. NOTE: The timeline specified by this Timeline Selector can be used with an HTML media element in the situation where the media resource is being provided by the application via Media Source Extensions. Other Timeline Selectors that depend on the container format of the media resource cannot be used in this situation. Values on the timeline represented by this Timeline Selector shall have a tick rate of 1000 Hz and therefore be expressed in units of milliseconds when used: • in CorrelationTimestamp objects (defined in the clause 8.2.3.3); and • in messages exchanged via the Timeline Synchronisation service endpoint (defined in clause 13.8). HBBTV,section 9.7.1.2: An HTML5 media element that is passed to the initMediaSynchroniser() [...] method [...]. The terminal is not required to maintain synchronization of all media objects attached to the MediaSynchroniser (including media on other terminals if inter-device synchronization is being performed) to an HTML5 media element representing the master media (it was passed to a MediaSynchroniser via the initMediaSynchroniser() method) while one or more of the following conditions are true for that HTML5 media element: * It is stalled while trying to fetch media data. * [...]. Synchronization of all media objects shall resume automatically when the HTML5 media element representing the master media returns to a state where all the conditions listed above are no longer true. | |||
| org.hbbtv_MSE-LL0010 | 1 | Ad insertion with MSE - mid-roll with 3 video elements, MediaSource HEAAC/AVC_HD_25, DASH HEAAC/AVC_SD_25, DASH HEAAC/AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing a MediaSource with HEAAC/AVC_HD_25 content is paused, and a second media element with preloaded HEAAC/AVC_SD_25 DASH media is played in its entirety, and then a third media element with preloaded HEAAC/AVC_HD_25 DASH content is played. | 2024-1 2023-3 2023-2 2023-1 | HBBTV 1.6.1 | 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. The terminal shall support each of the following scenarios: ... * one of the three HTML5 media elements refers to a MediaSource object and the other two refer to DASH content 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. | |||
| org.hbbtv_MSE-LL0020 | 1 | Ad insertion with MSE - mid-roll with 3 video elements, MediaSource 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 a MediaSource with HEAAC/AVC_HD_25 content is paused, and a second media element with preloaded HEAAC/AVC_SD_25 MP4 media is played in its entirety, and then a third media element with preloaded HEAAC/AVC_HD_25 MP4 content is played. The transition from the first to the second media element shall take place within 250 milliseconds and the transition between the second and third media element shall take place within 500 milliseconds. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 | HBBTV 1.6.1 HBBTV 1.7.1 | 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. The terminal shall support each of the following scenarios: ... * one of the three HTML5 media elements refers to a MediaSource object and the other two refer to DASH content 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 250 ms if all of the following conditions are met: ... 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 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 330 ms but may be up to 500 ms. | |||
| org.hbbtv_MSE-LL0030 | 1 | Ad insertion with MSE - mid-roll advert insertion, MediaSource 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 a MediaSource with HEAAC/AVC_HD_25 media is paused, and a second media element with preloaded HEAAC/AVC_SD_25 MP4 media is played in its entirety, and then the playing of the MSE media is resumed. The transition from the first to the second media element shall take place within 250 milliseconds and the transition from the second back to the first media element shall take place within 500 milliseconds. | 2024-1 2023-3 2023-2 2023-1 | HBBTV 1.6.1 | 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. The terminal shall support each of the following scenarios: ... * one of the three HTML5 media elements refers to a MediaSource object and the other two refer to DASH content 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 250 ms if all of the following conditions are met: ... 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 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 330 ms but may be up to 500 ms. | |||
| org.hbbtv_MSE-LL0100 | 1 | MSE integration - ISO BMFF - emsg boxes | When video and audio are played using MSE and video and audio segments contain an emsg box prior to the moof box, appending the content to the MSE SourceBuffers does not cause any error events and the content is presented without artefacts or glitches. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.13: Implementations shall accept the presence of 'emsg' boxes before the beginning of a new media segment. DASH,section 5.10.3.3: The Event Message box ('emsg') provides signalling for generic events related to the media presentation time. The same semantics as for an event defined in the MPD specified in subclause 5.10.2 applies. ... | |||
| org.hbbtv_MSE-LL0110 | 1 | MSE integration - ISO BMFF - CMAF box structure | When video and audio are played using MSE and the video and audio segments appended to the MSE SourceBuffers include segments that (a) start with an styp box and a moof box, (b) start with a prft box and a moof box, (c) start with an emsg box and a moof box, (d) start with an styp box, a prft box, an emsg box, and a moof box, appending the content to the MSE SourceBuffers does not cause any error events and the content is presented without artefacts or glitches. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 | HBBTV,section 9.6.13: In circumstances where the segments from a DVB DASH presentation are passed to an MSE SourceBuffer, implementations of MSE and the HTML5 media element shall support the requirements of ETSI TS 103 285 [45] clauses ... the two paragraphs following the note in clause 10.17. TS-103-285,section 10.17: Players shall support Representations which conform to the constraints defined for the 'cmfc' brand in clause 7 of ISO/IEC 23000-19 [40]. In particular players shall be able to decode Representations which conform to the requirements for a CMAF Track defined in clause 7.3.2.2 of ISO/IEC 23000-19 [40] or for a CMAF Track File defined in clause 7.3.3.3 of ISO/IEC 23000-19 [40]. CMAF,section 7.3.2.4: Table 8 — CMAF fragment structure NL 0|Format Req.|... styp|0/1|... prft|0/1|... emsg|*|... DASH,section 5.10.3.3: The Event Message box ('emsg') provides signalling for generic events related to the media presentation time. The same semantics as for an event defined in the MPD specified in subclause 5.10.2 applies. ... ISO/IEC-14496-12,section 8.16.2: Segment Type Box ... If segments are stored in separate files (e.g. on a standard HTTP server) it is recommended that these 'segment files' contain a segment‐type box, which must be first if present, to enable identification of those files, and declaration of the specifications with which they are compliant. ISO/IEC-14496-12,section 8.16.5: Producer Reference Time Box ... The producer reference time box supplies relative wall‐clock times at which movie fragments, or files containing movie fragments (such as segments) were produced. | |||
| org.hbbtv_MSE-LL0120 | 1 | MSE integration - ISO BMFF - negative composition time offset | When A/V being sourced via MSE uses a version 1 trun box for video that includes negative values within the composition time offset field within that box, the terminal shall smoothly play the stream, with the audio and video correctly synchronised. | 2024-1 2023-3 2023-2 2021-3 2021-2 | HBBTV 1.6.1 | HBBTV,section 9.6.13: In circumstances where the segments from a DVB DASH presentation are passed to an MSE SourceBuffer, implementations of MSE and the HTML5 media element shall support the requirements of ETSI TS 103 285 [45] clauses 10.2, 10.3, 10.4, 10.15, 10.16, the two paragraphs following the note in clause 10.17 and the first paragraph of 10.19. TS-103-285,section 10.2: Players shall support the usage of the track fragment run box ('trun') with negative composition offsets in order to maintain audio visual presentation synchronisation. Note: Negative composition offsets were added to ISO/IEC 14496-12:2008 in Amendment 3 ISO/IEC-14496-12,section 8.8.8: Track Fragment Run Box ... A track run documents a contiguous set of samples for a track. | |||
| org.hbbtv_MSE-LL0200 | 1 | MSE integration - throughput - XHR HD | When an application retrieves a sequence of VOD video and audio media segments of 960 ms duration using the XMLHttpRequest API from an https endpoint and the video bitrate is at least 11.5 Mbps and the total packaged data rate of audio and video does not exceed 12 Mbps and the segments are then appended to the MSE SourceBuffer following initialisation with an initialisation segment and played using an HTML5 media element whilst the application updates on-screen text and graphics every second, then once the media starts to play, playback continues without rebuffering, the rate of segment data arriving is not less than 12 Mbps and each update of the on-screen text and graphics is visible. | 2024-1 2023-3 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.13: Terminals shall support retrieval of media using either the XMLHttpRequest or Fetch APIs with sufficient performance to read the media and pass it to MSE SourceBuffer(s) at the minimum bitrates specified for adaptive bitrate streaming in clause 7.3.1.2, whilst maintaining acceptable application interaction performance. HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: * 12 Mb/s if the terminal does not support UHD video * 39 Mb/s if the terminal does support UHD video but does not support HFR video. * 51 Mb/s if the terminal supports UHD HFR video. TS-103-285,section 4.5: Segment duration shall be at least 960 ms, except for the last segment of a Period which may be shorter. WMAS,section 3.8: Devices MUST be conforming implementations of the following specifications: ... * XMLHttpRequest [XHR] | |||
| org.hbbtv_MSE-LL0210 | 1 | MSE integration - throughput - Fetch HD | When an application retrieves a sequence of VOD video and audio media segments of 960 ms duration using the Fetch API from an https endpoint and the video bitrate is at least 11.5 Mbps and the total packaged data rate of audio and video does not exceed 12 Mbps and the segments are then appended to the MSE SourceBuffer following initialisation with an initialisation segment and played using an HTML5 media element whilst the application updates on-screen text and graphics every second, then once the media starts to play, playback continues without rebuffering, the rate of segment data arriving is not less than 12 Mbps and each update of the on-screen text and graphics is visible. | 2024-1 2023-3 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.13: Terminals shall support retrieval of media using either the XMLHttpRequest or Fetch APIs with sufficient performance to read the media and pass it to MSE SourceBuffer(s) at the minimum bitrates specified for adaptive bitrate streaming in clause 7.3.1.2, whilst maintaining acceptable application interaction performance. HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: * 12 Mb/s if the terminal does not support UHD video. * 39 Mb/s if the terminal does support UHD video but does not support HFR video. * 51 Mb/s if the terminal supports UHD HFR video. TS-103-285,section 4.5: Segment duration shall be at least 960 ms, except for the last segment of a Period which may be shorter. WMAS,section 3.8: Devices MUST be conforming implementations of the following specifications: * Fetch [FETCH] | |||
| org.hbbtv_MSE-LL0220 | 1 | MSE integration - throughput - XHR UHD | When an application retrieves a sequence of VOD video and audio media segments of 960 ms duration using the XMLHttpRequest API from an https endpoint and the video bitrate is at least 38 Mbps and the total packaged data rate of audio and video does not exceed 39 Mbps and the segments are then appended to the MSE SourceBuffer following initialisation with an initialisation segment and played using an HTML5 media element whilst the application updates on-screen text and graphics every second, then once the media starts to play, playback continues without rebuffering, the rate of segment data arriving is not less than 39 Mbps and each update of the on-screen text and graphics is visible. | 2024-1 2023-3 2022-1 | HBBTV 1.6.1 | HBBTV,section 9.6.13: Terminals shall support retrieval of media using either the XMLHttpRequest or Fetch APIs with sufficient performance to read the media and pass it to MSE SourceBuffer(s) at the minimum bitrates specified for adaptive bitrate streaming in clause 7.3.1.2, whilst maintaining acceptable application interaction performance. HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: ... * 39 Mb/s if the terminal does support UHD video but does not support HFR video. TS-103-285,section 4.5: Segment duration shall be at least 960 ms, except for the last segment of a Period which may be shorter. WMAS,section 3.8: Devices MUST be conforming implementations of the following specifications: ... * XMLHttpRequest [XHR] | -DASH_HFR +HEVC_UHD | ||
| org.hbbtv_MSE-LL0230 | 1 | MSE integration - throughput - Fetch UHD | When an application retrieves a sequence of VOD video and audio media segments of 960 ms duration using the Fetch API from an https endpoint and the video bitrate is at least 38 Mbps and the total packaged data rate of audio and video does not exceed 39 Mbps and the segments are then appended to the MSE SourceBuffer following initialisation with an initialisation segment and played using an HTML5 media element whilst the application updates on-screen text and graphics every second, then once the media starts to play, playback continues without rebuffering, the rate of segment data arriving is not less than 39 Mbps and each update of the on-screen text and graphics is visible. | 2024-1 2023-3 2022-1 | HBBTV 1.6.1 | HBBTV,section 9.6.13: Terminals shall support retrieval of media using either the XMLHttpRequest or Fetch APIs with sufficient performance to read the media and pass it to MSE SourceBuffer(s) at the minimum bitrates specified for adaptive bitrate streaming in clause 7.3.1.2, whilst maintaining acceptable application interaction performance. HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: ... * 39 Mb/s if the terminal does support UHD video but does not support HFR video. TS-103-285,section 4.5: Segment duration shall be at least 960 ms, except for the last segment of a Period which may be shorter. WMAS,section 3.8: Devices MUST be conforming implementations of the following specifications: * Fetch [FETCH] | -DASH_HFR +HEVC_UHD | ||
| org.hbbtv_MSE-LL0240 | 1 | MSE integration - throughput - XHR UHD HFR | When an application retrieves a sequence of VOD video and audio media segments of 960 ms duration using the XMLHttpRequest API from an https endpoint and the video bitrate is at least 50 Mbps and the total packaged data rate of audio and video does not exceed 51 Mbps and the segments are then appended to the MSE SourceBuffer following initialisation with an initialisation segment and played using an HTML5 media element whilst the application updates on-screen text and graphics every second, then once the media starts to play, playback continues without rebuffering, the rate of segment data arriving is not less than 51 Mbps and each update of the on-screen text and graphics is visible. | 2024-1 2022-2 2022-1 | HBBTV 1.6.1 | HBBTV,section 9.6.13: Terminals shall support retrieval of media using either the XMLHttpRequest or Fetch APIs with sufficient performance to read the media and pass it to MSE SourceBuffer(s) at the minimum bitrates specified for adaptive bitrate streaming in clause 7.3.1.2, whilst maintaining acceptable application interaction performance. HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: ... * 51 Mb/s if the terminal supports UHD HFR video. TS-103-285,section 4.5: Segment duration shall be at least 960 ms, except for the last segment of a Period which may be shorter. WMAS,section 3.8: Devices MUST be conforming implementations of the following specifications: ... * XMLHttpRequest [XHR] | +DASH_HFR +HEVC_UHD | ||
| org.hbbtv_MSE-LL0250 | 1 | MSE integration - throughput - Fetch UHD HFR | When an application retrieves a sequence of VOD video and audio media segments of 960 ms duration using the Fetch API from an https endpoint and the video bitrate is at least 50 Mbps and the total packaged data rate of audio and video does not exceed 51 Mbps and the segments are then appended to the MSE SourceBuffer following initialisation with an initialisation segment and played using an HTML5 media element whilst the application updates on-screen text and graphics every second, then once the media starts to play, playback continues without rebuffering, the rate of segment data arriving is not less than 51 Mbps and each update of the on-screen text and graphics is visible. | 2024-1 2022-2 2022-1 | HBBTV 1.6.1 | HBBTV,section 9.6.13: Terminals shall support retrieval of media using either the XMLHttpRequest or Fetch APIs with sufficient performance to read the media and pass it to MSE SourceBuffer(s) at the minimum bitrates specified for adaptive bitrate streaming in clause 7.3.1.2, whilst maintaining acceptable application interaction performance. HBBTV,section 7.3.1.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: ... * 51 Mb/s if the terminal supports UHD HFR video. TS-103-285,section 4.5: Segment duration shall be at least 960 ms, except for the last segment of a Period which may be shorter. WMAS,section 3.8: Devices MUST be conforming implementations of the following specifications: * Fetch [FETCH] | +DASH_HFR +HEVC_UHD | ||
| org.hbbtv_MSE-LL0300 | 1 | MSE integration - SourceBuffer size - audio | After a sequence of audio segments totaling 2 Mbytes have been appended to an MSE SourceBuffer, the 'buffered' attribute of the SourceBuffer includes a time range that completely covers the time period of audio data appended and when the content is played without further data being appended, the full time period of audio data appended plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.13: MSE SourceBuffers shall be able to accept at least the following quantities of data without invoking the coded frame removal algorithm: For audio: 2 Mbyte ... When content that has been delivered through MSE is played from the beginning to the end, the first and last frame of video shall be visible and the audio corresponding to the period from the start of the first video frame to the end of the last video frame shall be audible. MSE,section 3.5.10: Coded Frame Eviction Algorithm This algorithm is run to free up space in this source buffer when new data is appended. ... NOTE: ... The web application can use the buffered attribute to observe whether portions of the buffered data have been evicted. ... For each range in removal ranges, run the coded frame removal algorithm with start and end equal to the removal range start and end timestamp respectively. MSE,section 3.1: buffered of type TimeRanges, readonly Indicates what TimeRanges are buffered in the SourceBuffer. | |||
| org.hbbtv_MSE-LL0310 | 1 | MSE integration - SourceBuffer size - HD video | After a sequence of audio segments totaling 2 Mbytes have been appended to an MSE SourceBuffer, and a sequence of video segments totaling 24 Mbytes have been appended to a second MSE SourceBuffer, and the audio data represents a duration no shorter than the video, then the 'buffered' attribute of the audio SourceBuffer includes a time range that completely covers the time period of audio data appended and the 'buffered' attribute of the video SourceBuffer includes a time range that completely covers the time period of video data appended and when the content is played without further data being appended, the full time period of video data appended plays, with accompanying audio. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.13: MSE SourceBuffers shall be able to accept at least the following quantities of data without invoking the coded frame removal algorithm: For audio: 2 Mbyte and for video: 24 Mbytes if the terminal does not support UHD video ... When content that has been delivered through MSE is played from the beginning to the end, the first and last frame of video shall be visible and the audio corresponding to the period from the start of the first video frame to the end of the last video frame shall be audible. MSE,section 3.5.10: Coded Frame Eviction Algorithm This algorithm is run to free up space in this source buffer when new data is appended. ... NOTE: ... The web application can use the buffered attribute to observe whether portions of the buffered data have been evicted. ... For each range in removal ranges, run the coded frame removal algorithm with start and end equal to the removal range start and end timestamp respectively. MSE,section 3.1: buffered of type TimeRanges, readonly Indicates what TimeRanges are buffered in the SourceBuffer. | -HEVC_UHD | ||
| org.hbbtv_MSE-LL0400 | 1 | MSE integration - start-up time - initial | When an HTML5 video element that is not paused references MSE and valid initialisation segments have been appended to audio and video SourceBuffers, and the media element has not previously decoded any media, then once a sequence of complete video and audio CMAF chunks are appended to the SourceBuffers, starting from a random access point and extending 500ms beyond it, then playback starts within one second of the time when chunks have been appended that extend to 500ms for both video and audio. | 2024-1 2023-3 2023-2 2021-2 | HBBTV 1.6.1 | HBBTV,section 9.6.13: The following table defines start-up time requirements that apply to media elements whose source is MSE. The required start-up time depends on whether the media element has previously decoded any media since having any necessary hardware resources allocated to it (see clause 9.6.2). In each case, the start-up time requirement applies once all of the following conditions become have become true: * A valid initialisation segment has been appended to the SourceBuffer. * One or more CMAF Chunks have been appended to the SourceBuffer(s) covering at least the period from the current playback position to a point 500ms ahead. * There is a random access point at the current playback position. * The media element is not paused. Context: The media element has not previously decoded any media since having any necessary hardware resources allocated to it (e.g. when starting playback of a new stream) Requirement: Playback shall begin within 1 second. | |||
| org.hbbtv_MSE-LL0410 | 1 | MSE integration - start-up time - subsequent | When an HTML5 video element that is not paused references MSE and valid initialisation segments have been appended to audio and video SourceBuffers, and the media element has previously decoded media from the same stream and no action has occured that would take away decoder resources, then once a sequence of complete video and audio CMAF chunks are appended to the SourceBuffers, starting from a random access point at a new play position and extending 500ms beyond it, then playback starts within 250ms of the time when chunks have been appended that extend to 500ms for both video and audio. | 2024-1 2023-3 2023-2 2023-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.13: The following table defines start-up time requirements that apply to media elements whose source is MSE. The required start-up time depends on whether the media element has previously decoded any media since having any necessary hardware resources allocated to it (see clause 9.6.2). In each case, the start-up time requirement applies once all of the following conditions become have become true: * A valid initialisation segment has been appended to the SourceBuffer. * One or more CMAF Chunks have been appended to the SourceBuffer(s) covering at least the period from the current playback position to a point 500ms ahead. * There is a random access point at the current playback position. * The media element is not paused. Context: The media element has already decoded some content and retains its necessary hardware resources (e.g. when seeking within a stream) Requirement: Playback shall begin within 250ms. | |||
| org.hbbtv_MSE-LL0500 | 1 | MSE integration - isTypeSupported is accurate | For each audio_profile of type "audio/mp4" or video_profile element of type "video/mp4" that is included in the HbbTV specification, where the terminal lists that profile in the XML capabilities document with transport="dash", the terminal responds true to MediaSource.isTypeSupported for a range of MIME type strings that describe codecs, profiles and levels that are necessary to decode that audio_profile or video_profile and where the terminal either (i) does not list that profile in the XML capabilities document at all or (ii) lists that profile in the XML capabilities document but not with transport="dash", the terminal responds false to MediaSource.isTypeSupported for the MIME type string that describes the most demanding codec, profile and level that the profile would require. | 2024-1 2023-3 2023-2 2023-1 2022-2 2022-1 | HBBTV 1.6.1 | HBBTV,section 9.6.13: Terminals that support any video or audio codec for native playback of MPEG DASH content shall support that codec with MSE, with the same codec profiles and capabilities. Implementations shall support inband parameter sets (e.g. 'avc3' or 'hev1' sample entry type) as required by DVB DASH clauses 5.1.2 and 5.2.1. ... MediaSource.isTypeSupported shall truthfully reflect the terminal capabilities. Specifically, where the type passed to isTypeSupported includes codec information (e.g. video codec profile and level information, or audio object type information) terminals shall return true if the codec capabilities described by the codec information are fully supported and false if they are not. TS-103-285,section 5.1.2: Players which support H.264 shall support both sample entries using 'avc1' and 'avc3' (both storage for SPS/PPS within the initialization segment or inband within the media segment). TS-103-285,section 5.2.1: Players which support HEVC shall support both sample entries using 'hvc1' and 'hev1' (both storage for VPS/SPS/PPS within the initialization segment or inband within the media segment). | |||
| org.hbbtv_MSE-LL0610 | 1 | MSE integration - AC4 Preselection selection | When AC4 audio that includes multiple preselections is written to an MSE SourceBuffer and played using an HTML5 video element, and exactly one of the preselections that is not the first matches the terminal user preferences for language and audio description, then the matching preselection is heard. | 2024-1 | HBBTV 1.6.1 | 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]: ... 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. | +AC4 | ||
| org.hbbtv_MSE-LL0700 | 1 | MSE integration - EME ClearKey | An application sets a video element to reference MSE and encrypted content is appended to a SourceBuffer such that it can be decrypted using the Clear Key system and then the application calls the play method. In the callback of the 'message' event, the application is asked for the key to decrypt the content and after providing the correct key to the update method, the content is successfully decrypted and presented. | 2024-1 2023-3 2023-1 | HBBTV 1.6.1 | HBBTV,section B.3: The "Clear Key" key system defined in clause 9.1 of the EME specification referenced from [76] shall be supported for content delivered by MPEG DASH (see clause E of the present document) and content from a MediaSource object. EME,section 9.1: The "org.w3.clearkey" Key System uses plain-text clear (unencrypted) key(s) to decrypt the source. No additional client-side content protection is required. This Key System is described below. EME,section 13.1: Source and Key Known at Page Load (Clear Key) In this simple example, the source file and clear-text license are hard-coded in the page. | |||
| org.hbbtv_MSE-LL0810 | 1 | MSE integration - seek to a point other than a RAP - seek time with less than 40% non reference frames | For a 704x396 50Hz video track encoded using H.264/AVC High Profile Level 4.0, when video and AAC audio are playing and a portion of the tracks away from the current playback position starting from a random access point to at least 2.9 seconds beyond it have been written to MSE SourceBuffers, and the region of the video track from the random access point to 2.4 seconds beyond it contains less than 40% non-reference frames, then a seek to a position 2.4 seconds beyond the random access point completes within 1 450 ms with video playing smoothly starting at the seek point and with accompanying audio. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.1.3: Table 11a: Requirements on seek accuracy ... Content sourced via MSE|Seeks shall be performed precisely. Where video content is such that it can be decoded at a rate of 2.0 or more without exceeding the constraints of the codec profile and level described in the Initialization Segment, the following shall apply: * Terminals shall be able to identify the nearest preceding random access point and decode from there up to the requested position at the rates specified in clause 10.20.7.3 of ETSI TS 103 285 [45], selected based on the multiple of normal play speed that would not exceed the codec profile and level constraints. * The seek operation shall be completed no later than 250 ms after the seek duration implied by the required decode rate, provided that sufficient data is present in the SourceBuffers to begin playback from the new position ... For example, a 704x396 50Hz video track encoded using H.264/AVC can ... A seek into such a track to a point that is 2.4 seconds beyond a random access point would be required to complete within 2400/3.3 + 250 = 977 ms if it contains more than 40% non-reference frames or 2400/2 + 250 = 1 450 ms if it does not. HBBTV,section 9.6.13: The following table defines start-up time requirements that apply to media elements whose source is MSE. ... In each case, the start-up time requirement applies once all of the following conditions become have become true: * One or more CMAF Chunks have been appended to the SourceBuffer(s) covering at least the period from the current playback position to a point 500ms ahead. TS-103-285,section 10.20.7.3: For the purposes of random access, low latency players shall be able to decode video content at the speeds indicated in Table 33. Table 33: Decoding performance requirements @maxPlayoutRate | Proportion of non-reference frames | Minimum required decoding speed >= 2.0 | Any | 2x >= 3.0 | >40% | 3x >= 4.0 | >40% | 3.3x ISO/IEC-14496-10,section A.3.1: Table A-1 - Level limits Level number | Max macroblock processing rate | ... | Max video bit rate MaxBR 1000bits/s | ... 4 | 245760 | ... | 20 000 | ... ISO/IEC-14496-10,section 3.77: macroblock: A 16x16 block of luma samples and ... ISO/IEC-14496-10,section 3.95: non-reference frame: A frame coded with nal_ref_idc equal to 0. | |||
| org.hbbtv_MSE-LL0820 | 1 | MSE integration - seek to a point other than a RAP - seek time with over 40% non reference frames | For a 704x396 50Hz video track encoded using H.264/AVC High Profile Level 4.0, when video and AAC audio are playing and a portion of the tracks away from the current playback position starting from a random access point to at least 2.9 seconds beyond it have been written to MSE SourceBuffers, and the region of the video track from the random access point to 2.4 seconds beyond it contains more than 40% non-reference frames, then a seek to a position 2.4 seconds beyond the random access point completes within 977 ms with video playing smoothly starting at the seek point and with accompanying audio. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.1.3: Table 11a: Requirements on seek accuracy ... Content sourced via MSE|Seeks shall be performed precisely. Where video content is such that it can be decoded at a rate of 2.0 or more without exceeding the constraints of the codec profile and level described in the Initialization Segment, the following shall apply: * Terminals shall be able to identify the nearest preceding random access point and decode from there up to the requested position at the rates specified in clause 10.20.7.3 of ETSI TS 103 285 [45], selected based on the multiple of normal play speed that would not exceed the codec profile and level constraints. * The seek operation shall be completed no later than 250 ms after the seek duration implied by the required decode rate, provided that sufficient data is present in the SourceBuffers to begin playback from the new position ... For example, a 704x396 50Hz video track encoded using H.264/AVC can ... A seek into such a track to a point that is 2.4 seconds beyond a random access point would be required to complete within 2400/3.3 + 250 = 977 ms if it contains more than 40% non-reference frames or 2400/2 + 250 = 1 450 ms if it does not. HBBTV,section 9.6.13: The following table defines start-up time requirements that apply to media elements whose source is MSE. ... In each case, the start-up time requirement applies once all of the following conditions become have become true: * One or more CMAF Chunks have been appended to the SourceBuffer(s) covering at least the period from the current playback position to a point 500ms ahead. TS-103-285,section 10.20.7.3: For the purposes of random access, low latency players shall be able to decode video content at the speeds indicated in Table 33. Table 33: Decoding performance requirements @maxPlayoutRate | Proportion of non-reference frames | Minimum required decoding speed >= 2.0 | Any | 2x >= 3.0 | >40% | 3x >= 4.0 | >40% | 3.3x ISO/IEC-14496-10,section A.3.1: Table A-1 - Level limits Level number | Max macroblock processing rate | ... | Max video bit rate MaxBR 1000bits/s | ... 4 | 245760 | ... | 20 000 | ... ISO/IEC-14496-10,section 3.77: macroblock: A 16x16 block of luma samples and ... ISO/IEC-14496-10,section 3.95: non-reference frame: A frame coded with nal_ref_idc equal to 0. | |||
| org.hbbtv_MSE-LL0900 | 1 | Capability discovery - audio output - stereo only | The terminal XML capabilities document either does not contain an audio_system element or it contains an audio_system element with audio_output_format="stereo" or audio_output_format="multichannel-preferred". | 2024-1 2023-3 2023-2 2022-2 2022-1 2021-3 2021-2 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.4.7: Terminals that can output multi-channel audio shall include an element of the following form to describe current audio output capabilities of the terminal: <audio_system audio_output_format="audio-type"/> ... "stereo" – the terminal and any connected devices known to it only have active stereo audio outputs; any multi-channel audio sources will be downmixed. An expertly mixed stereo audio source can be expected to give a better audio experience than a multi-channel source, which the terminal would just downmix to stereo. ... "multichannel-preferred" – the conditions for “multichannel” do not apply but the terminal believes that it can produce a better audio experience if the application provides a multi-channel audio source than if the application provides an expertly mixed stereo source. | -HAS_MULTI_CHANNEL_SPEAKERS | ||
| org.hbbtv_MSE-LL0910 | 1 | Capability discovery - audio output - multichannel | The terminal XML capabilities document contains an audio_system element with audio_output_format="multichannel". | 2024-1 2023-3 2023-2 2022-2 2022-1 | HBBTV 1.6.1 | HBBTV,section 10.2.4.7: Terminals that can output multi-channel audio shall include an element of the following form to describe current audio output capabilities of the terminal: <audio_system audio_output_format="audio-type"/> ... "multichannel" – the terminal has one or more active multi-channel audio outputs and multi-channel audio is enabled by terminal settings; multi-channel audio sources should be heard without downmixing to stereo. The terminal may be outputting multi-channel audio directly or sending it to an external device which supports the format. | |||
| org.hbbtv_MSE-LL0920 | 1 | Capability discovery - variable speed playback | If the terminal XML capabilities document contains an html5_media_variable_rate element, then when any content is played using an HTML5 media element, when playbackRate is changed in turn to the three values min, (min+max)/2 and max, where min and max are the values of the corresponding attributes from the html5_media_variable_rate element, then in each case the media timeline advances at a rate that is within +/- 5% of the requested rate and the audio plays at the original pitch. | 2024-1 2023-3 2023-2 2023-1 | HBBTV 1.6.1 | HBBTV,section 10.2.4.7: Where terminals support forward playback using an HTML5 media element with a playbackRate other than 1.0 when using a MediaSource object in a manner such that (a) the requested playback speed is achieved to within +/- 5% of the value of playbackRate and (b) within a certain range of playbackRate there is no change to the pitch of any audio that is present, an element of the following form shall be included: <html5_media_variable_rate min=”rate” max=”rate”/> where the min and max attributes values describe the positive range of playbackRate under which the above conditions (a) and (b) will be met, provided that the video and audio is such that it can remain within the profile and level constraints of the terminal’s decoder. | |||
| org.hbbtv_MSE-LL1000 | 1 | System performance | When an application incorporates an unmodified release of dash.js that supports low latency playback, and the player is requested to present a valid DVB DASH low latency stream in low latency mode, the content plays. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 | HBBTV,section 9.6.13: Terminals shall be able to play low-latency DASH content using JavaScript DASH players. * Testing Requirements: The above requirement shall be tested using unmodified releases of JavaScript DASH players that are widely deployed. Testing should include provision for errors in a DASH player that are only apparent on some terminal implementations and not others. | |||
| org.hbbtv_MSR09010 | 1 | "application/oipfSearchManager" implements API functions: "createSearch", "getChannelConfig". | "application/oipfSearchManager" object implements API functions: "createSearch", "getChannelConfig". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.1: The application/oipfSearchManager embedded object | |||
| org.hbbtv_MSR09020 | 1 | Calling the getChannelConfig function on "application/oipfSearchManager" and "video/broadcast" embedded objects return identical objects. | Content of ChannelConfig objects returned by getChannelConfig function of "application/oipfSearchManager" and "video/broadcast" are compared. All properties, especially channels in channelList shall be identical. All included channel parameters: channelType, ccid, dsd, onid, tsid, sid and name are considered. | 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: Detailed section by section definition OIPF-DAE,section 7.12.1: The application/oipfSearchManager embedded object OIPF-DAE,section 7.13.1: The video/broadcast embedded object OIPF-DAE,section 7.13.9: The ChannelConfig class | |||
| org.hbbtv_MSR09030 | 3 | Function "createSearch(1)" of "application/oipfSearchManager" embedded object returns MetadataSearch type object. | Function "createSearch(1)" of "application/oipfSearchManager" embedded object returns object which implements MetadataSearch class API methods: createQuery, setQuery, addChannelConstraint and findProgrammesFromStream, properties: searchTarget=1 and result. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.1.2: MetadataSearch createSearch(Integer searchTarget) OIPF-DAE,section 7.12.2: The MetadataSearch class | |||
| org.hbbtv_MSR09060 | 1 | onMetadataSearch callback shall be called with correct parameters. | After calling getResults() method of application/oipfSearchManager object the onMetadataSearch callback shall be run with two parameters: first "MetadataSearch" type object, second Integer. MetadataSearch object contains following properties: searchTarget, result, setQuery, addChannelConstraint, createQuery and findProgrammesFromStream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.1.1: Due to the nature of metadata queries, searches are asynchronous and events are used to notify the application that results are available. MetadataSearch events SHALL be targeted at the application/oipfSearchManager object. | |||
| org.hbbtv_MSR09061 | 1 | onMetadataSearch callback shall be called asynchronously. | After calling getResults() method of application/oipfSearchManager object, the onMetadataSearch callback shall be run asynchronously. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.1.1: Due to the nature of metadata queries, searches are asynchronous and events are used to notify the application that results are available. MetadataSearch events SHALL be targeted at the application/oipfSearchManager object. | |||
| org.hbbtv_MSR09062 | 1 | When search is finished, onMetadataSearch callback with argument state=0 is called. | When search is finished, onMetadataSearch(state=0,...) callback shall be run. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2: When all requested results have been found, the terminal SHALL dispatch a MetadataSearchevent with status=0. | |||
| org.hbbtv_MSR09064 | 1 | When search is finished, the state argument of event object send to MetadataSearch listener is equal 0. | The MetadataSearch Event interface object sent to the listener after terminal finishes search shall contain the property state equal to 0. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2: When all requested results have been found, the terminal SHALL dispatch a MetadataSearchevent with status=0. | |||
| org.hbbtv_MSR09065 | 1 | DOM2 'MetadataSearch' listener shall be called with correct event parameter. | After calling the getResults method of the application/oipfSearchManager object, the DOM2 'MetadataSearch' event listener shall be called. The Event interface object sent to the listener shall contain properties: 'bubbles' equal 'false', 'cancelable' equal 'false', number 'state' and 'search' - an instance of the MetadataSearch class containing following properties and methods: 'searchTarget', 'result', 'setQuery', 'addChannelConstraint', 'createQuery' and 'findProgrammesFromStream'. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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.12.1.1: Due to the nature of metadata queries, searches are asynchronous and events are used to notify the application that results are available. MetadataSearch events SHALL be targeted at the application/oipfSearchManagerobject. | ||
| org.hbbtv_MSR09066 | 1 | DOM2 'MetadataSearch' listener shall be dispatched asynchronously. | After call of getResults method of the application/oipfSearchManager object the DOM2 event listener method shall be dispatched asynchronously. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.1.1: Due to the nature of metadata queries, searches are asynchronous and events are used to notify the application that results are available. MetadataSearch events SHALL be targeted at the application/oipfSearchManager object. | |||
| org.hbbtv_MSR09067 | 1 | MetadataSearch results are based on the updated metadata, if EIT table changes. | After performing a search, if the EIT table changes, getResults() shall eventually get results based on the updated metadata. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2: The data exposed via the SearchResults.item() method is static and never changes as a result of any updates to the underlying metadata database until SearchResults.getResults()is next called. | |||
| org.hbbtv_MSR09068 | 1 | Update of metadata due to EIT table changes shall not affect on the data exposed via the SearchResult.item() of MetadataSearch. | After search performing, if EIT table is updated, objects returned by SearchResult.item() shall not change. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2: The data exposed via the SearchResults.item() method is static and never changes as a result of any updates to the underlying metadata database until SearchResults.getResults()is next called. | |||
| org.hbbtv_MSR09080 | 1 | "SearchResults" type object implements API functions: "item", "getResults", "abort". | "SearchResults" type object implements API functions: "item", "getResults", "abort". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.4.2: The SearchResults class methods. | |||
| org.hbbtv_MSR09081 | 1 | Array notation of SearchResults. | Access to i-th element of currently available results shall be realized by 'result[i]', where i = 0, 1, ..., result.length - 1. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.4: In addition to the properties and methods defined below a SearchResultsobject SHALL support the array notation to access the results in this collection. | |||
| org.hbbtv_MSR09090 | 1 | "offset" argument of getResults(offset,....) shift result set. | The result collection retrieved by call of getResults(offset,...) method shall be correctly shifted by value of offset parameter. | 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: all search results shall be returned ordered first by channel, in the same order as presented to applications through a ChannelList object, then by start time in ascending order. OIPF-DAE,section 7.12.4.1: readonly Integer offset - The current offset into the total result set. | |||
| org.hbbtv_MSR09091 | 1 | Subsequent calls of getResults() method retrieves specified subset of items. | When getResults() is called with its 'offset' and 'count' parameters specified to fetch a subset of programmes within the expected results, and is then called again to fetch the rest of the programmes after the subset in the previous search; both calls to getResults() shall retrieve the expected results. | 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: Detailed section by section definition OIPF-DAE,section 7.12.4.1: getResults Perform the search and retrieve the specified subset of the items that match the query. | |||
| org.hbbtv_MSR09092 | 1 | 'offset' parameter of result property. | After each call of getResults(offset,...), the 'offset' parameter of the result property shall be set correctly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.4.1: getResults Perform the search and retrieve the specified subset of the items that match the query. | |||
| org.hbbtv_MSR09093 | 1 | 'totalSize' parameter is not altered after subsequent calls of getResults(). | When getResults(offset, count) is called subsequently, the totalSize parameter of the result property shall stay unchanged. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.4.1: getResults Perform the search and retrieve the specified subset of the items that match the query. | |||
| org.hbbtv_MSR09100 | 1 | Result property of MetadataSearch class shall be empty until getResults() is used. | result property, until "getResults()" is used, shall have: length = 0, totalSize = 0. Call item() shall return undefined. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.9.2: The MetadataSearch class OIPF-DAE,section 7.12.4: The set of results SHALL only be valid if a call to getResults() has been made. If this method has not been called, the set of results SHALL be empty (i.e. the value of the totalSize property SHALL be 0 and calls to item() SHALL return undefined). | |||
| org.hbbtv_MSR09130 | 1 | Value of "totalSize" property of "SearchResults" type object is equal to number of results found by MetadataSearch. | When the getResults() method has been called, specifying a sub-set of the expected results; the 'totalSize' property of the resulting SearchResults object shall be equal to the total number of programmes matching the query. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.4.1: readonly Integer totalSize - The total number of items in the result set | |||
| org.hbbtv_MSR09210 | 3 | Terminal correctly implements comparison type '0' in Metadata APIs for "Programme.name" parameter. | MetadataSearch queries launched for compare field: 'Programme.name' with comparison type=0 (True if the specified value is equal to the value of the specified field) shall return correct set of programmes. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2.2: 0 - True if the specified value is equal to the value of the specified field. | |||
| org.hbbtv_MSR092101 | 3 | Terminal correctly implements comparison type '0' in Metadata APIs for "Programme.startTime" parameter. | MetadataSearch queries launched for compare field: 'Programme.startTime' with comparison type=0 (True if the specified value is equal to the value of the specified field) shall return correct set of programmes. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2.2: 0 - True if the specified value is equal to the value of the specified field. | |||
| org.hbbtv_MSR092102 | 3 | Terminal correctly implements comparison type '0' in Metadata APIs for "Programme.programmeID" parameter. | MetadataSearch queries launched for compare field: 'Programme.programmeID' with comparison type=0 (True if the specified value is equal to the value of the specified field) shall return correct set of programmes. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2.2: 0 - True if the specified value is equal to the value of the specified field. | |||
| org.hbbtv_MSR09211 | 3 | Terminal correctly implements comparison type '1' in Metadata APIs for "Programme.name" parameter. | MetadataSearch queries launched for compare field 'Programme.name', with comparison type=1 (True if the specified value is not equal to the value of the specified field) shall return correct set of programmes. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2.2: 1 - True if the specified value is not equal to the value of the specified field. | |||
| org.hbbtv_MSR092111 | 1 | Terminal correctly implements comparison type '1' in Metadata APIs for "Programme.startTime" parameter. | MetadataSearch queries launched for compare field 'Programme.startTime' with comparison type=1 (True if the specified value is not equal to the value of the specified field) shall return correct set of programmes. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2.2: 1 - True if the specified value is not equal to the value of the specified field. | |||
| org.hbbtv_MSR092112 | 1 | Terminal correctly implements comparison type '1' in Metadata APIs for "Programme.programmeID" parameter. | MetadataSearch queries launched for compare field 'Programme.programmeID' with comparison type=1 (True if the specified value is not equal to the value of the specified field) shall return correct set of programmes. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2.2: 1 - True if the specified value is not equal to the value of the specified field. | |||
| org.hbbtv_MSR09216 | 3 | Terminal correctly implements comparison type '6' for compare field 'Programme.name' in Metadata APIs. | MetadataSearch queries launched for compare field: 'Programme.name' with comparison type=6 (True if the string value of the specified field contains the specified value) shall return correct set of programmes. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2.2: 6 - True if the string value of the specified field contains the specified value | |||
| org.hbbtv_MSR092162 | 1 | Comparison type '6' for compare field: 'Programme.name' shall be case-insensitive. | MetadataSearch queries launched for compare field: 'Programme.name', with comparison type=6 (True if the string value of the specified field contains the specified value) shall be case-insensitive. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-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.12.2.2: 6 - True if the string value of the specified field contains the specified value. This operation SHALL be case insensitive. | ||
| org.hbbtv_MSR09217 | 1 | setQuery - remove existing query. | If a search is performed on a MetadataSearch object using a Query object (Query A), and while the MetadataSearch object is in the 'found' state a 2nd search is performed using a new Query object (Query B) that matches different programmes and a sub-set of the programmes matched by Query A. The terminal shall only retrieve programmes that match Query B and Query A shall not affect the results. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 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.12.2.2: Set the query terms to be used for this search, discarding any previously-set query terms. | ||
| org.hbbtv_MSR09240 | 1 | Search manager shall be able to perform two independent searches. | When two queries that match 2 distinct sets of results are assigned to two MetadataSearch objects using the setQuery() method, and results are obtained for each in turn; the SearchResult object associated with each MetadataSearch object shall contain the expected results. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 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.12.2.2: void setQuery( Query query ) Set the query terms to be used for this search, discarding any previously-set query terms. | ||
| org.hbbtv_MSR09241 | 1 | Two independent searches with different channel constraints. | Two MetadataSearch objects are instantiated, each object is given different channel constraints that will give two distinct sets of results with the following Query objects: Both Query objects are created using the createQuery() method of their respective MetadataSearch objects, and in each case, createQuery() is given identical parameters; after the search is performed the SearchResult object associated with each MetadataSearch object shall contain the expected results. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-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.12.2.2: Constrain the search to only include results from the specified channel. | ||
| org.hbbtv_MSR09242 | 1 | Channel constraints shall be removed on given search object only. | Two MetadataSearch objects are instantiated, each object is given the same channel constraints that will affect the expected results matched by the following Query objects: Both Query objects are created using the createQuery() method of the two MetadataSearch objects, and in each case, createQuery() is given identical parameters. When the channel constraints are removed from one of the MetadataSearch objects and the search is performed on each MetadataSearch object in turn, the SearchResult object associated with each MetadataSearch object shall contain the expected results. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-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.12.2.2: Constrain the search to only include results from the specified channel. | ||
| org.hbbtv_MSR09243 | 1 | Two independent "findProgrammesFromStream()" searches. | When 2 MetadataSearch objects are instantiated, and findProgrammesFromStream() is called on each with different parameters specified that will return different sets of results; when the search is performed on each in turn, the SearchResult object associated with each MetadataSearch object shall contain the expected results. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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.12.2.2: void findProgrammesFromStream : Set a query and constraints for retrieving metadata for programmes from a given channel and given start time from metadata contained in the stream as defined in section. | ||
| org.hbbtv_MSR09250 | 3 | Subsequent calls to addChannelConstraint SHALL add the specified channel to the list of channels from which results should be returned in Metadata API. | Two calls of addChannelConstraint(Channel) for different channels shall limit search results to programmes on those channels. | 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: Detailed section by section definition OIPF-DAE,section 7.12.2.2: Constrain the search to only include results from the specified channel. If a channel constraint has already been set, subsequent calls to addChannelConstraint() SHALL add the specified channel to the list of channels from which results should be returned. | |||
| org.hbbtv_MSR09260 | 1 | findProgrammesFromStream(currentChannel, startTime,...) of Metadata API shall retrieve programme showing at the startTime on current channel. | findProgrammesFromStream(currentChannel, startTime,...) shall retrieve programme, which starts before startTime and is showing at the startTime. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2.2: The start time is inclusive; any programmes starting at the start time, or which are showing at the start time, will be included in the search results. | |||
| org.hbbtv_MSR09262 | 1 | findProgrammesFromStream() removes channel constraints. | When calling findProgrammesFromStream() on the MetadataSearch object, the existing channel constraints shall be removed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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.12.2.2: 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_MSR09263 | 1 | findProgrammesFromStream(Channel, startTime,...) of Metadata API shall retrieve programme showing at the startTime from given (not current) Channel. | findProgrammesFromStream (Channel, startTime,...) shall retrieve programme, which starts before startTime and is showing at the startTime. Channel parameter does not refer to the currentChannel. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2.2: The start time is inclusive; any programmes starting at the start time, or which are showing at the start time, will be included in the search results. | |||
| org.hbbtv_MSR09270 | 3 | The "and()" method of query object performs the logical AND operation on queries. | The MetadataSearch object shall be able to combine two queries using AND boolean logic when the and() method is called on a Query object, specifying a second Query object as its argument. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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.12.3: and() Create a query based on the logical AND of the predicates represented by the current query and the argument query | ||
| org.hbbtv_MSR09280 | 3 | The "or()" method of query object performes the logical OR operation on queries. | The MetadataSearch object shall be able to combine two queries using OR boolean logic when the or() method is called on a Query object, specifiying a second Query object as its argument. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.3: Query or( Query query ) ... Create a query based on the logical OR of the predicates represented by the current query and the argument query. | |||
| org.hbbtv_MSR09290 | 3 | The "not" method of query object creates a query based on the logical NOT operation. | The logical NOT operation on query shall be realized by "not()" method of given Query type object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.3: not()... Create a new query that is the logical negation of the current query. | |||
| org.hbbtv_MSR09295 | 1 | Complex queries using the Metadata API "not" "and" and "or" method of query object are supported. | A complex query using the and(), or() and not() methods available on the Query object can be created and when set to the MetadataSearch object, shall produce the expected results. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.3: The Query class represents a metadata query that the user wants to carry out. This may be a simple search, or a complex search involving Boolean logic. | |||
| org.hbbtv_MSR09300 | 1 | All search results of MetadataSearch type object shall be returned ordered first by channel, in the same order as presented to applications through a ChannelList object, then by start time in ascending order. | All search results of MetadataSearch type object shall be returned ordered first by channel, in the same order as presented to applications through a ChannelList object, then by start time in ascending order. | 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: The orderBy method is not included - all search results shall be returned ordered first by channel, in the same order as presented to applications through a ChannelList object, then by start time in ascending order. | |||
| org.hbbtv_MSR09310 | 3 | Metadata APIs channel constraint is removed by addChannelConstraint(null) call. | addChannelConstraint(null) shall remove constraint set by call addChannelConstraint(Channel). | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2.2: If the value of this [addChannelConstraint] argument is null, any existing channel constraint SHALL be removed. | |||
| org.hbbtv_MSR09510 | 1 | MetadataSearch: Idle state after channel constraint adding. | When constraints are added; the 'length' and totalSize parameters of the SearchResults object shall be equal to 0; calling item() with the 'index' parameter specified as 0 shall return undefined, the 0th element of SearchResults array shall be undefined. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2: 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 MetadataSearchevent with status=3. | |||
| org.hbbtv_MSR09530 | 1 | getResults(.., count): results limited to count. | Achieved length of search results collection shall be equal to the 'count' parameter of the getResults(..., count) method. The total number of programmes which matches to the query is greater than the count value. | 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: Detailed section by section definition OIPF-DAE,section 7.12.2: The receiver acquires some or all of the items that match the specified query and constraints, and caches the requested subset of the results. OIPF-DAE,section 7.12.4: count - The number of results to retrieve. | |||
| org.hbbtv_MSTRSYNC0010 | 1 | MSTRSYNC deactivate broadcast audio in favor of broadband audio | When an application uses multi-stream sync with a broadcast service and a broadband stream where each stream has one audio and the application has unselected the broadcast audio before starting the multistream sync, the terminal shall not present the broadcast audio but it shall present the broadband audio after the synched presentation started. | 2024-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.8.1: The HbbTV application may use an API to select components from the input streams as defined by the APIs profiled in Annex A. HBBTV,section 10.2.7.3: Applications may change the terminal-derived component selection and discover the presentation status using the methods defined in clause 7.16.5 of OIPF DAE [1] and in clauses 4.7.10.10.1 and 4.7.10.12.5 of HTML5 [54]. HBBTV,section 8.2.3.2.2: Methods | void initMediaSynchroniser(...) | Initialises a MediaSynchroniser for multi-stream synchronisation and for inter-device synchronisation as a master terminal. Methods | void addMediaObject(...) | Adds a media object, i.e. video/broadcast object, AV Control object or HTML5 media object, to the MediaSynchroniser. OIPF-DAE,section 7.14.4: To support the selection of specific A/V components for playback (e.g. a specific subtitle language, audio language, or camera angle), the classes defined in sections 7.16.5.2 – 7.16.5.5 SHALL be supported and the constants, properties and methods defined in section 7.16.5.1 SHALL be supported on the video/broadcast object. OIPF-DAE,section 7.16.5.1.3: Methods | 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. Methods | void unselectComponent(AVComponent component) | Stop rendering of the specified component of the stream. HTML5,section 4.7.10.10.1: The audioTracks attribute of a media element must return a live AudioTrackList object representing the audio tracks available in the media element's media resource. ... An AudioTrackList object represents a dynamic list of zero or more audio tracks, of which zero or more can be enabled at a time. Each audio track is represented by an AudioTrack object. ... audioTrack.enabled [ = value ]. Returns true if the given track is active, and false otherwise. Can be set, to change whether the track is enabled or not. | |||
| org.hbbtv_MSTRSYNC0100 | 1 | MSTRSYNC of BC-TS/TEMI V with DASH A - no tolerance, no correlation timestamps needed | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state as the master media using and selecting a TEMI timeline that ticks with 50 ticks per second and is located in the adaption header of TS packets carrying the video elementary stream. After that an HTML5 media element associated with a DASH stream containing audio is added specifying no correlation timestamp and no tolerance value. The broadcast service shall be an SD service and have a video component using AVC encoding. The DASH media presentation shall have an audio component with AAC encoding using the High Efficiency Profile. After the terminal has started to present the broadcast video and an audio component it is requested to present the audio component of the broadband stream if that is not already the case. After the synchronised presentation 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-1 2022-3 2022-2 2022-1 2021-3 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 8.2.3.2.2: initMediaSynchroniser(): Initialises a MediaSynchroniser for multi-stream synchronisation and for inter-device synchronisation as a master terminal. [...] The media object becomes the master media (see clause 13.2.4) and the timeline selected for it defines the timeline used for the MediaSynchroniser API when performing multi-stream synchronisation and when acting as a master terminal for inter-device synchronisation as explained in clause 13.4.3. The media object specified as the parameter to this method shall be automatically added to this MediaSynchroniser and therefore cannot subsequently be explicitly added using the addMediaObject() method. [...] addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1. [...] argument(correlationTimestamp): If the correlation timestamp correlationTimestamp is undefined a correlation timestamp where the value of both properties is 0 shall be assumed. If the correlation timestamp is null or has an invalid format, adding the media object shall fail and the terminal dispatch an error event. [...] argument(tolerance): An optional synchronisation tolerance in milliseconds. The tolerance, if provided, is expressed as a positive value including 0. If the application passes a negative value or does not provide this argument then the terminal shall assume a tolerance of 0. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greatest of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. 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 : Broadcast MPEG2-TS with TEMI timeline for video; MPEG DASH ISOBMFF with DASH-PR timeline for audio.] [...] Mandatory HBBTV,section 13.4.2: Terminals shall support at least the following components of a DVB service to carry MPEG TEMI timeline descriptors: * Any component that is supported by the terminal for use with media synchronisation and MPEG TEMI, i.e. audio, video and subtitles. HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media objectand all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. | |||
| org.hbbtv_MSTRSYNC0110 | 1 | MSTRSYNC of BC-TS/TEMI V with DASH A and oob EBUTTD ST - no tolerance, no correlation timestamps needed | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state as the master media using and selecting a TEMI timeline that ticks with 50 ticks per second and is located in the adaptation header of TS packets carrying a separate PES component with no PES payload. After that an HTML5 media element associated with a DASH stream containing audio and EBU-TT-D subtitle, are added specifying no correlation timestamp and no tolerance value. The timeline specified, when the media object presenting the DASH stream is added, ticks at 50 ticks per second. The broadcast service shall be an HD service and have a video component using AVC 720p50 encoding. The DASH media presentation shall have an audio component with AAC encoding using the Low Complexity Profile. After the terminal has started to present the broadcast video, an audio component and the subtitles, it is requested to present the audio component of the broadband stream and the EBU-TT-D subtitles if that is not already the case. After the synchronised presentation started and again 2 minutes later, the presented broadcast component is observed to be synchronised to the presented broadband audio component within a margin of plus 50ms to minus 35ms and to the presented broadband subtitle component within a margin of plus 900ms to minus 500ms for a period of 15 seconds. | 2024-1 2023-3 2023-2 2018-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 8.2.3.2.2: initMediaSynchroniser(): Initialises a MediaSynchroniser for multi-stream synchronisation and for inter-device synchronisation as a master terminal. [...] The media object becomes the master media (see clause 13.2.4) and the timeline selected for it defines the timeline used for the MediaSynchroniser API when performing multi-stream synchronisation and when acting as a master terminal for inter-device synchronisation as explained in clause 13.4.3. The media object specified as the parameter to this method shall be automatically added to this MediaSynchroniser and therefore cannot subsequently be explicitly added using the addMediaObject() method. [...] addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1. [...] argument(correlationTimestamp): If the correlation timestamp correlationTimestamp is undefined a correlation timestamp where the value of both properties is 0 shall be assumed. If the correlation timestamp is null or has an invalid format, adding the media object shall fail and the terminal dispatch an error event. [...] argument(tolerance): An optional synchronisation tolerance in milliseconds. The tolerance, if provided, is expressed as a positive value including 0. If the application passes a negative value or does not provide this argument then the terminal shall assume a tolerance of 0. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greatest of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. 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 2 : Broadcast MPEG2-TS with TEMI timeline for video; MPEG DASH ISOBMFF with DASH-PR timeline for audio.; HTTP Out of Band EBU-TT-D with EBU-TT-D timeline for subtitles.] [...] Mandatory HBBTV,section 13.4.2: Terminals shall support at least the following components of a DVB service to carry MPEG TEMI timeline descriptors: [...] * Any component with stream_type 6 (private PES) and stream_id 1011 1101 ("private_stream_1") in the PES packet header, including, but not limited to, components where the PES packet payloads are empty. HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media object and all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. | ||
| org.hbbtv_MSTRSYNC0115 | 1 | MSTRSYNC of BC-TS/TEMI A/V with oob EBUTTD ST - no tolerance, no correlation timestamps needed | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state as the master media using and selecting a TEMI timeline that ticks with 25 ticks per second and is located in the adaption header of TS packets carrying a separate PES component with no PES payload. After HTML5 media object for a DASH stream with EBU-TT-D document as an out of band text track is added specifying no correlation timestamp and no tolerance value. The broadcast service shall be an SD service and have a video component using MPEG2 video encoding and MPEG1 Layer 2 audio coding. The DASH service shall have a single HEAAC audio component. After the terminal has setup media synchronisation with the DASH stream, the app makes sure audio from broadcast and the OOB subtitles are presented. After the synchronised presentation started and again 2 minutes later, subtitles are observed to be synchronised with the broadcast service to within a margin of plus 900ms to minus 500ms for a period of 15 seconds. | 2024-1 2023-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.3.2.2: initMediaSynchroniser(): Initialises a MediaSynchroniser for multi-stream synchronisation and for inter-device synchronisation as a master terminal. [...] The media object becomes the master media (see clause 13.2.4) and the timeline selected for it defines the timeline used for the MediaSynchroniser API when performing multi-stream synchronisation and when acting as a master terminal for inter-device synchronisation as explained in clause 13.4.3. The media object specified as the parameter to this method shall be automatically added to this MediaSynchroniser and therefore cannot subsequently be explicitly added using the addMediaObject() method. [...] addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1. [...] argument(correlationTimestamp): If the correlation timestamp correlationTimestamp is undefined a correlation timestamp where the value of both properties is 0 shall be assumed. If the correlation timestamp is null or has an invalid format, adding the media object shall fail and the terminal dispatch an error event. [...] argument(tolerance): An optional synchronisation tolerance in milliseconds. The tolerance, if provided, is expressed as a positive value including 0. If the application passes a negative value or does not provide this argument then the terminal shall assume a tolerance of 0. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greatest of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. 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 2a : Broadcast MPEG2-TS with TEMI timeline for video and audio; HTTP Out of Band EBU-TT-D with EBU-TT-D timeline for subtitles.] [...] Mandatory HBBTV,section 13.4.2: Terminals shall support at least the following components of a DVB service to carry MPEG TEMI timeline descriptors: [...] * Any component with stream_type 6 (private PES) and stream_id 1011 1101 ("private_stream_1") in the PES packet header, including, but not limited to, components where the PES packet payloads are empty. HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media object and all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. | ||
| org.hbbtv_MSTRSYNC0120 | 1 | MSTRSYNC of BC-TS/TEMI A/V with DASH ST - no tolerance, no correlation timestamps needed | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state as the master media using and selecting a TEMI timeline that ticks with 50 ticks per second and is located in the adaption header of TS packets carrying the audio elementary stream. After that HTML5 media object associated with an MPEG DASH stream containing EBU-TT-D subtitles is added specifying no correlation timestamp and no tolerance value. The timeline specified, when the media object presenting the DASH stream is added, ticks at 50 ticks per second. The broadcast service shall be an HD service and have a video component using AVC 1080i25 encoding and an audio component using AAC encoding with the Low Complexity profile. After the terminal has started to present the broadcast video, an audio component and subtitles, it is requested to present the audio component of the broadcast stream and the DASH EBU-TT-D subtitles if that is not already the case. After the synchronised presentation started and again 2 minutes later, the presented video and subtitle components are observed to be synchronised to within a margin of plus 900ms to minus 500ms for a period of 15 seconds. | 2024-1 2023-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.3.2.2: initMediaSynchroniser(): Initialises a MediaSynchroniser for multi-stream synchronisation and for inter-device synchronisation as a master terminal. [...] The media object becomes the master media (see clause 13.2.4) and the timeline selected for it defines the timeline used for the MediaSynchroniser API when performing multi-stream synchronisation and when acting as a master terminal for inter-device synchronisation as explained in clause 13.4.3. The media object specified as the parameter to this method shall be automatically added to this MediaSynchroniser and therefore cannot subsequently be explicitly added using the addMediaObject() method. [...] addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1.[...] argument(correlationTimestamp): If the correlation timestamp correlationTimestamp is undefined a correlation timestamp where the value of both properties is 0 shall be assumed. If the correlation timestamp is null or has an invalid format, adding the media object shall fail and the terminal dispatch an error event. [...] argument(tolerance): An optional synchronisation tolerance in milliseconds. The tolerance, if provided, is expressed as a positive value including 0. If the application passes a negative value or does not provide this argument then the terminal shall assume a tolerance of 0. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greatest of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. 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 3 : Broadcast MPEG2-TS with TEMI timeline for video and audio; MPEG DASH ISOBMFF with DASH-PR timeline for subtitles.] [...] Mandatory HBBTV,section 13.4.2: Terminals shall support at least the following components of a DVB service to carry MPEG TEMI timeline descriptors: * Any component that is supported by the terminal for use with media synchronisation and MPEG TEMI, i.e. audio, video and subtitles. HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media objectand all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. | ||
| org.hbbtv_MSTRSYNC0130 | 1 | MSTRSYNC of BC-TS/TEMI V/ST with DASH A - no tolerance, no correlation timestamps needed | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state of a DVB service including at least video and DVB subtitles as the master media using and selecting a TEMI timeline that ticks with 50 ticks per second and is located in the adaption header of TS packets carrying a separate PES component with no PES payload. After that an HTML5 media element (audio tag) associated with an MPEG DASH stream containing AAC audio is added specifying no correlation timestamp and no tolerance value. The timeline specified, when the media object presenting the DASH stream is added, ticks at 50 ticks per second. The broadcast service shall be an HD service and have a video component using AVC 1080p50 encoding. The DASH media presentation shall have an audio component with AAC encoding using the Low Complexity Profile. After the terminal has started to present the broadcast video, an audio component and subtitles, it is requested to present the subtitle component of the broadcast stream and the broadband audio if that is not already the case. After the synchronised presentation started and again 2 minutes later, the presented video and audio components are observed to be synchronised to within a margin of plus 50ms to minus 35ms for a period of 15 seconds. | 2024-1 2022-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 8.2.3.2.2: initMediaSynchroniser(): Initialises a MediaSynchroniser for multi-stream synchronisation and for inter-device synchronisation as a master terminal. [...] The media object becomes the master media (see clause 13.2.4) and the timeline selected for it defines the timeline used for the MediaSynchroniser API when performing multi-stream synchronisation and when acting as a master terminal for inter-device synchronisation as explained in clause 13.4.3. The media object specified as the parameter to this method shall be automatically added to this MediaSynchroniser and therefore cannot subsequently be explicitly added using the addMediaObject() method. [...] addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1. [...] argument(correlationTimestamp): If the correlation timestamp correlationTimestamp is undefined a correlation timestamp where the value of both properties is 0 shall be assumed. If the correlation timestamp is null or has an invalid format, adding the media object shall fail and the terminal dispatch an error event. [...] argument(tolerance): An optional synchronisation tolerance in milliseconds. The tolerance, if provided, is expressed as a positive value including 0. If the application passes a negative value or does not provide this argument then the terminal shall assume a tolerance of 0. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greatest of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. 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 4 : Broadcast MPEG2-TS with TEMI timeline for video and subtitles; MPEG DASH ISOBMFF with DASH-PR timeline for audio.] [...] Mandatory HBBTV,section 13.4.2: Terminals shall support at least the following components of a DVB service to carry MPEG TEMI timeline descriptors: [...] * Any component with stream_type 6 (private PES) and stream_id 1011 1101 ("private_stream_1") in the PES packet header, including, but not limited to, components where the PES packet payloads are empty. HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media objectand all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. | +AVC_LEVEL_42 | ||
| org.hbbtv_MSTRSYNC0140 | 1 | MSTRSYNC of BC-TS/TEMI V with DASH A/ST - no tolerance, no correlation timestamps needed | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state of a DVB service as the master media using and selecting a TEMI timeline that ticks with 50 ticks per second and is located in the adaption header of TS packets carrying the video component. After that an HTML5 media element associated with an MPEG DASH stream containing AAC audio and EBU-TT-D subtitles is added specifying no correlation timestamp and no tolerance value. The timeline specified, when the media object presenting the DASH stream is added, ticks at 50 ticks per second. The broadcast service shall be an SD service and have a video component using MPEG-2 video encoding. The DASH media presentation shall have an audio component with AAC encoding using the High Efficiency Profile. After the terminal has started to present the broadcast video, an audio component and subtitles, it is requested to present the subtitle and audio component of the broadband stream if that is not already the case. After the synchronised presentation started and again 2 minutes later, the presented broadcast component is observed to be synchronised to the presented broadband audio component within a margin of plus 50ms to minus 35ms and to the presented broadband subtitle component within a margin of plus 900ms to minus 500ms for a period of 15 seconds. | 2024-1 2023-3 2023-2 2023-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.3.2.2: initMediaSynchroniser(): Initialises a MediaSynchroniser for multi-stream synchronisation and for inter-device synchronisation as a master terminal. [...] The media object becomes the master media (see clause 13.2.4) and the timeline selected for it defines the timeline used for the MediaSynchroniser API when performing multi-stream synchronisation and when acting as a master terminal for inter-device synchronisation as explained in clause 13.4.3. The media object specified as the parameter to this method shall be automatically added to this MediaSynchroniser and therefore cannot subsequently be explicitly added using the addMediaObject() method. [...] addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1. [...] argument(correlationTimestamp): If the correlation timestamp correlationTimestamp is undefined a correlation timestamp where the value of both properties is 0 shall be assumed. If the correlation timestamp is null or has an invalid format, adding the media object shall fail and the terminal dispatch an error event. [...] argument(tolerance): An optional synchronisation tolerance in milliseconds. The tolerance, if provided, is expressed as a positive value including 0. If the application passes a negative value or does not provide this argument then the terminal shall assume a tolerance of 0. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greatest of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. 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 5 : Broadcast MPEG2-TS with TEMI timeline for video; MPEG DASH ISOBMFF with DASH-PR timeline for audio and subtitles.] [...] Mandatory HBBTV,section 13.4.2: Terminals shall support at least the following components of a DVB service to carry MPEG TEMI timeline descriptors: * Any component that is supported by the terminal for use with media synchronisation and MPEG TEMI, i.e. audio, video and subtitles. HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media objectand all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. | ||
| org.hbbtv_MSTRSYNC0150 | 1 | MSTRSYNC of BC-TS/TEMI A/V with DASH V - no tolerance, no correlation timestamps needed | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state of a DVB service as the master media using and selecting a TEMI timeline that ticks with 50 ticks per second and is located in the adaption header of TS packets carrying the video component. After that an HTML5 media element associated with an MPEG DASH stream containing AVC video is added with the multiDecoderMode set to true but specifying no correlation timestamp and no tolerance value. The timeline specified, when the media object presenting the DASH stream is added, ticks at 50 ticks per second. The HTML5 media element is scaled down and placed above the video/broadcast object. The broadcast service shall be an HD service and have a video component using AVC 720p50 encoding and an audio component with AAC encoding using the High Efficiency profile. The DASH media presentation shall have a video component with AVC 576p25 encoding. The terminal starts to present video, audio from brodcast and the video from broadband. After the synchronised presentation started and again 2 minutes later, the presented video and audio components are observed to be synchronised to within a margin of plus 50ms to minus 35ms for a period of 15 seconds. | 2024-1 2022-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 8.2.3.2.2: initMediaSynchroniser(): Initialises a MediaSynchroniser for multi-stream synchronisation and for inter-device synchronisation as a master terminal. [...] The media object becomes the master media (see clause 13.2.4) and the timeline selected for it defines the timeline used for the MediaSynchroniser API when performing multi-stream synchronisation and when acting as a master terminal for inter-device synchronisation as explained in clause 13.4.3. The media object specified as the parameter to this method shall be automatically added to this MediaSynchroniser and therefore cannot subsequently be explicitly added using the addMediaObject() method. [...] addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1. [...] argument(correlationTimestamp): If the correlation timestamp correlationTimestamp is undefined a correlation timestamp where the value of both properties is 0 shall be assumed. If the correlation timestamp is null or has an invalid format, adding the media object shall fail and the terminal dispatch an error event. [...] argument (tolerance): An optional synchronisation tolerance in milliseconds. The tolerance, if provided, is expressed as a positive value including 0. If the application passes a negative value or does not provide this argument then the terminal shall assume a tolerance of 0. argument (multiDecoderMode) An optional parameter that defines whether component selection for this media object is performed separately (as defined in clause 10.2.7.3) or collectively with other media objects on this MediaSynchroniser (as defined in clause 10.2.7.4). If the value does not equal true, the terminal shall follow the rules for component selection in clause 10.2.7.3. If the value is true and the terminal does not support multiple decoders or currently does not have sufficient resources it shall ignore the call and dispatch an error event with the error code 2. Otherwise the terminal shall follow the rules in clause 10.2.7.4. NOTE: Applications should check the extraSDVideoDecodes and extraHDVideoDecodes properties before using this parameter set to true. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greatest of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. 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 6 : Broadcast MPEG2-TS with TEMI timeline for video and audio; MPEG DASH ISOBMFF with DASH-PR timeline for a second video stream] [...] Mandatory if the terminal supports the simultaneous use of two video decoders for HbbTV services. HBBTV,section 13.4.2: Terminals shall support at least the following components of a DVB service to carry MPEG TEMI timeline descriptors: * Any component that is supported by the terminal for use with media synchronisation and MPEG TEMI, i.e. audio, video and subtitles. HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * Multiple presentations are in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. The application can choose this type of presentation by adding media objects to the MediaSynchroniser with the multiDecoderMode argument set to true. In this case, the terminal treats each such media objects as single presentations. | +2DECODER | ||
| org.hbbtv_MSTRSYNC0650 | 1 | Synchronised presentation of broadcast MP2TS AVC (TEMI) video (master) with DASH E-AC-3 (DASH-PR) audio | When a MediaSynchroniser is initialised with a video/broadcast object in the presenting state with broadcast MPEG 2 TS AVC 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 E-AC-3 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-1 2022-3 2022-2 2022-1 2021-3 2019-1 2018-3 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | 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. | +EAC3 | ||
| org.hbbtv_MSTRSYNC0730 | 1 | Synchronised presentation of broadcast MP2TS AVC (TEMI) video (master) with DASH E-AC-3 (DASH-PR) audio and DASH (DASH-PR) subtitles | When a MediaSynchroniser is initialised with a video/broadcast object in the presenting state with broadcast MPEG-2 TS AVC 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 HTML5 media object referencing DASH E-AC-3 audio and DASH subtitles as its 'mediaObject', a valid DASH-PR 'timelineSpecification' string that ticks with 50 ticks per second and no correlation timestamp or tolerance values specified. After the terminal has started to present the broadcast video, it is requested to present the audio and subtitle components of the broadband stream if that is not already the case. When the synchronised presentation is started, and again 2 minutes later, the presented broadcast component is observed to be synchronised to the presented broadband audio component within a margin of plus 50ms to minus 35ms and to the presented broadband subtitle component within a margin of plus 900ms to minus 500ms for a period of 15 seconds. | 2024-1 2021-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 8.2.3.2.2: void addMediaObject (Object mediaObject, String 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 5 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. | +EAC3 | ||
| org.hbbtv_MSTRSYNC1751 | 1 | MSTRSYNC of BC-TS/TEMI V with DASH A - gen-locked timelines, TEMI tickrate 50, correlationTimestamp present | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state as the master media using and selecting a TEMI timeline that ticks with 50 ticks per second. After that an HTML5 audio element associated with a DASH stream containing audio is added specifying a correlation timestamp and no tolerance value. The DASH media shall be deemed to be synchronised with the broadcast service if the DASH timeline value is 0 and the TEMI timeline value is 231, i.e. the correlation timestamp passed to addMediaObject is {'tlvMaster': 231, 'tlvOther': 0}. The timelines shall be gen-locked, i.e. no updateCorrelationTimestamp is needed. The broadcast service shall be an SD service and have a video component using AVC encoding. The DASH media presentation shall have an audio component with AAC encoding using the High Efficiency Profile. After the terminal has started to present the broadcast video and an audio component it is requested to present the audio component of the broadband stream if that is not already the case. After the synchronised presentation 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-1 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,section 8.2.3.2.2: addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1. argument(correlationTimestamp): An optional initial correlation timestamp that relates the media objects timeline to the synchronisation timeline. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greater of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. [...] The terminal shall also adjust the timing relationship of some or all of the streams if the application specifies a new timing relationship for a stream. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. HBBTV,section 9.7.4: The minimum accuracy for multi-device 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. 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 : Broadcast MPEG2-TS with TEMI timeline for video; MPEG DASH ISOBMFF with DASH-PR timeline for audio.] [...] Mandatory HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media objectand all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. | ||
| org.hbbtv_MSTRSYNC1752 | 1 | MSTRSYNC of BC-TS/TEMI V with DASH A and oob EBUTTD ST - TEMI tickrate 50, drifting timelines. | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state as the master media using and selecting a TEMI timeline that ticks with 50 ticks per second. After HTML5 media object associated with a DASH stream containing audio is added specifying a correlation timestamp and no tolerance value and out-of-band EBU-TT-D subtitles specifying a correlation timestamp and no tolerance value. The DASH timeline and the EBU-TT-D timeline both shall have a drift of 10ms per 20 seconds. The application updates the correlation timestamp for HTML5 media object every 10 seconds. The broadcast service shall be an HD service and have a video component using AVC 720p50 encoding. The DASH media presentation shall have an audio component with AAC encoding using the Low Complexity Profile. After the terminal has started to present the broadcast video, an audio component and a subtitle component, it is requested to present the audio component and the subtitles of the broadband streams if that is not already the case. After the synchronised presentation started and again 2 minutes later, the presented broadcast component is observed to be synchronised to the presented broadband audio component within a margin of plus 50ms to minus 35ms and to the presented broadband subtitle component within a margin of plus 900ms to minus 500ms for a period of 15 seconds. | 2024-1 2018-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 | HBBTV,section 8.2.3.2.2: addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1. argument(correlationTimestamp): An optional initial correlation timestamp that relates the media objects timeline to the synchronisation timeline. void updateCorrelationTimestamp (Object mediaObject, CorrelationTimestamp correlationTimestamp) [...] Updates the correlation timestamp for the media object, which relates the media object's timeline to the timeline used by the MediaSynchroniser API. [...] When an updated correlation timestamp is set for a media object which would change the temporal relative presentation of the media objects, the terminal shall adapt to this. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. HBBTV,section 9.7.4: The minimum accuracy for multi-device 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. HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media objec tand all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greater of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. [...] The terminal shall also adjust the timing relationship of some or all of the streams if the application specifies a new timing relationship for a stream. 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 2 : Broadcast MPEG2-TS with TEMI timeline for video; MPEG DASH ISOBMFF with DASH-PR timeline for audio.; HTTP Out of Band EBU-TT-D with EBU-TT-D timeline for subtitles.] [...] Mandatory HBBTV,section 13.4.2: [...] For a media stream that is a raw XML document containing EBU-TT-D conformant TTML subtitles that is delivered out of band the terminal shall support the use of a timeline derived from the timing information used within the EBU-TT-D conformant TTML subtitle document. The Timeline Selector for this timeline shall be "urn:hbbtv:sync:timeline:ebu-tt-d [...] An EBU-TT-D conformant TTML subtitle timing is expressed in terms of hours, minutes and seconds, where the seconds can include a decimal fractional part. 1 millisecond shall equal 1 tick and therefore the equivalent ticks time value on this Timeline shall be calculated as follows, rounding to the nearest integer: round(1000×(seconds+60×(minutes+60×hours))) HBBTV,section A.2.5.4: The terminal shall support the rendering of subtitles when carried in a separate subtitle-only stream using the AV Control object if the type of the subtitle-only stream is supported by the terminal for media synchronisation. The requirements on terminals for supporting subtitle-only streams are defined in 10.2.8.4. In any case, the following restrictions shall apply: [...] * For TTML subtitles: ** the video component is provided by the broadcast service, ** EITHER *** the type attribute of the AV Control object is "application/ttml+xml", *** the subtitle stream is delivered with a Content Type of "application/ttml+xml" *** and the subtitle stream is a single XML document. ** OR [...] | ||
| org.hbbtv_MSTRSYNC1754 | 1 | MSTRSYNC of BC-TS/TEMI V/ST with DASH A - TEMI tickrate 50, drifting timelines. | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state as the master media using and selecting a TEMI timeline that ticks with 50 ticks per second. After that an HTML5 media element associated with a DASH audio stream is added specifying a correlation timestamp and no tolerance value. The DASH timeline shall have a drift of 20ms per 20 seconds. The application updates the correlation timestamp for the HTML5 media element every 5 seconds. The broadcast service shall be an HD service and have a video component using AVC 1080p50 encoding. The DASH media presentation shall have an audio component with AAC encoding using the Low Complexity Profile. After the terminal has started to present the broadcast video and an audio component, it is requested to present the audio component of the broadband stream if that is not already the case. After the synchronised presentation 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-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,section 8.2.3.2.2: addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1. argument(correlationTimestamp): An optional initial correlation timestamp that relates the media objects timeline to the synchronisation timeline. void updateCorrelationTimestamp (Object mediaObject, CorrelationTimestamp correlationTimestamp) [...] Updates the correlation timestamp for the media object, which relates the media object's timeline to the timeline used by the MediaSynchroniser API. [...] When an updated correlation timestamp is set for a media object which would change the temporal relative presentation of the media objects, the terminal shall adapt to this. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greater of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. [...] The terminal shall also adjust the timing relationship of some or all of the streams if the application specifies a new timing relationship for a stream. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. HBBTV,section 9.7.4: The minimum accuracy for multi-device 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. 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 4 : Broadcast MPEG2-TS with TEMI timeline for video and subtitles; MPEG DASH ISOBMFF with DASH-PR timeline for audio.] [...] Mandatory HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media objectand all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. | +AVC_LEVEL_42 | ||
| org.hbbtv_MSTRSYNC1755 | 1 | MSTRSYNC of BC-TS/TEMI V with DASH A/ST - TEMI tickrate 25, drifting timelines. | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state as the master media using and selecting a TEMI timeline that ticks with 25 ticks per second. After that an HTML5 media element associated with a DASH stream with audio and subtitles is added specifying a correlation timestamp and no tolerance value. The timeline specified, when the media object presenting the DASH stream is added, ticks at 50 ticks per second. The DASH timeline shall have a drift of 13 ms per 10 seconds. The application updates the correlation timestamp for the HTML5 media element every 10 seconds. The broadcast service shall be an SD service and have a video component using MPEG-2 video encoding. The DASH media presentation shall have an audio component with AAC encoding using the High Efficiency Profile. After the terminal has started to present the broadcast video and an audio and a subtitle component, it is requested to present the audio and subtitle component of the broadband stream if that is not already the case. After the synchronised presentation started and again 2 minutes later, the video component is observed to be synchronised to the audio component within a margin of plus 50ms to minus 35ms and to the subtitles component within a margin of plus 900ms to minus 500ms for a period of 15 seconds. | 2024-1 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 8.2.3.2.2: addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1. argument(correlationTimestamp): An optional initial correlation timestamp that relates the media objects timeline to the synchronisation timeline. void updateCorrelationTimestamp (Object mediaObject, CorrelationTimestamp correlationTimestamp) [...] Updates the correlation timestamp for the media object, which relates the media object's timeline to the timeline used by the MediaSynchroniser API. [...] When an updated correlation timestamp is set for a media object which would change the temporal relative presentation of the media objects, the terminal shall adapt to this. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greater of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. [...] The terminal shall also adjust the timing relationship of some or all of the streams if the application specifies a new timing relationship for a stream. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. HBBTV,section 9.7.4: The minimum accuracy for multi-device 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. HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media objectand all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. 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 5 : Broadcast MPEG2-TS with TEMI timeline for video; MPEG DASH ISOBMFF with DASH-PR timeline for audio and subtitles.] [...] Mandatory | |||
| org.hbbtv_MSTRSYNC1855 | 1 | MSTRSYNC of BC-TS/TEMI V with DASH A/ST - DASH not available in time | A MediaSynchroniser is initialised with a video/broadcast object in the presenting state as the master media using and selecting a TEMI timeline that ticks with 50 ticks per second. After that an HTML5 media element associated with a DASH stream with audio and subtitles is added specifying a correlation timestamp and no tolerance value. The timeline specified, when the media object presenting the DASH stream is added, ticks at 50 ticks per second. The size of any segment of the DASH stream shall be 2 secs. The MPD availability start time of any segment of the DASH stream shall be 12 seconds later than the corresponding part of the broadcast service is delivered to the terminal. The broadcast service shall have a constant bitrate of 15 Mbit/s total for all of its components. The DASH timeline shall have a drift of 5 ms per 10 seconds. The application updates the correlation timestamp for the HTML5 media element every 20 seconds. The broadcast service shall be an HD service and have a video component using AVC 720p50 encoding. The DASH media presentation shall have an audio component with AAC encoding using the High Efficiency Profile. The terminal adjusts for the delivery delay between the broadcast service and the broadband stream using an internal buffer. After the terminal has started to present the broadcast video and an audio and a subtitle component, it is requested to present the audio and subtitle component of the broadband stream if that is not already the case. After the synchronised presentation started and again 2 minutes later, the presented broadcast component is observed to be synchronised to the presented broadband audio component within a margin of plus 50ms to minus 35ms and to the presented broadband subtitle component within a margin of plus 900ms to minus 500ms for a period of 15 seconds. | 2024-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,section 8.2.3.2.2: addMediaObject(): 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. The behaviour of the media objects when this method is called is defined in clause 9.7.1. argument(correlationTimestamp): An optional initial correlation timestamp that relates the media objects timeline to the synchronisation timeline. void updateCorrelationTimestamp (Object mediaObject, CorrelationTimestamp correlationTimestamp) [...] Updates the correlation timestamp for the media object, which relates the media object's timeline to the timeline used by the MediaSynchroniser API. [...] When an updated correlation timestamp is set for a media object which would change the temporal relative presentation of the media objects, the terminal shall adapt to this. HBBTV,section 10.2.8.1: When an application adds a new stream for synchronisation to already presenting media object(s) (broadcast services or broadband streams) the terminal shall adjust the presentation timing of some or all of the streams to attempt to synchronise them according to a timing relationship expressed by the application. [...] Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greater of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. [...] The terminal shall also adjust the timing relationship of some or all of the streams if the application specifies a new timing relationship for a stream. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. HBBTV,section 9.7.4: The minimum accuracy for multi-device 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. HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. [...] The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined;[...] * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media object and all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. 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 5 : Broadcast MPEG2-TS with TEMI timeline for video; MPEG DASH ISOBMFF with DASH-PR timeline for audio and subtitles.] [...] Mandatory HBBTV,section 13.5.1: In the case of media synchronisation between two or more pieces of timed content, additional buffer capacity is needed, as one timed content will be the most laggard and the other piece(s) of timed content need to be buffered to achieve time alignment. HBBTV,section 13.5.2: In case 3, the terminal shall use its buffer for media synchronisation to time the playout of the timed content with the correct timing for media synchronisation. The media synchronisation buffer model is provided in clause 13.5.3. It is the broadcaster's responsibility to assure that the terminal will not need more than the available buffer size for media synchronisation. HBBTV,section 13.5.3: The media synchronisation buffer is optional. The terminal exposes the presence of a buffer for media synchronisation through a non-zero value of the property minSyncBufferSize of the MediaSynchroniser embedded object (see clause 8.2.3.2.1). [...] * The size of the media synchronisation buffer shall be at least 30 Megabytes (that is 30 x 1024 x 1024 = 31 457 280 bytes). | +SYNC_BUFFER | ||
| org.hbbtv_MSTRSYNC2100 | 1 | Completion of initMediaSynchroniser | A broadcast is playing including video and audio. A broadcast-related application creates a media synchroniser, creates a video/broadcast object, sets the onSynchroniserInitialised property of the media synchroniser to a method, adds a listener to the media synchroniser for SynchroniserInitialised events and then initialises the media synchroniser with the video/broadcast object. After currentTime starts being updated with correct values for the broadcast timeline, a SynchroniserInitialised event is sent to the DOM-2 event listener and the onSynchroniserInitialised method is called. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 | Exclude: The test has an open Redmine ticket. | HBBTV 1.6.1 HBBTV 1.5.1 HBBTV 1.4.1 HBBTV 1.7.1 | HBBTV,section 8.2.3.2.2: If this method completes successfully without an error event being triggered then the MediaSynchroniser shall be considered initialized and a SynchroniserInitialised event shall be triggered after the currentTime property starts being updated. HBBTV,section 8.2.3.2.1: function onSynchroniserInitialised () Description The function that gets called when the initialization of this MediaSynchroniser object is successfully completed – specifically after the timeline is being monitored and the currentTime property has started to be updated. HBBTV,section 8.2.3.2.3: For the intrinsic event onSynchroniserInitialised, a corresponding DOM level 2 event shall be generated, in the following manner: Intrinsic event Corresponding DOM 2 event DOM 2 Event properties onSynchroniserInitialised SynchroniserInitialised Bubbles: No Cancelable: No Context Info: None HBBTV,section 4.6.11.3: If this method completes successfully without an error event being triggered then the MediaSynchroniser shall be considered initialized and a SynchroniserInitialised event shall be triggered after the currentTime property starts being updated. HBBTV,section 4.6.11.2: function onSynchroniserInitialised () Description The function that gets called when the initialization of this MediaSynchroniser object is successfully completed – specifically after the timeline is being monitored and the currentTime property has started to be updated. HBBTV,section 4.6.11.4: For the intrinsic event onSynchroniserInitialised, a corresponding DOM level 2 event shall be generated, in the following manner: Intrinsic event Corresponding DOM 2 event DOM 2 Event properties onSynchroniserInitialised SynchroniserInitialised Bubbles: No Cancelable: No Context Info: None | ||
| org.hbbtv_OBF08170 | 1 | Method oipfObjectFactory.isObjectSupported() shall return true for all mandatory embedded objects. | window.oipfObjectFactory.isObjectSupported() shall return true for all mandatory objects (mime types: video/broadcast, application/oipfApplicationManager, application/oipfCapabilities, application/oipfConfiguration, application/oipfSearchManager, application/oipfParentalControlManager). | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1.1: isObjectSupported | |||
| org.hbbtv_PMT0001 | 4 | PMT - response to AIT PID change with same AIT data | When a service contains an AIT that lists a single AUTOSTART application and the PMT changes so that the AIT PID is different and the new AIT is the same as the old AIT except that the version number is different, the application continues to run. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The PID on which an AIT component is carried may change. Terminals shall treat this in the same manner defined in clause 5.3.4.2 of ETSI TS 102 809 [3] for the case where an AIT is removed from the PMT and then reinstated. This means that the sub-table shall be considered to have changed, regardless of whether the AIT version number changes, and the normal “AIT updated” sequence defined in Figure 14 shall be followed. TS-102-809,section 5.3.4.2: Terminals shall monitor the PMT for changes in the number of AIT elementary streams present. [...] If the AIT sub-table signalling an application vanishes from the network completely, that application shall continue to run. The terminal shall monitor for the re-appearance of the AIT sub-table as defined for the appearance of new AIT sub-tables above while that service remains selected. | |||
| org.hbbtv_PMT0002 | 4 | PMT - response to AIT PID change with different AIT data and different version | When a service contains an AIT that lists a single AUTOSTART application (app 1) and the PMT changes so that the AIT PID is different and the AIT changes simultaneously so that it lists only a single AUTOSTART application (app 2) which is different to app 1 and the AIT version number changes, app 1 is killed and app 2 is launched. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The PID on which an AIT component is carried may change. Terminals shall treat this in the same manner defined in clause 5.3.4.2 of ETSI TS 102 809 [3] for the case where an AIT is removed from the PMT and then reinstated. This means that the sub-table shall be considered to have changed, regardless of whether the AIT version number changes, and the normal “AIT updated” sequence defined in Figure 14 shall be followed. TS-102-809,section 5.3.4.2: Terminals shall monitor the PMT for changes in the number of AIT elementary streams present. [...] If the AIT sub-table signalling an application vanishes from the network completely, that application shall continue to run. The terminal shall monitor for the re-appearance of the AIT sub-table as defined for the appearance of new AIT sub-tables above while that service remains selected. | |||
| org.hbbtv_PMT0003 | 3 | PMT - response to AIT PID change with different AIT data and same version | When a service contains an AIT that lists a single AUTOSTART application (app 1) and the PMT changes so that the AIT PID is different and the AIT changes simultaneously so that it lists only a single AUTOSTART application (app 2) which is different to app 1 and the AIT version number does not change, app 1 is killed and app 2 is launched. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The PID on which an AIT component is carried may change. Terminals shall treat this in the same manner defined in clause 5.3.4.2 of ETSI TS 102 809 [3] for the case where an AIT is removed from the PMT and then reinstated. This means that the sub-table shall be considered to have changed, regardless of whether the AIT version number changes, and the normal “AIT updated” sequence defined in Figure 14 shall be followed. TS-102-809,section 5.3.4.2: Terminals shall monitor the PMT for changes in the number of AIT elementary streams present. [...] If the AIT sub-table signalling an application vanishes from the network completely, that application shall continue to run. The terminal shall monitor for the re-appearance of the AIT sub-table as defined for the appearance of new AIT sub-tables above while that service remains selected. TS-102-809,section 5.3.4.2: Terminals shall monitor the PMT for changes in the number of AIT elementary streams present. [...] If the AIT sub-table signalling an application vanishes from the network completely, that application shall continue to run. The terminal shall monitor for the re-appearance of the AIT sub-table as defined for the appearance of new AIT sub-tables above while that service remains selected. | |||
| org.hbbtv_PMT0004 | 3 | Notification of change of components - video removed from video/broadcast object | When an application is running on a service containing 1 video component and any number of audio and subtitle components and a function is assigned to the onComponentChanged event and the video component is removed, the onComponentChanged function is called and componentType is 0. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponent method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_VIDEO Value: 0 Use: Represents a video component. This constant is used for all video components regardless of encoding. | |||
| org.hbbtv_PMT0005 | 3 | Notification of change of components - audio removed from video/broadcast object (1 component to 0 components) | When an application is running on a service containing 1 audio component and any number of video and subtitle components and a function is assigned to the onComponentChanged event and the audio component is removed, the onComponentChanged function is called and componentType is 1. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponents() method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_AUDIO Value: 1 Use: Represents an audio component. This constant is used for all audio components regardless of encoding. | |||
| org.hbbtv_PMT0006 | 3 | Notification of change of components - subtitles removed from video/broadcast object (1 component to 0 components) | When an application is running on a service containing 1 subtitle component and any number of video and audio components and a function is assigned to the onComponentChanged event and the subtitle component is removed, the onComponentChanged function is called and componentType is 2. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponents() method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_SUBTITLE Value: 2 Use: Represents a subtitle component. This constant is used for all subtitle components regardless of subtitle format. NOTE: A subtitle component may also be related to closed captioning as part of a video stream. | |||
| org.hbbtv_PMT0007 | 3 | Notification of change of components - video added to video/broadcast object | When an application is running on a service containing 0 video components and any number of audio and subtitle components and a function is assigned to the onComponentChanged event and a video component is introduced, the onComponentChanged function is called and componentType is 0. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponent method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_VIDEO Value: 0 Use: Represents a video component. This constant is used for all video components regardless of encoding. | |||
| org.hbbtv_PMT0008 | 3 | Notification of change of components - audio added to video/broadcast object (0 components to 1 component) | When an application is running on a service containing 0 audio components and any number of video and subtitle components and a function is assigned to the onComponentChanged event and an audio component is introduced, the onComponentChanged function is called and componentType is 1. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponents() method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_AUDIO Value: 1 Use: Represents an audio component. This constant is used for all audio components regardless of encoding. | |||
| org.hbbtv_PMT0009 | 3 | Notification of change of components - subtitles added to video/broadcast object (0 components to 1 component) | When an application is running on a service containing 0 subtitle components and any number of video and audio components and a function is assigned to the onComponentChanged event and a subtitle component is introduced, the onComponentChanged function is called and componentType is 2. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponents() method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_SUBTITLE Value: 2 Use: Represents a subtitle component. This constant is used for all subtitle components regardless of subtitle format. NOTE: A subtitle component may also be related to closed captioning as part of a video stream. | |||
| org.hbbtv_PMT0010 | 3 | Notification of change of components - multiple components changed in video/broadcast object | When an application is running on a service containing 1 video component, 1 audio component and 1 subtitle component and a function is assigned to the onComponentChanged event and each of the components is simultaneously replaced by different components of the same type but with different properties, the onComponentChanged function is called and componentType is undefined. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponents() method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_VIDEO Value: 0 Use: Represents a video component. This constant is used for all video components regardless of encoding. Name: COMPONENT_TYPE_AUDIO Value: 1 Use: Represents an audio component. This constant is used for all audio components regardless of encoding. Name: COMPONENT_TYPE_SUBTITLE Value: 2 Use: Represents a subtitle component. This constant is used for all subtitle components regardless of subtitle format. NOTE: A subtitle component may also be related to closed captioning as part of a video stream. | |||
| org.hbbtv_PMT0011 | 3 | getComponents - response to PMT change - video removed | When an application is running on a service containing 1 video component and any number of audio and subtitle components and the video component is removed, the getComponents(0) method returns 1 component before the video component is removed and returns 0 components after the video component is removed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 getComponents method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns in formation from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned , as represented by one of the constant values listed in section 7.16.5.1.1. | |||
| org.hbbtv_PMT0012 | 3 | getComponents - response to PMT change - audio removed (1 component to 0 components) | When an application is running on a service containing 1 audio component and any number of video and subtitle components and the audio component is removed, the getComponents(1) method returns 1 component before the audio component is removed and returns 0 components after the audio component is removed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 getComponents() method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns information from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned , as represented by one of the constant values listed in section 7.16.5.1.1. | |||
| org.hbbtv_PMT0013 | 3 | getComponents - response to PMT change - subtitles removed (1 component to 0 components) | When an application is running on a service containing 1 subtitle component and any number of video and audio components and the subtitle component is removed, the getComponents(2) method returns 1 component before the subtitle component is removed and returns 0 components after the subtitle component is removed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 getComponents() method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns information from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned , as represented by one of the constant values listed in section 7.16.5.1.1. | |||
| org.hbbtv_PMT0014 | 3 | getComponents - response to PMT change - video added | When an application is running on a service containing 0 video components and any number of audio and subtitle components and a video component is introduced, the getComponents(0) method returns 0 components before the video component is introduced and returns 1 component after the video component is introduced. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 getComponents method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns in formation from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned , as represented by one of the constant values listed in section 7.16.5.1.1. | |||
| org.hbbtv_PMT0015 | 3 | getComponents - response to PMT change - audio added (0 components to 1 component) | When an application is running on a service containing 0 audio components and any number of video and subtitle components and an audio component is introduced, the getComponents(1) method returns 0 components before the audio component is introduced and returns 1 component after the audio component is introduced. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 getComponents() method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns information from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned , as represented by one of the constant values listed in section 7.16.5.1.1. | |||
| org.hbbtv_PMT0016 | 3 | getComponents - response to PMT change - subtitles added (0 components to 1 component) | When an application is running on a service containing 0 subtitle components and any number of video and audio components and a subtitle component is introduced, the getComponents(2) method returns 0 components before the subtitle component is introduced and returns 1 component after the subtitle component is introduced. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 getComponents() method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns information from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned , as represented by one of the constant values listed in section 7.16.5.1.1. | |||
| org.hbbtv_PMT0017 | 3 | getComponents - response to PMT change - multiple components changed | When an application is running on a service containing 1 video component, 1 audio component and 1 subtitle component and each of the components is simultaneously replaced by different components of the same type but with different properties, the getComponents(null) method returns 3 components before and after the stream changes and each AVComponent correctly reflects the properties of the corresponding component in the stream before and after the stream changes. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 getComponents() method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns information from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned , as represented by one of the constant values listed in section 7.16.5.1.1. | |||
| org.hbbtv_PMT0030 | 1 | Notification of change of components - audio removed from video/broadcast object (2 components to 1 component) | When an application is running on a service containing 2 audio components and any number of video and subtitle components and a function is assigned to the onComponentChanged event and one of the audio components is removed, the onComponentChanged function is called and componentType is 1. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponents() method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_AUDIO Value: 1 Use: Represents an audio component. This constant is used for all audio components regardless of encoding. | |||
| org.hbbtv_PMT0040 | 1 | Notification of change of components - subtitles removed from video/broadcast object (2 components to 1 component) | When an application is running on a service containing 2 subtitle components and any number of video and audio components and a function is assigned to the onComponentChanged event and one of the subtitle components is removed, the onComponentChanged function is called and componentType is 2. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponents() method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_SUBTITLE Value: 2 Use: Represents a subtitle component. This constant is used for all subtitle components regardless of subtitle format. NOTE: A subtitle component may also be related to closed captioning as part of a video stream. | |||
| org.hbbtv_PMT0050 | 1 | Notification of change of components - audio added to video/broadcast object (1 component to 2 components) | When an application is running on a service containing 1 audio component and any number of video and subtitle components and a function is assigned to the onComponentChanged event and a second audio component is introduced, the onComponentChanged function is called and componentType is 1. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponents() method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_AUDIO Value: 1 Use: Represents an audio component. This constant is used for all audio components regardless of encoding. | |||
| org.hbbtv_PMT0060 | 1 | Notification of change of components - subtitles added to video/broadcast object (1 component to 2 components) | When an application is running on a service containing 1 subtitle component and any number of video and audio components and a function is assigned to the onComponentChanged event and a second subtitle component is introduced, the onComponentChanged function is called and componentType is 2. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponents() method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_SUBTITLE Value: 2 Use: Represents a subtitle component. This constant is used for all subtitle components regardless of subtitle format. NOTE: A subtitle component may also be related to closed captioning as part of a video stream. | |||
| org.hbbtv_PMT0070 | 1 | getComponents - response to PMT change - audio removed (2 components to 1 component) | When an application is running on a service containing 2 audio components and any number of video and subtitle components and one of the audio components is removed, the getComponents(1) method returns 2 components before the audio component is removed and returns 1 component after the audio component is removed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 getComponents() method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns information from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned , as represented by one of the constant values listed in section 7.16.5.1.1. | |||
| org.hbbtv_PMT0080 | 1 | getComponents - response to PMT change - subtitles removed (2 components to 1 component) | When an application is running on a service containing 2 subtitle components and any number of video and audio components and one of the subtitle components is removed, the getComponents(2) method returns 2 components before the subtitle component is removed and returns 1 component after the subtitle component is removed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 getComponents() method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns information from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned , as represented by one of the constant values listed in section 7.16.5.1.1. | |||
| org.hbbtv_PMT0090 | 1 | getComponents - response to PMT change - audio added (1 component to 2 components) | When an application is running on a service containing 1 audio component and any number of video and subtitle components and a second audio component is introduced, the getComponents(1) method returns 1 component before the audio component is introduced and returns 2 components after the audio component is introduced. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 getComponents() method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns information from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned , as represented by one of the constant values listed in section 7.16.5.1.1. | |||
| org.hbbtv_PMT0100 | 1 | getComponents - response to PMT change - subtitles added (1 component to 2 components) | When an application is running on a service containing 1 subtitle component and any number of video and audio components and a second subtitle component is introduced, the getComponents(2) method returns 1 component before the subtitle component is introduced and returns 2 components after the subtitle component is introduced. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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 getComponents() method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns information from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned , as represented by one of the constant values listed in section 7.16.5.1.1. | |||
| org.hbbtv_PMT0110 | 1 | Notification of change of components - A/V and subtitles removed from video/broadcast object and added back | An application is running on a service containing 1 video component, 1 audio component and 1 subtitle component and a function is assigned to the onComponentChanged event. The video, audio and subtitle components are all removed at the same time and then all added back at the same time. The onComponentChanged function is called twice, once when the components are removed and again when they are added back, and componentType is undefined each time. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 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.17: The video/broadcast and AV Control object shall be extended with the following property: function onComponentChanged. This function is called when there is a change in the set of components that would be returned by the getComponents() method. The specified function is called with one argument: Integer componentType - The type of component for which there has been a change in the current stream, as represented by one of the constant values listed in clause 7.16.5.1.1 of the OIPF DAE specification [1]. If there has been a change for more than one type of component, this argument will take the value undefined. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_VIDEO Value: 0 Use: Represents a video component. This constant is used for all video components regardless of encoding. Name: COMPONENT_TYPE_AUDIO Value: 1 Use: Represents an audio component. This constant is used for all audio components regardless of encoding. Name: COMPONENT_TYPE_SUBTITLE Value: 2 Use: Represents a subtitle component. This constant is used for all subtitle components regardless of subtitle format. NOTE: A subtitle component may also be related to closed captioning as part of a video stream. | |||
| org.hbbtv_PMT0120 | 1 | getComponents - response to PMT change - A/V and subtitles removed from video/broadcast object and added back | An application is running on a service containing 1 video component, 1 audio component and 1 subtitle component. The video, audio and subtitle components are all removed at the same time and then all added back at the same time. Before the components are removed and after the components are added back, getComponents(0), getComponents(1) and getComponents(2) each return 1 component; during the time the components are removed, getComponents(0), getComponents(1) and getComponents(2) each return 0 components. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 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 getComponents() method shall always return fresh information. For example, in the case of an MPEG-2 transport stream, after a change to the PMT. OIPF-DAE,section 7.16.5.1: AVComponentCollection getComponents ( Integer componentType ) If the set of components is known, returns a collection of AVComponent values representing the components of the specified type in the current stream. If componentType is set to null or undefined then all components are returned if they are known. NOTE: In the case of broadcast MPEG-2 transport streams, this method returns information from the PMT but the PMT is not always accurate. Components may be signalled in the PMT which are not actually present all the time. Components may be present but carrying information inconsistent with the PMT, for example a secondary audio stream may be signalled but carrying a copy of the primary audio stream when content for the secondary audio has not been produced. componentType: The type of component to be returned, as represented by one of the constant values listed in section 7.16.5.1.1. OIPF-DAE,section 7.16.5.1.1: The following constants are defined as properties on any objects implementing this section: Name: COMPONENT_TYPE_VIDEO Value: 0 Use: Represents a video component. This constant is used for all video components regardless of encoding. Name: COMPONENT_TYPE_AUDIO Value: 1 Use: Represents an audio component. This constant is used for all audio components regardless of encoding. Name: COMPONENT_TYPE_SUBTITLE Value: 2 Use: Represents a subtitle component. This constant is used for all subtitle components regardless of subtitle format. NOTE: A subtitle component may also be related to closed captioning as part of a video stream. | |||
| org.hbbtv_PRIV0001 | 1 | Do Not Track factory default behaviour | With the terminal in the factory default state, with no legal or regulatory requirements for DNT default behaviour in effect, and with no setup steps required by the terminal before an application can be launched, no DNT header will be included in HTTP requests from an application. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 12.1.1.1: To achieve this, any signal sent shall exclusively reflect the user's preference, not the choice of the terminal manufacturer, or any other mechanism outside the user's control. In the absence of user choice, legal, or regulatory requirements, no tracking preference shall be expressed by the terminal (i.e. the DNT header shall not be included in the HTTP request). | -PRIV_DNT_LEGALREGULATORY | ||
| org.hbbtv_PRIV0002 | 1 | Do Not Track factory default behaviour | With the terminal in the factory default state, with no legal or regulatory requirements for DNT default behaviour in effect, and the terminal requiring setup steps before an application can be launched, during which the user is asked for his tracking preference and the user has opted to not express a preference, no DNT header will be included in HTTP requests from an application. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 12.1.1.1: To achieve this, any signal sent shall exclusively reflect the user's preference, not the choice of the terminal manufacturer, or any other mechanism outside the user's control. In the absence of user choice, legal, or regulatory requirements, no tracking preference shall be expressed by the terminal (i.e. the DNT header shall not be included in the HTTP request). | -PRIV_DNT_LEGALREGULATORY | ||
| org.hbbtv_PRIV0004 | 1 | Do Not Track HTTP header | Depending on the user preferences, zero or one DNT headers may be present in any HTTP request made on behalf of an Hybrid Broadcast Broadband TV application, but never more than one. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 12.1.1.2.2: At most one DNT header can be present in a valid HTTP request. HBBTV,section 12.1.1.2.2: HbbTV terminals shall insert the DNT field into all outgoing HTTP requests made on behalf of an Hybrid Broadcast Broadband TV application as the means for expressing a user's tracking preference via HTTP. NOTE: This does not apply to HTTP requests made by the media player or the DRM agent. It shall be encoded as follows: DNT-field-name = "DNT" DNT-field-value = ( "0" / "1" ) *DNT-extension DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E | |||
| org.hbbtv_PRIV0005 | 1 | Do Not Track - unset | If the DNT user preference is in the unset state (i.e. no preference stated), no DNT header must be sent in any HTTP request made on behalf of an Hybrid Broadcast Broadband TV application. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 12.1.1.2.2: Terminals shall send the DNT header field if (and only if) a tracking preference is enabled. Terminals shall not send the DNT header field if a tracking preference is not enabled. HBBTV,section 12.1.1.2.2: HbbTV terminals shall insert the DNT field into all outgoing HTTP requests made on behalf of an Hybrid Broadcast Broadband TV application as the means for expressing a user's tracking preference via HTTP. NOTE: This does not apply to HTTP requests made by the media player or the DRM agent. It shall be encoded as follows: DNT-field-name = "DNT" DNT-field-value = ( "0" / "1" ) *DNT-extension DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E | |||
| org.hbbtv_PRIV0006 | 1 | Do Not Track - no tracking | If the DNT user preference is in the enabled-disallow state, a DNT:1 header must be sent in any HTTP request made on behalf of an Hybrid Broadcast Broadband TV application. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 12.1.1.2.2: The DNT-field-value sent by an HbbTV terminal shall begin with the numeric character "1" (%x31) if all of the following conditions are met: a) a tracking preference is enabled, b) the preference is for no tracking, c) there is not an exception for the origin server targeted by this request. HBBTV,section 12.1.1.2.2: HbbTV terminals shall insert the DNT field into all outgoing HTTP requests made on behalf of an Hybrid Broadcast Broadband TV application as the means for expressing a user's tracking preference via HTTP. NOTE: This does not apply to HTTP requests made by the media player or the DRM agent. It shall be encoded as follows: DNT-field-name = "DNT" DNT-field-value = ( "0" / "1" ) *DNT-extension DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E | |||
| org.hbbtv_PRIV0007 | 1 | Do Not Track - tracking allowed | If the terminal provides the third DNT state in its user preferences (enabled-allow), and it is selected in the preferences, a DNT:0 header must be sent in any HTTP request made on behalf of an Hybrid Broadcast Broadband TV application. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 12.1.1.2.2: The DNT-field-value sent by an HbbTV terminal shall begin with the numeric character "0" (%x30) if all of the following conditions are met: a) a tracking preference is enabled, b) the preference is to allow tracking in general or by specific exception for the origin server targeted by this request. HBBTV,section 12.1.1.2.2: HbbTV terminals shall insert the DNT field into all outgoing HTTP requests made on behalf of an Hybrid Broadcast Broadband TV application as the means for expressing a user's tracking preference via HTTP. NOTE: This does not apply to HTTP requests made by the media player or the DRM agent. It shall be encoded as follows: DNT-field-name = "DNT" DNT-field-value = ( "0" / "1" ) *DNT-extension DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E | |||
| org.hbbtv_PRIV0008 | 1 | Third party cookies | The terminal shall not accept third party cookies. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 12.1.2: Manufacturers of HbbTV terminals may block all third party cookies. If they do not, then they shall provide the user the option of doing so. | +PRIV_DEFAULT_BLOCK_3RD_PARTY_COOKIES | ||
| org.hbbtv_PRIV0009 | 1 | Blocking tracking websites | The terminal shall provide a setting in user preferences to turn blocking of tracking websites on and off. | 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 12.1.3: Manufacturers of HbbTV terminals should consider providing the option of disallowing requests to tracking websites. If such an option is provided, manufacturers shall allow the user to set this option in a similar way to the DNT setting in clause 12.1. | +PRIV_CAN_BLOCK_TRACKERS | ||
| org.hbbtv_PRIV0010 | 1 | Cookies and Web Storage enabled by default | In factory default state, it must be possible to set a cookie as defined in section 10.2.1, and it must be possible to use Web Storage according to http://www.w3.org/TR/2013/REC-webstorage-20130730/. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 12.1.4: Terminals may offer the user the option to disable persistent storage (cookies, Web Storage) on a per-application or per-site basis. [...] Persistent storage shall not be disabled by default. OIPF-DAE,section 2.1: [WEBSTORAGE-20130730] Ian Hickson. Web Storage. 30 July 2013. W3C Recommendation. URL: http://www.w3.org/TR/2013/REC-webstorage-20130730/ OIPF-DAE,section 7: Terminals SHALL support the Web Storage API [WEBSTORAGE-20130730]. | |||
| org.hbbtv_PRIV0011 | 1 | Third party cookies | The terminal shall provide a setting in user preferences to disallow third party cookies. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 12.1.2: Manufacturers of HbbTV terminals may block all third party cookies. If they do not, then they shall provide the user the option of doing so. | -PRIV_DEFAULT_BLOCK_3RD_PARTY_COOKIES | ||
| org.hbbtv_PTR00001 | 1 | To check the pointer capability from HbbTV app when terminal do not support it. | When terminal does not support pointer-based input then the "pointer" element of the XMLCapability shall either not be present or shall have the value "false". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. | -POINTER | ||
| org.hbbtv_PTR00002 | 1 | To check the pointer capability from HbbTV app when terminal set supports. | When terminal supports pointer-based input then the pointer element of the XMLCapability shall be present and have the value "true". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. | +POINTER | ||
| org.hbbtv_PTR00003 | 1 | Testing the "mousemove" event when terminal set supports pointer. | When terminal supports pointer-based input, and pointing device is moved over element, then DOM Level 3 Mouse event handler will be invoked successfully for "mousemove" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: mousemove [...] A user agent MUST dispatch this event when a pointing device is moved while it is over an element. The frequency rate of events while the pointing device is moved is implementation-, device-, and platform-specific, but multiple consecutive mousemove events SHOULD be fired for sustained pointer-device movement, rather than a single event for each instance of mouse movement. Implementations are encouraged to determine the optimal frequency rate to balance responsiveness with performance. | +POINTER | ||
| org.hbbtv_PTR00004 | 1 | Testing the "dblclick" event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device is clicked over the element twice then DOM Level 3 Mouse event handler will be invoked successfully for "dblclick" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 10.2.2.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: dblclick[...] A user agent MUST dispatch this event when the primary button of a pointing device is clicked twice over an element. The definition of a double click depends on the environment configuration, except that the event target MUST be the same between mousedown, mouseup, and dblclick. This event type MUST be dispatched after the event type click if a click and double click occur simultaneously, and after the event type mouseup otherwise. | +POINTER | |
| org.hbbtv_PTR00005 | 1 | Testing the "mousedown" event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device is pressed over the element then DOM Level 3 Mouse event handler will be invoked successfully for "mousedown" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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 10.2.2.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: mousedown[...] A user agent MUST dispatch this event when a pointing device button is pressed over an element. | +POINTER | |
| org.hbbtv_PTR00006 | 1 | Testing the "mouseup" event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device button is released over the element then DOM Level 3 Mouse event handler will be invoked successfully for "mouseup" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: mouseup[...] A user agent MUST dispatch this event when a pointing device button is released over an element. | +POINTER | ||
| org.hbbtv_PTR00007 | 1 | Testing the "mouseenter" event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device is entered over element then DOM Level 3 Mouse event handler will be invoked successfully for "mouseenter" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: mouseenter[...] A user agent MUST dispatch this event when a pointing device is moved onto the boundaries of an element or one of its descendent elements. This event type is similar to mouseover, but differs in that it does not bubble, and MUST NOT be dispatched when the pointer device moves from an element onto the boundaries of one of its descendent elements. | +POINTER | ||
| org.hbbtv_PTR00008 | 1 | Testing the "mouseleave" event when terminal supports pointer. | When terminal supports pointer-based input, pointing device is on an element which has descendent elements and pointing device is moved off the boundaries of an element and all of its descendent elements, then DOM Level 3 Mouse event handler will be invoked successfully for "mouseleave" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: mouseleave[...] A user agent must dispatch this event when a pointing device is moved off of the boundaries of an element and all of its descendent elements. This event type is similar to mouseout, but differs in that does not bubble, and that it must not be dispatched until the pointing device has left the boundaries of the element and the boundaries of all of its children. | +POINTER | ||
| org.hbbtv_PTR00009 | 1 | Testing the "mouseout" event when terminal supports pointer. | When terminal supports pointer-based input, pointing device is on an element which has descendent elements and pointing device is moved off the boundaries of the element and moved to one of its descendent elements, then DOM Level 3 Mouse event handler will be invoked successfully for "mouseout" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: mouseout[...] A user agent must dispatch this event when a pointing device is moved off of the boundaries of an element. This event type is similar to mouseleave, but differs in that does bubble, and that it must be dispatched when the pointer device moves from an element onto the boundaries of one of its descendent elements. | +POINTER | ||
| org.hbbtv_PTR00010 | 1 | Testing the "mouseover" event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device is moved onto the boundaries of an element then DOM Level 3 Mouse event handler will be invoked successfully for "mouseover" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: mouseover[...] A user agent MUST dispatch this event when a pointing device is moved onto the boundaries of an element. This event type is similar to mouseenter, but differs in that it bubbles, and that it MUST be dispatched when the pointer device moves onto the boundaries of an element whose ancestor element is the event target for the same event listener instance. | +POINTER | ||
| org.hbbtv_PTR00011 | 1 | Testing the "mousemove" event when terminal supports pointer. | When terminal supports pointer-based input, then DOM Level 3 Mouse event handler will be invoked successfully for "mousemove" event, if pointing device is moved over the element A, then it leaves element A and enter into element B, it will fire "mousemove" events for elements A and B. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: mousemove[...] A user agent MUST dispatch this event when a pointing device is moved while it is over an element. | +POINTER | ||
| org.hbbtv_PTR00012 | 1 | Testing the "mousemove" event when terminal supports pointer and we call removeEventListener(). | When terminal supports pointer-based input, and application calls addEventListener() followed by removeEventListener(), and then the pointer device is moved over an element, terminal will not invoke a DOM 3 "mousemove" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: mousemove[...] A user agent MUST dispatch this event when a pointing device is moved while it is over an element. DOM3-Events,section 4.3.1: Methods: Removes an event listener. Calling removeEventListener with arguments that do not identify any currently registered EventListener on the EventTarget has no effect. | +POINTER | ||
| org.hbbtv_PTR00013 | 1 | Testing the "click" event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device is clicked over the element then DOM Level 3 Mouse event handler will be invoked successfully for "click" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: click[...] The click event type MUST be dispatched on the topmost event target indicated by the pointer, when the user presses down and releases the primary pointer button, or otherwise activates the pointer in a manner that simulates such an action. | +POINTER | ||
| org.hbbtv_PTR00014 | 1 | Testing the "onclick" DOM 2 event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device is clicked over the element then DOM 2 Level event handler will be invoked on the registered element with onclick event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM2-Events,section 1.6.2: The click event occurs when the pointing device button is clicked over an element. A click is defined as a mousedown and mouseup over the same screen location. HTML5,section 2.2.2: Implementations must support DOM and the events defined in DOM Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM interfaces. [DOM] [DOMEVENTS] | +POINTER | ||
| org.hbbtv_PTR00016 | 1 | Testing the "onmousedown" DOM 2 event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device is pressed over the element then DOM Level 2 event handler will be invoked on the registered element with "onmousedown" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM2-Events,section 1.6.2: The mousedown event occurs when the pointing device button is pressed over an element. This event is valid for most elements. HTML5,section 2.2.2: Implementations must support DOM and the events defined in DOM Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM interfaces. [DOM] [DOMEVENTS] | +POINTER | ||
| org.hbbtv_PTR00017 | 1 | Testing the "onmouseup" DOM 2 event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device is pressed and released over the element then DOM Level 2 event handler will be invoked on the registered element with "onmouseup" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM2-Events,section 1.6.2: The mouseup event occurs when the pointing device button is released over an element. This event is valid for most elements. HTML5,section 2.2.2: Implementations must support DOM and the events defined in DOM Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM interfaces. [DOM] [DOMEVENTS] | +POINTER | ||
| org.hbbtv_PTR00018 | 1 | Testing the "onmouseover" DOM 2 event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device is moved over the element then DOM Level 2 event handler will invoked on the registered element with "onmouseover" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM2-Events,section 1.6.2: The mouseover event occurs when the pointing device is moved onto an element. This event is valid for most elements. HTML5,section 2.2.2: Implementations must support DOM and the events defined in DOM Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM interfaces. [DOM] [DOMEVENTS] | +POINTER | ||
| org.hbbtv_PTR00019 | 1 | Testing the "onmouseout" DOM 2 event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device is moved over the element, then DOM Level 2 event handler will be invoked on the registered element with "onmouseout" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM2-Events,section 1.6.2: The mouseout event occurs when the pointing device is moved away from an element. This event is valid for most elements. HTML5,section 2.2.2: Implementations must support DOM and the events defined in DOM Events, because this specification is defined in terms of the DOM, and some of the features are defined as extensions to the DOM interfaces. [DOM] [DOMEVENTS] | +POINTER | ||
| org.hbbtv_PTR00020 | 1 | Testing the "wheel" event when terminal supports pointer. | When terminal supports pointer-based input, and pointing device wheel is moved over element, then the DOM Level 3 Mouse wheel event handler will be invoked successfully for "wheel" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.4: Wheel Event Types: Wheels are devices that can be rotated in one or more spatial dimensions, and which can be associated with a pointer device. The deltaMode attribute contains an indication of the units of measurement for the delta values. The default value is DOM_DELTA_PIXEL (pixels). DOM3-Events,section 5.2.4: wheel[...] A user agent MUST dispatch this event when a mouse wheel has been rotated around any axis, or when an equivalent input device (such as a mouse-ball, certain tablets or touchpads, etc.) has emulated such an action. | +POINTER +WHEEL | ||
| org.hbbtv_PTR00021 | 1 | Testing the "wheel" event when terminal supports pointer and we unregistered the event by using removeEventListener(). | When terminal supports pointer-based input, and application calls addEventListener() followed by removeEventListener(), and then the pointer device wheel is moved over an element, terminal will not invoke a DOM 3 pointer device wheel event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.4: Wheel Event Types: Wheels are devices that can be rotated in one or more spatial dimensions, and which can be associated with a pointer device. The deltaMode attribute contains an indication of the units of measurement for the delta values. The default value is DOM_DELTA_PIXEL (pixels). DOM3-Events,section 5.2.4: wheel[...] A user agent MUST dispatch this event when a mouse wheel has been rotated around any axis, or when an equivalent input device (such as a mouse-ball, certain tablets or touchpads, etc.) has emulated such an action. DOM3-Events,section 4.3.1: Methods: Removes an event listener. Calling removeEventListener with arguments that do not identify any currently registered EventListener on the EventTarget has no effect. | +POINTER +WHEEL | ||
| org.hbbtv_PTR00022 | 1 | Testing the "deltamode" attribute when terminal supports pointer it should return one of these values. | When terminal supports pointer-based input, and pointing device wheel is moved over element. Then DOM Level 3 wheel event handler will be invoked for "wheel" event, and generate the "deltamode" attribute. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.4: Wheel Event Types: Wheels are devices that can be rotated in one or more spatial dimensions, and which can be associated with a pointer device. The deltaMode attribute contains an indication of the units of measurement for the delta values. The default value is DOM_DELTA_PIXEL (pixels). DOM3-Events,section 5.2.4: deltamode[...] A user agent MUST dispatch this event when a mouse wheel has been rotated around any axis, or when an equivalent input device (such as a mouse-ball, certain tablets or touchpads, etc.) has emulated such an action. Depending on the platform and input device, diagonal wheel deltas MAY be delivered either as a single wheel event with multiple non-zero axes or as separate wheel events for each non-zero axis. | +POINTER +WHEEL | ||
| org.hbbtv_PTR00023 | 1 | Testing the "deltaX" event when terminal supports pointer and "deltamode" attribute should be set. | When terminal supports pointer-based input, and pointing device wheel is moved over element in the horizontal direction, then DOM Level 3 Mouse wheel event handler will be invoked successfully for "wheel" event and "deltaX" will be modified accordingly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 10.2.2.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.4: Wheel Event Types: Wheels are devices that can be rotated in one or more spatial dimensions, and which can be associated with a pointer device. In user agents where the default action of the wheel event is to scroll, the value must be the measurement along the x-axis in pixels, lines, or pages. DOM3-Events,section 5.2.4: deltaX[...] In user agents where the default action of the wheel event is to scroll, the value MUST be the measurement along the x-axis (in pixels, lines, or pages) to be scrolled in the case where the event is not cancelled. Otherwise, this is an implementation-specific measurement (in pixels, lines, or pages) of the movement of a wheel device around the x-axis. | +POINTER +WHEEL_X | ||
| org.hbbtv_PTR00024 | 1 | Testing the "deltaY" event when terminal supports pointer and "deltamode" attribute should be set. | When terminal supports pointer-based input, and pointing device wheel is moved over element in vertical direction, then DOM Level 3 Mouse wheel event handler will be invoked successfully for "wheel" event and "deltaY" will be modified accordingly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 10.2.2.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.4: Wheel Event Types: Wheels are devices that can be rotated in one or more spatial dimensions, and which can be associated with a pointer device. In user agents where the default action of the wheel event is to scroll, the value must be the measurement along the Y-axis in pixels, lines, or pages. DOM3-Events,section 5.2.4: deltaY[...] In user agents where the default action of the wheel event is to scroll, the value MUST be the measurement along the y-axis (in pixels, lines, or pages) to be scrolled in the case where the event is not cancelled. Otherwise, this is an implementation-specific measurement (in pixels, lines, or pages) of the movement of a wheel device around the y-axis. | +POINTER +WHEEL_Y | ||
| org.hbbtv_PTR00025 | 1 | Testing the "deltaZ" event when terminal supports pointer and "deltamode" attribute should be set. | When terminal supports pointer-based input, and pointing device wheel is moved over element to ZOOM IN or ZOOM OUT. Then DOM Level 3 Mouse wheel event handler will be invoked successfully for "wheel" event and "deltaZ" will be modified accordingly. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 10.2.2.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.4: Wheel Event Types: Wheels are devices that can be rotated in one or more spatial dimensions, and which can be associated with a pointer device. In user agents where the default action of the wheel event is to scroll, the value must be the measurement along the z-axis in pixels, lines, or pages. DOM3-Events,section 5.2.4: deltaZ[...] In user agents where the default action of the wheel event is to scroll, the value MUST be the measurement along the z-axis (in pixels, lines, or pages) to be scrolled in the case where the event is not cancelled. Otherwise, this is an implementation-specific measurement (in pixels, lines, or pages) of the movement of a wheel device around the z-axis. | +POINTER +WHEEL_Z | ||
| org.hbbtv_PTR00026 | 1 | Testing the "mouseleave" event when pointing device is moved off the boundaries of an element but not outside the boundaries of all of its descendent elements. | When terminal supports pointer-based input, pointing device is on an element which has descendent elements and pointing device is moved off the boundaries of an element but not outside the boundaries of all of its descendent elements, then DOM Level 3 Mouse event handler will be not be invoked for "mouseleave" event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: If a terminal indicates that it has pointer support in the capability profile as defined in clause 9 of the OIPF DAE specification [1], implementations shall provide a mechanism for the end user to generate mouse events and may provide a mechanism for the end user to generate wheel events as defined in clause 9.3.24 of the OIPF DAE specification [1]. OIPF-DAE,section 9.3.24: Pointer support: The pointer element indicates whether or not the OITF provides the user with a way to make pointer-based input (such as mouse or touch) to the browser. If the capability is true then the OITF SHALL be able to generate all pointer device event types as included in the Web Standards terminal Profile [OIPF_DAE2_WEB]. DOM3-Events,section 5.2.3: Mouse Event Types: The pointer device event module originates click, dblclick, mousedown, mouseup, mouseover, mousemove, and mouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball. DOM3-Events,section 5.2.3: mouseleave[...] A user agent must dispatch this event when a pointing device is moved off of the boundaries of an element and all of its descendent elements. This event type is similar to mouseout, but differs in that does not bubble, and that it must not be dispatched until the pointing device has left the boundaries of the element and the boundaries of all of its children. | +POINTER | ||
| org.hbbtv_QUIET0010 | 2 | setChannel with quiet value 0 | A broadcast-related application creates a video/broadcast object and binds it to the current channel. When it calls the setChannel method on that video/broadcast object with the quiet argument set to zero, the HbbTV terminal changes to the specified channel. Any channel change banner displays the new channel and any front panel display displays the new channel. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.1: The following changes shall apply to the video/broadcast object to support "quiet" service selection. void setChannel( Channel channel, Boolean trickplay, String contentAccessDescriptorURL, Number quiet ) HBBTV,section A.2.4.3.2: For the setChannel() method, if the quiet argument is set to 0 or is omitted then the terminal shall execute the channel change operation normally. Typically, this means that the viewer experience is exactly as if they had initiated a standard channel change operation using any of the terminal's inherent channel navigation mechanisms, e.g. using the Ch+ or Ch- keys or numeric entry. This may be reflected in (but not restricted to): • Presentation of any channel information on the terminal's front panel. • Presentation of any now/next information or channel banner. • The channel from which any relative navigation, such as Ch+/- or calls to prevChannel() or nextChannel(), shall be performed. | |||
| org.hbbtv_QUIET0020 | 2 | setChannel with quiet value 1 | A broadcast-related application creates a video/broadcast object and binds it to the current channel. When it calls the setChannel method on that video/broadcast object with the quiet argument set to one, the HbbTV terminal changes to the specified channel. No channel change banner or equivalent is drawn by the HbbTV terminal. Any front panel display or channel info UI shows the new channel. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.1: The following changes shall apply to the video/broadcast object to support "quiet" service selection. void setChannel( Channel channel, Boolean trickplay, String contentAccessDescriptorURL, Number quiet ) HBBTV,section A.2.4.3.2: If the quiet argument is set to 1 then the terminal shall execute the channel change operation but shall not present any channel banner that is usually displayed by the terminal. ... After a channel change where the quiet argument is set to a value of 1 or 2, the application lifecycle shall be identical to a normal channel change, i.e. one where the quiet argument is set to the value 0 or omitted. The lifecycle of the application shall follow the rules defined in sections 6.2.2.2 and 6.2.2.3 of the present document. The AIT of the new channel shall be obeyed following the channel change operation. | |||
| org.hbbtv_QUIET0030 | 2 | setChannel with quiet value 2 | A broadcast-related application creates a video/broadcast object and binds it to the current channel. When it calls the setChannel method on that video/broadcast object with the quiet argument set to two, the HbbTV terminal changes to the specified channel. No channel change banner or equivalent is drawn by the HbbTV terminal. Any front panel display or channel info UI shows the original channel. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-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.2.4.3.1: The following changes shall apply to the video/broadcast object to support "quiet" service selection. void setChannel( Channel channel, Boolean trickplay, String contentAccessDescriptorURL, Number quiet ) HBBTV,section A.2.4.3.2: If the quiet argument is set to 2 then the terminal shall execute the channel change operation quietly. This means that the terminal shall suppress the presentation of all information usually presented during a channel change operation. In addition, the channel selected by the last normal channel change operation shall be used for all relevant interaction with the terminal by the viewer, which may include (but is not restricted to): • Presentation of any channel information on the terminal's front panel. • Presentation of any now/next information or channel banner. • The channel from which any relative navigation, such as Ch+/- or calls to prevChannel() or nextChannel(), shall be performed. The channel which is reported to HbbTV applications as the current channel shall be the actual channel currently selected, regardless of the type of channel change by which it was selected. After a channel change where the quiet argument is set to a value of 1 or 2, the application lifecycle shall be identical to a normal channel change, i.e. one where the quiet argument is set to the value 0 or omitted. The lifecycle of the application shall follow the rules defined in sections 6.2.2.2 and 6.2.2.3 of the present document. The AIT of the new channel shall be obeyed following the channel change operation. | |||
| org.hbbtv_QUIET0040 | 2 | setChannel with quiet value 2 - next | A broadcast-related application creates a video/broadcast object and binds it to the current channel (channel 'A'). The application calls the setChannel method on that video/broadcast object to change to channel 'B' with the quiet argument set to two. Once the HbbTV terminal has successfully changed to channel 'B', the HbbTV application calls nextChannel and the channel changes to the next channel relative to channel 'A' and not to the next channel relative to channel 'B'. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.1: The following changes shall apply to the video/broadcast object to support "quiet" service selection. void setChannel( Channel channel, Boolean trickplay, String contentAccessDescriptorURL, Number quiet ) HBBTV,section A.2.4.3.2: If the quiet argument is set to 2 then the terminal shall execute the channel change operation quietly. This means that the terminal shall suppress the presentation of all information usually presented during a channel change operation. In addition, the channel selected by the last normal channel change operation shall be used for all relevant interaction with the terminal by the viewer, which may include (but is not restricted to): • Presentation of any channel information on the terminal's front panel. • Presentation of any now/next information or channel banner. • The channel from which any relative navigation, such as Ch+/- or calls to prevChannel() or nextChannel(), shall be performed. The channel which is reported to HbbTV applications as the current channel shall be the actual channel currently selected, regardless of the type of channel change by which it was selected. After a channel change where the quiet argument is set to a value of 1 or 2, the application lifecycle shall be identical to a normal channel change, i.e. one where the quiet argument is set to the value 0 or omitted. The lifecycle of the application shall follow the rules defined in sections 6.2.2.2 and 6.2.2.3 of the present document. The AIT of the new channel shall be obeyed following the channel change operation. | |||
| org.hbbtv_QUIET0050 | 2 | setChannel with quiet value 2 - prev | A broadcast-related application creates a video/broadcast object and binds it to the current channel (channel 'A'). The application calls the setChannel method on that video/broadcast object to change to channel 'B' with the quiet argument set to two. Once the HbbTV terminal has successfully changed to channel 'B', the HbbTV application calls prevChannel and the channel changes to the previous channel relative to channel 'A' and not to the previous channel relative to channel 'B'. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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.2.4.3.1: The following changes shall apply to the video/broadcast object to support "quiet" service selection. void setChannel( Channel channel, Boolean trickplay, String contentAccessDescriptorURL, Number quiet ) HBBTV,section A.2.4.3.2: If the quiet argument is set to 2 then the terminal shall execute the channel change operation quietly. This means that the terminal shall suppress the presentation of all information usually presented during a channel change operation. In addition, the channel selected by the last normal channel change operation shall be used for all relevant interaction with the terminal by the viewer, which may include (but is not restricted to): • Presentation of any channel information on the terminal's front panel. • Presentation of any now/next information or channel banner. • The channel from which any relative navigation, such as Ch+/- or calls to prevChannel() or nextChannel(), shall be performed. The channel which is reported to HbbTV applications as the current channel shall be the actual channel currently selected, regardless of the type of channel change by which it was selected. After a channel change where the quiet argument is set to a value of 1 or 2, the application lifecycle shall be identical to a normal channel change, i.e. one where the quiet argument is set to the value 0 or omitted. The lifecycle of the application shall follow the rules defined in sections 6.2.2.2 and 6.2.2.3 of the present document. The AIT of the new channel shall be obeyed following the channel change operation. | |||
| org.hbbtv_RELIABILITY01 | 1 | Broadband broadcast content switch, A/V control playout to the end | A broadcast-related HbbTV application does not include video broadcast object and is presenting MPEG-2 SD video + MPEG-1 layer 2 audio + broadcast subtitles. An A/V control object size is 1/2 x 1/2 of screen size. The application starts playback (and presentation) of to MPEG2 TS file AVC_25_HD_HEAAC without subtitles using the A/V Control object. When the playout is finished, the terminal automatically resumes presentation of broadcast video, audio and subtitles. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.8: Terminals shall be able to reliably switch from presenting broadcast video, audio and subtitles to presenting broadband video, audio and then return to presenting broadcast video, audio and subtitles. Including specifically the following • Both where the broadband content is played to the end and where playback is stopped before the end is reached HBBTV,section A.2.1: If a broadcast-related application that either does not include a video/broadcast object at all or includes a video/broadcast object that is in the unrealized state attempts to start playing broadband-delivered video/audio then the presentation of the broadcast channel shall be suspended and allocation of the required media resources by the A/V control object shall succeed. After the A/V control object release the allocated resources, e.g. by stopping the media, presentation of the broadcast service shall resume. OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object SHALL be released when state 6 (‘error’) or 0 (‘stopped’) or 5 (‘finished’) are reached | |||
| org.hbbtv_RELIABILITY02 | 1 | Broadband broadcast content switch, A/V control playout stopped in the middle | A broadcast-related HbbTV application includes an video/broadcast object presenting AVC HD 25 + HEAAC + broadcast subtitles and an A/V Control object with data referring to static DASH MPD with AVC_HD_25 + HEAAC. The video/broadcast object is in the fullscreen mode. The application moves video/broadcast object to the stopped state, then starts playout of the broadband video. When the playout of the A/V Control object is stopped before reaching end of media and the application moves video/broadcast object to presenting state then presentation of broadcast content by video/broadcast object is resumed and the terminal presents video, audio and subtitles. | 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 9.8: Terminals shall be able to reliabily switch from presenting broadcast video, audio and subtitles to presenting broadband video, audio and then return to presenting broadcast video, audio and subtitles. Including specifically the following • Both where the broadband content is played to the end and where playback is stopped before the end is reached OIPF-DAE,section 7.14.1.1: Scarce resources for playback using the A/V Control object SHALL be released when state 6 (‘error’) or 0 (‘stopped’) or 5 (‘finished’) are reached | |||
| org.hbbtv_RELIABILITY03 | 1 | Broadband broadcast content switch, HTML5 video playout to the end, Audio Description resume | A broadcast service includes: AVC HD 25 video, HEAAC ( primary audio ), HEAAC (Audio Description), broadcast subtitles, an autostart broadcast-related HbbTV application. The application includes a video broadcast object and an HTML5 video element with src referring to ISOBMFF mp4 file AVC_HD_25 + HEAAC (no audio description). The application moves the video/broadcast object to the stopped state, then starts playout of the video element. When playout is finished due to reaching end of media, application releases the video element resource and moves video/broadcast object to the presenting state, then the presentation of broadcast is resumed and the terminal presents the broadcast video and the AD audio. | 2024-1 2023-3 2023-2 2023-1 2021-3 2021-2 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.8: Terminals shall be able to reliabily switch from presenting broadcast video, audio and subtitles to presenting broadband video, audio and then return to presenting broadcast video, audio and subtitles. Including specifically the following • Both where the broadband content is played to the end and where playback is stopped before the end is reached • Including where the broadband content has subtitles (and the user has enabled subtitles), where the broadband content has subtitles (but the user has disabled subtitles) and where it does not have subtitles. • Both where the broadband content is preloaded using the load method and where it is played without that method being used. HBBTV,section 10.2.7.2: Terminals shall support a method for the user to enable and disable audio description streams | |||
| org.hbbtv_RELIABILITY04 | 1 | Broadband broadcast content switch, subtitles disabled | A broadcast service includes: AVC HD 25 video, HEAAC, primary audio broadcast subtitles, an autostart broadcast-related HbbTV application. The subtitles are disabled. The application includes a video broadcast object and moves it to stopped state. After that in the same event loop spin, the application creates an HTML5 video element, adds to it source element referring to broadband ISOBMFF MP4 file AVC_HD_25 + HEAAC encoded and track elements referring to EBU-TT-D out-of-band subtitles, calls to 'play' of the video element. No 'load' method is called. After the broadband video playout is finished, the video element is removed from the DOM tree. After that, when the video/broadcast object is released then: presentation of broadcast video returns to the terminal, the presentation of broadcast both video and the audio is resumed, the subtitles are not displayed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2021-2 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.2: Hardware resources shall also be released if the HTML5 media element is removed from the DOM and no other references to it exist (see Annex J for a code example of how to achieve this). When resources are released, the terminal may discard any decoded frames that have not been displayed. HBBTV,section 9.8: Terminals shall be able to reliabily switch from presenting broadcast video, audio and subtitles to presenting broadband video, audio and then return to presenting broadcast video, audio and subtitles. Including specifically the following • Both where the broadband content is played to the end and where playback is stopped before the end is reached • Including where the broadband content has subtitles (and the user has enabled subtitles), where the broadband content has subtitles (but the user has disabled subtitles) and where it does not have subtitles. • Both where the broadband content is preloaded using the load method and where it is played without that method being used. HBBTV,section 10.2.7.2: Terminals shall support a method for the user to enable and disable subtitles and to select at least one preferred subtitle language. | |||
| org.hbbtv_RELIABILITY05 | 1 | Broadband broadcast content switch, preloaded content | A broadcast service includes: AVC HD 25 video, HEAAC, primary audio broadcast subtitles (default language), broadcast subtitles (for hard of hearing), an autostart broadcast-related HbbTV application. The subtitles are enabled, the default language subtitles are displayed with video. The application includes a video broadcast object and moves it to fullscreen mode and stopped state. After that all the steps are performed in the same event loop spin: the application creates an HTML5 video element, adds to it source element referring to broadband ISOBMFF MP4 file AVC_HD_25 + HEAAC encoded and track element referring to EBU-TT-D out-of-band subtitles. sets the 'mode' attribute of TextTrack to 'Showing by default', sets the 'kind' attribute of TextTrack to 'captions'. calls to 'load' of the video element. When the video element reach the 'HAVE_ENOUGH_DATA' ready state, then the application moves the video element to 'playing' state. After that, when the playout is finished, the video element is removed from DOM tree and video/broadcast object is moved to 'presenting' play state. After that, the terminal resumes presentation of broadcast video, audio and the default language subtitles. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2021-3 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.6.2: Hardware resources shall also be released if the HTML5 media element is removed from the DOM and no other references to it exist (see Annex J for a code example of how to achieve this). When resources are released, the terminal may discard any decoded frames that have not been displayed. HBBTV,section 9.8: Terminals shall be able to reliabily switch from presenting broadcast video, audio and subtitles to presenting broadband video, audio and then return to presenting broadcast video, audio and subtitles. Including specifically the following • Both where the broadband content is played to the end and where playback is stopped before the end is reached • Including where the broadband content has subtitles (and the user has enabled subtitles), where the broadband content has subtitles (but the user has disabled subtitles) and where it does not have subtitles. • Both where the broadband content is preloaded using the load method and where it is played without that method being used. HBBTV,section 10.2.7.2: Terminals shall support a method for the user to enable and disable subtitles and to select at least one preferred subtitle language. HTML5,section 4.8.9: captions Captions Transcription or translation of the dialogue, sound effects, relevant musical cues, and other relevant audio information, suitable for when the soundtrack is unavailable (e.g. because it is muted or because the user is deaf). Displayed over the video; labeled as appropriate for the hard-of-hearing. HTML5,section 4.8.10.10.1: Showing by default Indicates that the text track is active | |||
| org.hbbtv_RELIABILITY06 | 1 | Broadband broadcast content switch, HTML5 video playout stopped in the middle | A broadcast-related HbbTV application includes a video broadcast object presenting AVC HD 25 + HEAAC + broadcast subtitles and an HTML5 video element with src referring to static DASH MPD with AVC_HD_25 + HEAAC + TTML subtitles, language of subtitles is different than the language of subtitles present in broadcast. The application moves video/broadcast object to the stopped state, then starts playout of the video element. Next, the application attempts to present broadband subtitles by setting mode attribute to 'showing' of the text track element. After that, when the playout is stopped before reaching end of media and the application releases both the video element resource and the video/broadcast resource (call to release) then the presentation of broadcast is resumed and the terminal automatically resumes presentation of broadcast video, audio and subtitles. | 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.5.1: Reception of EBU-TT-D subtitles shall be supported in-band in the following ways: with MPEG DASH content as defined in annex E and the DVB DASH specification [45]; HBBTV,section 9.8: Terminals shall be able to reliabily switch from presenting broadcast video, audio and subtitles to presenting broadband video, audio and then return to presenting broadcast video, audio and subtitles. Including specifically the following • Both where the broadband content is played to the end and where playback is stopped before the end is reached • Including where the broadband content has subtitles (and the user has enabled subtitles), where the broadband content has subtitles (but the user has disabled subtitles) and where it does not have subtitles. • Both where the broadband content is preloaded using the load method and where it is played without that method being used. HTML5,section 4.8.10.1: Showing Showing by default Indicates that the text track is active. If no attempt has yet been made to obtain the track's cues, the user agent will perform such an attempt momentarily. The user agent is maintaining a list of which cues are active, and events are being fired accordingly. In addition, for text tracks whose kind is subtitles or captions, the cues are being displayed over the video as appropriate; for text tracks whose kind is descriptions, the user agent is making the cues available to the user in a non-visual fashion; and for text tracks whose kind is chapters, the user agent is making available to the user a mechanism by which the user can navigate to any point in the media resource by selecting a cue. | |||
| org.hbbtv_RLNCH0040 | 1 | REMOTE LAUNCH: Successful launching HbbTV app with user approval | When the companion screen app requests the launch of an HbbTV Application using a proper HTTP POST message and the launch of the HbbTV application is approved by the user, the terminal shall successfully launch the HbbTV application and respond with HTTP status code 201. | 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-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.6.2: On receiving the HTTP POST request, the terminal shall attempt to launch the HbbTV application. If the launch succeeds then the terminal shall respond with the response code 201. [...] The terminal might have states where the feature is temporarily unavailable, e.g. during a channel scan. The states when the feature is not available are not defined by the present document. [...] Terminals shall not, by default, launch applications without at least one of the following approvals or pre-approvals: * Explicit approval by the user to launch the application at the time the launch request is made. [...] The HbbTV application shall be deemed to have launched successfully when the current document readiness of the Document object of the application transitions from “loading” to the next state. | +RLAUNCH_USER_APPROVAL | ||
| org.hbbtv_RLNCH0041 | 1 | REMOTE LAUNCH: Successful launching HbbTV app with pre-approval | When the companion screen app requests the launch of an HbbTV Application using a proper HTTP POST message and the HbbTV application is pre-approved, the terminal shall successfully launch the HbbTV application and respond with HTTP status code 201. | 2024-1 2023-3 2023-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 14.6.2: On receiving the HTTP POST request, the terminal shall attempt to launch the HbbTV application. If the launch succeeds then the terminal shall respond with the response code 201. [...] The HbbTV application shall be deemed to have launched successfully when the current document readiness of the Document object of the application transitions from “loading” to the next state. [...] The terminal might have states where the feature is temporarily unavailable, e.g. during a channel scan. The states when the feature is not available are not defined by the present document. [...] Terminals shall not, by default, launch applications without at least one of the following approvals or pre-approvals: [...] * Explicit pre-approval by the user that the specific application can be launched (for example by the mechanism referred to above). * Explicit pre-approval by the manufacturer. * Explicit pre-approval by another party managing the network or market where the terminal is located. [...] NOTE 2: For HbbTV terminals which only use pre-approval, it may be necessary for some applications to be pre- approved (and others not to be pre-approved) in order to run the HbbTV test suite. | +RLAUNCH_PREAPPROVAL | ||
| org.hbbtv_RLNCH0050 | 1 | REMOTE LAUNCH: App not found - user approval | When a companion screen app requests the launch of an HbbTV Application, that has been approved by the user, using a proper HTTP POST message but the URL of the HbbTV application is temporarily unavailable, the terminal shall respond with HTTP status code 404. | 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-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.6.2: On receiving the HTTP POST request, the terminal shall attempt to launch the HbbTV application. [...] If the launch could not be completed because the application could not be retrieved successfully then the terminal shall respond with the response code 404. [...] The terminal might have states where the feature is temporarily unavailable, e.g. during a channel scan. The states when the feature is not available are not defined by the present document. [...] Terminals shall not, by default, launch applications without at least one of the following approvals or pre-approvals: * Explicit approval by the user to launch the application at the time the launch request is made. | +RLAUNCH_USER_APPROVAL | ||
| org.hbbtv_RLNCH0051 | 1 | REMOTE LAUNCH: App not found - pre-approval | When a companion screen app requests the launch of an HbbTV Application, that has been pre-approved, using a proper HTTP POST message but the URL of the HbbTV application is temporarily unavailable, the terminal shall respond with HTTP status code 404. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 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.6.2: On receiving the HTTP POST request, the terminal shall attempt to launch the HbbTV application. [...] If the launch could not be completed because the application could not be retrieved successfully then the terminal shall respond with the response code 404. [...] The terminal might have states where the feature is temporarily unavailable, e.g. during a channel scan. The states when the feature is not available are not defined by the present document. [...] Terminals shall not, by default, launch applications without at least one of the following approvals or pre-approvals: * Explicit approval by the user to launch the application at the time the launch request is made. | +RLAUNCH_PREAPPROVAL | ||
| org.hbbtv_RLNCH0060 | 1 | REMOTE LAUNCH: Response Code SERVICE UNAVAILABLE | When the companion screen app requests the launch of the HbbTV application using a proper HTTP POST message in a state where the terminal feature is temporarily unavailable, the terminal shall repond with the HTTP status code 503. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 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.6.2: The terminal might have states where the feature is temporarily unavailable, e.g. during a channel scan. The states when the feature is not available are not defined by the present document. If the terminal rejects the application launch for this reason it shall respond with the response code 503. | +RLAUNCH_TEMP_UNAVAILABLE | ||
| org.hbbtv_RLNCH0070 | 1 | REMOTE LAUNCH: Launch denied by user | When a companion screen application has sent a request to launch an application that was not approved or pre-approved yet, the terminal shall request the user's approval which shall not be given, i.e. the request shall be denied by the user, and then the terminal shall respond to the request with a status code 403, a Content-Type header set to "text/plain" and the response body containing only the 4 character string "USER". | 2024-1 2023-3 2023-2 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 14.6.2: On receiving the HTTP POST request, the terminal shall attempt to launch the HbbTV application. [...] Terminals shall not, by default, launch applications without at least one of the following approvals or pre-approvals: * Explicit approval by the user to launch the application at the time the launch request is made. [...] 'The terminal UI should provide means for the user to control the use of this feature. This may include means for the user to accept or block requests from particular companion devices or for particular HbbTV applications. If the terminal rejects the application launch for this reason it shall respond with the response code 403, where the body of the response is the 4 character string "USER" and has content type "text/plain". | +RLAUNCH_USER_APPROVAL | ||
| org.hbbtv_RLNCH0071 | 1 | REMOTE LAUNCH: Launch denied by terminal | When a companion screen app requests the launch of an HbbTV Application using a proper HTTP POST message and the HbbTV application is not pre-approved, the terminal responds with the HTTP status code 403 and an empty response body. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 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.6.2: On receiving the HTTP POST request, the terminal shall attempt to launch the HbbTV application. [...] Terminals shall not, by default, launch applications without at least one of the following approvals or pre-approvals: * Explicit pre-approval by the manufacturer. * Explicit pre-approval by another party managing the network or market where the terminal is located [...] If the terminal rejects the request for reasons other than any of the above, then it shall respond with the response code 403, with an empty response body. | +RLAUNCH_PREAPPROVAL -RLAUNCH_USER_APPROVAL | ||
| org.hbbtv_RLNCH0090 | 1 | REMOTE LAUNCH: URL check fails - user re-approval | When a companion screen application first requests to launch an application that is either pre-approved by the user or the user approves the launch, the terminal shall launch this application and respond with the status 201. When the companion screen app then requests to launch an application using an XMLAIT that is identical to the first request except for the applicationLocation part and this combination of applicationTransport and applicationLocation, i.e. the HTTP URL, have not been pre-approved yet, the terminal shall ask the user for approval. | 2024-1 2023-3 2023-2 2023-1 2022-1 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 14.6.2: On receiving the HTTP POST request, the terminal shall attempt to launch the HbbTV application. [...] If the launch succeeds then the terminal shall respond with the response code 201. [...] Terminals shall not, by default, launch applications without at least one of the following approvals or pre-approvals: * Explicit approval by the user to launch the application at the time the launch request is made. [...] In cases of pre-approval, at the time of approval, the applicationTransport and applicationLocation elements from the XML AIT shall be stored. At the time launching is requested, the terminal shall determine if an application is pre-approved by comparing the complete applicationTransport element and of that part of the applicationLocation element excluding any query or fragment from the request to launch an application with the set of pre-approved values. If a match is found for both of these then the application shall be considered pre-approved regardless of mismatches in other values from the XML AIT. If a requested application is not pre-approved then terminals that support explicit approval by the user to launch the application at the time the launch request is made shall ask the user for that explicit approval. | +RLAUNCH_USER_APPROVAL | ||
| org.hbbtv_RLNCH0091 | 1 | REMOTE LAUNCH: URL check fails - request denied | When a companion screen application first requests to launch an application that is pre-approved, the terminal shall launch this application and respond with the status 201. When the companion screen app then requests to launch an application using an XMLAIT that is identical to the first request except for the applicationLocation part and this combination of applicationTransport and applicationLocation, i.e. the HTTP URL, have not been pre-approved yet, the terminal shall deny the request and respond with the status code 403. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: On receiving the HTTP POST request, the terminal shall attempt to launch the HbbTV application. [...] Terminals shall not, by default, launch applications without at least one of the following approvals or pre-approvals: * Explicit pre-approval by the user that the specific application can be launched (for example by the mechanism referred to above). * Explicit pre-approval by the manufacturer. * Explicit pre-approval by another party managing the network or market where the terminal is located In cases of pre-approval, at the time of approval, the applicationTransport and applicationLocation elements from the XML AIT shall be stored. At the time launching is requested, the terminal shall determine if an application is pre-approved by comparing the complete applicationTransport element and of that part of the applicationLocation element excluding any query or fragment from the request to launch an application with the set of pre-approved values. If a match is found for both of these then the application shall be considered pre-approved regardless of mismatches in other values from the XML AIT. [...] NOTE: For HbbTV terminals which only use pre-approval, it may be necessary for some applications to be pre-approved (and others not to be pre-approved) in order to run the HbbTV test suite. [...] If the terminal rejects the request for reasons other than any of the above, then it shall respond with the response code 403, with an empty response body. | +RLAUNCH_PREAPPROVAL -RLAUNCH_USER_APPROVAL | ||
| org.hbbtv_RLNCH0120 | 1 | REMOTE LAUNCH: Options method | When the terminal receives an HTTP cross-origin request using the OPTIONS method, which is targeting the Application Launch service end-point, then it shall process the request as preflight including the following headers in the HTTP response: Access-Control-Allow-Origin, Access-Control-Max-Age, Access-Control-Allow-Methods and Access-Control-Allow-Headers. The value of the response headers shall confirm that the terminal permits a subsequent POST request to come from any origin. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Specifically, when the HbbTV terminal receives an HTTP request with request URL targetting the UPnP device description or the DIAL REST Service: * If the request uses the OPTIONS method, the HbbTV terminal shall process the request as a preflight request in accordance with clause 6.2 of the W3C Cross-Origin Resource Sharing recommendation [42] including the following HTTP headers in the HTTP response as appropriate: Access-Control-Allow-Origin, Access-Control-Max-Age, Access-Control-Allow-Methods and Access-Control-Allow-Headers. These headers shall be used to indicate that requests are permitted from any origin and to confirm that a CS application may use the HTTP POST. | |||
| org.hbbtv_RLNCH0130 | 1 | REMOTE LAUNCH: Cross-origin-response - user approved | When the terminal receives an HTTP request targeting the Application Launch service endpoint containing an Origin header and the user approves the app launch, the terminal shall launch the application and respond with an HTTP status code 201 including an Access-Control-Allow-Origin header. The value of this response header shall either be the asterisk character "*" or a case-sensitive match for the value of the Origin header from the HTTP request. | 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-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 14.6.2: On receiving the HTTP POST request, the terminal shall attempt to launch the HbbTV application. [...] The terminal might have states where the feature is temporarily unavailable, e.g. during a channel scan. The states when the feature is not available are not defined by the present document. [...] Terminals shall not, by default, launch applications without at least one of the following approvals or pre-approvals: * Explicit approval by the user to launch the application at the time the launch request is made. HBBTV,section 14.8: If the request contains an Origin header, then the HbbTV terminal shall include an Access-Control-Allow-Origin header in the HTTP response. The value of this response header shall be either the asterisk character "*" or a case-sensitive match for the value of the Origin header from the HTTP request. | +RLAUNCH_USER_APPROVAL | ||
| org.hbbtv_RLNCH0131 | 1 | REMOTE LAUNCH: Cross-origin-response - pre-approved | When the terminal receives an HTTP request targeting the Application Launch service endpoint containing an Origin header and the requested app is pre-approved for launching, the terminal shall launch that application and respond with an HTTP status code 201 including an Access-Control-Allow-Origin header. The value of this response header shall either be the asterisk character "*" or a case-sensitive match for the value of the Origin header from the HTTP request. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.6.2: On receiving the HTTP POST request, the terminal shall attempt to launch the HbbTV application. [...] The terminal might have states where the feature is temporarily unavailable, e.g. during a channel scan. The states when the feature is not available are not defined by the present document. [...] Terminals shall not, by default, launch applications without at least one of the following approvals or pre-approvals: [...] * Explicit pre-approval by the user that the specific application can be launched (for example by the mechanism referred to above). * Explicit pre-approval by the manufacturer. * Explicit pre-approval by another party managing the network or market where the terminal is located. [...] NOTE: For HbbTV terminals which only use pre-approval, it may be necessary for some applications to be pre-approved (and others not to be pre-approved) in order to run the HbbTV test suite. HBBTV,section 14.8: If the request contains an Origin header, then the HbbTV terminal shall include an Access-Control-Allow-Origin header in the HTTP response. The value of this response header shall be either the asterisk character "*" or a case-sensitive match for the value of the Origin header from the HTTP request. | +RLAUNCH_PREAPPROVAL | ||
| org.hbbtv_RLNCH0140 | 1 | REMOTE LAUNCH: successful transitioning HbbTV app launched with user approval from broadcast-independent to broadcast-related | Following the companion screen app requesting the launch of an HbbTV Application using a proper HTTP POST message and the launch of the HbbTV application being approved by the user, when a new service is selected which allows the launched HbbTV Application to be broadcast-related, the application shall transition to a broadcast-related application and shall allow access to the broadcast resources. | 2024-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 14.6.2: On receiving the HTTP POST request, the terminal shall attempt to launch the HbbTV application. [...] The terminal might have states where the feature is temporarily unavailable, e.g. during a channel scan. The states when the feature is not available are not defined by the present document. [...] Terminals shall not, by default, launch applications without at least one of the following approvals or pre-approvals: * Explicit approval by the user to launch the application at the time the launch request is made. HBBTV,section 6.2.2.2: Behaviour when selecting a broadcast service (flow diagram): New Service Selected->Application Running->Not Broadcast Related->Can Transition | +RLAUNCH_USER_APPROVAL | ||
| org.hbbtv_SMALL_INC0020 | 1 | terminalChannel property | When an HbbTV application obtains a Channel object and reads the terminalChannel property, the value is the channel number used by the terminal's native UI. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.5: The following additional property on the Channel class (as defined in OIPF DAE specification [1]) shall be supported. An integer property which shall be set to the value of the terminal's Logical Channel Number as used by the terminal's native UI. This allows for terminals to have different channel values (for example by way of user sorting) from the LCN values provided in SI by the broadcast network. | |||
| org.hbbtv_SMALL_INC0030 | 1 | DVB-SI descriptors with private data specifier | When an HbbTV application reads the SI descriptors from a Programme object where the DVB-SI includes descriptors scoped by a private data specifier and the HbbTV application passes that private data specifier as the privateDataSpecifier argument to the getSIDescriptors method as well as the descriptor tag values, the descriptors concerned are returned. | 2024-1 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 A.1: DVB-SI extensions to Programme | 7.16.2.4 | M OIPF-DAE,section 7.16.2.4: Get the contents of the descriptor specified by descriptorTag from the DVB SI EIT programme's descriptor loop. privateDataSpecifier: An optional argument giving the private_data_specifier as specified by [EN 300 468]. If this argument is present, only descriptors related to the identified specifier will be returned. | |||
| org.hbbtv_SMALL_INC0035 | 1 | DVB-SI descriptors with incorrect private data specifier | When an HbbTV application reads the SI descriptors from a Programme object where the DVB-SI includes descriptors scoped by a private data specifier and the HbbTV application passes an incorrect private data specifier as the privateDataSpecifier argument to the getSIDescriptors method but with the correct descriptor tag values, the method returns null. | 2024-1 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 A.1: DVB-SI extensions to Programme | 7.16.2.4 | M OIPF-DAE,section 7.16.2.4: Get the contents of the descriptor specified by descriptorTag from the DVB SI EIT programme's descriptor loop. privateDataSpecifier: An optional argument giving the private_data_specifier as specified by [EN 300 468]. If this argument is present, only descriptors related to the identified specifier will be returned. | |||
| org.hbbtv_SMALL_INC0060 | 1 | Broadcast-related application not affected when broadcast video is stopped | When a broadcast-related application stops playback of broadcast video by calling the stop method on a video/broadcast object in the presenting state, the application remains broadcast-related. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: Stopping and resuming playback of broadcast video using the stop() and bindToCurrentChannel() methods on a video/broadcast object shall not affect the broadcast-related status of an Application. | |||
| org.hbbtv_SMALL_INC0065 | 1 | Broadcast-related application not affected when broadcast video is restarted | When a broadcast-related application stops playback of broadcast video by calling the stop method on a video/broadcast object in the presenting state and then resumes presenting the video using bindToCurrentChannel(), the application is still broadcast-related. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: Stopping and resuming playback of broadcast video using the stop() and bindToCurrentChannel() methods on a video/broadcast object shall not affect the broadcast-related status of an Application. | |||
| org.hbbtv_SMALL_INC0070 | 1 | EXIT key destroys AUTOSTART application and second AUTOSTART application launches | When the user presses the EXIT button (or equivalent) while a broadcast service with an autostart application is selected and a broadcast-related HbbTV application is running, the running application is terminated, the broadcast signalling is processed and the autostart application started. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: EXIT or comparable button [...] Not available to applications [...] Mandatory 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 [...] If the only running broadcast-related application exits without starting a broadcast-independent application or without the terminal changing channel, the AIT shall be re-parsed and any autostart application shall be re-started following the rules defined in the previous clause. It may be that the restarted application is the same one as the one that just exited. | |||
| org.hbbtv_SMALL_INC0100 | 1 | parental rating for b-i apps - granted | When an application attempts to launch a broadcast-independent application whose XML AIT includes a <parentalRating> element identifying the application as applicable to the widest possible audience according to a supported parental rating scheme and the terminal is configured to permit access to media identified as applicable to that audience then the application is launched. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.2: When parental ratings are required, the XML AIT format described in clause 5.4 of TS 102 809 [3] is extended to provide parental rating information for broadcast-independent applications. The inclusion of a <ParentalRating> element as defined below in the extended format of the application's <ApplicationDescriptor> element indicates the parental rating for that application. HBBTV,section 6.2.2.6.2: When an attempt is made to launch an application using any of the mechanisms defined in clause 6.2.2, the terminal shall enforce parental access control on the application being launched in the same way that the terminal would enforce parental access control when attempting to play a media content item. NOTE: Whether the terminal enforces parental access control when launching applications may depend on the configuration of the terminal and in particular parental control settings that have been configured by the user. If playback of a media content item with the same parental rating would be blocked (e.g. because the user does not enter the correct parental control PIN, or because the terminal is configured to automatically block consumption of content above a given parental rating or if none of the parental ratings provided in the broadcast AIT or XML AIT are supported by the terminal), the request to launch the application shall fail. HBBTV,section 10.2.1: Parental rating scheme [...] Terminal shall at least support the scheme of a minimum recommended age encoded as per EN 300 468 [16]. | |||
| org.hbbtv_SMALL_INC0110 | 1 | parental rating for b-i apps - denied | When an application attempts to launch a broadcast-independent application whose XML AIT includes a <parentalRating> element identifying the application as applicable to the narrowest possible audience according to a supported parental rating scheme and the terminal is configured to deny access to media identified as applicable to that audience then the application is not launched. | 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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.2: When parental ratings are required, the XML AIT format described in clause 5.4 of TS 102 809 [3] is extended to provide parental rating information for broadcast-independent applications. The inclusion of a <ParentalRating> element as defined below in the extended format of the application's <ApplicationDescriptor> element indicates the parental rating for that application. HBBTV,section 6.2.2.6.2: When an attempt is made to launch an application using any of the mechanisms defined in clause 6.2.2, the terminal shall enforce parental access control on the application being launched in the same way that the terminal would enforce parental access control when attempting to play a media content item. NOTE: Whether the terminal enforces parental access control when launching applications may depend on the configuration of the terminal and in particular parental control settings that have been configured by the user. If playback of a media content item with the same parental rating would be blocked (e.g. because the user does not enter the correct parental control PIN, or because the terminal is configured to automatically block consumption of content above a given parental rating or if none of the parental ratings provided in the broadcast AIT or XML AIT are supported by the terminal), the request to launch the application shall fail. HBBTV,section 10.2.1: Parental rating scheme [...] Terminal shall at least support the scheme of a minimum recommended age encoded as per EN 300 468 [16]. | |||
| org.hbbtv_SMALL_INC0120 | 1 | parental rating for autostart b-r apps - granted | When a terminal attempts to launch an autostart broadcast-related application whose AIT includes a parental_rating_descriptor identifying the application as having a minimum recommended age of 4 and the terminal is configured not to restrict access for that age then the application is launched. | 2024-1 2023-3 2023-2 2023-1 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.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: In addition, the broadcast AIT may contain a parental_rating_descriptor, as defined in ETSI EN 300 468 [16], carried in the common descriptor loop of the AIT. Terminals shall support this descriptor, as defined in clause 6.2.2.6.2. HBBTV,section 10.2.6.1: The following shall apply if access to broadcast applications is blocked as a result: If access to an application in the broadcast AIT is blocked and the launch of this application is due to the behaviour defined in clauses 6.2.2.2 and 6.2.2.3, then the rules defined in those clauses apply. If access to an application in the broadcast AIT is blocked and the launch of this application is being requested by another application, then this launch request shall fail and the application shall not be loaded or run. HBBTV,section 10.2.1: Parental rating scheme [...] Terminal shall at least support the scheme of a minimum recommended age encoded as per EN 300 468 [16]. | |||
| org.hbbtv_SMALL_INC0130 | 1 | parental rating for present b-r apps - granted | When an application attempts to launch a present broadcast-related application whose AIT includes a parental_rating_descriptor identifying the application as having a minimum recommended age of 4 and the terminal is configured not to restrict access for that age then the application is launched. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 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 7.2.3.1: In addition, the broadcast AIT may contain a parental_rating_descriptor, as defined in ETSI EN 300 468 [16], carried in the common descriptor loop of the AIT. Terminals shall support this descriptor, as defined in clause 6.2.2.6.2. HBBTV,section 10.2.6.1: The following shall apply if access to broadcast applications is blocked as a result: If access to an application in the broadcast AIT is blocked and the launch of this application is due to the behaviour defined in clauses 6.2.2.2 and 6.2.2.3, then the rules defined in those clauses apply. If access to an application in the broadcast AIT is blocked and the launch of this application is being requested by another application, then this launch request shall fail and the application shall not be loaded or run. HBBTV,section 10.2.1: Parental rating scheme [...] Terminal shall at least support the scheme of a minimum recommended age encoded as per EN 300 468 [16]. | ||
| org.hbbtv_SMALL_INC0140 | 1 | parental rating for autostart b-r apps - refused | When a terminal attempts to launch an autostart broadcast-related application whose AIT includes a parental_rating_descriptor identifying the application as having a minimum recommended age of 18 and the terminal is configured to restrict access for that age then the application is not launched and the terminal tries the next highest priority application signalled as autostart. | 2024-1 2023-3 2023-2 2023-1 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.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: In addition, the broadcast AIT may contain a parental_rating_descriptor, as defined in ETSI EN 300 468 [16], carried in the common descriptor loop of the AIT. Terminals shall support this descriptor, as defined in clause 6.2.2.6.2. HBBTV,section 10.2.6.1: The following shall apply if access to broadcast applications is blocked as a result: If access to an application in the broadcast AIT is blocked and the launch of this application is due to the behaviour defined in clauses 6.2.2.2 and 6.2.2.3, then the rules defined in those clauses apply. If access to an application in the broadcast AIT is blocked and the launch of this application is being requested by another application, then this launch request shall fail and the application shall not be loaded or run. HBBTV,section 10.2.1: Parental rating scheme [...] Terminal shall at least support the scheme of a minimum recommended age encoded as per EN 300 468 [16]. HBBTV,section 6.2.2.2: Is the app blocked by parental rating? [...] Yes [...] Find the next highest priority Application signalled as AUTOSTART. | |||
| org.hbbtv_SMALL_INC0150 | 1 | parental rating for present b-r apps - refused | When an application attempts to launch a present broadcast-related application whose AIT includes a parental_rating_descriptor identifying the application as having a minimum recommended age of 18 and the terminal is configured to restrict access for that age then the application is not launched and the launching application receives an onApplicationLoadError. | 2024-1 2023-3 2023-2 2023-1 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.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.2.3.1: In addition, the broadcast AIT may contain a parental_rating_descriptor, as defined in ETSI EN 300 468 [16], carried in the common descriptor loop of the AIT. Terminals shall support this descriptor, as defined in clause 6.2.2.6.2. HBBTV,section 10.2.6.1: The following shall apply if access to broadcast applications is blocked as a result: If access to an application in the broadcast AIT is blocked and the launch of this application is due to the behaviour defined in clauses 6.2.2.2 and 6.2.2.3, then the rules defined in those clauses apply. If access to an application in the broadcast AIT is blocked and the launch of this application is being requested by another application, then this launch request shall fail and the application shall not be loaded or run. HBBTV,section 10.2.1: Parental rating scheme [...] Terminal shall at least support the scheme of a minimum recommended age encoded as per EN 300 468 [16]. 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), All properties of the Application object referred to by appl SHALL have the value undefined and calling any methods on that object SHALL fail. | |||
| org.hbbtv_SMALL_INC0160 | 1 | parental rating for b-r apps - changes ignored | A terminal that is configured not to restrict access for age 4 but to restrict access for age 18 launches an autostart broadcast-related application whose AIT includes a parental_rating_descriptor identifying the application as having a minimum recommended age of 4. The AIT is then updated to change the parental_rating_descriptor to indicate a minimum recommended age of 18. The application continues to run uninterrupted. | 2024-1 2023-3 2023-2 2023-1 2022-3 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 6.2.2.1: The launch of an application may be blocked by the terminal if a parental rating value is signalled in the broadcast AIT or XML AIT. However, once launched, a change in the parental rating in a broadcast AIT does not cause the running application to be killed. HBBTV,section 7.2.3.1: In addition, the broadcast AIT may contain a parental_rating_descriptor, as defined in ETSI EN 300 468 [16], carried in the common descriptor loop of the AIT. Terminals shall support this descriptor, as defined in clause 6.2.2.6.2. | |||
| org.hbbtv_STABILITY0010 | 1 | Stability - service selection - carousel transport | There are two services carrying broadcast-related autostart applications delivered in different carousels. The selected service is repeatedly changed from one service to the other (as if by user interaction), no faster than at 50 ms intervals and no slower than at 1 second intervals (or the time required for the application to start fully, if greater than 1 second). After 20 service changes at varying intervals, the correct application starts successfully and presents the correct audio and video. | 2024-1 2023-3 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall operate reliably in response to rapid user interaction. Specifically, the terminal shall remain fully functional in the following circumstances. Fully functional in this case means at least that the appropriate application at the end of each sequence starts successfully, that it functions as designed and that, where a broadcast service is selected, the video and audio from that service are presented. The user changes the selected service 20 times consecutively between two services carrying broadcast-related autostart applications delivered in different carousels, the time interval between requested service changes varying between 50 ms and the greater of (a) the time interval required for the application to start fully and (b) 1 second. | |||
| org.hbbtv_STABILITY0020 | 1 | Stability - service selection - broadband transport | There are two services carrying broadcast-related autostart applications delivered over broadband. The selected service is repeatedly changed from one service to the other (as if by user interaction), no faster than at 50 ms intervals and no slower than at 1 second intervals (or the time required for the application to start fully, if greater than 1 second). After 20 service changes at varying intervals, the correct application starts successfully and presents the correct audio and video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall operate reliably in response to rapid user interaction. Specifically, the terminal shall remain fully functional in the following circumstances. Fully functional in this case means at least that the appropriate application at the end of each sequence starts successfully, that it functions as designed and that, where a broadcast service is selected, the video and audio from that service are presented. [...] The user changes the selected service 20 times consecutively between two services carrying broadcast-related autostart applications delivered over broadband, the time interval between requested service changes varying between 50 ms and the greater of (a) the time interval required for the application to start fully and (b) 1 second. | |||
| org.hbbtv_STABILITY0030 | 1 | Stability - service selection - mixed transport | There are two services carrying broadcast-related autostart applications, one delivered in a carousel and the other delivered over broadband. The selected service is repeatedly changed from one service to the other (as if by user interaction), no faster than at 50 ms intervals and no slower than at 1 second intervals (or the time required for the application to start fully, if greater than 1 second). After 20 service changes at varying intervals, the correct application starts successfully and presents the correct audio and video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall operate reliably in response to rapid user interaction. Specifically, the terminal shall remain fully functional in the following circumstances. Fully functional in this case means at least that the appropriate application at the end of each sequence starts successfully, that it functions as designed and that, where a broadcast service is selected, the video and audio from that service are presented. [...] The user changes the selected service 20 times consecutively between two services carrying broadcast-related autostart applications, one delivered in a carousel, the other delivered over broadband, the time interval between requested service changes varying between 50 ms and the greater of (a) the time interval required for the application to start fully and (b) 1 second. | |||
| org.hbbtv_STABILITY0040 | 1 | Stability - repeated termination - broadcast-related | A broadcast-related autostart application is repeatedly terminated using the "EXIT or comparable button" mechanism at varying intervals, no faster than at 50 ms intervals and no slower than at 1 second intervals (or the time required for the application to start fully, if greater than 1 second). After 20 activations of the mechanism, the application starts successfully and presents broadcast audio and video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall operate reliably in response to rapid user interaction. Specifically, the terminal shall remain fully functional in the following circumstances. Fully functional in this case means at least that the appropriate application at the end of each sequence starts successfully, that it functions as designed and that, where a broadcast service is selected, the video and audio from that service are presented. [...] A broadcast-related autostart application is terminated manually by the user using the "EXIT or comparable button" mechanism (see clause 6.2.2.11) 20 times consecutively, the time interval between activations of the mechanism varying between 50 ms and the greater of (a) the time interval required for the application to restart fully and (b) 1 second. | |||
| org.hbbtv_STABILITY0050 | 1 | Stability - repeated termination - Internet TV Portal | A broadcast-independent application is repeatedly started from the Internet TV Portal and then terminated manually by the user. This happens 20 times. When the application is started one further time, the application starts successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall operate reliably in response to rapid user interaction. Specifically, the terminal shall remain fully functional in the following circumstances. Fully functional in this case means at least that the appropriate application at the end of each sequence starts successfully, that it functions as designed and that, where a broadcast service is selected, the video and audio from that service are presented. [...] If the terminal supports a means to launch broadcast-independent HbbTV applications from an Internet TV Portal as described in section 5.3.5: a broadcast-independent HbbTV application is started from the Internet TV Portal and then terminated manually by the user 20 times consecutively and then finally started one further time. | |||
| org.hbbtv_STABILITY0070 | 1 | Stability - no A/V glitches when application launches - present/DSM-CC | When a terminal is presenting broadcast audio and video and a broadcast-related non-autostart application delivered by DSM-CC object carousel launches, and the application does not try to control video playback, there are no artifacts or glitches in the presented broadcast audio or video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall be able to present broadcast audio and video reliably when HbbTV applications are launching and stopping. Specifically: When the terminal launches a broadcast-related application and broadcast audio or video is being presented and that application does not try to control video playback, there shall not be any artifacts or glitches in presented broadcast audio or video. This includes applications delivered by broadband and DSM-CC object carousel, as well as both autostart and non-autostart applications. | |||
| org.hbbtv_STABILITY0080 | 1 | Stability - no A/V glitches when application exits - destroyApplication() | When a terminal is presenting broadcast audio and video and a broadcast-related application is running that does not try to control video playback and the application calls destroyApplication(), there are no artifacts or glitches in the presented broadcast audio or video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall be able to present broadcast audio and video reliably when HbbTV applications are launching and stopping. Specifically: [...] When the terminal terminates a broadcast-related application and broadcast audio or video is being presented and that application did not try to control video playback, there shall not be any artifacts or glitches in presented broadcast audio or video. This includes where the application calls destroyApplication() to exit itself, when application signalling causes the application to be stopped and when it is terminated manually by the user. | |||
| org.hbbtv_STABILITY0085 | 1 | Stability - no A/V glitches when application exits - signalling | When a terminal is presenting broadcast audio and video and a broadcast-related application is running that does not try to control video playback and the broadcast signalling changes so that the application is terminated, there are no artifacts or glitches in the presented broadcast audio or video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall be able to present broadcast audio and video reliably when HbbTV applications are launching and stopping. Specifically: [...] When the terminal terminates a broadcast-related application and broadcast audio or video is being presented and that application did not try to control video playback, there shall not be any artifacts or glitches in presented broadcast audio or video. This includes where the application calls destroyApplication() to exit itself, when application signalling causes the application to be stopped and when it is terminated manually by the user. | |||
| org.hbbtv_STABILITY0090 | 1 | Stability - no A/V glitches when application exits - manual termination | When a terminal is presenting broadcast audio and video and a broadcast-related application is running that does not try to control video playback and the application is terminated manually by the user, there are no artifacts or glitches in the presented broadcast audio or video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall be able to present broadcast audio and video reliably when HbbTV applications are launching and stopping. Specifically: [...] When the terminal terminates a broadcast-related application and broadcast audio or video is being presented and that application did not try to control video playback, there shall not be any artifacts or glitches in presented broadcast audio or video. This includes where the application calls destroyApplication() to exit itself, when application signalling causes the application to be stopped and when it is terminated manually by the user. | |||
| org.hbbtv_STABILITY0100 | 1 | Stability - truncated content | When an application requests content from an XML, HTML or media file and download of the content is interrupted because the file is truncated, the terminal continues to respond to channel change and application termination requests. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall be resilient to transient error conditions that are likely to occur, as well as to conditions of low resource availability. Specifically, the terminal shall remain responsive to channel change and application termination requests in the following circumstances: The terminal downloads, or attempts to download an XML, HTML, or media file, which has been truncated. | |||
| org.hbbtv_STABILITY0110 | 1 | Stability - packet loss | When an application is loading over an IP connection and download of the application is interrupted by a TCP connection reset or sustained packet loss, the terminal continues to respond to channel change and application termination requests. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall be resilient to transient error conditions that are likely to occur, as well as to conditions of low resource availability. Specifically, the terminal shall remain responsive to channel change and application termination requests in the following circumstances: [...] A broadband application download is prematurely interrupted by a TCP connection reset, or sustained packet loss. | |||
| org.hbbtv_STABILITY0120 | 1 | Stability - carousel removed | When an application is loading from an object carousel and download of the application is interrupted by removal of the carousel from the broadcast stream, the terminal continues to respond to channel change and application termination requests. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall be resilient to transient error conditions that are likely to occur, as well as to conditions of low resource availability. Specifically, the terminal shall remain responsive to channel change and application termination requests in the following circumstances: [...] A broadcast application download is prematurely interrupted by the removal of a carousel from the broadcast stream. | |||
| org.hbbtv_STABILITY0130 | 1 | Stability - very large asset | When the initial HTML page of an application has a file size of 100MB and the application is loaded, the terminal continues to respond to channel change and application termination requests, regardless of whether the application is loaded successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall be resilient to transient error conditions that are likely to occur, as well as to conditions of low resource availability. Specifically, the terminal shall remain responsive to channel change and application termination requests in the following circumstances: [...] The terminal attempts to download an initial HTML page with a file size of 100 MB. For the avoidance of doubt, it is not required that such a page be properly loaded and rendered. | |||
| org.hbbtv_STABILITY0140 | 1 | Stability - unbounded memory usage | When an application attempts to create and initialise an unbounded number of arrays, each containing 2 000 000 integers, until resource allocation fails, the terminal continues to respond to channel change and application termination requests. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall be resilient to transient error conditions that are likely to occur, as well as to conditions of low resource availability. Specifically, the terminal shall remain responsive to channel change and application termination requests in the following circumstances: [...] An application attempts to create and initialise an unbounded number of JavaScript arrays, each containing 2 000 000 integers, until the allocation fails. | |||
| org.hbbtv_STABILITY0150 | 1 | Stability - uncaught exception | When an application raises an exception that is not caught, the terminal continues to respond to channel change and application termination requests. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall be resilient to transient error conditions that are likely to occur, as well as to conditions of low resource availability. Specifically, the terminal shall remain responsive to channel change and application termination requests in the following circumstances: [...] The browser raises exceptions that are not explicitly caught by the application. | |||
| org.hbbtv_STABILITY0160 | 1 | Stability - application enters an infinite loop | When an application enters an infinite recursive loop, the terminal continues to respond to channel change and application termination requests. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.8: Terminals shall be resilient to transient error conditions that are likely to occur, as well as to conditions of low resource availability. Specifically, the terminal shall remain responsive to channel change and application termination requests in the following circumstances: [...] An application enters an infinite JavaScript loop including infinite recursion. | |||
| org.hbbtv_SUB0010 | 1 | EBUTTD: 8 concurrent regions | The terminal successfully renders, in correct synchronisation with associated video, an EBU-TT-D document in which the subtitles change over time but always use 8 concurrent active regions. | 2024-1 2023-3 2023-2 2023-1 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 7.3.1.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall have no more than 8 concurrently visible regions. | |||
| org.hbbtv_SUB0020 | 1 | EBUTTD: UTF-8 encoding | The terminal successfully renders an EBU-TT-D document that includes a representative selection of UTF-8 characters using the embedded Tiresias font. The selection of characters shall contain at least a subset of characters in the unicode range of 00A0-017E (excluding 0149) and all characters listed individually in table C.1 of ETSI TS 102 809. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall use UTF-8 character encoding | |||
| org.hbbtv_SUB0024 | 1 | EBUTTD: in-band within live DASH stream | When an application is using an HTML5 media element object to present a live DASH stream containing at least one video, one audio and one EBU-TT-D subtitle component, and the application selects for presentation one of the in-band subtitle components via the HTML5 API (by setting the mode attribute of the corresponding TextTrack object to "showing"), the terminal successfully renders the selected EBU-TT-D subtitles in correct synchronisation with the presented video component. | 2024-1 2023-2 2023-1 2022-3 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.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]. | |||
| org.hbbtv_SUB0026 | 1 | EBUTTD: Compressed DASH delivery | The terminal successfully renders, in correct synchronisation with their associated video, EBU-TT-D subtitles that are encapsulated in ISOBMFF and delivered with HTTP compression enabled in an MPEG DASH stream conforming to the DVB DASH profile and annex E of the HbbTV specification. | 2024-1 2023-3 2023-2 2023-1 2022-3 2020-3 2020-2 2020-1 2019-3 2019-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.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 TS-103-285,section 7.1.1: Note: As the subtitles are carried as XML within the sample data, the use of HTTP compression is recommended. Clause 10.11 of the present document requires Player support for gzip compression to enable this. TS-103-285,section 10.11: Players shall support gzip content coding according to RFC2616 [18]. | ||
| org.hbbtv_SUB0028 | 1 | EBUTTD: DASH delivery - timing not aligned with samples 1 | When EBU-TT-D subtitles are delivered in an MPEG DASH stream conforming to the DVB DASH profile and annex E of the HbbTV specification, where each subtitle segment contains a single sample, each sample contains an EBU-TT-D document whose start time is before the sample start time and whose end time is after the sample end time, and the terminal has downloaded each subtitle segment in its entirety before the video frames visible during the same period on the media timeline are presented, the terminal successfully renders the subtitles in correct synchronisation with their associated video, with the subtitles rendered over each video frame coming only from the subtitle sample located at the same position on the media timeline. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 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 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 EBU-TECH-3381,section 6: The begin and end of an EBU-TT-D document may not be coincident with the begin and end of the sample. All subtitle content that falls partially or wholly within the duration of the sample shall be present in the EBU-TT-D document and shall be displayed. Subtitle content that falls entirely out of the duration of the sample shall be omitted in the EBU-TT-D document that is contained within that sample.For error recovery the timed content that falls outside of the sample boundaries may be used for error recovery (e.g. if a subsequent sample has not arrived in time for processing), however if a subtitle sample corresponding to a particular video frame visibility period has been received then that subtitle sample shall the only one from which subtitles shall be displayed. | ||
| org.hbbtv_SUB0029 | 1 | EBUTTD: DASH delivery - timing not aligned with samples 2 | When EBU-TT-D subtitles are delivered in an MPEG DASH stream conforming to the DVB DASH profile and annex E of the HbbTV specification, where each subtitle segment contains a single sample, and each sample contains an EBU-TT-D document whose start time is after the sample start time and whose end time is before the sample end time, the terminal successfully renders the subtitles in correct synchronisation with their associated video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2020-3 2020-2 2020-1 2019-3 2019-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.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 EBU-TECH-3381,section 6: The begin and end of an EBU-TT-D document may not be coincident with the begin and end of the sample. | ||
| org.hbbtv_SUB0110 | 1 | EBUTTD: out-of-band with non-live DASH. | The terminal successfully renders subtitles from an EBU-TT-D document delivered out-of-band via HTTP as a single XML file, in correct synchronisation with associated video that is being delivered in a non-live DASH stream. | 2024-1 2023-3 2023-2 2023-1 2022-3 2020-3 2020-2 2020-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 7.3.1.5.1: Out of band delivered EBU-TT-D subtitles shall be supported 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, with a document size of up to and including 512kByte. HBBTV,section 7.3.1: 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. | ||
| org.hbbtv_SUB0120 | 1 | EBUTTD: single document with 512 kByte. | The terminal successfully renders subtitles from an EBU-TT-D document delivered out-of-band via HTTP as a single XML file of size 512kBytes, in correct synchronisation with associated video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2019-2 2019-1 2018-3 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 7.3.1.5.1: Out of band delivered EBU-TT-D subtitles shall be supported 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, with a document size of up to and including 512kByte. | ||
| org.hbbtv_SUB0130 | 1 | EBUTTD: Select out-of-band ST with HTML5 | When AV content that has two associated out-of-band EBU-TT-D subtitle components is being presented by an HTML5 media object, and the application then selects for presentation one of the out-of-band subtitle components by setting the mode attribute of the corresponding TextTrack object to "showing", the terminal thereafter successfully renders the correct EBU-TT-D subtitle component over the video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2: Independent of the system format, terminals shall create TextTrack objects for HTML <track> elements representing TTML subtitle components that are carried out-of-band (see clause 7.3.1.5) when represented by a <track> element in an HTML document. HTML5,section 4.7.10.12.1: A mode One of the following: Disabled Indicates that the text track is not active. Other than for the purposes of exposing the track in the DOM, the user agent is ignoring the text track. No cues are active, no events are fired, and the user agent will not attempt to obtain the track's cues. [...] Showing Indicates that the text track is active. | |||
| org.hbbtv_SUB0140 | 1 | EBUTTD: Unselect out-of-band ST with HTML5 | When AV content is being presented by an HTML5 media object, with an associated out-of-band EBU-TT-D subtitle component being rendered over the video, and the application then deselects the subtitle component that is being presented by setting the mode attribute of the corresponding TextTrack object to "disabled", the terminal stops rendering the corresponding subtitle component. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.12.2: Independent of the system format, terminals shall create TextTrack objects for HTML <track> elements representing TTML subtitle components that are carried out-of-band (see clause 7.3.1.5) when represented by a <track> element in an HTML document. HTML5,section 4.7.10.12.1: A mode One of the following: Disabled Indicates that the text track is not active. Other than for the purposes of exposing the track in the DOM, the user agent is ignoring the text track. No cues are active, no events are fired, and the user agent will not attempt to obtain the track's cues. [...] Showing Indicates that the text track is active. | |||
| org.hbbtv_SUB0150 | 1 | EBUTTD: Select in-band DASH ST with HTML5 | When an audio and a video component from an MPEG DASH stream that also contains two EBU-TT-D subtitle components (i.e., two subtitle Adaptation Sets) are being presented by an HTML5 media object, and the application then selects for presentation one of the in-band subtitle components by setting the mode attribute of the corresponding TextTrack object to "showing", the terminal thereafter successfully renders the correct EBU-TT-D subtitle component over the video. | 2024-1 2023-3 2023-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.5.1: 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. HBBTV,section A.2.12.1: The following shall apply when an HTML5 video element is presenting content whose system format is MPEG DASH; [...] - A TextTrack object shall be created for each Adaptation Set in the MPD carrying EBU-TT-D TTML data as defined in the DVB DASH profile []. The order of TextTrack objects in the TextTrackList shall be the same as the order that the corresponding Adaptation Sets are in the MPD. HTML5,section 4.7.10.12.1: A mode One of the following: Disabled Indicates that the text track is not active. Other than for the purposes of exposing the track in the DOM, the user agent is ignoring the text track. No cues are active, no events are fired, and the user agent will not attempt to obtain the track's cues. [...] Showing Indicates that the text track is active. | |||
| org.hbbtv_SUB0160 | 1 | EBUTTD: Unselect in-band DASH ST with HTML5 | When an audio, a video and an EBU-TT-D subtitle component from the same MPEG DASH stream are being presented by an HTML5 media object, and the application then deselects the subtitle component that is being presented by setting the mode attribute of the corresponding TextTrack object to "disabled", the terminal stops rendering the corresponding subtitle component. | 2024-1 2023-3 2023-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.5.1: 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. HBBTV,section A.2.12.1: The following shall apply when an HTML5 video element is presenting content whose system format is MPEG DASH; [...] - A TextTrack object shall be created for each Adaptation Set in the MPD carrying EBU-TT-D TTML data as defined in the DVB DASH profile []. The order of TextTrack objects in the TextTrackList shall be the same as the order that the corresponding Adaptation Sets are in the MPD. HTML5,section 4.7.10.12.1: A mode One of the following: Disabled Indicates that the text track is not active. Other than for the purposes of exposing the track in the DOM, the user agent is ignoring the text track. No cues are active, no events are fired, and the user agent will not attempt to obtain the track's cues. [...] Showing Indicates that the text track is active. | |||
| org.hbbtv_SUB0190 | 1 | EBUTTD: Select out-of-band ST with AV Control object | When AV content that has two associated out-of-band EBU-TT-D subtitle components is being presented by an AV Control object, and the application then selects for presentation one of the out-of-band subtitle components by passing the corresponding AVSubtitleComponent to the AV Control object's selectComponent method, the terminal thereafter successfully renders the correct EBU-TT-D subtitle component over the video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-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.5.1: 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. HBBTV,section A.2.5.3: The terminal shall support the component selection API defined in clause 7.14.4.1 of OIPF DAE [1] for in-band and out-of-band delivered TTML subtitles as defined in clause 7.3.1.5. | |||
| org.hbbtv_SUB0210 | 1 | EBUTTD: Select inband DASH ST with AV Control object | When an audio and a video component from an MPEG DASH stream that also contains two EBU-TT-D subtitle components (i.e., two subtitle Adaptation Sets) are being presented by an AV Control object, and the application then selects for presentation one of the subtitle components by passing the corresponding AVSubitleComponent to the AV Control object's selectComponent method, the terminal thereafter successfully renders the correct EBU-TT-D subtitle component over the video. | 2024-1 2023-3 2023-2 2023-1 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.1.5.1: 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. HBBTV,section A.2.5.3: The terminal shall support the component selection API defined in clause 7.14.4.1 of OIPF DAE [1] for in-band and out-of-band delivered TTML subtitles as defined in clause 7.3.1.5. | |||
| org.hbbtv_SUB0220 | 1 | EBUTTD: Unselect inband DASH ST with AV Control object | When an audio, a video and an EBU-TT-D subtitle component from the same MPEG DASH stream are being presented by an AV Control object, and the application then deselects the subtitle component that is being presented by passing the corresponding AVSubtitleComponent to the AV Control object's unselectComponent method, the terminal stops rendering the corresponding subtitle component. | 2024-1 2023-3 2023-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.5.1: 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. HBBTV,section A.2.5.3: The terminal shall support the component selection API defined in clause 7.14.4.1 of OIPF DAE [1] for in-band and out-of-band delivered TTML subtitles as defined in clause 7.3.1.5. | |||
| org.hbbtv_SUB0290 | 1 | EBUTTD: Font matching "sansSerif" | When an EBU-TT-D document refers to the generic font-family "sansSerif" from a tt:style element that is used in a tt:region element that itself is used from a tt:div element in the subtitle document, and the application references a downloadable font (whose name is not "sansSerif") in an MPEG DASH MPD, the terminal renders the subtitle of that tt:div element with the embedded Tiresias font. All other subtitles of the document uses a font-family that matches that of the downloadable font and are correctly rendered by the terminal using the downloadable font. | 2024-1 2023-3 2023-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.5.1: When matching embedded fonts, the following mappings for TTML genericFamilyName shall apply: "sansSerif" shall match Tiresias | |||
| org.hbbtv_SUB0350 | 1 | EBUTTD: MPD SupplementalProperty | When an application is presenting an MPEG DASH stream that contains an in-band EBU-TT-D subtitle component whose subtitles use a downloadable font that is signalled by a SupplementalProperty element in the DASH MPD, and the application selects for presentation this in-band subtitle component, the terminal correctly renders the subtitles using the downloadable font. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 7.3.1.5.1: Fonts shall be downloaded when referenced using [...] a SupplementalProperty [...] | |||
| org.hbbtv_SUB0370 | 1 | EBUTTD: MPD SupplementalProperty download failure | When an application is presenting an MPEG DASH stream that contains an in-band EBU-TT-D subtitle component whose subtitles use a downloadable font that is signalled by a SupplementalProperty element in the DASH MPD, and the application selects for presentation this in-band subtitle component, but the downloadable font is not available at its download location, the terminal ignores the downloadable font and renders the subtitles with a suitable embedded font. | 2024-1 2023-3 2023-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 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.5.1: Error handling shall be as defined in the DVB DASH specification [45]. TS-103-285,section 7.2.3: If a Player is unable to download a font for any reason or having downloaded a font is unable to process it, then: [...] If the font download was signalled using the SupplementalProperty descriptor, the Adaptation Set containing the descriptor shall be presented as if the descriptor was not present. | |||
| org.hbbtv_SUB0390 | 1 | EBUTTD: CASD download font | When an application is using an AV Control object to present AV content that is signalled by a Content Access Streaming Descriptor and which is being progressively streamed via HTTP, and the application selects for presentation an associated out-of-band EBU-TT-D subtitle component that references a downloadable font which is signalled in the same Content Access Streaming Descriptor and whose essential attribute is set to false, the terminal correctly renders the subtitles using the downloadable font. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.5.1: Terminals shall support downloadable fonts signalled in the Content Access Streaming Descriptor for streaming content as defined in clause 7.3.2.1 | |||
| org.hbbtv_SUB0420 | 1 | EBUTTD: CASD download failure for non-essential font | When an application is using an AV Control object to present AV content that is signalled by a Content Access Streaming Descriptor and which is being progressively streamed via HTTP, and the application selects for presentation an associated out-of-band EBU-TT-D subtitle component that references a downloadable font with the generic font-family name "sansSerif" which is signalled in the same Content Access Streaming Descriptor and whose essential attribute is set to false, but the downloadable font is not available at its download location, the terminal correctly renders the subtitles using the embedded Tiresias font. | 2024-1 2023-3 2023-2 2023-1 2022-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.5.1: If a terminal is unable to download a font for any reason or having downloaded a font is unable to use it, then: If the font download does not have the @essential attribute set to true, the terminal shall present the subtitles as if this DownloadableFont element were not included | |||
| org.hbbtv_SUB0600 | 1 | EBUTTD: DASH with single subtitle segment | When an application is presenting an MPEG DASH stream whose length is at least two minutes, and which contains an EBU-TT-D subtitle Adaptation Set consisting of a single ISOBMFF segment that contains a single sample, the content of which is an EBU-TT-D document that contains multiple subtitles whose presentation times are distributed throughout the duration of the DASH stream, the terminal successfully renders the EBU-TT-D subtitle component in correct synchronisation with the presented video component. | 2024-1 2023-2 2023-1 2022-3 2022-2 2022-1 2020-3 2020-2 2020-1 2019-3 2019-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.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 TS-103-285,section 4.3: Subtitle segments shall be available at or before the time at which other media segments with which they are presented become available TS-103-285,section 4.5: Subtitle segments shall have a maximum segment size of 512kB | ||
| org.hbbtv_SUB0610 | 1 | EBUTTD: DASH with larger subtitle segments | When an application is presenting an MPEG DASH stream whose length is at least five minutes, and which contains an EBU-TT-D subtitle Adaptation Set containing at least five segments, whose segment duration is greater than that of the segments of the presented video and audio components, but which is not an integer multiple of the duration of either the video or audio segments, the terminal successfully renders the EBU-TT-D subtitle component in correct synchronisation with the presented video component. | 2024-1 2023-2 2023-1 2022-3 2019-2 2019-1 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.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 TS-103-285,section 4.3: Subtitle segments shall be available at or before the time at which other media segments with which they are presented become available TS-103-285,section 4.5: Subtitle segments shall have a maximum segment size of 512kB | |||
| org.hbbtv_SUB0620 | 1 | EBUTTD: Enable subtitles via UI for DASH stream presented by HTML5 media object | When an application is using an HTML5 media object to present video and audio components from an MPEG DASH stream that also contains an EBU-TT-D subtitle component, and subtitles are then enabled on the terminal using the terminal UI, the terminal thereafter successfully renders the in-band EBU-TT-D subtitle component in correct synchronisation with the presented video component. | 2024-1 2023-2 2023-1 2022-3 2020-3 2020-2 2020-1 2019-3 2019-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | 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 HBBTV,section 10.2.7.2: Terminals shall support a method for the user to enable and disable subtitles and to select at least one preferred subtitle language. Terminals shall use this information when playing content to determine whether to present subtitles and to select between multiple subtitles when they are available. | |||
| org.hbbtv_SUB0630 | 1 | EBUTTD: Enable subtitles via UI for ISOBMFF stream presented by AV Control object | When an application, which declares an out-of-band EBU-TT-D subtitle component using a param element, is using an AV Control object to present video and audio components from an ISOBMFF file that is being progressively streamed via HTTP, and subtitles are then enabled on the terminal using the terminal UI, the terminal thereafter successfully renders the out-of-band EBU-TT-D subtitle component in correct synchronisation with the presented video component. | 2024-1 2023-2 2023-1 2022-3 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,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 HBBTV,section 10.2.7.2: Terminals shall support a method for the user to enable and disable subtitles and to select at least one preferred subtitle language. Terminals shall use this information when playing content to determine whether to present subtitles and to select between multiple subtitles when they are available. | ||
| org.hbbtv_SUB1001 | 1 | tt:br in tt:p | Each time a tt:br element is encountered in a tt:p element the presentation processor shall start a new line. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.2.1.1: A tt:br element may be used to insert a forced line break. TTML1,section 7.1.7: When presented on a visual medium, the presence of a br element must be interpreted as a forced line break. | |||
| org.hbbtv_SUB1002 | 1 | Multiple Div | When content elements that are descendants of different tt:div elements are simultaneously active all of those content elements shall be rendered by a presentation processor. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.2.1: The tt:div element shall be a logical container of textual content. TTML1,section 7.1.4: The div element functions as a logical container and a temporal structuring element for a sequence of textual content units represented as logical sub-divisions or paragraphs. TTML1,section 10.2.4: The semantics of parallel and sequential time containment are those defined by [SMIL 2.1], § 10.4.2, while taking into account any overriding semantics defined by this specification. SMIL 2.1,section 10.4.2: A par container, short for "parallel", defines a simple time grouping in which multiple elements can play back at the same time. | |||
| org.hbbtv_SUB1004 | 1 | tt:br in tt:span | Each time a tt:br element is encountered in a tt:span element the presentation processor shall start a new line. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.2.1.1.1: A tt:br element may be used to insert a forced line break. TTML1,section 7.1.7: When presented on a visual medium, the presence of a br element must be interpreted as a forced line break. | |||
| org.hbbtv_SUB1005 | 1 | cellResolution and fontSize | The font size of text content shall be rendered by a presentation processor according to the inherited font size. The percentage value of the calculated font-size shall be translated to absolute values based on the cellResolution attribute that is specified on the tt:tt element. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3: Expresses a virtual visual grid composed of horizontal and vertical cells. This grid divides the root container region [...] in rows and columns. The first value defines the number of columns and the second value defines the number of rows. EBU-TECH-3380,section 3.1.2.1: The font- size of a glyph. Only one percentage value shall be specified. TTML1,section 6.2.1: The ttp:cellResolution attribute may be used by an author to express the number of horizontal and vertical cells into which the Root Container Region area is divided for the purpose of expressing presentation semantics in terms of a uniform grid. TTML1,section 8.2.9: The tts:fontSize attribute is used to specify a style property that defines the font size for glyphs that are selected for glyph areas generated by content flowed into a region.[...] Initial: 1c [...] Percentages: if not region element, then relative to parent element's font size; otherwise, relative to the Computed Cell Size | |||
| org.hbbtv_SUB1006 | 1 | tts:backgroundColor applied to a tt:span | When tts:backgroundColor is applied to a span element a presentation processor shall render the background colour for the content in the inline-area generated by the span element. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Background color of a region, a block area generated by a tt:p element or an inline area generated by a tt:span element. EBU-TECH-3380,section 3.2.1.1.1: The tt:span element may be used to apply style information to the enclosed textual content. TTML1,section 8.2.2: The tts:backgroundColor attribute is used to specify a style property that defines the background color of a region or an area generated by content flowed into a region. TTML1,section 7.1.6: When presented on a visual medium, a span element is intended to generate a sequence of inline areas, each containing one or more glyph areas. XSL 1.1,section 7.8.2: This property sets the background color of an element, either a <color> value or the keyword transparent, to make the underlying colors shine through. CSS 2.1,section 14.2.1: This property sets the background color of an element, either a <color> value or the keyword transparent, to make the underlying colors shine through. | |||
| org.hbbtv_SUB1007 | 1 | tts:color using a RGB color triple | When a color is applied using a tts:color attribute whose value is an RGB color triple as hash color expression (#rrggbb) the content shall be rendered by the presentation processor as an opaque foreground color in the defined SRGB color space. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Foreground color of an area. EBU-TECH-3380,section 4.2: The content shall be constrained to a hex notated RGB color triple or a hex notated RGBA color tuple. TTML1,section 8.2.3: The tts:color attribute is used to specify a style property that defines the foreground color of marks associated with an area generated by content flowed into a region. XSL 1.1,section 7.18.1: This property describes the foreground color of an element's text content. CSS 2.1,section 14.1: This property describes the foreground color of an element's text content. | |||
| org.hbbtv_SUB1008 | 1 | Styling Test - Color - 003 | When a color is applied using a tts:color attribute whose value is an RGBA color tuple as hash color expression (#rrggbbaa) the content shall be rendered by the presentation processor as a foreground color in the defined SRGB color space where the opacity is set according to the value of the alpha component in that color expression. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Foreground color of an area. EBU-TECH-3380,section 4.2: The content shall be constrained to a hex notated RGB color triple or a hex notated RGBA color tuple. TTML1,section 8.2.3: The tts:color attribute is used to specify a style property that defines the foreground color of marks associated with an area generated by content flowed into a region. TTML1,section 8.3.2: For the purpose of performing presentation processing such that non-opaque or non-transparent alpha or opacity values apply, then the semantics of compositing functions are defined with respect to the use of the SRGB color space for both inputs and outputs of the composition function. XSL 1.1,section 7.18.1: This property describes the foreground color of an element's text content. CSS 2.1,section 14.1: This property describes the foreground color of an element's text content. | |||
| org.hbbtv_SUB1009 | 1 | Styling Test - Color - 008 | When a tts:color style attribute is applied to a tt:span element the textual content that is enclosed by that tt:span element shall be rendered by a presentation processor in the foreground color specified by that tts:color attributes value. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Foreground color of an area. EBU-TECH-3380,section 3.2.1.1.1: The tt:span element may be used to apply style information to the enclosed textual content. TTML1,section 8.2.3: The tts:color attribute is used to specify a style property that defines the foreground color of marks associated with an area generated by content flowed into a region. TTML1,section 7.1.6: When presented on a visual medium, a span element is intended to generate a sequence of inline areas, each containing one or more glyph areas. XSL 1.1,section 7.18.1: This property describes the foreground color of an element's text content. CSS 2.1,section 14.1: This property describes the foreground color of an element's text content. | |||
| org.hbbtv_SUB1010 | 1 | tts:unicodeBidi with "bidiOverride" and tts:direction with "ltr" applied to a tt:span. | If tts:unicodeBidi with value "bidiOverride" and tts:direction with the value "ltr" is applied to a tt:p or tt:span the presentation processor shall render the enclosed textual content so that the Unicode algorithm is overridden and the reordering is strictly in left-to-right sequence. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Directionality if bi directional text is used. EBU-TECH-3380,section 3.1.2.1: Directional embedding or override according to the Unicode bidirectional algorithm. TTML1,section 8.2.4: The tts:direction attribute is used to specify a style property that defines the directionality of an embedding or override according to the Unicode bidirectional algorithm. TTML1,section 8.2.21: The tts:unicodeBidi attribute is used to specify a style property that defines a directional embedding or override according to the Unicode bidirectional algorithm. XSL 1.1,section 8.2.4: This property specifies the base writing direction of blocks and the direction of embeddings and overrides (...) for the Unicode BIDI algorithm. XSL 1.1,section 7.29.6: If the element is inline-level or a block-level element that contains only inline-level elements, ['bidi-override'] creates an override. This means that inside the element, reordering is strictly in sequence according to the 'direction' property; the implicit part of the bidirectional algorithm is ignored. This corresponds to adding a LRO (U+202D; for 'direction: ltr') or RLO (U+202E; for 'direction: rtl') at the start of the element and a PDF (U+202C) at the end of the element. CSS 2.1,section 9.10: This property specifies the base writing direction of blocks and the direction of embeddings and overrides (...) for the Unicode bidirectional algorithm. CSS 2.1,section 9.10: For inline elements ['bidi-override'] creates an override. For block container elements ['bidi-override'] creates an override for inline-level descendants not within another block container element. This means that inside the element, reordering is strictly in sequence according to the 'direction' property; the implicit part of the bidirectional algorithm is ignored. This corresponds to adding a LRO (U+202D; for 'direction: ltr') or RLO (U+202E; for 'direction: rtl') at the start of the element or at the start of each anonymous child block box, if any, and a PDF (U+202C) at the end of the element. | |||
| org.hbbtv_SUB1011 | 1 | tts:unicodeBidi with "bidiOverride" and tts:direction with "rtl" applied to a tt:span. | If tts:unicodeBidi with value "bidiOverride" and tts:direction with the value "rtl" is applied to a tt:p or tt:span the presentation processor shall render the enclosed textual content so that the Unicode algorithm is overridden and the reordering is strictly in right-to-left sequence. | 2024-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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Directionality if bi directional text is used. EBU-TECH-3380,section 3.1.2.1: Directional embedding or override according to the Unicode bidirectional algorithm. TTML1,section 8.2.4: The tts:direction attribute is used to specify a style property that defines the directionality of an embedding or override according to the Unicode bidirectional algorithm. TTML1,section 8.2.21: The tts:unicodeBidi attribute is used to specify a style property that defines a directional embedding or override according to the Unicode bidirectional algorithm. XSL 1.1,section 8.2.4: This property specifies the base writing direction of blocks and the direction of embeddings and overrides (...) for the Unicode BIDI algorithm. XSL 1.1,section 7.29.6: If the element is inline-level or a block-level element that contains only inline-level elements, [bidi-override] creates an override. This means that inside the element, reordering is strictly in sequence according to the 'direction' property; the implicit part of the bidirectional algorithm is ignored. This corresponds to adding a LRO (U+202D; for 'direction: ltr') or RLO (U+202E; for 'direction: rtl') at the start of the element and a PDF (U+202C) at the end of the element. CSS 2.1,section 9.10: This property specifies the base writing direction of blocks and the direction of embeddings and overrides (...) for the Unicode bidirectional algorithm. CSS 2.1,section 9.10: For inline elements ["bidi-override"] creates an override. For block container elements ["bidi-override"] creates an override for inline-level descendants not within another block container element. This means that inside the element, reordering is strictly in sequence according to the 'direction' property; the implicit part of the bidirectional algorithm is ignored. This corresponds to adding a LRO (U+202D; for 'direction: ltr') or RLO (U+202E; for 'direction: rtl') at the start of the element or at the start of each anonymous child block box, if any, and a PDF (U+202C) at the end of the element. | |||
| org.hbbtv_SUB1012 | 1 | tts:unicodeBidi with "embed" and tts:direction with "ltr" applied to a tt:span. | If tts:unicodeBidi with value "embed" and tts:direction with the value "ltr" is applied to a tt:p or tt:span the presentation processor shall render the enclosed textual content as if a new embedding level was opened with the direction left-to-right. | 2024-1 2020-1 2019-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Directionality if bi directional text is used. EBU-TECH-3380,section 3.1.2.1: Directional embedding or override according to the Unicode bidirectional algorithm. TTML1,section 8.2.4: The tts:direction attribute is used to specify a style property that defines the directionality of an embedding or override according to the Unicode bidirectional algorithm. TTML1,section 8.2.21: The tts:unicodeBidi attribute is used to specify a style property that defines a directional embedding or override according to the Unicode bidirectional algorithm. XSL 1.1,section 8.2.4: This property specifies the base writing direction of blocks and the direction of embeddings and overrides (...) for the Unicode BIDI algorithm. XSL 1.1,section 7.29.6: If the element is inline-level, ["embed"] value opens an additional level of embedding with respect to the bidirectional algorithm. The direction of this embedding level is given by the 'direction' property. Inside the element, reordering is done implicitly. This corresponds to adding a LRE (U+202A; for 'direction: ltr') or RLE (U+202B; for 'direction: rtl') at the start of the element and a PDF (U+202C) at the end of the element. CSS 2.1,section 9.10: This property specifies the base writing direction of blocks and the direction of embeddings and overrides (...) for the Unicode bidirectional algorithm. CSS 2.1,section 9.10: If the element is inline, ['embed'] opens an additional level of embedding with respect to the bidirectional algorithm. The direction of this embedding level is given by the 'direction' property. Inside the element, reordering is done implicitly. This corresponds to adding a LRE (U+202A; for 'direction: ltr') or RLE (U+202B; for 'direction: rtl') at the start of the element and a PDF (U+202C) at the end of the element. | |||
| org.hbbtv_SUB1013 | 1 | tts:unicodeBidi with "embed" and tts:direction with "rtl" applied to a tt:span. | If tts:unicodeBidi with value "embed" and tts:direction with the value "rtl" is applied to a tt:p or tt:span the presentation processor shall render the enclosed textual content as if a new embedding level was opened with the direction right-to-left. | 2024-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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Directionality if bi directional text is used. EBU-TECH-3380,section 3.1.2.1: Directional embedding or override according to the Unicode bidirectional algorithm. TTML1,section 8.2.4: The tts:direction attribute is used to specify a style property that defines the directionality of an embedding or override according to the Unicode bidirectional algorithm. TTML1,section 8.2.21: The tts:unicodeBidi attribute is used to specify a style property that defines a directional embedding or override according to the Unicode bidirectional algorithm. XSL 1.1,section 7.29.1: This property specifies the base writing direction of blocks and the direction of embeddings and overrides (...) for the Unicode BIDI algorithm. XSL 1.1,section 7.29.6: If the element is inline-level, ["embed"] value opens an additional level of embedding with respect to the bidirectional algorithm. The direction of this embedding level is given by the 'direction' property. Inside the element, reordering is done implicitly. This corresponds to adding a LRE (U+202A; for 'direction: ltr') or RLE (U+202B; for 'direction: rtl') at the start of the element and a PDF (U+202C) at the end of the element. CSS 2.1,section 9.10: This property specifies the base writing direction of blocks and the direction of embeddings and overrides (...) for the Unicode bidirectional algorithm. CSS 2.1,section 9.10: If the element is inline, ['embed'] opens an additional level of embedding with respect to the bidirectional algorithm. The direction of this embedding level is given by the 'direction' property. Inside the element, reordering is done implicitly. This corresponds to adding a LRE (U+202A; for 'direction: ltr') or RLE (U+202B; for 'direction: rtl') at the start of the element and a PDF (U+202C) at the end of the element. | |||
| org.hbbtv_SUB1014 | 1 | tts:displayAlign set to "before" | If the tts:displayAlign attribute of a region is set to "before" the presentation processor shall align block elements in the block progression direction with the first block element aligned to the before edge of the region (e.g. if the block progression direction is top-to-bottom all block elements generated by a p element have to be aligned to the top of the region). Alignment shall be calculated after padding space (specified by tts:padding) has been subtracted from the region. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Alignment in the block progression direction. EBU-TECH-3380,section 3.1.3.1: Padding (or inset) space on all sides of a region area. TTML1,section 8.2.6: The tts:displayAlign attribute is used to specify a style property that defines the alignment of block areas in the block progression direction. TTML1,section 8.2.16: The tts:padding attribute is used to specify padding (or inset) space on all sides of a region's area. XSL 1.1,section 7.14.4: This property specifies the alignment, in the block-progression-direction, of the areas that are the children of a reference-area.(...). The before-edge of the allocation-rectangle of the first child area is placed coincident with the before-edge of the content-rectangle of the reference-area. XSL 1.1,section 4.2.3: [...] ... the content-rectangle is the rectangle bounding the inside of the padding and is used to describe the constraints on the positions of descendant areas. Related to this is the allocation-rectangle of an area, which is used to describe the constraints on the position of the area within its parent area. | |||
| org.hbbtv_SUB1015 | 1 | tts:displayAlign set to "after" | If the tts:displayAlign attribute of a region is set to "after" the presentation processor shall align block elements in the block progression direction with the last block element aligned to the after edge of the region (e.g. if the block progression direction is top-to-bottom all block elements generated by a p element have to be aligned to the bottom of the region). Alignment shall be calculated after padding space (specified by tts:padding) has been subtracted from the region. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Alignment in the block progression direction. EBU-TECH-3380,section 3.1.3.1: Padding (or inset) space on all sides of a region area. TTML1,section 8.2.6: The tts:displayAlign attribute is used to specify a style property that defines the alignment of block areas in the block progression direction. TTML1,section 8.2.16: The tts:padding attribute is used to specify padding (or inset) space on all sides of a region's area. (...) If the value of this attribute consists of one <length> specification, then that length applies to all edges of the affected areas. XSL 1.1,section 7.14.4: after The after-edge of the allocation-rectangle of the last child area is placed coincident with the after-edge of the content-rectangle of the reference-area. XSL 1.1,section 4.2.3: [...] ... the content-rectangle is the rectangle bounding the inside of the padding and is used to describe the constraints on the positions of descendant areas. Related to this is the allocation-rectangle of an area, which is used to describe the constraints on the position of the area within its parent area. | |||
| org.hbbtv_SUB1016 | 1 | tts:displayAlign set to "center" | If the tts:displayAlign attribute of a region is set to "center" the presentation processor shall place all block elements in the block progression direction so that the distance between the before-edge of the first block element and the before-edge of the region plus specified padding space to the before edge of the region is the same as the distance between the after-edge of the last block element and the after-edge of the region minus specified padding space to the after edge of the region. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Alignment in the block progression direction. TTML1,section 8.2.6: The tts:displayAlign attribute is used to specify a style property that defines the alignment of block areas in the block progression direction. XSL 1.1,section 4.2.3: [...] ... the content-rectangle is the rectangle bounding the inside of the padding and is used to describe the constraints on the positions of descendant areas. Related to this is the allocation-rectangle of an area, which is used to describe the constraints on the position of the area within its parent area. XSL 1.1,section 7.14.4: This property specifies the alignment, in the block-progression-direction, of the areas that are the children of a reference-area.(...). The child areas are placed such that the distance between the before-edge of the allocation-rectangle of the first child area and the before-edge of the content-rectangle of the reference-area is the same as the distance between the after-edge of the allocation-rectangle of the last child area and the after-edge of the content-rectangle of the reference-area. | |||
| org.hbbtv_SUB1017 | 1 | tts:extent | The width and height of each region are proportional to the width and height of the video rendering plane and the proportions are those specified in percentage values by the region's tts:extent attribute for width and height respectively. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Width and height of a region area. Only percentage values shall be specified. The values shall be relative to the width and height of the root container region. EBU-TECH-3380,section 2.5: The implementation shall provide a rendering plane which shall be coincident with the root container region of the EBU TT document. If the related media object is a video media object then the rendering plane shall be coincident with the rendering plane of the video media object. TTML1,section 8.2.7: The tts:extent attribute is used to specify the width and height of a region area. (...) If the value of this attribute consists of two [length] specifications, then they must be interpreted as width and height, where the first specification is the width, and the second specification is the height. | |||
| org.hbbtv_SUB1018 | 1 | tts:fontStyle with the value "normal" | When a tts:fontStyle attribute with the value of "normal" is applied to a tt:span the presentation processor shall render the enclosed content with a font that is classified as "normal". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Font style that applies to glyphs. TTML1,section 8.2.10: The tts:fontStyle attribute is used to specify a style property that defines the font style to apply to glyphs that are selected for glyph areas generated by content flowed into a region, where the mapping from font style value to specific font face or style parameterization is not determined by this specification. XSL 1.1,section 2.9.7: ['normal'] specifies a font that is classified as "normal" in the [user agent's] font database. CSS 2.1,section 15.4: A value of 'normal' selects a font that is classified as 'normal' in the [user agent's] font database. | |||
| org.hbbtv_SUB1019 | 1 | tts:fontStyle with the value "italic" | When a tts:fontStyle attribute with the value of "italic" is applied to a tt:span the presentation processor shall render the enclosed content with a font that is classified as "italic". Fonts with Italic, Cursive, or Kursiv in their names will typically be labeled "italic". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 7.3.1.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Font style that applies to glyphs. TTML1,section 8.2.10: The tts:fontStyle attribute is used to specify a style property that defines the font style to apply to glyphs that are selected for glyph areas generated by content flowed into a region, where the mapping from font style value to specific font face or style parameterization is not determined by this specification. XSL 1.1,section 2.9.7: ['italic'] specifies a font that is classified as "italic" in the [user agent's] font database, or, if that is not available, one labeled 'oblique'. Fonts with Italic, Cursive, or Kursiv in their names will typically be labeled "italic". (...) XSL modifications to the CSS definition: 'italic' will be satisfied if there is either a face in the [user agent's] font database labeled with the CSS keyword 'italic' (preferred) or 'oblique'. Otherwise the values must be matched exactly or font-style will fail. CSS 2.1,section 15.4: A value of 'italic' selects a font that is labeled 'italic', or, if that is not available, one labeled 'oblique'. | |||
| org.hbbtv_SUB1020 | 1 | tts:fontWeight with the value "normal" | When a tts:fontWeight attribute with the value of "normal" is applied to a tt:span the presentation processor shall render the enclosed content with a font with the weight value of "400". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Font weight that applies to glyphs. TTML1,section 8.2.11: The tts:fontWeight attribute is used to specify a style property that defines the font weight to apply to glyphs that are selected for glyph areas generated by content flowed into a region, where the mapping from font weight value to specific font face or weight parameterization is not determined by this specification. XSL 1.1,section 7.9.9: The "font-weight" property specifies the weight of the font. [The value] normal [is the] same as "400". CSS 2.1,section 15.6: The 'font-weight' property selects the weight of the font. The values '100' to '900' form an ordered sequence, where each number indicates a weight that is at least as dark as its predecessor. The keyword 'normal' is synonymous with '400'. | |||
| org.hbbtv_SUB1021 | 1 | tts:fontWeight with the value "bold" | When a tts:fontWeight attribute with the value of "bold" is applied to a tt:span the presentation processor shall render the enclosed content with a font with the weight value of "700". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Font weight that applies to glyphs. TTML1,section 8.2.11: The tts:fontWeight attribute is used to specify a style property that defines the font weight to apply to glyphs that are selected for glyph areas generated by content flowed into a region, where the mapping from font weight value to specific font face or weight parameterization is not determined by this specification. XSL 1.1,section 7.9.9: The "font-weight" property specifies the weight of the font. [The value] bold [is the] same as "700". CSS 2.1,section 15.6: The 'font-weight' property selects the weight of the font. The values '100' to '900' form an ordered sequence, where each number indicates a weight that is at least as dark as its predecessor. The keyword (...) 'bold' is synonymous with '700'. | |||
| org.hbbtv_SUB1022 | 1 | tts:origin | The presentation processor shall render each region so that its top left corner is at the x and y coordinates specified by the tts:origin attribute of the region. Example: With tts:origin="20% 80%" the top left corner of the region is shifted 20% of the video rendering plane width to the right and 80% of the video rendering plane height to the bottom. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: The x and y coordinates of the top left corner of a region with respect to the root container region. The (0, 0) coordinate shall be assumed to be the top left corner of the root container region. Only percentage values shall be specified. The values shall be relative to the width and height of the root container region. EBU-TECH-3380,section 2.5: The implementation shall provide a rendering plane which shall be coincident with the root container region of the EBU TT document. If the related media object is a video media object then the rendering plane shall be coincident with the rendering plane of the video media object. TTML1,section 8.2.14: The tts:origin attribute is used to specify the x and y coordinates of the origin of a region area with respect to the origin of the Root Container Region. (...) If the value of this attribute consists of two <length> specifications, then they must be interpreted as x and y coordinates, where the first specification is the x coordinate, and the second specification is the y coordinate. | |||
| org.hbbtv_SUB1023 | 1 | tts:padding with one value | If the tts:padding of a region is set to a single value the presentation processor shall apply the specified value as padding to all sides of the region's area. | 2024-1 2023-3 2023-2 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-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Padding (or inset) space on all sides of a region area. TTML1,section 8.2.16: The tts:padding attribute is used to specify padding (or inset) space on all sides of a region's area. (...) If the value of this attribute consists of one <length> specification, then that length applies to all edges of the affected areas. XSL 1.1,section 7.31.15: A shorthand property for setting padding-top, padding-bottom, padding-left, and padding-right of a block-area or inline-area. If there is only one value, it applies to all sides. CSS 2.1,section 8.4: The padding properties specify the width of the padding area of a box. The 'padding' shorthand property sets the padding for all four sides. | |||
| org.hbbtv_SUB1024 | 1 | tts:padding with two values | If the tts:padding of a region is set to two values the presentation processor shall apply the first value as padding space to the before and after edges and the second value as padding space to the start and end edges of the region's area. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Padding (or inset) space on all sides of a region area. If the value consists of two <length> specifications, then the first applies to the before and after edges, and the second applies to the start and end edges. TTML1,section 8.2.16: The tts:padding attribute is used to specify padding (or inset) space on all sides of a region area. (...) If the value consists of two <length> specifications, then the first applies to the before and after edges, and the second applies to the start and end edges. | |||
| org.hbbtv_SUB1025 | 1 | tts:padding with three values | If the tts:padding of a region is set to three values the presentation processor shall apply the first value as padding space to the before edge, the second value to the start and end edges and the third value as padding space to the after edge of the region's area. | 2024-1 2023-3 2023-2 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-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Padding (or inset) space on all sides of a region area. TTML1,section 8.2.16: The tts:padding attribute is used to specify padding (or inset) space on all sides of a region area. (...) If three <length> specifications are provided, then the first applies to the before edge, the second applies to the start and end edges, and the third applies to the after edge. | |||
| org.hbbtv_SUB1026 | 1 | tts:padding with four values | If the tts:padding of a region is set to four values the presentation processor shall apply the first value to the before edge, the second value to the end edge, the third value to the after edge and the fourth value to the start edge of the region's area. | 2024-1 2023-3 2023-2 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-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Padding (or inset) space on all sides of a region area. TTML1,section 8.2.16: The tts:padding attribute is used to specify padding (or inset) space on all sides of a region area. (...) If four <length> specifications are provided, then they apply to before, end, after, and start edges, respectively. | |||
| org.hbbtv_SUB1028 | 1 | tts:showBackground with the value whenActive | When the tts:showBackground attribute of the region has the value whenActive a presentation processor shall render the background color of the region only when some content is flowed into the region. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Constraints on when the background color of a region is intended to be presented. [...] ; if the value is “whenActive”, then the background color of a region is rendered only when some content is flowed into the region. TTML1,section 8.2.17: The tts:showBackground attribute is used to specify constraints on when the background color of a region is intended to be presented. [...] if the value is whenActive, then the background color of a region is rendered only when some content is flowed into the region. | |||
| org.hbbtv_SUB1029 | 1 | Style Inheritance | If an inheritable style attribute is specified on more than one ancestor element of a given text (e.g. tts:color set to the value white on tt:body and to yellow on tt:p) then the presentation processor renders the text content according to the value specified by the closest ancestor on which that value is specified (e.g. yellow). | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." TTML1,section 8.4.2.1: Style properties are inherited from ancestor Content elements within an intermediate synchronic document if a style property is not associated with a Content element (or an anonymous span) and the style property is designated as inheritable. If a style property is determined to require inheritance, then the inherited value must be the value of the same named style property in the computed style set of the element's immediate ancestor element within the applicable intermediate synchronic document. | |||
| org.hbbtv_SUB1030 | 1 | tts:textAlign set to right | If a tts:textAlign attribute with the value "right" is applied to a tt:p element (by direct reference of a style or inheritance) all inline areas in this tt:p are aligned to the right in the inline progression direction. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Alignment of inline areas in a containing block. TTML1,section 8.2.18: The tts:textAlign attribute is used to specify a style property that defines how inline areas are aligned within a containing block area in the inline progression direction. XSL 1.1,section 7.16.9: This property describes how inline content of a block is aligned. CSS 2.1,section 16.2: This property describes how inline-level content of a block container is aligned. [...] A block of text is a stack of line boxes. In the case of 'left', 'right' and 'center', this property specifies how the inline-level boxes within each line box align with respect to the line box's left and right sides; [...] | |||
| org.hbbtv_SUB1031 | 1 | tts:textAlign set to left | If a tts:textAlign attribute with the value "left" is applied to a tt:p element (by direct reference of a style or inheritance) all inline areas in this tt:p are aligned to the left in the inline progression direction. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Alignment of inline areas in a containing block. TTML1,section 8.2.18: The tts:textAlign attribute is used to specify a style property that defines how inline areas are aligned within a containing block area in the inline progression direction. XSL 1.1,section 7.16.9: This property describes how inline content of a block is aligned. CSS 2.1,section 16.2: This property describes how inline-level content of a block container is aligned. [...] A block of text is a stack of line boxes. In the case of 'left', 'right' and 'center', this property specifies how the inline-level boxes within each line box align with respect to the line box's left and right sides; [...] | |||
| org.hbbtv_SUB1032 | 1 | tts:textAlign set to center | If a tts:textAlign attribute with the value "center" is applied to a tt:p element (by direct reference of a style or inheritance) all inline areas in this tt:p are centered in the inline progression direction. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Alignment of inline areas in a containing block. TTML1,section 8.2.18: The tts:textAlign attribute is used to specify a style property that defines how inline areas are aligned within a containing block area in the inline progression direction. XSL 1.1,section 7.16.9: This property describes how inline content of a block is aligned. CSS 2.1,section 16.2: This property describes how inline-level content of a block container is aligned. [...] A block of text is a stack of line boxes. In the case of 'left', 'right' and 'center', this property specifies how the inline-level boxes within each line box align with respect to the line box's left and right sides; [...] | |||
| org.hbbtv_SUB1033 | 1 | tts:textAlign set to start | If a tts:textAlign attribute with the value "start" is applied to a tt:p element (by direct reference of a style or inheritance ) all inline areas in this tt:p are aligned to the start edge in the inline progression direction. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 7.3.1.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Alignment of inline areas in a containing block. [...] The alignment values "start" and "end" depend on the writing direction of the text which may be specified on a tt:region element with the attribute tts:writingMode. TTML1,section 8.2.18: The tts:textAlign attribute is used to specify a style property that defines how inline areas are aligned within a containing block area in the inline progression direction. XSL 1.1,section 7.16.9: This property describes how inline content of a block is aligned.[...] start [...] Specifies that the content is to be aligned on the start-edge in the inline-progression-direction. | |||
| org.hbbtv_SUB1034 | 1 | tts:textAlign set to end | If a tts:textAlign attribute with the value "end" is applied to a tt:p element (by direct reference of a style or inheritance ) all inline areas in this tt:p are aligned to the end edge in the inline progression direction. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Alignment of inline areas in a containing block. [...] The alignment values "start" and "end" depend on the writing direction of the text which may be specified on a tt:region element with the attribute tts:writingMode. TTML1,section 8.2.18: The tts:textAlign attribute is used to specify a style property that defines how inline areas are aligned within a containing block area in the inline progression direction. XSL 1.1,section 7.16.9: This property describes how inline content of a block is aligned.[...] end [...] Specifies that the content is to be aligned on the end-edge in the inline-progression-direction. | |||
| org.hbbtv_SUB1036 | 1 | tts:wrapOption set to wrap | If the attribute tts:wrapOption with the value "wrap" is applied to a content element automatic line wrapping shall be performed. The presentation processor shall attempt to draw all text within the element's content rectangle, calculated as the inner area of the region after padding has been applied, drawing no foreground pixels beyond the edge at either end of any line. New lines should be created where an overflow would otherwise occur and text that could not be drawn at the end of one line must flow in to the beginning of the following line. If tts:overflow is set to "visible" then the new lines may extend all the way to the edge of the root container extent. | 2024-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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Defines whether or not automatic line wrapping (breaking) applies within the context of the affected element. If the value is "wrap" automated line breaking shall occur if the line overflows the extent of the region that contains the corresponding content. EBU-TECH-3380,section 3.1.3.1: Defines whether a region area is clipped if the content of the region overflows the specified extent of the region. If the value of this attribute is "visible", then content should not be clipped. TTML1,section 8.2.23: The tts:wrapOption attribute is used to specify a style property that defines whether or not automatic line wrapping (breaking) applies within the context of the affected element. TTML1,section 8.2.15: The tts:overflow attribute is used to specify a style property that defines whether a region area is clipped or not if the descendant areas of the region overflow its extent. XSL 1.1,section 7.16.13: wrap [...] Line-breaking will occur if the line overflows the available block width. | |||
| org.hbbtv_SUB1037 | 1 | tts:wrapOption set to noWrap | If the attribute tts:wrapOption with the value "noWrap" is applied to a content element no automatic line wrapping shall apply within the context of the affected element. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.2.1: Defines whether or not automatic line wrapping (breaking) applies within the context of the affected element. If the value is “noWrap” no automated line breaking shall occur. In the case when lines are longer than the available width of the region and "noWrap" is set, the overflow shall be treated in accordance with the specified value of the tts:overflow attribute of the corresponding region. TTML1,section 8.2.23: The tts:wrapOption attribute is used to specify a style property that defines whether or not automatic line wrapping (breaking) applies within the context of the affected element. XSL 1.1,section 7.16.13: no-wrap: No line-wrapping will be performed. In the case when lines are longer than the available width of the content-rectangle, the overflow will be treated in accordance with the "overflow" property specified on the reference-area. | |||
| org.hbbtv_SUB1038 | 1 | tts:writingMode set to lrtb | When the tts:writingMode attribute of a region is set to "lrtb" the presentation processor shall render the text in this region so that inline components and text within a line are written left-to-right. Lines and blocks shall be placed top-to-bottom. | 2024-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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Writing mode of subtitle content. "lrtp": “Left to Right Top to Bottom” TTML1,section 8.2.24: The tts:writingMode attribute is used to specify a style property that defines the block and inline progression directions to be used for the purpose of stacking block and inline areas within a region area. XSL 1.1,section 7.29.7: Inline components and text within a line are written left-to-right. Lines and blocks are placed top-to-bottom. Establishes the following directions: inline-progression-direction to left-to-right [...] block-progression-direction to top-to-bottom | |||
| org.hbbtv_SUB1039 | 1 | tts:writingMode set to rltb | When the tts:writingMode attribute of a region is set to "rltb" the presentation processor shall render the text in this region so that inline components and text within a line are written right-to-left. Lines and blocks shall be placed top-to-bottom. | 2024-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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Writing mode of subtitle content. [...] "rltb": "Right to Left Top to Bottom" TTML1,section 8.2.24: The tts:writingMode attribute is used to specify a style property that defines the block and inline progression directions to be used for the purpose of stacking block and inline areas within a region area. XSL 1.1,section 7.29.7: Inline components and text within a line are written right-to-left. Lines and blocks are placed top-to-bottom. Establishes the following directions: inline-progression-direction to right-to-left [...] block-progression-direction to top-to-bottom | |||
| org.hbbtv_SUB1041 | 1 | tts:writingMode set to tblr | When the tts:writingMode attribute of a region is set to "tblr" the presentation processor shall render the text in this region so that inline components and text within a line are written top-to-bottom. Lines and blocks shall be placed left-to-right. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.1.3.1: Writing mode of subtitle content. [...] "tblr": "Top to Bottom Left to Right" TTML1,section 8.2.24: The tts:writingMode attribute is used to specify a style property that defines the block and inline progression directions to be used for the purpose of stacking block and inline areas within a region area. XSL 1.1,section 7.29.7: Inline components and text within a line are stacked top-to-bottom. Lines and blocks are stacked left-to-right. Establishes the following directions: inline-progression-direction to top-to-bottom [...] block-progression-direction to left-to-right | |||
| org.hbbtv_SUB1045 | 1 | begin and end attribute on a tt:p | If begin and end attribute are present on tt:p element the enclosed content shall be rendered according to the time expressions of those attributes. | 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.2.1.1: begin (attribute): [...] Start point of a temporal interval associated with a tt:p element. [...] end (attribute): End point of a temporal interval associated with a tt:p element. TTML1,section 10.2.1: The begin attribute is used to specify the begin point of a temporal interval associated with a timed element. [...] The begin point of a temporal interval is included in the interval; i.e., the interval is left-wise closed. TTML1,section 10.2.2: The end attribute is used to specify the ending point of a temporal interval associated with a timed element. [...] The ending point of a temporal interval is not included in the interval; i.e., the interval is right-wise open. | |||
| org.hbbtv_SUB1046 | 1 | begin and end attribute on a tt:span | If 'begin' and 'end' attributes are present on tt:span element the enclosed content shall be rendered according to the time expressions of those attributes. | 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 3.2.1.1: begin (attribute): [...] Start point of a temporal interval associated with a tt:span element. [...] end (attribute): End point of a temporal interval associated with a tt:span element. TTML1,section 10.2.1: The begin attribute is used to specify the begin point of a temporal interval associated with a timed element. [...] The begin point of a temporal interval is included in the interval; i.e., the interval is left-wise closed. TTML1,section 10.2.2: The end attribute is used to specify the ending point of a temporal interval associated with a timed element. [...] The ending point of a temporal interval is not included in the interval; i.e., the interval is right-wise open. | |||
| org.hbbtv_SUB1047 | 1 | Initial value Test - cellResolution | If the ttp:cellResolution attribute is not specified on the root element a presentation processor shall apply the initial value of "32 15". The initial value should be checked as follows: Vertically: a document that omits the cellResolution attribute and specifies a style with a 100% font size must be presented with a font that is 1/15 of the height of the root container extent, or equivalently, the rendering plane of the video area. Horizontally: a document that omits the cellResolution attribute and specifies a style with an opaque background colour and a linePadding value of "1c" should result in text being rendered with additional background on either side of the text whose width is 1/32 of the width of the root container extent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)."[...] Terminals shall support the ebutts:multiRowAlign and ebutts:linePadding extensions to TTML defined in the EBU-TT-D specification [43]. EBU-TECH-3380,section 2.3: TTML 1.0 defines initial values for certain attributes that act as fallback values in case a value cannot be computed from a specified value in the document. The EBU TT D specification does not override these initial values and for any TTML 1.0 attribute that is used in an EBU TT D document the initial value as specified in TTML 1.0 shall apply. EBU-TECH-3380,section 3: Expresses a virtual visual grid composed of horizontal and vertical cells. This grid divides the root container region (see “Definition of terms”) in rows and columns. The first value defines the number of columns and the second value defines the number of rows. The ttp:cellResolution should be set explicitly. Otherwise the default value of "32 15" shall apply. TTML1,section 6.2.1: The ttp:cellResolution attribute may be used by an author to express the number of horizontal and vertical cells into which the Root Container Region area is divided for the purpose of expressing presentation semantics in terms of a uniform grid[...]If not specified, the number of columns and rows must be considered to be 32 and 15, respectively. | |||
| org.hbbtv_SUB1048 | 1 | Initial value Test - direction | If tts:direction does not apply to a tt:span or tt:p through reference or inheritance a presentation processor shall render the enclosed content as if "ltr" was specified. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 2.3: TTML 1.0 defines initial values for certain attributes that act as fallback values in case a value cannot be computed from a specified value in the document. The EBU TT D specification does not override these initial values and for any TTML 1.0 attribute that is used in an EBU TT D document the initial value as specified in TTML 1.0 shall apply. TTML1,section 8.2.4: The tts:direction attribute is used to specify a style property that defines the directionality of an embedding or override according to the Unicode bidirectional algorithm. [...] Initial: ltr | |||
| org.hbbtv_SUB1049 | 1 | Initial value test - tts:fontFamily | If tts:fontFamily does not apply to text content through reference or inheritance a presentation processor shall render text as if "default" was specified. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." TTML1,section 8.2.8: The tts:fontFamily attribute is used to specify a style property that defines the font family from which glyphs are selected for glyph areas generated by content flowed into a region. [...] Initial: default TTML1,section 8.3.6: If the generic family name default is specified (or implied by an initial value), then its typographic characteristics are considered to be implementation dependent; however, it is recommended that this default font family be mapped to an monospaced, sans-serif font. | |||
| org.hbbtv_SUB1050 | 1 | Initial value Test - fontSize | If tts:fontSize does not apply to text content through reference or inheritance a presentation processor shall render the text as if "100%" was specified. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 2.3: TTML 1.0 defines initial values for certain attributes that act as fallback values in case a value cannot be computed from a specified value in the document. The EBU TT D specification does not override these initial values and for any TTML 1.0 attribute that is used in an EBU TT D document the initial value as specified in TTML 1.0 shall apply. EBU-TECH-3380,section 3.1.2.1: The font-size of a glyph. Only one percentage value shall be specified. TTML1,section 8.2.9: The tts:fontSize attribute is used to specify a style property that defines the font size for glyphs that are selected for glyph areas generated by content flowed into a region.[...] Initial: 1c [...] Percentages: if not region element, then relative to parent element's font size; otherwise, relative to the Computed Cell Size. | |||
| org.hbbtv_SUB1051 | 1 | Initial value Test - lineHeight | If tts:lineHeight does not apply to a tt:p through reference or inheritance a presentation processor shall render enclosed content as if the value "normal" was specified. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 2.3: TTML 1.0 defines initial values for certain attributes that act as fallback values in case a value cannot be computed from a specified value in the document. The EBU TT D specification does not override these initial values and for any TTML 1.0 attribute that is used in an EBU TT D document the initial value as specified in TTML 1.0 shall apply. EBU-TECH-3380,section 3.1.2.1: Inter-baseline separation between line areas. Only a percentage value or the string “normal” shall be specified. The semantics are defined as in TTML 1.0. TTML1,section 8.2.12: The tts:lineHeight attribute is used to specify a style property that defines the inter-baseline separation between line areas generated by content flowed into a region.[...] Initial: normal" | |||
| org.hbbtv_SUB1057 | 1 | Initial value Test - wrapOption | If tts:wrapOption does not apply to text content a presentation processor shall render the text as if the value "wrap" was specified. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 2.3: TTML 1.0 defines initial values for certain attributes that act as fallback values in case a value cannot be computed from a specified value in the document. The EBU TT D specification does not override these initial values and for any TTML 1.0 attribute that is used in an EBU-TT-D document the initial value as specified in TTML 1.0 shall apply. EBU-TECH-3380,section 3.1.2.1: Defines whether or not automatic line wrapping (breaking) applies within the context of the affected element. If the value is “wrap” automated line-breaking shall occur if the line overflows the extent of the region that contains the corresponding content. If the value is “noWrap” no automated line-breaking shall occur. In the case when lines are longer than the available width of the region and “noWrap” is set, the overflow shall be treated in accordance with the specified value of the tts:overflow attribute of the corresponding region. If the value of the tts:wrapOption is set to “noWrap” the region that corresponds to the affected content should have the attribute tts:overflow set to “visible”. TTML1,section 8.2.23: The tts:wrapOption attribute is used to specify a style property that defines whether or not automatic line wrapping (breaking) applies within the context of the affected element. [...] Initial: wrap | |||
| org.hbbtv_SUB1058 | 1 | Initial value Test - displayAlign | If tts:displayAlign was not specified for a region a presentation processor shall render content in that region as if the value "before" was specified. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)." EBU-TECH-3380,section 2.3: TTML 1.0 defines initial values for certain attributes that act as fallback values in case a value cannot be computed from a specified value in the document. The EBU TT D specification does not override these initial values and for any TTML 1.0 attribute that is used in an EBU-TT-D document the initial value as specified in TTML 1.0 shall apply. EBU-TECH-3380,section 3.1.3.1: Alignment in the block progression direction. TTML1,section 8.2.6: The tts:displayAlign attribute is used to specify a style property that defines the alignment of block areas in the block progression direction. [...] Initial: before | |||
| org.hbbtv_SUB1071 | 1 | Test textAlign center, multiRowAlign start | When requested to present an EBU-TT-D document that includes a 3-line subtitle in which the top line is longest and if the lines are marked up with tts:textAlign="center" and ebutts:multiRowAlign="start" that are applied to the tt:p element by inheritance the presentation processor/terminal shall align the top line to the center and the shorter lines to the start alignment point of the top line. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)."[...] Terminals shall support the ebutts:multiRowAlign and ebutts:linePadding extensions to TTML defined in the EBU-TT-D specification [43]. EBU-TECH-3380,section 3.1.2.1: Alignment of multiple 'rows' of inline areas within a containing block area. EBU-TECH-3380,section ANNEX.C: tts:textAlign="center" and ebutts:multiRowAlign = "start": The longest 'row' shall be center aligned. Shorter 'rows' shall be start aligned against the start alignment point created by the longest 'row'. EBU-TECH-3380,section 3.1.2.1: Alignment of inline areas in a containing block. [...] The alignment values "start" and "end" depend on the writing direction of the text which may be specified on a tt:region element with the attribute tts:writingMode. TTML1,section 8.2.18: The tts:textAlign attribute is used to specify a style property that defines how inline areas are aligned within a containing block area in the inline progression direction. | |||
| org.hbbtv_SUB1072 | 1 | Test textAlign center, multiRowAlign end | When requested to present an EBU-TT-D document that includes a 3-line subtitle in which the second line is longest and if the lines are marked up with tts:textAlign="center" and ebutts:multiRowAlign="end" that are applied to the tt:p element by direct reference the presentation processor/terminal shall align the second line to the center and the shorter lines to the end alignment point of the second line. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)."[...] Terminals shall support the ebutts:multiRowAlign and ebutts:linePadding extensions to TTML defined in the EBU-TT-D specification [43]. EBU-TECH-3380,section 3.1.2.1: Alignment of multiple 'rows' of inline areas within a containing block area. EBU-TECH-3380,section ANNEX.C: tts:textAlign="center" and ebutts:multiRowAlign = "end": The longest 'row' shall be center aligned. Shorter 'rows' shall be end aligned against the end alignment point created by the longest 'row'. EBU-TECH-3380,section 3.1.2.1: Alignment of inline areas in a containing block. [...] The alignment values "start" and "end" depend on the writing direction of the text which may be specified on a tt:region element with the attribute tts:writingMode. TTML1,section 8.2.18: The tts:textAlign attribute is used to specify a style property that defines how inline areas are aligned within a containing block area in the inline progression direction. | |||
| org.hbbtv_SUB1078 | 1 | Test linePadding and cellResolution | When a tts:linePadding attribute applies to tt:p by direct reference of a style or by inheritance the specified padding space shall be rendered to each line area that is generated by the content inside the p element taking into account the specified cell resolution of the document. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format)."[...] Terminals shall support the ebutts:multiRowAlign and ebutts:linePadding extensions to TTML defined in the EBU-TT-D specification [43]. EBU-TECH-3380,section 3.1.2.1: Padding (or inset) space on the start and end edges of each rendered line-area It may be specified by the block-level elements tt:body, tt:div and tt:p by reference to a style element and is inherited. Background color applies to the area including the line padding. EBU-TECH-3380,section 4.11: The content shall be constrained to one non-negative number of type xs:decimal appended by the metric “c”. The reference for the metric “c” (for cells) is the virtual grid that is defined by ttp:cellResolution. 1c corresponds to one cell in this grid. The value shall apply to the start and end edges of each rendered line area. EBU-TECH-3380,section 4.1: The content shall be constrained to two numbers of type xs:positiveInteger delimited by a space. The first value shall define the number of columns and the second value shall define the number of rows. | |||
| org.hbbtv_SUB1080 | 1 | EBUTTD: No gaps between adjacent line backgrounds for lineHeight="125%" | An EBU-TT-D file contains a single tt:p element that contains multiple tt:span elements, each of which contains a single word of text. Within the tt:p element there are also two tt:br elements, each positioned between a pair of tt:span elements such that there is more than one tt:span element on either side of each tt:br. The tt:p element references a single tt:style element, which includes one tts:lineHeight attribute whose value is "125%"; all tt:span elements reference a single tt:style element, which includes one tts:backgroundColor attribute whose value represents an opaque color. When the terminal presents this file over a video stream, there are no gaps between the backgrounds of adjacent lines. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 | HBBTV,section 7.3.1.5.1: On terminals that support EBU-TT-D version 1.0 and no later version, where the tts:lineHeight attribute of a tt:p element has the value "normal" or a value less than or equal to 125%, the background of each generated inline area shall be rendered such that there are no gaps between the rendered backgrounds of adjacent lines. | -EBUTTD_GT_1_0 | ||
| org.hbbtv_SUB1081 | 1 | EBUTTD: No gaps between adjacent line backgrounds for lineHeight="normal" | An EBU-TT-D file contains a single tt:p element that contains multiple tt:span elements, each of which contains a single word of text. Within the tt:p element there are also two tt:br elements, each positioned between a pair of tt:span elements such that there is more than one tt:span element on either side of each tt:br. The tt:p element references a single tt:style element, which includes one tts:lineHeight attribute whose value is "normal"; all tt:span elements reference a single tt:style element, which includes one tts:backgroundColor attribute whose value represents an opaque color. When the terminal presents this file over a video stream, there are no gaps between the backgrounds of adjacent lines. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 | HBBTV,section 7.3.1.5.1: On terminals that support EBU-TT-D version 1.0 and no later version, where the tts:lineHeight attribute of a tt:p element has the value "normal" or a value less than or equal to 125%, the background of each generated inline area shall be rendered such that there are no gaps between the rendered backgrounds of adjacent lines. | -EBUTTD_GT_1_0 | ||
| org.hbbtv_SUB1082 | 1 | EBUTTD: No gaps between adjacent line backgrounds when itts:fillLineGap is true | An EBU-TT-D file contains a single tt:p element that contains multiple tt:span elements, each of which contains a single word of text. Within the tt:p element there are also two tt:br elements, each positioned between a pair of tt:span elements such that there is more than one tt:span element on either side of each tt:br. The tt:p element references a single tt:style element, which includes one tts:lineHeight attribute whose value is "130%" and which includes one itts:fillLineGap attribute whose value is "true"; all tt:span elements reference a single tt:style element, which includes one tts:backgroundColor attribute whose value represents an opaque color. When the terminal presents this file over a video stream, there are no gaps between the backgrounds of adjacent lines. | 2024-1 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 7.3.1.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: * The subtitle document shall be compliant with the EBU-TT-D specification version 1.0.1 [43] (referred to as "EBU-TT-D" format). ... Terminals shall support the ebutts:multiRowAlign, ebutts:linePadding and itts:fillLineGap extensions to TTML defined or referenced in the EBU-TT-D specification [43]. EBU-TECH-3380,section 3.1.2.1: itts:fillLineGap (attribute) ... Type and semantics shall be as defined in IMSC 1.0.1. IMSC,section 6.7.6: If itts:fillLineGap="true" then the background of each inline area generated by descendant spans of the p element SHALL extend to the before-edge and after-edge of its containing line area | |||
| org.hbbtv_SUB1083 | 1 | EBUTTD: Gaps between adjacent line backgrounds when itts:fillLineGap is false | An EBU-TT-D file contains a single tt:p element that contains multiple tt:span elements, each of which contains a single word of text. Within the tt:p element there are also two tt:br elements, each positioned between a pair of tt:span elements such that there is more than one tt:span element on either side of each tt:br. The tt:p element references a single tt:style element, which includes one tts:lineHeight attribute whose value is "124%" and which includes one itts:fillLineGap attribute whose value is "false"; all tt:span elements reference a single tt:style element, which includes one tts:backgroundColor attribute whose value represents an opaque color. When the terminal presents this file over a video stream, there are gaps between the backgrounds of adjacent lines through which the underlying video can be seen. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 | The challenge exists but not validated | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: * The subtitle document shall be compliant with the EBU-TT-D specification version 1.0.1 [43] (referred to as "EBU-TT-D" format). ... Terminals shall support the ebutts:multiRowAlign, ebutts:linePadding and itts:fillLineGap extensions to TTML defined or referenced in the EBU-TT-D specification [43]. EBU-TECH-3380,section 3.1.2.1: itts:fillLineGap (attribute) ... Type and semantics shall be as defined in IMSC 1.0.1. IMSC,section 6.7.6: If itts:fillLineGap="true" then the background of each inline area generated by descendant spans of the p element SHALL extend to the before-edge and after-edge of its containing line area | ||
| org.hbbtv_SUB1090 | 1 | EBUTTD: Timing on multiple tt:spans within a tt:p | An EBU-TT-D file contains a single tt:p element with no begin or end time. This tt:p contains multiple tt:span elements, each of which contains a single word of text. All the tt:span elements have declared begin and end times: the begin time of each tt:span (other than the first) is one second greater than the begin time of the immediately preceding tt:span; the end time of all tt:spans is three seconds greater than the begin time of the last tt:span in the tt:p element. When the terminal presents this file over a video stream, the content of each tt:span becomes visible at its begin time (with the effect that a new word is added to the end of the rendered paragraph every second), and the rendered content of all tt:spans in the tt:p is removed from display immediately before the common end time shared by all the tt:spans and is not visible at that end time. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 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.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: The subtitle document shall be compliant with the EBU-TT-D specification (referred to as "EBU-TT-D" format). EBU-TECH-3380,section 3.2.1.1: begin (attribute): [...] Start point of a temporal interval associated with a tt:p element. [...] end (attribute): End point of a temporal interval associated with a tt:p element. EBU-TECH-3380,section 3.2.1.1.1: begin (attribute): [...] Start point of a temporal interval associated with a tt:span element. [...] end (attribute): End point of a temporal interval associated with a tt:span element. TTML1,section 10.2.1: The begin attribute is used to specify the begin point of a temporal interval associated with a timed element. [...] The begin point of a temporal interval is included in the interval; i.e., the interval is left-wise closed. TTML1,section 10.2.2: The end attribute is used to specify the ending point of a temporal interval associated with a timed element. [...] The ending point of a temporal interval is not included in the interval; i.e., the interval is right-wise open. | |||
| org.hbbtv_SUB2017 | 1 | Subtitle timing is synchronised relative to correct syncbase | When presenting timed EBU-TT-D format subtitle content, delivered as standalone file or in an ISOBMFF wrapper as part of a DASH presentation, including a representative set of subtitles and a subtitle A whose begin attribute is "00:00:00" and whose end is "00:00:05" and a subtitle B whose begin attribute is "00:31:00.20" and whose end attribute is "00:31:07.80", all subtitles appear and disappear at the correct time, and subtitle A appears at time zero on the media timeline and disappears at 5 seconds, and subtitle B appears at 31 minutes and 0.2 seconds and disappears before 31 minutes and 7.8 seconds where all times are on the media timeline, and are relative to the subtitle track. The appear and disappear time accuracy is +0.5s -0.9s. | 2024-1 2023-2 2023-1 2022-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.1.5.1: Terminals shall be able to correctly render TTML based subtitles with the following constraints: [...] with ISOBMFF content as defined by the EBU specification for carrying EBU-TT-D in ISOBMFF [44] EBU-TECH-3381,section 6: The timing behaviour for processing EBU-TT-D subtitle samples shall be the same as defined in ISO/IEC 14496-30:2014 Section 5.2 and 6.3. In accordance with this definition all time expressions in the EBU-TT-D document shall be relative to the start of the subtitle track and not to the start of the sample. ISO/IEC-14496-30,section 5.2: The top-level internal timing values in the timed text samples based on TTML express times on the track presentation timeline – that is, the track media time as optionally modified by the edit list. For example, the begin and end attributes of the <body> element, if used are relative to the start of the track, not relative to the start of the sample. TTML1,section 10.4: If the governing time base is media, then time expressions are considered to be equivalent to offset based timing in [SMIL 2.1], where the specific semantics of N.2 Media Time Base apply. SMIL 2.1,section 10.4.1: Offset values are used to specify when an element should begin or end relative to its syncbase. | |||
| org.hbbtv_SYNCAPI0002 | 1 | initMediaSynchroniser() with MPEG-2 TS (TEMI) video/broadcast object | Calling initMediaSynchroniser() with a 'mediaObject' argument equal to a video/broadcast object associated with an MPEG-2 TS containing a service with AVC video component and TEMI timeline and a valid TEMI 'timelineSpecification' argument shall not cause any errors to be raised | 2024-1 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 10.2.8.3: Terminals shall support multi-stream synchronization with the constraints defined in clause 10.2.8.4 for broadband streams which are: [...] * or delivered via HTTP as an EBU-TT-D compliant TTML document as defined in clause 7.3.1.5.1 with timeline as defined in clause 13.3.2. [...] The terminal shall implement the Media Synchroniser API defined in clause 8.2.3. HBBTV,section 8.2.3.2.2: void initMediaSynchroniser (Object mediaObject, String timelineSpecification) [...] mediaObject | The media object (video/broadcast object, AV Control object, HTML5 media object, or a RemoteMediaObject) that carries the timeline that will be used by the Media Synchroniser API. timelineSpecification | Type and location of the timeline to be used by the media Synchroniser API. Please refer to clauses 8.2.3.5 and 13.3. | |||
| org.hbbtv_SYNCAPI0003 | 1 | MediaSynchroniser - Error event 4 raised when addMediaObject called with previously added mediaObject | When a MediaSynchroniser has already been initialised via a call to initMediaSynchroniser(), calling addMediaObject() with the same 'mediaObject' parameter, an Error event shall be dispatched with an 'error' property of 4 | 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.8.3: The terminal shall implement the Media Synchroniser API defined in clause 8.2.3. HBBTV,section 8.2.3.2.2: void addMediaObject (Object mediaObject, String timelineSpecification, CorrelationTimestamp correlationTimestamp, Number tolerance) [...] If the media object has already been added to the MediaSynchroniser, then this call shall be ignored and an error event thrown. HBBTV,section 8.2.3.3.1: function onError (Number error) [...] Number error | The code of the last error that occured as defined in clause 8.2.3.4.3. HBBTV,section 8.2.3.3.3: 4 | Media object is already associated with the MediaSynchroniser. | |||
| org.hbbtv_SYNCAPI0004 | 1 | MediaSynchroniser - Error event 7 - addMediaObject called on uninitialised MediaSynchroniser | When calling addMediaObject() on a MediaSynchroniser when initMediaSynchroniser() has not been called, an Error event shall be dispatched with an 'error' property of 7 | 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.8.3: Terminals shall support multi-stream synchronization with the constraints defined in clause 10.2.8.4 for broadband streams which are: [...] * or delivered via HTTP as an EBU-TT-D compliant TTML document as defined in clause 7.3.1.5.1 with timeline as defined in clause 13.3.2. [...] The terminal shall implement the Media Synchroniser API defined in clause 8.2.3. HBBTV,section 8.2.3.2.2: void addMediaObject (Object mediaObject, String timelineSpecification, CorrelationTimestamp correlationTimestamp, Number tolerance) [...] If the MediaSynchroniser is not initialized then this call shall be ignored and an error event thrown. HBBTV,section 8.2.3.3.1: function onError (Number error) [...] Number error | The code of the last error that occured as defined in clause 8.2.3.4.3. HBBTV,section 8.2.3.3.3: 7 | The call failed because the MediaSynchroniser is not yet initialised. | |||
| org.hbbtv_SYNCAPI0005 | 1 | MediaSynchroniser - Error event 16 - initMediaSynchroniser called with video/broadcast in UNREALIZED state | When initMediaSynchroniser() is called with its 'mediaObject' parameter set to a video/broadcast object in the UNREALIZED state, an Error event shall be dispatched with an 'error' property of 16 | 2024-1 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 8.2.3.2.4: Error codes ... 16 The master media object is not in a suitable state to participate in synchronization. See clause 9.7.1. HBBTV,section 9.7.1.1: A video/broadcast object that is passed to the initMediaSynchroniser or addMediaObject methods shall always be in the presenting state. Passing a video/broadcast object in any other state to these methods shall result in an error being triggered with error number '9' or '16'. HBBTV,section 10.2.8.3: The terminal shall implement the Media Synchroniser API defined in clause 8.2.3. | |||
| org.hbbtv_SYNCAPI0006 | 1 | MediaSynchroniser - Error event 5 - addMediaObject called with null CorrelationTimestamp | When addMediaObject() is called with broadband DASH audio, a valid DASH-PR 'timelineSpecification' string (that requests a timeline relative to an identified period that is present in the DASH MPD) and a 'correlationTimestamp' of null on a MediaSynchroniser initialised with broadcast MPEG-2 TS / TEMI video, an Error event shall be dispatched with an 'error' property of 5 | 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.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.8.3: The terminal shall implement the Media Synchroniser API defined in clause 8.2.3. HBBTV,section 8.2.3.3.3: 5 | The correlation timestamp set for a media object is null or has an invalid format. HBBTV,section 8.2.3.2.2: void addMediaObject (Object mediaObject, String timelineSpecification, CorrelationTimestamp correlationTimestamp, Number tolerance) [...] If the correlation timestamp is null or has an invalid format, adding the media object shall fail and the terminal throw an error event. | |||
| org.hbbtv_SYNCAPI0007 | 1 | MediaSynchroniser - Error event 7 - updateCorrelationTimestamp called on uninitialised MediaSynchroniser | When a MediaSynchroniser is not initialised and updateCorrelationTimestamp() is called with an HTML5 HEAAC audio 'mediaObject' and a valid 'correlationTimestamp' string, an Error event shall be dispatched with an 'error' value of 7 | 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 8.2.3.2.2: void updateCorrelationTimestamp (Object mediaObject, CorrelationTimestamp correlationTimestamp) HBBTV,section 8.2.3.3.3: 7 | The call failed because the MediaSynchroniser is not yet initialised HBBTV,section 10.2.8.3: The terminal shall implement the Media Synchroniser API defined in clause 8.2.3. | |||
| org.hbbtv_SYNCAPI001 | 1 | MediaSynchroniser 'minSyncBufferSize' property - implemented | The 'minSyncBufferSize' property value of the MediaSynchroniser is equal to an integer greater than or equal to 31457280. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.1: minSyncBufferSize - The size in bytes of the buffer for synchronisation as described by the buffer model in clause 13.5 if implemented, else zero. HBBTV,section 10.2.8.1: The terminal shall implement the buffer model as defined in clause 13.5 to handle the different transmission delays of each stream. HBBTV,section 13.5.1: In the case of media synchronisation between two or more pieces of timed content, additional buffer capacity is needed, as one timed content will be the most laggard and the other piece(s) of timed content need to be buffered to achieve time alignment. HBBTV,section 13.5.3: The media synchronisation buffer is optional. HBBTV,section 13.5.3: The size of the media synchronisation buffer shall be at least 30 Megabytes (that is 30 x 1024 x 1024 = 31 457 280 bytes). | +SYNC_BUFFER | ||
| org.hbbtv_SYNCAPI008 | 1 | MediaSynchroniser 'minSyncBufferSize' property - not implemented | The 'minSyncBufferSize' property value of the MediaSynchroniser is equal to 0. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-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.3.2.1: minSyncBufferSize - The size in bytes of the buffer for synchronisation as described by the buffer model in clause 13.5 if implemented, else zero. HBBTV,section 10.2.8.1: The terminal shall implement the buffer model as defined in clause 13.5 to handle the different transmission delays of each stream. HBBTV,section 13.5.1: In case of media synchronisation between two or more pieces of timed content, additional buffer capacity is needed, as one timed content will be the most laggard and the other piece(s) of timed content need to be buffered to achieve time alignment. HBBTV,section 13.5.3: The media synchronisation buffer is optional. | -SYNC_BUFFER | ||
| org.hbbtv_SYNCAPI0270 | 1 | sync API: check nrOfSlaves property for 0 connected slaves | When a HbbTV application has initialised a MediaSynchroniser, enabled inter-device synchronisation causing the terminal to become a master terminal, no websocket connections to the CSS-CII end point have been succesfully established and the application interrogates the nrOfSlaves property, the value '0' will be returned. | 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 8.2.3.2.1: readonly Number nrOfSlaves Description: If this MediaSynchroniser is being used as the master for inter-device synchronisation it shall be the number of current web socket connections on the CSS-CII service end point provided by the terminal. Otherwise it shall be null. | |||
| org.hbbtv_SYNCAPI0280 | 1 | sync API: check nrOfSlaves property for a terminal that has not yet enabled inter-device sync | When a HbbTV application has initialised a MediaSynchroniser, but not yet enabled inter-device synchronisation causing the terminal to become a master terminal, and the application interrogates the nrOfSlaves property, the value 'null' will be returned. | 2024-1 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 8.2.3.2.1: readonly Number nrOfSlaves Description: if this MediaSynchroniser is being used as the master for inter-device synchronisation it shall be the number of current web socket connections on the CSS-CII service end point provided by the terminal. Otherwise it shall be null. | |||
| org.hbbtv_SYNCAPI0520 | 1 | sync API: a call to enableInterDeviceSync for a MediaSynchroniser not yet initialised causes an error to be thrown | When a HbbTV application has created a MediaSynchroniser object but not yet initialised it, and the method "enableInterDeviceSync" is called on that MediaSynchroniser object, the terminal will throw the error event with code '7' and the lastErrorSource will be null. | 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 8.2.3.2.1: void enableInterDeviceSync (function callback) Description: If the MediaSynchroniser is not initialised, or is in a permanent error state, then this call shall be ignored and an error event dispatched HBBTV,section 8.2.3.2.4: error codes value: 7 Description: The call failed because the MediaSynchroniser is not yet initialised permanent or transient: Transient HBBTV,section 8.2.3.2.1: function onError (Number lastError, Object lastErrorSource) Description: [...] The second argument [...] If the error was not caused by a media object or the master terminal or interaction with the master terminal, then this shall be null. HBBTV,section 8.2.3.2.1: readonly Object lastErrorSource Description: [...] If no error has yet occurred for this MediaSynchroniser object, or if the error was not caused by a media object and was not caused by the master terminal or interaction with the master terminal, then this shall be null. | |||
| org.hbbtv_SYNCAPI0521 | 1 | sync API: a call to enableInterDeviceSync for a MediaSynchroniser in permanent error state causes an error to be thrown | When a HbbTV application has created and initialised a MediaSynchroniser with a presenting video/broadcast object as the master media that was passed to the initMediaSynchroniser method and then the video/broadcast object undergoes a permanent error and transitions to the UNREALIZED state caused by an attempt to change to a channel that cannot be found, and then the method "enableInterDeviceSync" is called on that MediaSynchroniser object, the terminal will throw the error event with code '13' and the lastErrorSource will be null. | 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.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.3.2.1: void enableInterDeviceSync (function callback) Description: If the MediaSynchroniser is not initialised, or is in a permanent error state, then this call shall be ignored and an error event dispatched HBBTV,section 8.2.3.2.4: error codes value: 13 Description: The method call failed because the MediaSynchroniser is in a permanent error state or because it has been replaced by a newer initialised MediaSynchroniser. permanent or transient: Transient HBBTV,section 8.2.3.2.1: function onError (Number lastError, Object lastErrorSource) Description: [...] The second argument [...] If the error was not caused by a media object or the master terminal or interaction with the master terminal, then this shall be null. HBBTV,section 8.2.3.2.1: readonly Object lastErrorSource Description: [...] If no error has yet occurred for this MediaSynchroniser object, or if the error was not caused by a media object and was not caused by the master terminal or interaction with the master terminal, then this shall be null. HBBTV,section 9.7.1.1: If the video/broadcast object has a permanent error (and hence transitions to the Unrealised state) then - If it represents master media (it was passed to a MediaSynchroniser via the initMediaSynchroniser method) then this shall result in a permanent error of the MediaSynchroniser (see clause 13.3.8) []. OIPF-DAE,section 7.13.1.1: [Table 8, row 13] Trigger: Permanent error including - failure to change to a new channel (e.g. the channel cannot be found [...] New state: Unrealized state; Transition Events: ChannelChangeError | |||
| org.hbbtv_SYNCAPI0541 | 1 | sync API: check that, after the terminal has ceased being a master due to a call to disableInterDeviceSync, both its CSS-TS and CSS-CII endpoints have been disabled | A HbbTV application has initialised a MediaSynchroniser, using the initMediaSynchroniser method, and enabled inter-device synchronisation causing the terminal to become a master terminal. 60 seconds after the application has called disableInterDeviceSync(), the application checks the value of the interDeviceSyncEnabled property, which results to be 'false'. A CSA attempts to connect to the previously available CSS-TS and CSS-CII endpoints of the terminal sending a websocket client handshake to each of them, then the terminal will respond to each attempt to connect with a HTTP message with code 403 "Forbidden" to the CSA. | 2024-1 2023-3 2023-2 2023-1 2022-1 2021-3 2020-3 2020-2 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 8.2.3.2.2: void disableInterDeviceSync (function callback) Description: If the terminal is a master terminal it shall cease to be a master terminal as defined in clause 13.3.4. HBBTV,section 13.3.4: the terminal shall disable inter-device synchronisation by disabling the DVB CSS-TS protocol endpoint as described in clause 13.8.2. The terminal may also disable the CSS-CII and CSS-WC protocol endpoints as described in clause 13.6.2 and 13.7.3. HBBTV,section 13.8.2.1: When the terminal ceases to be a master terminal, it shall close any connections to the CSS-TS service endpoint from slave terminals or CSAs, following the process described in clause 9 of ETSI TS 103 286-2 [47] HBBTV,section 13.6.2: A master terminal shall implement a CSS-CII service endpoint as defined in clause 6 of ETSI TS 103 286-2 [47] at the terminal's broadband interface. TS-103-286-2,section 6.3: If the CSS-CII service endpoint is currently unavailable then the TV Device shall refuse the connection request by responding with an HTTP response code of 403 "Forbidden". TS-103-286-2,section 9.3: If the CSS-TS service endpoint is currently unavailable then the MSAS function of the TV Device shall refuse the connection request by responding with an HTTP response code of 403 "Forbidden". | ||
| org.hbbtv_SYNCAPI0590 | 1 | sync API: a call to disableInterDeviceSync for a MediaSynchroniser not yet initialised causes an error to be thrown | When a HbbTV application has created a MediaSynchroniser object, but not yet initialised it, and then the application calls the method "disableInterDeviceSync" on that MediaSynchroniser object, the terminal will throw an error event with code '7' and the lastErrorSource will be null. | 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 8.2.3.2.2: void disableInterDeviceSync (function callback) Description: If the MediaSynchroniser is not initialised, then this call shall be ignored and an error event dispatched. HBBTV,section 8.2.3.2.1: function onError (Number lastError, Object lastErrorSource) Description: [...] The second argument [...] If the error was not caused by a media object or the master terminal or interaction with the master terminal, then this shall be null. HBBTV,section 8.2.3.2.1: readonly Object lastErrorSource Description: [...] If no error has yet occurred for this MediaSynchroniser object, or if the error was not caused by a media object and was not caused by the master terminal or interaction with the master terminal, then this shall be null. | |||
| org.hbbtv_SYNCAPI0591 | 1 | sync API: a call to disableInterDeviceSync for a MediaSynchroniser that has since being replaced causes an error to be thrown | A HbbTV application has initialised a MediaSynchroniser object (using the method initMediaSynchroniser), and then initialised another Media Synchroniser object (using the method initMediaSynchroniser again), thus causing the first MediaSynchroniser object being replaced by the second. When the application calls the method "disableInterDeviceSync" on the first MediaSynchroniser object, the terminal will throw an error event with code 13 and the lastErrorSource will be null. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 8.2.3.2.2: void disableInterDeviceSync (function callback) Description: If the MediaSynchroniser is in a permanent error state, then this call shall be ignored and an error event dispatched (see clause 13.3.8) with error code 7 or 13 (according to the definition of the error codes). HBBTV,section 13.3.8: 13 The method call failed because the MediaSynchroniser is in a permanent error state or because it has been replaced by a newer initialized MediaSynchroniser. Transient (see note) HBBTV,section 8.2.3.2.1: function onError (Number lastError, Object lastErrorSource) Description: [...] The second argument [...] If the error was not caused by a media object or the master terminal or interaction with the master terminal, then this shall be null. HBBTV,section 8.2.3.2.1: readonly Object lastErrorSource Description: [...] If no error has yet occurred for this MediaSynchroniser object, or if the error was not caused by a media object and was not caused by the master terminal or interaction with the master terminal, then this shall be null. | |||
| org.hbbtv_SYNCAPI1410 | 1 | MediaSynchroniser - Error event 14 - Parental Rating block for HTML5 media element (master media) | The application has created and initialised a MediaSynchroniser with a playing HTML5 media element as the master media that was passed to the initMediaSynchroniser method and enabled inter-device synchronisation causing it to become a master terminal, and a connection has been made to the CSS-CII and CSS-TS endpoints provided by the terminal. When later the media presentation is blocked due to parental access control then the MediaSynchroniser is expected to dispatch an error event with error code 14 and to cease inter-device synchronisation by closing the connection to the CSS-TS endpoint and reporting a presentationStatus of "fault" via the connection to the CSS-CII endpoint. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 10.2.6.5: If access to media content presented by a video/broadcast object, an HTML5 media element or an AV control object is blocked by the terminal due to parental access control then: * If it represents master media (it was passed to a MediaSynchroniser via the initMediaSynchroniser() method) then this shall result in a permanent error of the MediaSynchroniser (see clause 13.3.8) with an error being triggered with error number 14. HBBTV,section 9.6.8: If an application attempts to present content using an HTML5 media element and this is blocked due to parental access control, the application shall receive a MediaError with the code property set to MEDIA_ERR_DECODE. HBBTV,section 13.6.2: [Table 23] Primary aspect of presentationStatus when master media is an HTML5 media element [...] [row 3] An error has occurred [...] fault HBBTV,section 13.3.8: When a permanent error of the MediaSynchroniser occurs, the MediaSynchroniser shall enter the permanent error state. [...] If the terminal is a master terminal or slave terminal then the terminal shall also cease to be a master terminal or slave terminal. HBBTV,section 13.3.4: A terminal shall cease to be a master terminal if: [...] there is a permanent error of the MediaSynchroniser object [...] then the terminal shall disable inter-device synchronisation by disabling the DVB CSS-TS protocol endpoint as described in clause 13.8.2 [...] If the permanent error is due to a state transition for the media object representing the master media that results in the primary aspect of presentationStatus changing to "fault" (see clause 13.6.2) then a CII message communicating the presentationStatus shall be sent [...] When a protocol endpoint is disabled, the terminal shall cleanly close any connections to that endpoint. | ||
| org.hbbtv_SYNCAPI1411 | 1 | MediaSynchroniser - Error event 2 - Parental Rating block for HTML5 media element object (other media) | When the application has created a MediaSynchroniser object and has initialised it by passing it a playing video/broadcast object and then called the addMediaObject method, passing it an HTML5 media element, causing the HTML5 media element to be successfully added and later the HTML5 media element is blocked due to parental access control then the MediaSynchroniser object dispatches an error event with error code 2. | 2024-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,section 10.2.6.5: If access to media content presented by a video/broadcast object, an HTML5 media element or an AV control object is blocked by the terminal due to parental access control then: * If it represents other media (it was added to a MediaSynchroniser via the addMediaObject() method) then this shall result in a transient error of the MediaSynchroniser (see clause 13.3.7) and the object shall be removed as if an application had called the removeMediaObject() method and an error event triggered with error number 2. | ||
| org.hbbtv_SYNCAPI1500 | 1 | MediaSynchroniser - Error event 16 - initMediaSynchroniser called with video/broadcast object in STOPPED state | When the application creates a MediaSynchroniser object and the application calls the initMediaSynchroniser method passing a video/broadcast object that is in the "STOPPED" then the MediaSynchroniser object dispatches an error event with error code 16. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.7.1.1: A video/broadcast object that is passed to the initMediaSynchroniser() or addMediaObject() methods shall always be in the connecting or presenting states. Passing a video/broadcast object in any other state to these methods shall result in an error being triggered with error number ‘9’ or '16'. HBBTV,section 8.2.3.2.4: [Error codes table] 16 : The master media object is not in a suitable state to participate in synchronisation. | |||
| org.hbbtv_SYNCAPI1520 | 1 | MediaSynchroniser - Error event 14 - video/broadcast object (master media) has permanent error | When the application has created and initialised a MediaSynchroniser with a presenting video/broadcast object as the master media that was passed to the initMediaSynchroniser method and then the video/broadcast object undergoes a permanent error and transitions to the UNREALIZED state caused by an attempt to change to a channel that cannot be found then the MediaSynchroniser is expected to dispatch an error event with error code 14. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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 9.7.1.1: If the video/broadcast object has a permanent error (and hence transitions to the Unrealised state) then: If it represents master media (it was passed to a MediaSynchroniser via the initMediaSynchroniser() method) then this shall result in a permanent error of the MediaSynchroniser (see clause 13.3.8) with an error being triggered with error number '14'. OIPF-DAE,section 7.13.1.1: [Table 8, row 13] Trigger: Permanent error including - failure to change to a new channel (e.g. the channel cannot be found [...] New state: Unrealized state; Transition Events: ChannelChangeError | |||
| org.hbbtv_SYNCAPI1540 | 1 | MediaSynchroniser - Error event 16 - video/broadcast object (master media) transitions to UNREALIZED state | When the application has created and successfully initialised a MediaSynchroniser with a video/broadcast object as the master media that was passed to the initMediaSynchroniser method and then the application calls the video/broadcast object's release() method causing it to transition to the UNREALIZED state then the MediaSynchroniser object dispatches an error event with error code 16. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-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 9.7.1.1: If the video/broadcast object transitions to the stopped or unrealised states for any other reason then: * If it represents the master media then this shall result in a permanent error of the MediaSynchroniser with error code 16. OIPF-DAE,section 7.13.1.1: [Table 8, row 12] Trigger: release() or setChannel(null); New state: Unrealized | |||
| org.hbbtv_SYNCAPI1565 | 1 | MediaSynchroniser - synchronisation resumes after video/broadcast object (other media) experiences temporary signal loss | When the application creates a MediaSynchroniser object and initialises it by passing it a paused (having not yet played) A/V control object or HTML5 media element (with a timeline that ticks at a minimum of 100 ticks per second) and then calls the addMediaObject method, passing it a video/broadcast object and specifying a TEMI timeline (that ticks at a minimum of 50 ticks per second) but with no synchronisation tolerance, causing the video/broadcast object to be successfully added, and then there is a temporary 2 second loss of broadcast signal, then 5 seconds after the latest of either loss ending or the video/broadcast object returning from the connecting state to the presenting state, then it is expected that the video/broadcast object will be synchronised to the other media object to within plus 50ms to minus 35ms when observed over a period of at least 15 seconds. | 2024-1 2023-3 2023-2 2023-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,section 9.7.1.1: The terminal is not required to maintain synchronisation of a video/broadcast object (that was added to the MediaSynchroniser using the addMediaObject() method) to the media object representing the master media while that video/broadcast object has a transient error (that it has not yet recovered from) or is in the connecting state. Synchronisation of the video/broadcast object to the media object representing the master media shall resume automatically when the video/broadcast object returns to the presenting state (and hence recovers from any transient error). HBBTV,section 10.2.8.1: Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greater of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. HBBTV,section A.2.4.2.: Terminals shall only support one active instance of a video/broadcast object at any time. "Active" means here that the video/broadcast object is either in the connecting or the presenting state. | +SYNC_BUFFER | ||
| org.hbbtv_SYNCAPI1570 | 1 | MediaSynchroniser - video/broadcast (master media) - setChannel | When the application has created and successfully initialised a MediaSynchroniser with a video/broadcast object with a TEMI timeline (that ticks at a minimum of 50 ticks per second) using the initMediaSynchroniser method and synchronised it (to within 10ms) to another another media object that was added using the addMediaObject method with a timeline that ticks at a minimum of 100 ticks per second but with no synchronisation tolerance specified and then the application calls the setChannel method (to change to another channel which has the same TEMI timeline timeline_id, timescale and timestamps values carried in a component with the same component tag number and the same video/audio content as the current channel), then it is expected that once the video/broadcast object returns to the presenting state (because the channel change is complete) and the other media object is back in a playing state, then the video/broadcast object will be synchronised to the other media object to within plus 50ms to minus 35ms when observed over a period of at least 15 seconds. | 2024-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.7.1.1: If the setChannel(), prevChannel(), nextChannel(), pause(), resume(), setSpeed(), seek() or stopTimeshift() methods are called then the method call shall proceed for the video/broadcast object. Additionally: * If it represents the master media then the terminal shall adjust the presentation timing of the other media to try to synchronise it with the new presentation timing of the master media. HBBTV,section 10.2.8.1: Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greater of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. OIPF-DAE,section 7.13.1.2: readonly Integer playState The current play state of the video/broadcast object. Valid values are: 0 | unrealized 1 | connecting 2 | presenting 3 | stopped | |||
| org.hbbtv_SYNCAPI1600 | 1 | MediaSynchroniser - Error event 16 - initMediaSynchroniser called with HTML5 video element object when readyState < HAVE_CURRENT_DATA | When the application creates a MediaSynchroniser object and the application calls the initMediaSynchroniser method passing an HTML5 media element for which no source has yet been set (causing it to be in readyState < HAVE_CURRENT_DATA) then the MediaSynchroniser object dispatches an error event with error code 16. | 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 9.7.1.2: An HTML5 media element that is passed to the initMediaSynchroniser() or addMediaObject() methods shall have the readyState property set to HAVE_CURRENT_DATA, HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA [...] Passing in a media element in any other state to these methods shall result in an error being dispatched with error number 9 or 16. HBBTV,section 8.2.3.2.4: [Error codes table] 16 : The master media object is not in a suitable state to participate in synchronisation. | |||
| org.hbbtv_SYNCAPI1601 | 1 | MediaSynchroniser - Error event 16 - initMediaSynchroniser called with HTML5 video element playback already ended | When the application has created a MediaSynchroniser object and initialised it by passing it an HTML5 media element that has already played to the end of the resource (and whose readyState attribute therefore has value HAVE_METADATA or greater) then the MediaSynchroniser object dispatches an error event with error code 16. | 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 9.7.1.2: An HTML5 media element that is passed to the initMediaSynchroniser() or addMediaObject() methods [...] shall be playing or paused. The media element shall not have reached the end of the media resource (see "ended playback" as defined in HTML5 [54]). [...] Passing in a media element in any other state to these methods shall result in an error being dispatched with error number 9 or 16. HBBTV,section 8.2.3.2.4: [Error codes table] 16 : The master media object is not in a suitable state to participate in synchronisation. HTML5,section 4.7.10.8: A media element is said to have ended playback when: The element's readyState attribute is HAVE_METADATA or greater, and [...] * The current playback position is the end of the media resource, and * The direction of playback is forwards, and * Either the media element does not have a loop attribute specified, or the media element has a current media controller. | |||
| org.hbbtv_SYNCAPI1610 | 1 | MediaSynchroniser - Error event 9 - addMediaObject called with HTML5 video element object when readyState < HAVE_CURRENT_DATA | When the application has created a MediaSynchroniser object and initialised it by passing it a presenting video/broadcast object and then calls the addMediaObject method passing an HTML5 media element for which no source has yet been set (causing it to be in readyState < HAVE_CURRENT_DATA) then the MediaSynchroniser object dispatches an error event with error code 9. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.7.1.2: An HTML5 media element that is passed to the initMediaSynchroniser() or addMediaObject() methods shall have the readyState property set to HAVE_CURRENT_DATA, HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA [...] Passing in a media element in any other state to these methods shall result in an error being dispatched with error number 9 or 16. HBBTV,section 8.2.3.2.4: [Error codes table] 9 : The media object (that was passed using the addMediaObject() method) is not in a suitable state to participate in synchronisation. | |||
| org.hbbtv_SYNCAPI1611 | 1 | MediaSynchroniser - Error event 9 - addMediaObject called with HTML5 video element playback already ended | When the application has created a MediaSynchroniser object and initialised it by passing it a presenting video/broadcast object and then calls the addMediaObject method passing an HTML5 media element that has already played to the end of the resource then the MediaSynchroniser object dispatches an error event with error code 9. | 2024-1 2023-3 2023-2 2023-1 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 9.7.1.2: An HTML5 media element that is passed to the initMediaSynchroniser() or addMediaObject() methods [...] shall be playing or paused. [...] Passing in a media element in any other state to these methods shall result in an error being dispatched with error number 9 or 16. HBBTV,section 8.2.3.2.4: [Error codes table] 9 : The media object (that was passed using the addMediaObject() method) is not in a suitable state to participate in synchronisation. HTML5,section 4.7.10.8: A media element is said to have stopped due to errors when the element's readyState attribute is HAVE_METADATA or greater, and the user agent encounters a non-fatal error during the processing of the media data, and due to that error, is not able to play the content at the current playback position. | +2DECODER | ||
| org.hbbtv_SYNCAPI1612 | 1 | MediaSynchroniser - Error event 9 - addMediaObject called with HTML5 video element stopped due to non fatal errors | When the application has created a MediaSynchroniser object and initialised it by passing it a presenting video/broadcast object and then calls the addMediaObject method passing an HTML5 media element that has encountered a non-fatal error that caused it to stop (due to use of an unsupported codec) then the MediaSynchroniser object dispatches an error event with error code 9. | 2024-1 2023-3 2023-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 9.7.1.2: An HTML5 media element that is passed to the initMediaSynchroniser() or addMediaObject() methods [...] shall be playing or paused. [...] Passing in a media element in any other state to these methods shall result in an error being dispatched with error number 9 or 16. HBBTV,section 8.2.3.2.4: [Error codes table] 9 : The media object (that was passed using the addMediaObject() method) is not in a suitable state to participate in synchronisation. HTML5,section 4.7.10.8: A media element is said to have ended playback when: The element's readyState attribute is HAVE_METADATA or greater, and [...] * The current playback position is the end of the media resource, and * The direction of playback is forwards, and * Either the media element does not have a loop attribute specified, or the media element has a current media controller. | ||
| org.hbbtv_SYNCAPI1630 | 1 | MediaSynchroniser - Error event 2 - HTML5 video element (other media) has error while fetching data | When the application has created a MediaSynchroniser object and has initialised it by passing it a presenting video/broadcast object and then called the addMediaObject method, passing it an HTML5 media element that is paused (having not yet played), causing the HTML5 media element to be successfully added, and then the HTML5 media element fires a MediaError with error code MEDIA_ERR_NETWORK then the MediaSynchroniser object dispatches an error event with error code 2. | 2024-1 2023-3 2023-2 2022-3 2022-2 2022-1 2021-3 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.7.1.2: If an error occurs while fetching the media data (and hence an error event is triggered) then; [...] * If it represents other media (it was added to a MediaSynchroniser via the addMediaObject() method) then this shall result in a transient error of the MediaSynchroniser (see clause 13.3.7) and the object shall be removed as if an application had called the removeMediaObject() method and an error event dispatched with error 2. HTML5,section 4.8.10.5: If the connection is interrupted after some media data has been received, causing the user agent to give up trying to fetch the resource: Fatal network errors that occur after the user agent has established whether the current media resource is usable (i.e. once the media element's readyState attribute is no longer HAVE_NOTHING) must cause the user agent to execute the following steps: 1. The user agent should cancel the fetching process. 2. Set the error attribute to a new MediaError object whose code attribute is set to MEDIA_ERR_NETWORK. | |||
| org.hbbtv_SYNCAPI1640 | 1 | MediaSynchroniser - Error event 16 - HTML5 video element (master media) source reloaded | When the application has created and successfully initialised a MediaSynchroniser with an HTML5 media element as the master media that was passed to the initMediaSynchroniser method and then the application causes the media source to be reloaded then the MediaSynchroniser object dispatches an error event with error code 16. | 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 9.7.1.2: If the HTML5 media element source is reloaded (by the application calling the load() method), [...] then: * If it represents the master media then this shall result in a permanent error of the MediaSynchroniser with error code 16. HTML5,section 4.8.10.2: If a src attribute of a media element is set or changed, the user agent must invoke the media element's media element load algorithm | |||
| org.hbbtv_SYNCAPI1650 | 1 | MediaSynchroniser - Error event 9 - HTML5 video element (other media) source reloaded | When the application creates a MediaSynchroniser object and initialises it by passing it a presenting video/broadcast object and then calls the addMediaObject method, passing it an HTML5 media element that is paused (having not yet played), causing the HTML5 media element to be successfully added, and then application causes the media source to be reloaded then the MediaSynchroniser object generates an error with code 9. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.7.1.2: If the HTML5 media element source is reloaded (by the application calling the load() method), [...] then: * If it represents the other media then this shall result in a transient error of the MediaSynchroniser with error code 9 and the object shall be removed as if an application had called the removeMediaObject() method. HTML5,section 4.8.10.2: If a src attribute of a media element is set or changed, the user agent must invoke the media element's media element load algorithm | |||
| org.hbbtv_SYNCAPI1660 | 1 | MediaSynchroniser - synchronisation resumes after HTML5 video element (master media) was stalled | The application has created and successfully initialised a MediaSynchroniser with an HTML5 media element using initMediaSynchroniser and enabled inter-device synchronisation causing the terminal to become a master terminal and a connection has been established to the CSS-TS endpoint of the terminal (requesting a timeline that ticks at a minimum of 100 ticks per second in the initial setup-data message) and at least one Control Timestamp has been received providing the timeline position. When the streaming of media data to the terminal is temporarily stalled causing the HTML5 media element to stall and then resume then it is expected that, after resumption, when the timing of presentation indicated by the value of the latest Control Timestamp is compared to the timing of presentation of the master media as observed by monitoring the light emitted then it is found to be accurate to within plus or minus the sum of 10ms and the current error bounds in estimating the Wall Clock of the master terminal (using the CSS-WC protocol) when measured over a period of 15 seconds. | 2024-1 2023-3 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.7.1.2: The terminal is not required to maintain synchronisation of all media objects attached to the MediaSynchroniser (including media on other terminals if inter-device synchronisation is being performed) to an HTML5 media element representing the master media (it was passed to a MediaSynchroniser via the initMediaSynchroniser() method) while one or more of the following conditions are true for that HTML5 media element: [...] * It is stalled while trying to fetch media data. [...] Synchronisation of all media objects shall resume automatically when the HTML5 media element representing the master media returns to a state where all the conditions listed above are no longer true. HBBTV,section 13.8.2.4: Control Timestamps sent by the MSAS function of the master terminal to slave terminals and CSAs shall, when the synchronisation timeline is available, represent the timing of presentation of the master media by the master terminal. [...] When a Control Timestamp is representing a timing of presentation with respect to the reference point for timestamping, it shall do so to within plus or minus the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.4: The minimum accuracy for 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 the Synchronisation timeline (see clause 13.4.3.2). | |||
| org.hbbtv_SYNCAPI1661 | 1 | MediaSynchroniser - synchronisation resumes after HTML5 video element (master media) was at effectivePlayspeed X that is not 0 (paused) or 1 (normal) | The application has created and successfully initialised a MediaSynchroniser with an HTML5 media element and enabled inter-device synchronisation causing the terminal to become a master terminal and a connection has been established to the CSS-TS endpoint of the terminal (requesting a timeline that ticks at a minimum of 100 ticks per second in the initial setup-data message) and at least one Control Timestamp has been received providing the timeline position. When the application temporarily sets the playbackRate property to X (where X is neither 0 nor 1) for 5 seconds before returning it to a value of 1 then it is expected that, after normal rate resumes, when the timing of presentation indicated by the value of the latest Control Timestamp is compared to the timing of presentation of the master media as observed by monitoring the light emitted, then it is found to be accurate to within plus or minus the sum of 10ms and the current error bounds in estimating the Wall Clock of the master terminal (using the CSS-WC protocol) when measured over a period of 15 seconds. | 2024-1 2023-3 2022-3 2022-1 2021-3 2021-2 2021-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.7.1.2: The terminal is not required to maintain synchronisation of all media objects attached to the MediaSynchroniser (including media on other terminals if inter-device synchronisation is being performed) to an HTML5 media element representing the master media (it was passed to a MediaSynchroniser via the initMediaSynchroniser() method) while one or more of the following conditions are true for that HTML5 media element: [...] * It is playing (not paused) at an "effective playback rate" (as defined in the HTML5 specification) that is not 0 or 1 for reasons other than adjusting its presentation timing to enable media objects representing other media to synchronise to it. [...] Synchronisation of all media objects shall resume automatically when the HTML5 media element representing the master media returns to a state where all the conditions listed above are no longer true. HBBTV,section 13.8.2.4: Control Timestamps sent by the MSAS function of the master terminal to slave terminals and CSAs shall, when the synchronisation timeline is available, represent the timing of presentation of the master media by the master terminal. [...] When a Control Timestamp is representing a timing of presentation with respect to the reference point for timestamping, it shall do so to within plus or minus the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.4: The minimum accuracy for 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 the Synchronisation timeline (see clause 13.4.3.2). | |||
| org.hbbtv_SYNCAPI1670 | 1 | MediaSynchroniser - synchronisation resumes after HTML5 video element (other media) was stalled | When the application creates a MediaSynchroniser object and initialises it by passing it a presenting video/broadcast object (with a timeline that ticks at a minimum of 100 ticks per second) and then calls the addMediaObject method, passing it an HTML5 media element that is paused (having not yet played) and specifying a timeline that ticks at a minimum of 100 ticks per second but with no synchronisation tolerance specified, causing the HTML5 media element to be successfully added, and then streaming of media data is temporarily stalled causing the HTML5 media element to stall and then resume then it is expected that the HTML5 media element will be synchronised with the video/broadcast object to within plus 50ms to minus 35ms when observed over a period of at least 15 seconds after the HTML5 media element resumes because it has enough media data. | 2024-1 2023-3 2022-3 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,section 9.7.1.2: The terminal is not required to maintain synchronisation of an HTML5 media element (that was added to the MediaSynchroniser using the addMediaObject() method) to the media object representing the master media while that HTML5 media element is stalled while trying to fetch media data. Synchronisation of the HTML5 media element to the media object representing the master media shall resume automatically when sufficient data becomes available. HBBTV,section 10.2.8.1: Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greater of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. | ||
| org.hbbtv_SYNCAPI1680 | 1 | MediaSynchroniser - HTML5 video element (master media) set currentTime | The application has created and successfully initialised a MediaSynchroniser with an HTML5 media element and enabled inter-device synchronisation causing the terminal to become a master terminal and a connection has been established to the CSS-TS endpoint of the terminal (requesting a timeline that ticks at a minimum of 100 ticks per second in the initial setup-data message) and at least one Control Timestamp has been received providing the timeline position. When the application sets the currentTime property of the HTML5 media element to a new value (for which the terminal will be required to seek to and for which it will be able to seek to the corresponding position in the stream for the media object), then it is expected that once the HTML5 media element fires the seeked event and then the timing of presentation indicated by the value of the latest Control Timestamps is compared to the timing of presentation of the master media as observed by monitoring the light emitted, then it is found to be accurate to within plus or minus the sum of 10ms and the current error bounds in estimating the Wall Clock of the master terminal (using the CSS-WC protocol) when measured over a period of 15 seconds. | 2024-1 2023-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,section 9.7.1.2: If the currentTime or playbackRate properties are set or the play() or pause() methods are called then the property setting or method call shall proceed for the HTML5 media element. Additionally: If it represents the master media then the terminal shall adjust the presentation timing of the other media to try to synchronise it with the new presentation timing of the master media. HBBTV,section 13.8.2.4: Control Timestamps sent by the MSAS function of the master terminal to slave terminals and CSAs shall, when the synchronisation timeline is available, represent the timing of presentation of the master media by the master terminal. [...] When a Control Timestamp is representing a timing of presentation with respect to the reference point for timestamping, it shall do so to within plus or minus the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.4: The minimum accuracy for 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 the Synchronisation timeline (see clause 13.4.3.2). HTML5,section 4.7.10.9: When the user agent is required to seek to a particular new playback position in the media resource, optionally with the approximate-for-speed flag set, it means that the user agent must run the following steps. [...] 17. Queue a task to fire a simple event named seeked at the element. | |||
| org.hbbtv_SYNCAPI1681 | 1 | MediaSynchroniser - HTML5 video element (master media) set playbackRate is reflected in timestamps sent via CSS-TS | The application has created and successfully initialised a MediaSynchroniser with an HTML5 media element and enabled inter-device synchronisation causing the terminal to become a master terminal and a connection has been established to the CSS-TS endpoint of the terminal (requesting a timeline that ticks at a minimum of 100 ticks per second in the initial setup-data message) and at least one Control Timestamp has been received providing the timeline position. When the application sets the playbackRate property to 0 then it is expected that, after this takes effect, the Control Timestamps sent by the master terminal via the CSS-TS protocol shall indicate that the timeline has paused by reporting a timelineSpeedMutiplier property value equal to zero. | 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 9.7.1.2: If the currentTime or playbackRate properties are set or the play() or pause() methods are called then the property setting or method call shall proceed for the HTML5 media element. Additionally: If it represents the master media then the terminal shall adjust the presentation timing of the other media to try to synchronise it with the new presentation timing of the master media. HBBTV,section 13.8.2.4: The timelineSpeedMultiplier property in Control Timestamps shall represent the speed of presentation of the master media at the master terminal. The property shall have the value 1 under normal playback conditions. When presentation of the master content is paused (by the user or by the terminal when waiting for buffers to fill), the value shall be zero. | |||
| org.hbbtv_SYNCAPI1682 | 1 | MediaSynchroniser - HTML5 video element (master media) - play() is reflected in timestamps sent via CSS-TS | The application has created and successfully initialised a MediaSynchroniser with an HTML5 media element and enabled inter-device synchronisation causing the terminal to become a master terminal and a connection has been established to the CSS-TS endpoint of the terminal (requesting a timeline that ticks at a minimum of 100 ticks per second in the initial setup-data message) and at least one Control Timestamp has been received providing the timeline position. When the application calls the pause method followed 2 seconds later by the play method to resume then it is expected that, after the playing event fires from the media object, when then the timing of presentation indicated by the value of the latest Control Timestamps is compared to the timing of presentation of the master media as observed by monitoring the light emitted, then it is found to be accurate to within plus or minus the sum of 10ms and the current error bounds in estimating the Wall Clock of the master terminal (using the CSS-WC protocol) when measured over a period of 15 seconds. | 2024-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,section 9.7.1.2: If the currentTime or playbackRate properties are set or the play() or pause() methods are called then the property setting or method call shall proceed for the HTML5 media element. Additionally: If it represents the master media then the terminal shall adjust the presentation timing of the other media to try to synchronise it with the new presentation timing of the master media. HBBTV,section 13.8.2.4: Control Timestamps sent by the MSAS function of the master terminal to slave terminals and CSAs shall, when the synchronisation timeline is available, represent the timing of presentation of the master media by the master terminal. [...] When a Control Timestamp is representing a timing of presentation with respect to the reference point for timestamping, it shall do so to within plus or minus the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.4: The minimum accuracy for 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 the Synchronisation timeline (see clause 13.4.3.2). | |||
| org.hbbtv_SYNCAPI1683 | 1 | MediaSynchroniser - HTML5 video element (master media) - pause() | The application has created and successfully initialised a MediaSynchroniser with an HTML5 media element and enabled inter-device synchronisation causing the terminal to become a master terminal and a connection has been established to the CSS-TS endpoint of the terminal (requesting a timeline that ticks at a minimum of 100 ticks per second in the initial setup-data message) and at least one Control Timestamp has been received providing the timeline position. When the application calls the pause method of the HTML5 media element then it is expected that, after the pause takes effect, the Control Timestamps sent by the master terminal via the CSS-TS protocol shall indicate that the timeline has paused by reporting a timelineSpeedMultiplier property value equal to zero. | 2024-1 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,section 9.7.1.2: If the currentTime or playbackRate properties are set or the play() or pause() methods are called then the property setting or method call shall proceed for the HTML5 media element. Additionally: If it represents the master media then the terminal shall adjust the presentation timing of the other media to try to synchronise it with the new presentation timing of the master media. HBBTV,section 13.8.2.4: The timelineSpeedMultiplier property in Control Timestamps shall represent the speed of presentation of the master media at the master terminal. The property shall have the value 1 under normal playback conditions. When presentation of the master content is paused (by the user or by the terminal when waiting for buffers to fill), the value shall be zero. | |||
| org.hbbtv_SYNCAPI1690 | 1 | MediaSynchroniser - HTML5 video element (other media) set currentTime | When the application creates a MediaSynchroniser object and initialises it by passing it a presenting video/broadcast object that is playing (using a TEMI timeline (that ticks at a minimum of 50 ticks per second) and then calls the addMediaObject method, passing it an HTML5 media element that is paused (having not yet played) and specifying a timeline that with a minimum tick rate of 100 ticks per second, causing the HTML5 media element to be successfully added, and then application sets the currentTime property of the HTML5 media element to a new value, then it is expected that the MediaSynchroniser generates an error event with error code 9 and a subsequent call to removeMediaObject method passing the HTML5 media element will generate an error with error code 8 because it has already been removed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 2021-3 2021-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.7.1.2: If the currentTime or playbackRate properties are set or the play() or pause() methods are called then the property setting or method call shall proceed for the HTML5 media element. Additionally: If it represents other media then a transient error of the MediaSynchroniser with error code 9 shall be generated and the object shall be removed as if an application had called the removeMediaObject() method. HBBTV,section 10.2.8.1: Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greater of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. | |||
| org.hbbtv_SYNCAPI1691 | 1 | MediaSynchroniser - HTML5 video element (other media) set playbackRate | When the application creates a MediaSynchroniser object and initialises it by passing it a presenting video/broadcast object that is playing (using a TEMI timeline (that ticks at a minimum of 50 ticks per second)) and then calls the addMediaObject method, passing it an HTML5 media element that is paused (having not yet played) and specifying a timeline that with a minimum tick rate of 100 ticks per second, causing the HTML5 media element to be successfully added, and then application sets the playbackRate property of the HTML5 media element to a new value, then it is expected that the MediaSynchroniser generates an error event with error code 9 and a subsequent call to removeMediaObject method passing the HTML5 media element will generate an error with error code 8 because it has already been removed. | 2024-1 2023-3 2022-3 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.7.1.2: If the currentTime or playbackRate properties are set or the play() or pause() methods are called then the property setting or method call shall proceed for the HTML5 media element. Additionally: If it represents other media then a transient error of the MediaSynchroniser with error code 9 shall be generated and the object shall be removed as if an application had called the removeMediaObject() method. HBBTV,section 10.2.8.1: Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greater of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. | |||
| org.hbbtv_SYNCAPI1693 | 1 | MediaSynchroniser - HTML5 video element (other media) - pause() | When the application creates a MediaSynchroniser object and initialises it by passing it a presenting video/broadcast object that is playing (using a TEMI timeline (that ticks at a minimum of 50 ticks per second)) and then calls the addMediaObject method, passing it an HTML5 media element that is paused (having not yet played) and specifying a timeline that with a minimum tick rate of 100 ticks per second, causing the HTML5 media element to be successfully added, and then application calls the pause method of the HTML5 media element, then it is expected that the MediaSynchroniser generates an error event with error code 9 and a subsequent call to removeMediaObject method passing the HTML5 media element will generate an error with error code 8 because it has already been removed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.7.1.2: If the currentTime or playbackRate properties are set or the play() or pause() methods are called then the property setting or method call shall proceed for the HTML5 media element. Additionally: If it represents other media then a transient error of the MediaSynchroniser with error code 9 shall be generated and the object shall be removed as if an application had called the removeMediaObject() method. HBBTV,section 10.2.8.1: Any difference in timing of presentation for streams that are synchronised according to the timing relationship shall be no greater than plus or minus the greater of: the application specified tolerance and the minimum synchronisation accuracy defined in clause 9.7.4. HBBTV,section 9.7.2: The synchronisation tolerance defines the maximum time by which the presentation of two media streams can be out of sync but still considered synchronised. [...] The synchronisation of the other media and master media is deemed within tolerance if the difference in the play position of both streams is not greater than the given tolerance value at any time. 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. | |||
| org.hbbtv_SYNCAPI1712 | 1 | MediaSynchroniser - Error event 9 - addMediaObject called with HTML5 video element (other media) - pause() | When the application creates a MediaSynchroniser object and initialises it by passing it a presenting video/broadcast object and then calls the addMediaObject method, passing it HTML5 media object that is paused (having not yet played), causing HTML5 media object to be successfully added, and application calls the pause method on html5 media object and then the MediaSynchroniser object generates an error with code 9. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-1 2021-3 2021-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.7.1.2: If the currentTime or playbackRate properties are set or the play() or pause() methods are called then the property setting or method call shall proceed for the HTML5 media element. Additionally: If it represents other media then a transient error of the MediaSynchroniser with error code 9 shall be generated and the object shall be removed as if an application had called the removeMediaObject() method. HBBTV,section 8.2.3.2.4: [Error codes table] 9 : The media object (that was passed using the addMediaObject() method) is not in a suitable state to participate in synchronisation. OIPF-DAE,section 7.14.1: readonly Number error [...] 3 - insufficient resources. | |||
| org.hbbtv_SYNCAPI1730 | 1 | MediaSynchroniser - Error event 9 - HTML5 video element (other media) set currentTime | When the application has created a MediaSynchroniser object and has initialised it by passing it a presenting video/broadcast object(using a TEMI timeline that ticks at 100 ticks per second) and then calls the addMediaObject method, passing HTML5 media object that is paused (having not yet played), causing the HTML5 media object to be successfully added and then the application sets the currentTime property of the HTML5 media element to a new value, then the MediaSynchroniser object dispatches an error event with error code 9. | 2024-1 2022-2 2022-1 2021-3 2021-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.7.1.2: If the currentTime or playbackRate properties are set or the play() or pause() methods are called then the property setting or method call shall proceed for the HTML5 media element. Additionally: If it represents other media then a transient error of the MediaSynchroniser with error code 9 shall be generated and the object shall be removed as if an application had called the removeMediaObject() method. | |||
| org.hbbtv_SYNCAPI1740 | 1 | MediaSynchroniser - Error event 16 - video/broadcast (master media) enters STOPPED state | When the application has created and successfully initialised a MediaSynchroniser with a presenting video/broadcast object as master media and was passed to initMediaSynchroniser method and then video/broadcast object moved to "STOPPED" by calling stop() and then the MediaSynchroniser object dispatches an error event with error code 16. | 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,section 9.7.1.1: If the video/broadcast object transitions to the stopped or unrealised states for any other reason then: * If it represents the master media then this shall result in a permanent error of the MediaSynchroniser with error code 16. | |||
| org.hbbtv_SYNCAPI1750 | 1 | MediaSynchroniser - Error event 9 - HTML5 media object (other media) - play() | When the application creates a MediaSynchroniser object and initialises it by passing it a presenting video/broadcast object and then calls the addMediaObject method, passing it HTML5 media object that is paused (having not yet played), causing HTML5 media object to be successfully added, and application calls play() method on html5 media object and then the MediaSynchroniser object generates an error with code 9 | 2024-1 2021-3 2021-2 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 9.7.1.2: If the currentTime or playbackRate properties are set or the play() or pause() methods are called then the property setting or method call shall proceed for the HTML5 media element. Additionally: : [...] * If it represents other media then a transient error of the MediaSynchroniser with error code 9 shall be generated and the object shall be removed as if an application had called the removeMediaObject() method. | ||
| org.hbbtv_SYNCAPI2001 | 1 | removeMediaObject: remove synced audio stream and then continue playing with broadcast audio | While a synchronised single presentation of broadcast video using TEMI as timeline and broadband DASH audio presented by an HTML5 audio element is being performed, the application removes the HTML5 audio element from the MediaSynchroniser and stops it. After the application has removed the HTML5 audio element the terminal selects an audio component from the broadcast service for presentation to the user, it calls any registered event listener for the onSelectedComponentChanged event with the value COMPONENT_TYPE_AUDIO and the application retrieves a non-empty list of AVAudioComponent's when calling the getCurrentActiveComponents(vbo.COMPONENT_TYPE_AUDIO) method on the video/broadcast object (vbo) presenting the master media. | 2024-1 2022-2 2022-1 2021-3 2021-2 2020-1 2019-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 8.2.3.2.2: void removeMediaObject (Object mediaObject): [...] The terminal shall not stop the presentation of media objects purely as a result of this method call. However, if there are insufficient decoders available to continue to present this media object, the presentation of the media object may cease due to insufficient resources. HBBTV,section 10.2.7.1: The terminal always performs a default selection of components to present from all of the available components. This is described in clause 10.2.7.2 below. A running HbbTV application may override the default selection as described in clause 10.2.7.3 below. There is no linkage between how selection of different media types is done; an application may override the default selection for any one media type, any two media types or all or none to modify the presentation of the media to the user. The set of components that are available for this selection depends on how media is being presented. Four scenarios are defined; * A single presentation is in progress using a single media object. In this case, the components that are available are those found in the input or source to that media object. For an HTML5 media element, these are the VideoTracks, AudioTracks and TextTracks. For an A/V Control object or a video/broadcast object, these are the AVComponents. * A single presentation is in progress using more than one media object synchronised using multi-stream synchronisation as defined in clause 10.2.8 of the present document. In this case, the components that are available are the union of those in the master media objectand all the other media objects attached to the MediaSynchroniser that were not added with the multiDecoderMode argument set to true. HBBTV,section 10.2.7.2: [...] the removal of a media object from a MediaSynchroniser shall cause the terminal to re-evaluate which components to be presented by default. | |||
| org.hbbtv_SYNCAPI2021 | 1 | errorHandling 15: 1: No TEMI timeline found on selected component | A broadcast service contains a TEMI timeline with timeline ID equal to 150 and a component tag (signalled in the stream_identifier descriptor) equal to 1. The application initializes a MediaSynchroniser object with the video/broadcast object presenting the service and selecting a timeline with ID 150 and component tag 2. The terminal shall call the onError function registered on the onError property of the MediaSynchroniser with the first parameter equal to 15 the second parameter passing the video/broadcast object. When the onError function was called the lastError property of the MediaSynchroniser object shall return 15 and the lastErrorSource shall return the video/broadcast object. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.1: function onError (Number lastError, Object lastErrorSource): The function that gets called when an error occurs for this MediaSynchroniser object. The terminal shall pass two arguments in the call. The first argument shall be the error code as defined in clause 8.2.3.2.4. The second argument shall be the media object that was the cause of the error or a string equalling the URL passed to initSlaveMediaSynchroniser() if the cause of the error is the master terminal or interaction with the master terminal. readonly Number lastError: If no error has yet occurred for this MediaSynchroniser object then the value of this property shall be null, otherwise the value shall be the code of the last error that occurred for this MediaSynchroniser object as defined in clause 8.2.3.2.4. readonly Boolean interDeviceSyncEnabled: Shall be true if and only if the terminal is currently a master terminal or a slave terminal. HBBTV,section 8.2.3.2.2: void initMediaSynchroniser() (Object mediaObject, String timelineSelector): [...] or if the selected timeline is determined to be not available then this shall result in a permanent error of the MediaSynchroniser and an error event shall be triggered. [...] NOTE: The availability of a timeline can sometimes only be determined some time after the terminal has begun presentation of the stream. This error can therefore occur some time after the MediaSynchoniser is initialised. See clause 9.7.3. HBBTV,section 8.2.3.2.4: The values of the error property are defined in this clause. [Value: 15; Description: The master media object or the selected timeline for a media object could not be found or the media timeline is no longer present. Permanent or transient: Permanent] | |||
| org.hbbtv_SYNCAPI2022 | 1 | errorHandling 15: 2: No TEMI timeline found with selected ID | A broadcast service contains a TEMI timeline with timeline ID equal to 1 and a component tag (signalled in the stream_identifier descriptor) equal to 2. The application initializes a MediaSynchroniser object with the video/broadcast object presenting the service and selecting a timeline with ID 2 and component tag 2. The terminal shall call the onError function registered on the onError property of the MediaSynchroniser with the first parameter equal to 15 the second parameter passing the video/broadcast object. When the onError function was called the lastError property of the MediaSynchroniser object shall return 15 and the lastErrorSource shall return the video/broadcast object. | 2024-1 2023-3 2023-2 2023-1 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 8.2.3.2.1: function onError (Number lastError, Object lastErrorSource): The function that gets called when an error occurs for this MediaSynchroniser object. The terminal shall pass two arguments in the call. The first argument shall be the error code as defined in clause 8.2.3.2.4. The second argument shall be the media object that was the cause of the error or a string equalling the URL passed to initSlaveMediaSynchroniser() if the cause of the error is the master terminal or interaction with the master terminal. readonly Number lastError: If no error has yet occurred for this MediaSynchroniser object then the value of this property shall be null, otherwise the value shall be the code of the last error that occurred for this MediaSynchroniser object as defined in clause 8.2.3.2.4. readonly Boolean interDeviceSyncEnabled: Shall be true if and only if the terminal is currently a master terminal or a slave terminal. HBBTV,section 8.2.3.2.2: void initMediaSynchroniser() (Object mediaObject, String timelineSelector): [...] or if the selected timeline is determined to be not available then this shall result in a permanent error of the MediaSynchroniser and an error event shall be triggered. [...] NOTE: The availability of a timeline can sometimes only be determined some time after the terminal has begun presentation of the stream. This error can therefore occur some time after the MediaSynchoniser is initialised. See clause 9.7.3. HBBTV,section 8.2.3.2.4: The values of the error property are defined in this clause. [Value: 15; Description: The master media object or the selected timeline for a media object could not be found or the media timeline is no longer present. Permanent or transient: Permanent] | |||
| org.hbbtv_SYNCAPI260 | 1 | sync API: check nrOfSlaves property for 3 connected slaves | When a HbbTV application has initialised a MediaSynchroniser, enabled inter-device synchronisation causing the terminal to become a master terminal, 3 websocket connections to the CSS-CII end point have been successfully established and the application interrogates the nrOfSlaves property, the value '3' will be returned. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.1: readonly Number nrOfSlaves Description: If this MediaSynchroniser is being used as the master for inter-device synchronisation it shall be the number of current web socket connections on the CSS-CII service end point provided by the terminal. Otherwise it shall be null. | |||
| org.hbbtv_SYNCAPI300 | 1 | sync API: check interDeviceSyncEnabled for a master terminal | A HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser API method, and called enable inter-device synchronisation specifying a callback function. When the HbbTV application is notified that the callback function has returned and then the application checks the value of the interDeviceSyncEnabled property, this value will be equal to 'true'. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.1: readonly Boolean interDeviceSyncEnabled Description: Shall be true if and only if the terminal is currently a master terminal or a slave terminal. HBBTV,section 8.2.3.2.2: void enableInterDeviceSync (function callback) [] If the MediaSynchroniser was initialised using the initMediaSynchroniser method then the terminal become a master terminal as defined in clause 13.3.3. HBBTV,section 13.3.3: NOTE: The application that requested that inter-device synchronisation be enabled is notified that the terminal has become a master terminal by callback []. | |||
| org.hbbtv_SYNCAPI310 | 1 | sync API: check interDeviceSyncEnabled for a terminal that has not yet enabled inter-device sync | A HbbTV application has initialised a MediaSynchroniser using the initMediaSynchroniser API method, but not yet enabled inter-device synchronisation and the application checks the value of the interDeviceSyncEnabled property, this value will be equal to 'false'. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.1: readonly Boolean interDeviceSyncEnabled Description: Shall be true if and only if the terminal is currently a master terminal or a slave terminal. HBBTV,section 8.2.3.2.2: void enableInterDeviceSync (function callback) [] If the MediaSynchroniser was initialised using the initMediaSynchroniser method then the terminal become a master terminal as defined in clause 13.3.3. | |||
| org.hbbtv_SYNCAPI320 | 1 | sync API: check interDeviceSyncEnabled for a a terminal that is in permanent error | When a HbbTV application has created and initialised a MediaSynchroniser with a presenting video/broadcast object as the master media that was passed to the initMediaSynchroniser method, and has enabled inter-device synchronisation, and then the video/broadcast object undergoes a permanent error and transitions to the UNREALIZED state caused by an attempt to change to a channel that cannot be found, and then the application checks the value of the interDeviceSyncEnabled property, this value will be equal to 'false'. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.1: readonly Boolean interDeviceSyncEnabled Description: Shall be true if and only if the terminal is currently a master terminal or a slave terminal. HBBTV,section 13.3.4: A terminal shall cease to be a master terminal if: [...] there is a permanent error of the MediaSynchroniser object. HBBTV,section 13.3.8: A permanent error of the MediaSynchroniser can occur if any of the following occurs: [] - errors of media objects representing the master media (see clause 9.7.1); HBBTV,section 9.7.1.1: If the video/broadcast object has a permanent error (and hence transitions to the Unrealised state) then - If it represents master media (it was passed to a MediaSynchroniser via the initMediaSynchroniser method) then this shall result in a permanent error of the MediaSynchroniser (see clause 13.3.8) with an error being triggered with error number '14'. OIPF-DAE,section 7.13.1.1: [Table 8, row 13] Trigger: Permanent error including - failure to change to a new channel (e.g. the channel cannot be found [...] New state: Unrealized state; Transition Events: ChannelChangeError | |||
| org.hbbtv_SYNCAPI440 | 1 | sync API: call to initSlaveMediaSynchroniser for a terminal without slave capability results in error | When a HbbTV application has initialised a MediaSynchroniser and tries to initiate it as a slave Media Synchroniser, a Javascript TypeError will be thrown. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.2: void initSlaveMediaSynchroniser (String css_ci_service_url) Description: If the terminal does not support the capability to act as a slave terminal, then this method shall be undefined. | -SYNC_SLAVE | ||
| org.hbbtv_SYNCAPI540 | 1 | sync API: check that, after the terminal has ceased being a master due to a call to disableInterDeviceSync, its CSS-TS endpoint has been disabled | A HbbTV application has initialised a MediaSynchroniser, using the initMediaSynchroniser method, and enabled inter-device synchronisation causing the terminal to become a master terminal. 60 seconds after the application has called disableInterDeviceSync(), the application checks the value of the interDeviceSyncEnabled property, which results to be 'false'. A CSA attempts to connect to the previously available CSS-TS endpoint of the terminal sending a websocket client handshake, then the terminal returns a HTTP message with code 403 "Forbidden" to the CSA. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.3.2.1: void disableInterDeviceSync (function callback) Description: If the terminal is a master terminal it shall cease to be a master terminal as defined in clause 13.3.4. HBBTV,section 13.3.4: the terminal shall disable inter-device synchronisation by disabling the DVB CSS-TS protocol endpoint as described in clause 13.8.2. HBBTV,section 13.8.2.1: When the terminal ceases to be a master terminal, it shall close any connections to the CSS-TS service endpoint from slave terminals or CSAs, following the process described in clause 9 of ETSI TS 103 286-2 [47] TS-103-286-2,section 9.3: If the CSS-TS service endpoint is currently unavailable then the MSAS function of the TV Device shall refuse the connection request by responding with an HTTP response code of 403 "Forbidden". | |||
| org.hbbtv_TA_MSE1001 | 1 | MSE and out-of-band subtitles | An application presents video and audio via MSE SourceBuffer using an HTML5 video element. The application adds two track elements as children of the video element, and as a result the TextTrack objects are created with properties representing tracks attributes. When the application sets 'mode' attribute of one TextTrack to SHOWING and OFF to the other one, then the enabled subtitles are displayed synchronously with video. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-2 2021-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV-TA-1,section 9.1.5: Clause A.2.12.2 ("Out-of-band text tracks") of TS 102 796 [1] shall be supported for HTML5 video elements whose source is MSE HBBTV,section 9.6.1: The Media Source Extensions (MSE) shall be supported (as required by WMAS 2018 [76]) as a source, either via the srcObject attribute of the media element (where supported), or alternatively through the use of an object URL pointing to a MediaSource object. Unless otherwise stated, all requirements of the present document that apply to the HTML5 media element apply equally when MSE is used. HBBTV,section A.2.12.2: For the avoidance of doubt, this shall also be supported for an HTML5 media element whose source is a MediaSource object. 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 HBBTV,section 10.2.7.2: Terminals shall support a method for the user to enable and disable subtitles and to select at least one preferred subtitle language. Terminals shall use this information when playing content to determine whether to present subtitles and to select between multiple subtitles when they are available. HBBTV,section A.2.12.2: Independent of the system format, terminals shall create TextTrack objects for HTML <track> elements representing TTML subtitle components that are carried out-of-band (see clause 7.3.1.5) when represented by a <track> element in an HTML document. HTML5,section 4.8.10.10.4: The mode attribute, on getting, must return the numeric value corresponding to the text track mode of the text track that the TextTrack object represents, as defined by the following list: OFF (numeric value 0) The text track disabled mode. HIDDEN (numeric value 1) The text track hidden mode. SHOWING (numeric value 2) The text track showing and showing by default modes. | |||
| org.hbbtv_TEMPORAL-LAYERS0020 | 1 | HEVC temporal layers - HFR terminal can play high frame rate representation consisting of two temporal layers | When the terminal loads an HbbTV Application including an HTML5 media object whose media source is initialized with a static 2017-profile DVB DASH MPD defining a stream containing a single HEVC UHD 100Hz video representation consisting of two temporal layers, and the Representation element has a urn:dvb:dash:highest_temporal_id:2017 SupplementalProperty descriptor containing the value of the higher temporal layer, and the @codecs attribute correctly indicates the profile and level required to decode the higher layer, 100Hz video is played back without artifacts or glitches. | 2024-1 2023-3 2023-2 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.1: The following clauses of the present document only apply to the 2017 profile. ... 5.2.8, 10.16 ... TS-103-285,section 10.16: Players which support HEVC shall support decoding Representations containing more than one temporal layer. They shall in addition support decoding Representations where the SPS indicates profiles and levels which are higher than those of the Representation, providing that the SPS includes values correct for all temporal layers include in the Representation. TS-103-285,section 5.2.8.2: Where HEVC video has been encoded using temporal layers, every Representation shall include a SupplementalProperty Descriptor indicating the HighestTid (Highest Temporal ID) present in the Representation, either by explicit signalling on the Representation or inheritance from the containing Adaptation Set. DVB DASH defines the following scheme to signal the HighestTid and this scheme shall be used | +DASH_HFR | ||
| org.hbbtv_TLS2000 | 1 | TLS handshake - version 1.3 and mandatory cipher suite | When an application requests a resource using an https URL, the terminal sends a TLS 1.3 ClientHello handshake message that has (i) a legacy_version with major=3 and minor=3, (ii) a supported_versions extension that contains at least versions 0x0303 and 0x0304, and (iii) at least the cipher suite value {0x13,0x01}. | 2024-1 2023-3 2023-2 2022-2 2022-1 | The challenge exists but not validated | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.2.1: TLS version 1.3 as defined in IETF RFC 8446 [73] and TLS version 1.2 as defined in IETF RFC 5246 [8] shall be supported. RFC8446,section 4.1.2: Structure of this message: ... struct { ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ Random random; opaque legacy_session_id<0..32>; CipherSuite cipher_suites<2..2^16-2>; opaque legacy_compression_methods<1..2^8-1>; Extension extensions<8..2^16-1>; } ClientHello; ... In TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. TLS 1.3 ClientHellos are identified as having a legacy_version of 0x0303 and a supported_versions extension present with 0x0304 as the highest version indicated therein. RFC8446,section 9.1: A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite RFC8446,section 9.2: All implementations MUST send and use these extensions when offering applicable features: "supported_versions" is REQUIRED for all ClientHello ... messages. RFC8446,section B.4: TLS_AES_128_GCM_SHA256 | {0x13,0x01} | ||
| org.hbbtv_TLS2010 | 1 | TLS handshake - version 1.3 mandatory extensions, signature algorithms and groups | When an application requests a resource using an https URL, the terminal sends a TLS 1.3 ClientHello handshake message that includes (i) the server_name extension and the ServerNameList includes one entry of type host_name in which the name field contains the host name from the https URL used, (ii) the supported_groups extension in which the NamedGroupList includes identifiers 0x0017 and 0x0018 and (iii) the signature_algorithms extension in which the SignatureSchemeList includes identifiers 0x0401, 0x0501, 0x0403, 0x0503, 0x0804, 0x0805 and (iv) a key_share extension. If a signature_algorithms_certificate extension is present then it includes at least the algorithms 0x0401, 0x0501, 0x0403, 0x0503, 0x0804, 0x0805. | 2024-1 2023-3 2023-2 2022-2 2022-1 | The challenge exists but not validated | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.2.1: TLS version 1.3 as defined in IETF RFC 8446 [73] and TLS version 1.2 as defined in IETF RFC 5246 [8] shall be supported. ... Terminals shall support all of the mandatory to implement extensions for TLS 1.3 as specified in IETF RFC 8446 [73] clause 9.2, including those required for certificate authentication and for DHE and ECDHE key exchange. HBBTV,section 11.2.4: Table 15b Signature algorithms and their status sha256WithRSAEncryption / rsa_pkcs1_sha256 0x0401 Mandatory sha384WithRSAEncryption / rsa_pkcs1_sha384 0x0501 Mandatory ecdsa-with-SHA256 / ecdsa_secp256r1_sha256 0x0403 Mandatory ecdsa-with-SHA384 / ecdsa_secp384r1_sha384 0x0503 Mandatory rsa_pss_rsae_sha256 0x0804 Mandatory rsa_pss_rsae_sha384 0x0805 Mandatory HBBTV,section 11.2.5: Table 15c Elliptic curves and their status secp256r1 (NIST P-256) 0x0017 Mandatory secp384r1 (NIST P-384) 0x0018 Mandatory RFC6066,section 3: In order to provide any of the server names, clients MAY include an extension of type "server_name" in the (extended) client hello. The "extension_data" field of this extension SHALL contain "ServerNameList" where: struct { NameType name_type; select (name_type) { case host_name: HostName; } name; } ServerName; enum { host_name(0), (255) } NameType; opaque HostName<1..2^16-1>; struct { ServerName server_name_list<1..2^16-1> } ServerNameList; The ServerNameList MUST NOT contain more than one name of the same name_type. ... "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. RFC8446,section 9.1: A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. RFC8446,section 9.2: Mandatory-to-implement Extensions In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the following TLS extensions: ... Signature Algorithms ("signature_algorithms") Signature Algorithms Certificate ("signature_algorithms_cert") Negotiated Groups ("supported_groups") Key Share ("key_share") Server Name Indication ("server_name"; Section 3 of [RFC 6066]) ... All implementations MUST send and use these extensions when offering applicable features: ... "signature_algorithms" is REQUIRED for certificate authentication. "supported_groups" is REQUIRED for ClientHello messages using DHE or ECDHE key exchange. "key_share" is REQUIRED for DHE or ECDHE key exchange. ... Additionally, all implementations MUST support the use of the "server_name" extension with applications capable of using it RFC8446,section 4.2.3: TLS 1.3 provides two extensions for indicating which signature algorithms may be used in digital signatures. The "signature_algorithms_cert" extension applies to signatures in certificates, and the "signature_algorithms" extension, which originally appeared in TLS 1.2, applies to signatures in CertificateVerify messages. ... If no "signature_algorithms_cert" extension is present, then the "signature_algorithms" extension also applies to signatures appearing in certificates. ... Implementations which have the same policy in both cases MAY omit the "signature_algorithms_cert" extension. ... The "extension_data" field of these extensions contains a SignatureSchemeList value: enum { /* RSASSA-PKCS1-v1_5 algorithms */ rsa_pkcs1_sha256(0x0401), rsa_pkcs1_sha384(0x0501), rsa_pkcs1_sha512(0x0601), /* ECDSA algorithms */ ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), ecdsa_secp521r1_sha512(0x0603) /* RSASSA-PSS algorithms with public key OID rsaEncryption */ rsa_pss_rsae_sha256(0x0804), rsa_pss_rsae_sha384(0x0805), rsa_pss_rsae_sha512(0x0806), ... } SignatureScheme; RFC8446,section 4.2.7: The "extension_data" field of this extension contains a "NamedGroupList" value: enum { /* Elliptic Curve Groups (ECDHE) */ secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), ... | ||
| org.hbbtv_TLS2020 | 1 | TLS server authentication success - TLS 1.3 server, valid cert, CA in trust list, ECDSA cert SHA-256, exact match on subjectAltName, no match on CN | When an application requests a resource using an https URL, and the server supports TLS 1.3 and not any other version, and the server presents a valid certificate chain issued by a CA that is in the HbbTV root certificate list and the root certificate has an ECDSA key and the intermediate and end entity certificates use the ecdsa_secp256r1_sha256 or ecdsa_secp384r1_sha384 signature algorithms and the server certificate contains a subjectAltName extension containing a dNSName value equal to the domain name used in the https URL, and the subject CN is not equal to the domain name used in the https URL, then the request succeeds. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.2.1: HTTP over TLS as defined in RFC 2818 [7] shall be supported for transporting application files over broadband. TLS version 1.3 as defined in IETF RFC 8446 [73] and TLS version 1.2 as defined in IETF RFC 5246 [8] shall be supported. HBBTV,section 11.2.3: Terminals shall trust all root certificates identified as mandatory ... on that list subject to the conditions in this clause. HBBTV,section 11.2.4: The algorithm requirements for signature verification are specified in the table below. ... ecdsa-with-SHA256 / ecdsa_secp256r1_sha256 0x0403 Mandatory ecdsa-with-SHA384 / ecdsa_secp384r1_sha384 0x0503 Mandatory RFC2818,section 3.1: If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. ... If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. RFC5280,section 4.2.1.6: The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include [...] a DNS name, an IP address, [...] When the subjectAltName extension contains a domain name system label, the domain name MUST be stored in the dNSName (an IA5String). | |||
| org.hbbtv_TLS2030 | 1 | TLS handshake - application layer protocol support for HTTP 1.1 and HTTP 2 | When an application requests a resource using an https URL, the terminal sends a TLS ClientHello handshake message that includes the application_layer_protocol_negotiation extension and the protocol list includes both "http/1.1" and "h2" with "h2" listed before "http/1.1". | 2024-1 2023-3 2023-2 2022-2 2022-1 | The challenge exists but not validated | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.2.1: Terminals shall support the Application-Layer Protocol Negotiation extension defined in IETF RFC 7301 [87] and shall indicate support for at least "http/1.1" and "h2". "h2" shall be listed before "http/1.1". RFC7301,section 3.1: A new extension type ("application_layer_protocol_negotiation(16)") is defined and MAY be included by the client in its "ClientHello" message. ... "ProtocolNameList" contains the list of protocols advertised by the client, in descending order of preference. Protocols are named by IANA-registered, opaque, non-empty byte strings... | ||
| org.hbbtv_TLS2100 | 1 | TLS and HTTP/2 - successful request - page load | When an application loads an HTML page from an https URL referencing a server that supports HTTP/2 but not HTTP/1.1, the page load succeeds. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.8: Terminals shall support the use of HTTP/2 [86] for requests for https: URLs initiated by the browser. | |||
| org.hbbtv_TLS2110 | 1 | TLS and HTTP/2 - successful request - XHR | When an application loads content using the XMLHttpRequest API from an https URL referencing a server that supports HTTP/2 but not HTTP/1.1, the request succeeds and the correct content is returned to the application. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.8: Terminals shall support the use of HTTP/2 [86] for requests for https: URLs initiated by the browser. | |||
| org.hbbtv_TLS2120 | 1 | TLS and HTTP/2 - successful request - first page load | When the terminal starts an application whose first page is obtained using an https URL referencing a server that supports HTTP/2 but not HTTP/1.1, the page load succeeds and the application starts. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 7.3.2.8: Terminals shall support the use of HTTP/2 [86] for requests for https: URLs initiated by the browser. | |||
| org.hbbtv_UHD-DRM-HDCP-0010 | 1 | DASH PQ10 (without Optional Supplemental Enhancement Information) HEVC, Main 10, Level 5.1, 50 FPS Clearkey protected content is protected by HDCP when passed through HDMI output | 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 protected with the "Clear Key" System the media shall be passed through the HDMI output of the device with HDCP 2.2 enabled. | 2024-1 2023-3 2023-2 2022-3 2022-2 | HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section B.3: The "Clear Key" key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH ... Receivers shall not allow content delivered in this way to be: ... Presented though any HDMI output without HDCP being enabled. | -HAS_DISPLAY +PQ10 | ||
| org.hbbtv_UHD-DRM-HDCP-0020 | 1 | DASH HLG10 HEVC, Main 10, Level 5.1, 50 FPS Clearkey protected content is protected by HDCP 2.2 when passed through HDMI output | 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 HLG10 HDR format video content protected with the "Clear Key" System the media shall be passed through the HDMI output of the device with HDCP 2.2 enabled. | 2024-1 2023-3 2023-2 2022-3 2022-2 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section B.3: The "Clear Key" key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH ... Receivers shall not allow content delivered in this way to be: ... Presented though any HDMI output without HDCP being enabled. | -HAS_DISPLAY +HEVC_UHD | ||
| org.hbbtv_UHD-HFR-AC4-0010 | 2 | HTML5 static video element displaying DASH HEVC PQ10 with Temporal Layers with a higher frame rate (HFR) 100fps at Main 10, Level 5.1 and AC-4 audio content at matching framerate | When the terminal loads an HbbTV Application including an HTML5 media object which references a static MPD defining a stream containing AC-4 audio and DASH HEVC PQ10 with Temporal Layers with a higher frame rate (HFR) 100fps format video content with BT.2020 colour space and framerate matching audio content, the media shall be correctly presented by the terminal and the playback shall be smooth and contain no decoding artifacts. | 2024-1 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 5.2.8: [...] Where HEVC video has been encoded using temporal layers, every Representation shall include a SupplementalProperty Descriptor indicating the HighestTid (Highest Temporal ID) present in the Representation, either by explicit signalling on the Representation or inheritance from the containing Adaptation Set. DVB DASH defines the following scheme to signal the HighestTid and this scheme shall be used: @schemeIDUri: “urn:dvb:dash:highest_temporal_id:2017” @value: decimal representation of the Highest Temporal ID [...] 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.2: [...] NOTE 2: Clause 6.7.2 in ETSI TS 101 154 specifies that if the IRD supports video frame rates between 100 Hz and 120 Hz, the IRD is also capable of decoding AC-4 audio frame rates in the set {100, 120 000/1 001, 120}Hz. [...] 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: Additional video 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. [...] 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; * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +AC4 +DASH_HFR +PQ10 | ||
| org.hbbtv_UHD-HFR-ADINS0010 | 1 | HTML5 mid-roll advert insertion, DASH HFR HEVC, Main 10, Level 5.2 and AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH HFR HEVC, Main 10, Level 5.2 media is paused, and a second HTML5 media element with pre-buffered DASH HE-AAC/AVC_HD_25 media is played in its entirety, and then the playing of the previous DASH media is resumed. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2020-3 2020-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 for audio-only content and for audio/video content in combination with all supported video formats. 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 J: Annex J (informative): Advert insertion guidance for content providers The present document provides support for dynamic insertion of advertising using multiple HTML5 media elements [...] | +DASH_HFR | ||
| org.hbbtv_UHD-HFR-BROADBAND0010 | 1 | UHD HFR broadband capability is not present when not supported | When an HbbTV application queries the xmlCapabilities, no video_profile element with name="MP4_HEVC_UHD_HFR_25_HEAAC_EBUTTD", type="video/mp4" and transport="dash" is present in the document returned, with or without a sync_tl or hdr attribute. | 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 10.2.4: Terminals that support HFR according to clause 5.2.8 of TS 103 285 [45] 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. This shall be in addition to the video_profile element(s) for the standard frame rate version of the codec. | -DASH_HFR | ||
| org.hbbtv_UHD-HFR-BROADBAND0020 | 1 | HFR terminal plays 100Hz representations from DASH MPD when HFR HLG10 broadband capability is supported | When an HbbTV application queries the xmlCapabilities, a <video_profile name="MP4_HEVC_UHD_HFR_25_HEAAC_EBUTTD" type="video/mp4" transport="dash" sync_tl="dash_pr" hdr="urn:dvb:dash:bitstream:video:hdr_hlg10"/> element is present in the document returned, and when the terminal loads an HbbTV Application including an HTML5 media object whose media source is initialized with a static 2017-profile DVB DASH MPD defining a stream containing an HEVC UHD HLG10 100Hz video representation (using only a single temporal layer), given sufficient network bandwidth, the 100Hz video is played back without artifacts or glitches and the video is presented or output in HDR mode. | 2024-1 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 10.2.4: Terminals that support HFR according to clause 5.2.8 of TS 103 285 [45] 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. This shall be in addition to the video_profile element(s) for the standard frame rate version of the codec. | +DASH_HFR +HLG10 | ||
| org.hbbtv_UHD-HFR-BROADBAND0030 | 1 | HFR terminal plays 100Hz representations from DASH MPD when HFR PQ10 broadband capability is supported | When an HbbTV application queries the xmlCapabilities, a <video_profile name="MP4_HEVC_UHD_HFR_25_HEAAC_EBUTTD" type="video/mp4" transport="dash" sync_tl="dash_pr" hdr="urn:dvb:dash:bitstream:video:hdr_pq10"/> element is present in the document returned, and when the terminal loads an HbbTV Application including an HTML5 media object whose media source is initialized with a static 2017-profile DVB DASH MPD defining a stream containing an HEVC UHD PQ10 100Hz video representation (using only a single temporal layer), given sufficient network bandwidth, the 100Hz video is played back without artifacts or glitches and the video is presented or output in HDR mode. | 2024-1 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 10.2.4: Terminals that support HFR according to clause 5.2.8 of TS 103 285 [45] 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. This shall be in addition to the video_profile element(s) for the standard frame rate version of the codec. | +DASH_HFR +PQ10 | ||
| org.hbbtv_UHD-HFR-BROADBAND0040 | 1 | Non-HFR terminal ignores 100Hz representations from DASH MPD | When the terminal loads an HbbTV Application including an HTML5 media object whose media source is initialized with a static DVB DASH 2017-profile MPD containing a single AdaptationSet containing an HEVC UHD 50Hz video representation (with a single temporal layer) and an HEVC UHD 100Hz video representation (with a single temporal layer), either the HTML5 video element contains no video tracks, or despite sufficient network bandwidth for the 100Hz representation to be downloaded, only the 50Hz video is played back, and without artifacts or glitches. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 | The challenge exists but not validated | 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 A.2.12.1: A VideoTrack object shall be created for each video Adaptation Set in the MPD for which @profiles includes or is inferred to include a profile supported by the terminal. TS-103-285,section 10.17: Players shall ignore any AdaptationSet or Representation that has a @codecs (including information such as profile and level, object type etc.), @frameRate, @width or @height or @par or @sar attribute that the player does not understand or cannot process. | -DASH_HFR +HEVC_UHD | |
| org.hbbtv_UHD-HFR-BROADBAND0050 | 1 | Terminal supporting broadcast HFR supports DASH HFR | When an HbbTV application queries the xmlCapabilities, a video_profile element with name="MP4_HEVC_UHD_HFR_25_HEAAC_EBUTTD", type="video/mp4" and transport="dash" is present in the document returned. | 2024-1 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 7.3.1.1: 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. |HEVC HDR HFR UHDTV IRD using HLG10|hevc_uhd_hfr_hlg10 player conformance point as defined in clause L.2 of TS 101 154 [] (see note 1)|HEVC_UHD_HFR_25, HEVC_UHD_HFR_30 (see note 2)| |HEVC HDR HFR UHDTV IRD using PQ10|hevc_uhd_hfr_pq10 player conformance point as defined in clause L.2 of TS 101 154 [] (see note 1)|HEVC_UHD_HFR_25, HEVC_UHD_HFR_30 (see note 2) HBBTV,section 10.2.4: Terminals that support HFR according to clause 5.2.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. This shall be in addition to the video_profile element(s) for the standard frame rate version of the codec. | +BROADCAST_HFR | ||
| org.hbbtv_UHD-HFR-CLEARKEY0010 | 1 | UHD HFR playback with EME ClearKey decryption | When the terminal loads an HbbTV Application including an HTML5 media object whose media source is initialized with a static DASH MPD defining a stream containing "cenc"-encrypted HEVC-encoded 3840x2160p 100fps HFR video encoded at 50 Mbps, "cenc"-encrypted AAC audio, and the application provides decryption keys via the EME Clear Key mechanism when required, the media shall be correctly presented by the terminal and the playback shall be smooth and contain no decoding artifacts. | 2024-1 2023-3 2023-2 2023-1 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section B.3: The "Clear Key" key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). ... The initialization data type 'cenc' shall be supported - see clause 8.3 of EME [66]. 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.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: ... 39 Mbit/s if the terminal does support UHD video but does not support HFR video. 51 Mbit/s if the terminal supports UHD HFR video. TS-103-285,section 10.19: Players that support decryption of encrypted content shall support the “cenc” scheme and may support the “cbcs” scheme both as referenced in clause 8 of the present document. | +DASH_HFR | ||
| org.hbbtv_UHD-HFR-HTML5-ACTIONS0010 | 1 | Pause HFR UHD HEVC video HTML5 MPEG DASH media element | Pausing the playback of a HTML5 MPEG DASH media element referencing HFR UHD HEVC that is currently playing, shall cause the video to freeze and the audio to suspend. | 2024-1 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. | +DASH_HFR | ||
| org.hbbtv_UHD-HFR-HTML5-ACTIONS0020 | 1 | Playback of paused HFR UHD HEVC video HTML5 MPEG DASH media element from next IDR | When resuming the playback of a HTML5 MPEG DASH media element referencing HFR UHD HEVC 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. | 2024-1 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.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. | +DASH_HFR | ||
| org.hbbtv_UHD-HFR-PERIOD-TRANS0010 | 1 | Period boundary transitions: HEVC UHD HFR to HEVC UHD SFR period continuous | The terminal shall correctly decode and display video content from a stream defined by a static DASH MPD containing two Periods, each containing an HEVC UHD video AdaptationSet with the same AdaptationSet@id value, each containing an AAC audio 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. The first period has 100Hz video and the second period has 50Hz video. Video and audio is played back seamlessly through the period boundary without artifacts or glitches. | 2024-1 2023-3 2023-2 2022-1 2021-3 2021-2 2021-1 | HBBTV 1.5.1 HBBTV 1.6.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. | +DASH_HFR | ||
| org.hbbtv_UHD-HLG10-AC4-0010 | 2 | HTML5 static video element displaying DASH HLG10 HEVC, Main 10, Level 5.1, 50 FPS video and AC-4 audio content at matching framerate | When the terminal loads an HbbTV Application including an HTML5 media object which references a static MPD defining a stream containing AC-4 audio and HEVC-encoded 3840x2160p HLG10 HDR format video content with BT.2020 colour space, both @50fps, the media shall be correctly presented by the terminal and the playback shall be smooth and contain no decoding artifacts. | 2024-1 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 5.2.6: [...] use of HLG10 within an AdaptationSet shall be signalled as follows: * MPD and AdaptationSet profile signalling in accordance with clause 4.1 indicating urn:dvb:dash:profile:dvb-dash:2017 [...] * An EssentialProperty descriptor with @schemeIdUri ="urn:mpeg:mpegB:cicp:TransferCharacteristics" and @value="14" (indicating BT.2020 OETF) [...] 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: Additional video 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. [...] 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; * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +AC4 +HEVC_UHD | ||
| org.hbbtv_UHD-HLG10-ADINS0010 | 1 | HTML5 mid-roll advert insertion, DASH HLG10 HEVC, Main 10, Level 5.1 and AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH HLG10 HEVC, Main 10, Level 5.1 media is paused, and a second HTML5 media element with pre-buffered DASH HE-AAC/AVC_HD_25 media is played in its entirety, and then the playing of the previous DASH media is resumed. | 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.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 for audio-only content and for audio/video content in combination with all supported video formats. HBBTV,section 9.6.1: The media 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 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 | ||
| org.hbbtv_UHD-HLG10-ADINS0020 | 1 | HTML5 mid-roll advert insertion, DASH HLG10 HEVC, Main 10, Level 5.1 and HEVC_UHD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH HLG10 HEVC, Main 10, Level 5.1 media is paused, and a second HTML5 media element with pre-buffered DASH HE-AAC/HEVC_UHD_25 media is played in its entirety, and then the playing of the previous DASH media is resumed. | 2024-1 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 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 for audio-only content and for audio/video content in combination with all supported video formats. HBBTV,section 9.6.1: The media 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 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 | ||
| org.hbbtv_UHD-HLG10-BROADBAND0010 | 1 | UHD HLG10 broadband capability is not present when not supported | When an HbbTV application queries the xmlCapabilities, no <video_profile name="MP4_HEVC_UHD_25_HEAAC_EBUTTD" type="video/mp4" transport="dash" sync_tl="dash_pr" hdr="urn:dvb:dash:bitstream:video:hdr_hlg10"/> element is present in the document returned. | 2024-1 2023-3 2023-2 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 10.2.4: Terminals that support HDR for broadband delivered video according to TS 103 285 [] shall include a video_profile element for each combination of video codec, audio codec, HDR technology and transport protocol supported with HbbTV. Each such video_profile element shall include a hdr attribute each as defined in clause A.2.15 below. | -HLG10 | ||
| org.hbbtv_UHD-HLG10-BROADBAND0020 | 1 | UHD HLG10 is indicated and plays in HDR mode when HLG10 broadband capability is supported | When an HbbTV application queries the xmlCapabilities, a <video_profile name="MP4_HEVC_UHD_25_HEAAC_EBUTTD" type="video/mp4" transport="dash" sync_tl="dash_pr" hdr="urn:dvb:dash:bitstream:video:hdr_hlg10"/> element is present in the document returned, and when a stream defined by a static DASH MPD containing HLG10 UHD HEVC media with AAC audio is played using an HTML5 video element, video and audio is played back without artifacts or glitches and the video is presented or output in HDR mode. | 2024-1 2023-3 2023-2 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,section 10.2.4: Terminals that support HDR for broadband delivered video according to TS 103 285 [] shall include a video_profile element for each combination of video codec, audio codec, HDR technology and transport protocol supported with HbbTV. Each such video_profile element shall include a hdr attribute each as defined in clause A.2.15 below. | +HLG10 | ||
| org.hbbtv_UHD-HLG10-BROADBAND0030 | 1 | UHD is indicated and UHD HLG10 plays when UHD (SDR) broadband capability is supported | When an HbbTV application queries the xmlCapabilities, a <video_profile name="MP4_HEVC_UHD_25_HEAAC_EBUTTD" type="video/mp4" transport="dash" sync_tl="dash_pr"/> element is present in the document returned, and when a stream defined by a static DASH MPD containing HLG10 UHD HEVC media with AAC audio is played using an HTML5 video element, video and audio is played back without artifacts or glitches. | 2024-1 2023-3 2023-2 2022-3 2022-2 2022-1 2021-1 2020-3 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 10.2.4: Terminals that support HEVC UHD video as defined in clause 7.3.1.3 shall include the following video profiles: <video_profile name="MP4_HEVC_UHD_25_HEAAC_EBUTTD" type="video/mp4" transport="dash" sync_tl="dash_pr"/> <video_profile name="MP4_HEVC_UHD_25_HEAAC_EBUTTD" type="video/mp4" /> | +HEVC_UHD -HLG10 | ||
| org.hbbtv_UHD-HLG10-BROADCAST0010 | 1 | UHD (SDR) broadcast capability is not present when not supported | When an HbbTV application queries the xmlCapabilities, no <broadcast>urn:dvb:broadcast:ird:video:HEVC_UHDTV_IRD</broadcast> element is present in the document returned. | 2024-1 2023-3 2023-2 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 10.2.4: Terminals shall list the video and audio technologies that they support for the broadcast as a list of <broadcast> elements, one element per supported technology. | -HEVC_UHD | ||
| org.hbbtv_UHD-HLG10-BROADCAST0020 | 1 | UHD HLG10 broadcast capability is not present when not supported | When an HbbTV application queries the xmlCapabilities, no <broadcast>urn:dvb:broadcast:ird:video:HEVC_HDR_UHDTV_IRD_using_HLG10</broadcast> element is present in the document returned. | 2024-1 2023-3 2023-2 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 10.2.4: Terminals shall list the video and audio technologies that they support for the broadcast as a list of <broadcast> elements, one element per supported technology. | -HLG10 | ||
| org.hbbtv_UHD-HLG10-BROADCAST0030 | 1 | UHD is indicated and UHD HLG10 plays when UHD (SDR) broadcast capability is supported | When an HbbTV application queries the xmlCapabilities, a <broadcast>urn:dvb:broadcast:ird:video:HEVC_UHDTV_IRD</broadcast> element is present in the document returned, and when a broadcast service using HLG10 UHD HEVC video and AAC audio is selected, the media shall be correctly presented by the terminal and the playback shall be smooth and contain no decoding artifacts. | 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 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.4: Terminals shall list the video and audio technologies that they support for the broadcast as a list of <broadcast> elements, one element per supported technology. TS-101-154,section 5.14.4.1: Bitstreams using HLG10: the Bitstreams are specified in such a way that HEVC UHDTV IRDs as specified in clause 5.14.3 are expected to produce good images, although with a quality that may be lower than the one produced by HEVC HDR UHDTV IRDs. | +HEVC_UHD -HLG10 | ||
| org.hbbtv_UHD-HLG10-BROADCAST0040 | 1 | UHD HLG10 is indicated and plays in HDR mode when HLG10 broadcast capability is supported | When an HbbTV application queries the xmlCapabilities, a <broadcast>urn:dvb:broadcast:ird:video:HEVC_HDR_UHDTV_IRD_using_HLG10</broadcast> element is present in the document returned, and when a broadcast service using HLG10 UHD HEVC video and AAC audio is selected, the media shall be correctly presented or output by the terminal in HDR mode and the playback shall be smooth and contain no decoding artifacts. | 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 10.2.4: Terminals shall list the video and audio technologies that they support for the broadcast as a list of <broadcast> elements, one element per supported technology. | +HLG10 | ||
| org.hbbtv_UHD-HLG10-CLEARKEY0010 | 1 | UHD HLG10 playback with EME ClearKey decryption | When the terminal loads an HbbTV Application including an HTML5 media object whose media source is initialized with a static DASH MPD defining a stream containing "cenc"-encrypted HEVC-encoded 3840x2160p 50fps HLG10 HDR format video encoded at 38 Mbps, "cenc"-encrypted AAC audio, and the appplication provides decryption keys via the EME Clear Key mechanism when required, the media shall be correctly presented by the terminal and the playback shall be smooth and contain no decoding artifacts. | 2024-1 2023-3 2023-1 2020-2 2020-1 | HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section B.3: The "Clear Key" key system defined in clause 9.1 of the encrypted media extensions API [66] shall be supported for content delivered by MPEG DASH (see clause E of the present document). ... The initialization data type 'cenc' shall be supported - see clause 8.3 of EME [66]. 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.2: For adaptive bitrate streaming, terminals shall support combinations of one video, one audio and one subtitle representation for which the combined channel bandwidth requirement for continuous playback does not exceed: ... 39 Mbit/s if the terminal does support UHD video but does not support HFR video. 51 Mbit/s if the terminal supports UHD HFR video. TS-103-285,section 10.19: Players that support decryption of encrypted content shall support the “cenc” scheme and may support the “cbcs” scheme both as referenced in clause 8 of the present document. | +HEVC_UHD | ||
| org.hbbtv_UHD-HLG10-HTML5-ACTIONS0010 | 1 | Pause HLG10 UHD HEVC video HTML5 MPEG DASH media element | Pausing the playback of a HTML5 MPEG DASH media element referencing HLG10 UHD HEVC that is currently playing, shall cause the video to freeze and the audio to suspend. | 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 | HBBTV 1.5.1 HBBTV 1.6.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. | +HLG10 | ||
| org.hbbtv_UHD-HLG10-HTML5-ACTIONS0020 | 1 | Playback of paused HLG10 UHD HEVC video HTML5 MPEG DASH media element from next IDR | When resuming the video playback of a HTML5 MPEG DASH media element referencing HLG10 UHD HEVC that has previously been paused, the terminal shall start video playback at or before the IDR following the pause position, preferably from the next frame following the pause position. | 2024-1 2023-3 2023-2 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,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. | +HEVC_UHD | ||
| org.hbbtv_UHD-HLG10-OVERLAY0010 | 1 | UHD HLG10 overlaid by opaque graphics | When an HbbTV application presents HLG10 UHD HEVC DASH content using an HTML5 video element and the video element is overlaid with text and graphics in pure white rgb(255, 255, 255) colour on an opaque black rgb(0, 0, 0) background, the text and graphics are visible and readable and the video cannot be seen through the black background of the graphics. | 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 | HBBTV 1.5.1 HBBTV 1.6.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.15: Players shall take into account the colour or HDR format when combining subtitles and on-screen graphics with video for display. | +HEVC_UHD | ||
| org.hbbtv_UHD-HLG10-OVERLAY0020 | 1 | UHD HLG10 overlaid by semi-transparent graphics | When an HbbTV application presents HLG10 UHD HEVC DASH content using an HTML5 video element and the video element is overlaid with graphics in 50% transparent white rgba(255, 255, 255, 0.5) and 50% transparent black rgba(0, 0, 0, 0.5), the graphics are visible and the video can be seen beneath. | 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 | HBBTV 1.5.1 HBBTV 1.6.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.15: Players shall take into account the colour or HDR format when combining subtitles and on-screen graphics with video for display. | +HEVC_UHD | ||
| org.hbbtv_UHD-HLG10-OVERLAY0030 | 1 | UHD HLG10 with subtitles | When an HbbTV application presents HLG10 UHD HEVC DASH content with EBU-TT-D subtitles using an HTML5 video element and the subtitles include the colours "#ffffff", "#ffff00", "#00ffff", "#00ff00" on a black background "#000000", the subtitles are visible and readable and the video cannot be seen beneath the black background. | 2024-1 2023-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 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.15: Players shall take into account the colour or HDR format when combining subtitles and on-screen graphics with video for display. | +HEVC_UHD | ||
| org.hbbtv_UHD-HLG10-PERIOD-TRANS0010 | 1 | Period boundary transitions: UHD HLG10 to AVC/AAC | The terminal shall correctly decode and display video content from a stream defined by a static DASH MPD containing a period containing HLG10 UHD HEVC media followed by a period containing AVC_HD_25 media, both with AAC audio. Video from both periods is played back in its entirety without artifacts or glitches and the transition is successful. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-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 ... | +HLG10 | ||
| org.hbbtv_UHD-HLG10-PERIOD-TRANS0020 | 1 | Period boundary transitions: AVC/AAC to UHD HLG10 | The terminal shall correctly decode and display video content from a stream defined by a static DASH MPD containing a period containing AVC_HD_25 media followed by a period containing HLG10 UHD HEVC media, both with AAC audio. Video and audio from both periods is played back in its entirety without artifacts or glitches and the transition is successful. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-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 ... | +HLG10 | ||
| org.hbbtv_UHD-HLG10-PERIOD-TRANS0030 | 1 | Period boundary transitions: UHD HLG10 continuous | The terminal shall correctly decode and display video content from a stream defined by a static DASH MPD containing two Periods, each containing an HLG10 HEVC video AdaptationSet with the same AdaptationSet@id value, each containing an AAC audio 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. Video and audio is played back seamlessly through the period boundary without artifacts or glitches. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2020-1 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.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. | +HLG10 | ||
| org.hbbtv_UHD-HLG10-PERIOD-TRANS0040 | 1 | Period boundary transitions: UHD HLG10 to HEVC SDR/AAC | The terminal shall correctly decode and display video content from a stream defined by a static DASH MPD containing a period containing HLG10 UHD HEVC media followed by a period containing SDR UHD HEVC media, both with AAC audio. Video and audio from both periods is played back in its entirety without artifacts or glitches and the transition is successful. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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 ... | +HLG10 | ||
| org.hbbtv_UHD-HLG10-PERIOD-TRANS0050 | 1 | Period boundary transitions: HEVC SDR/AAC to UHD HLG10 | The terminal shall correctly decode and display video content from a stream defined by a static DASH MPD containing a period containing SDR UHD HEVC media followed by a period containing HLG10 UHD HEVC media, both with AAC audio. Video and audio from both periods is played back in its entirety without artifacts or glitches and the transition is successful | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2020-2 2020-1 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 ... | +HLG10 | ||
| org.hbbtv_UHD-HLG10-SEEKACCURACY0010 | 1 | Seek to start of HLG10 media segment in live period | An application starts HLG10 UHD DASH content playing and then seeks to a location that is in a live period and is identifiable from the MPD as being the start of a video media segment. The seek is frame accurate. The position reported by the media player API reports the true media position after the seek. | 2024-1 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,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. | +HEVC_UHD | ||
| org.hbbtv_UHD-PQ10-AC4-0010 | 2 | HTML5 static video element displaying DASH PQ10 HEVC, Main 10, Level 5.1, 50 FPS video and AC-4 audio content at matching framerate | When the terminal loads an HbbTV Application including an HTML5 media object which references a static MPD defining a stream containing AC-4 audio and HEVC-encoded 3840x2160p PQ10 HDR format video content with BT.2020 colour space, both @50fps, the media shall be correctly presented by the terminal and the playback shall be smooth and contain no decoding artifacts. | 2024-1 2023-3 2023-2 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 5.2.7: [...] Use of PQ10 within an AdaptationSet shall be signalled as follows: * MPD and AdaptationSet profile signalling in accordance with clause 4.1 indicating urn:dvb:dash:profile:dvb-dash:2017 [...] * An EssentialProperty descriptor with @schemeIdUri ="urn:mpeg:mpegB:cicp:TransferCharacteristics" and @value="16" (indicating BT.2100 PQ system) 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: Additional video 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. [...] 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; * Adaptively streamed video and/or audio as defined in annex E of the present document shall be supported [...] | +AC4 +PQ10 | ||
| org.hbbtv_UHD-PQ10-ADINS0001 | 3 | HTML5 mid-roll advert insertion, DASH PQ10 HEVC, Main 10, Level 5.1 and AVC_HD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH PQ10 HEVC, Main 10, Level 5.1 media is paused, and a second HTML5 media element with DASH with HE-AAC/AVC_HD_25 media is played in its entirety, and then the playing of the previous DASH media is resumed. | 2024-1 2023-3 2023-2 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: Table 9 defines the subset of the combinations of system, video, audio [...] formats [...] that shall be supported for non-adaptive HTTP streaming [...] 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 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 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 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 [...] | +PQ10 | ||
| org.hbbtv_UHD-PQ10-ADINS0002 | 3 | HTML5 mid-roll advert insertion, DASH PQ10 HEVC, Main 10, Level 5.1 and HEVC_UHD_25 | Content is presented without artefacts or glitches when a currently playing HTML5 media element referencing DASH PQ10 HEVC, Main 10, Level 5.1 media is paused, and a second media element with DASH HE-AAC/HEVC_UHD_25 media is played in its entirety, and then the playing of the previous DASH media is resumed. | 2024-1 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 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 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 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.3: [...] * Terminals [...] shall also support HEVC UHD for content received by the broadband connection. [...] HBBTV,section 9.6.1: The media 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 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 [...] | +PQ10 | ||
| org.hbbtv_UHD-PQ10-BROADBAND0010 | 1 | UHD PQ10 broadband capability reported correctly and UHD PQ10 media presented | When an HbbTV application queries the xmlCapabilities a <video_profile name="MP4_HEVC_UHD_25_HEAAC_EBUTTD" type="video/mp4" transport="dash" sync_tl="dash_pr" hdr="urn:dvb:dash:bitstream:video:hdr_pq10"/> element is present in the document returned. When play() is called on an HTMLVideoElement referencing an MPD containing UHD PQ10 video, the video is presented correctly. | 2024-1 2023-3 2023-2 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-2 2020-1 | The challenge exists but not validated | HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 10.2.4: Terminals that support HDR for broadband delivered video according to TS 103 285 [] shall include a video_profile element for each combination of video codec, audio codec, HDR technology and transport protocol supported with HbbTV. Each such video_profile element shall include a hdr attribute each as defined in clause A.2.15 below. | +PQ10 | |
| org.hbbtv_UHD-PQ10-BROADBAND0020 | 1 | UHD PQ10 broadband capability reported correctly | When an HbbTV application queries the xmlCapabilities a <video_profile name="MP4_HEVC_UHD_25_HEAAC_EBUTTD" type="video/mp4" transport="dash" sync_tl="dash_pr" hdr="urn:dvb:dash:bitstream:video:hdr_pq10"/> element is not present in the document returned. | 2024-1 2023-3 2023-2 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 10.2.4: Terminals that support HDR for broadband delivered video according to TS 103 285 [] shall include a video_profile element for each combination of video codec, audio codec, HDR technology and transport protocol supported with HbbTV. Each such video_profile element shall include a hdr attribute each as defined in clause A.2.15 below. | -PQ10 | ||
| org.hbbtv_UHD-PQ10-BROADCAST0020 | 1 | UHD PQ10 broadcast capability reported correctly and UHD PQ10 media presented | "When an HbbTV application queries the xmlCapabilities a <broadcast>urn:dvb:broadcast:ird:video:HEVC_HDR_UHDTV_IRD_using_PQ10</broadcast> element is present in the document returned, and when a broadcast service using PQ10 UHD HEVC video is selected, the video is presented correctly." | 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 10.2.4: Terminals shall list the video and audio technologies that they support for the broadcast as a list of <broadcast> elements, one element per supported technology. The list shall be the same for both broadcast-related and broadcast-independent applications. | +PQ10 | ||
| org.hbbtv_UHD-PQ10-BROADCAST0040 | 1 | UHD PQ10 broadcast capability reported correctly | When an HbbTV application queries the xmlCapabilities a <broadcast>urn:dvb:broadcast:ird:video:HEVC_HDR_UHDTV_IRD_using_PQ10</broadcast> element is not present in the document returned. | 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 10.2.4: Terminals shall list the video and audio technologies that they support for the broadcast as a list of <broadcast> elements, one element per supported technology. The list shall be the same for both broadcast-related and broadcast-independent applications. | -PQ10 | ||
| org.hbbtv_UHD-PQ10-HTML5-ACTIONS0010 | 1 | Pause PQ10 UHD HEVC video HTML5 MPEG DASH media element | Pausing the playback of a HTML5 MPEG DASH media element referencing PQ10 UHD HEVC that is currently playing, shall cause the video to freeze and the audio to suspend. | 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 | HBBTV 1.5.1 HBBTV 1.6.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. | +PQ10 | ||
| org.hbbtv_UHD-PQ10-HTML5-ACTIONS0020 | 1 | Playback of paused PQ10 UHD HEVC video HTML5 MPEG DASH media element from next IDR | When resuming the video playback of a HTML5 MPEG DASH media element referencing PQ10 UHD HEVC that has previously been paused, the terminal shall start video playback at or before the IDR following the pause position, preferably from the next frame following the pause position. | 2024-1 2023-3 2023-2 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,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. | +PQ10 | ||
| org.hbbtv_UHD-PQ10-NOT-SUPPORTED | 1 | Play an alternative video Representation if PQ10 is not supported. | The DASH MPD contains in the same Period an Adaptation Set with PQ10 UHD HEVC media and Role@value set to "main", and a second Adaptation Set with AVC_HD_25 media and Role@value not set to "main". A terminal that doesn´t support PQ10 shall playback the AVC_HD_25 media Representation. | 2024-1 2023-3 2022-3 2022-2 2022-1 2021-3 2021-1 | HBBTV 1.5.1 HBBTV 1.6.1 | TS-103-285,section 5.2.7: High Dynamic Range using PQ10 TS-103-285,section 10.1: DVB Profile support [...] 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 [...] Players shall ignore a parent element if the scheme or the value for the EssentialProperty child element is not recognized by the Player TS-103-285,section 10.14: Players shall process the EssentialProperty and SupplementalProperty descriptors defined in clause 5.2.5. Players shall ignore any video AdaptationSet that has an EssentialProperty descriptor indicating colour primaries, matrix coefficients or transfer characteristics that the player does not support. Players without integrated displays shall take into account the capabilities of any currently connected display when determining whether or not a particular colour space or transfer function is supported. TS-103-285,section 10.17: Compatibility 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. | -PQ10 | ||
| org.hbbtv_UHD-PQ10-OVERLAY0010 | 1 | UHD PQ10 overlaid by opaque graphics | When an HbbTV application presents PQ10 UHD HEVC DASH content using an HTML5 video element and the video element is overlaid with text and graphics in pure white rgb(255, 255, 255) colour on an opaque black rgb(0, 0, 0) background, the text and graphics are visible and readable and the video cannot be seen through the black background of the graphics. | 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 | HBBTV 1.5.1 HBBTV 1.6.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.15: Players shall take into account the colour or HDR format when combining subtitles and on-screen graphics with video for display. | +PQ10 | ||
| org.hbbtv_UHD-PQ10-OVERLAY0020 | 1 | UHD PQ10 overlaid by semi-transparent graphics | When an HbbTV application presents PQ10 UHD HEVC DASH content using an HTML5 video element and the video element is overlaid with graphics in 50% transparent white rgba(255, 255, 255, 0.5) and 50% transparent black rgba(0, 0, 0, 0.5), the graphics are visible and the video can be seen beneath. | 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 | HBBTV 1.5.1 HBBTV 1.6.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.15: Players shall take into account the colour or HDR format when combining subtitles and on-screen graphics with video for display. | +PQ10 | ||
| org.hbbtv_UHD-PQ10-OVERLAY0030 | 1 | UHD PQ10 with subtitles | When an HbbTV application presents PQ10 UHD HEVC DASH content with EBU-TT-D subtitles using an HTML5 video element and the subtitles include the colours "#ffffff", "#ffff00", "#00ffff", "#00ff00" on a black background "#000000", the subtitles are visible and readable and the video cannot be seen beneath the black background. | 2024-1 2023-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 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.15: Players shall take into account the colour or HDR format when combining subtitles and on-screen graphics with video for display. | +PQ10 | ||
| org.hbbtv_UHD-PQ10-PERIOD-TRANS0010 | 1 | Period boundary transitions: UHD PQ10 to AVC/AAC | The terminal shall correctly decode and display video content from a stream defined by a static DASH MPD containing a period containing PQ10 UHD HEVC media followed by a period containing AVC_HD_25 media, both with AAC audio. Video and audio from both periods is played back in its entirety without artifacts or glitches and the transition is successful. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2020-1 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... | +PQ10 | ||
| org.hbbtv_UHD-PQ10-PERIOD-TRANS0020 | 1 | Period boundary transitions: AVC/AAC to UHD PQ10 | The terminal shall correctly decode and display video content from a stream defined by a static DASH MPD containing a period containing AVC_HD_25 media followed by a period containing PQ10 UHD HEVC media, both with AAC audio. Video and audio from both periods is played back in its entirety without artifacts or glitches and the transition is successful. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-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 ... | +PQ10 | ||
| org.hbbtv_UHD-PQ10-PERIOD-TRANS0030 | 1 | Period boundary transitions: UHD PQ10 continuous | The terminal shall correctly decode and display video content from a stream defined by a static DASH MPD containing two Periods, each containing an PQ10 HEVC video AdaptationSet with the same AdaptationSet@id value, each containing an AAC audio 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. Video and audio is played back seamlessly through the period boundary without artifacts or glitches. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 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. | +PQ10 | ||
| org.hbbtv_UHD-PQ10-SEEKACCURACY0010 | 2 | seek to start of PQ10 media segment in live period | An application starts PQ10 DASH content playback and then seeks to a position that is in a live period and is identifiable from the MPD as being the start of a PQ10 video 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-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 | HBBTV 1.5.1 HBBTV 1.6.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. | +PQ10 | ||
| org.hbbtv_UHD-PQ10-SEEKACCURACY0030 | 1 | seek to other positions in PQ10 DASH content - live period - nearest position before target | An application starts PQ10 DASH content playback and then seeks to a position that is in a live Period but not identifiable from the MPD as being the start of a PQ10 media segment and where the nearest position that is identifiable is before the target position but after the current position. Either the seek shall be 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-1 2023-3 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 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 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. | +PQ10 | ||
| org.hbbtv_UHD-STATIC-0070 | 1 | HTML5 static video element displaying DASH HLG10 HEVC, Main 10, Level 5.1, 50 FPS content | When the terminal loads an HbbTV Application including an HTML5 media object which references a static MPD defining a stream containing HEAAC 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-1 2023-3 2023-2 2023-1 2022-3 2022-2 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.3: Terminals that support HEVC UHD video on the broadcast connection defined by DVB as "HEVC UHDTV IRD" in clause 5.14.3 of ETSI TS 101 154 [14] shall also support HEVC UHD for content received by the broadband connection | +HEVC_UHD | ||
| org.hbbtv_V15E20010 | 1 | descriptorTagExtension | When the DVB-SI information corresponding to a Programme includes an extended descriptor, an application can read that descriptor using the getSIDescriptors method with the descriptorTag argument being 0x7f and passing the "Tag extension value" in the descriptorTagExtension argument. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 4.8.1: Change Table A.1 in Annex A.1 to [...] The optional argument descriptorTagExtension to the method getSIDescriptors is mandatory when descriptorTag is 0x7f and ignored in all other cases. OIPF-DAE,section 7.16.2.4: descriptorTagExtension [...] An optional argument giving the descriptor tag extension as specified by [EN 300 468]. This argument is mandatory when descriptorTag is 0x7f and ignored in all other cases. EN-300-468,section 6.3: All extended descriptors are based on the extension_descriptor (see clause 6.2.16). Table 107 lists the extended descriptors declared or defined within the present document, giving the descriptor tag extension values and the intended placement within the SI tables. This does not imply that their use in other tables is restricted. | |||
| org.hbbtv_V15E20020 | 1 | channel.nid | When an HbbTV application obtains a Channel object for a channel where there is exactly one NIT actual subtable in the transport stream carrying the channel then the value of the nid property shall be either the network_id in that subtable or the network_id of a NIT subtable used to discover the channel during the configuration process. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 4.8.5: Change Table A.1 in Annex A.1 to [...] Channel class [...] The following properties shall be supported: [...] nid HBBTV,section A.1: Channel class [...] The following properties shall be supported: [...] nid OIPF-DAE,section 8.4.3: The following tables show the mapping from the properties of the Channel class to the source of the data for that property. For channels of type ID_DVB_*: nid [...] Assigned by the terminal [...] Assigned by the terminal as follows: If during the terminal configuration process, a network_id value was selected (either explicitly or implicitly) and the NIT subtable with that network_id value was used by the terminal to discover the correct delivery system descriptor of this channel, then the value of this property shall be that network_id value. Otherwise, if there is exactly one NIT 'actual' subtable in the Transport Stream that is carrying the channel then the value of this property shall be the network_id in that subtable. Terminals are not required to update the value if it changes dynamically in the broadcast Transport Stream. Otherwise the value shall be undefined. OIPF-DAE,section 8.4.3: The following tables show the mapping from the properties of the Channel class to the source of the data for that property. For channels of type ID_DVB_*: nid [...] Assigned by the terminal [...] Assigned by the terminal as follows: If during the terminal configuration process, a network_id value was selected (either explicitly or implicitly) and the NIT subtable with that network_id value was used by the terminal to discover the correct delivery system descriptor of this channel, then the value of this property shall be that network_id value. Otherwise, if there is exactly one NIT 'actual' subtable in the Transport Stream that is carrying the channel then the value of this property shall be the network_id in that subtable. Terminals are not required to update the value if it changes dynamically in the broadcast Transport Stream. Otherwise the value shall be undefined. | |||
| org.hbbtv_V15E20030 | 1 | change of app transport protocol from broadband to broadcast | When a running broadcast-related, non-service-bound application delivered via broadband changes to a service where the same application is allowed to run but is delivered via broadcast, the application is killed and the application signalling processed from the start to find an application to start. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 4.3.2: Is it signalled in the new service with the same transport protocol? [...] No [...] Kill currently running application HBBTV,section 6.2.2.2: Is it signalled in the new service with the same transport protocol? [...] No [...] Kill currently running application | |||
| org.hbbtv_V15E20040 | 1 | change of app transport protocol from broadcast to broadband | When a running broadcast-related, non-service-bound application delivered via broadcast changes to a service where the same application is allowed to run but is delivered via broadband, the application is killed and the application signalling processed from the start to find an application to start. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 4.3.2: Is it signalled in the new service with the same transport protocol? [...] No [...] Kill currently running application HBBTV,section 6.2.2.2: Is it signalled in the new service with the same transport protocol? [...] No [...] Kill currently running application | |||
| org.hbbtv_V15E20065 | 1 | XHR and DSMCC Carousel Apps - Extended Boundary - Page From Broadband | Code in an HTML page loaded from HTTP attempts to make an XMLHttpRequest call to an HTTP server. The page is part of an HbbTV application deliverd by broadcast whose boundary is extended with an HTTP URL. The origin header of the XHR request is set to the origin of the HTML page in the form of an HTTP URL according to the CORS specification and not to a DVB URI. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: For resources loaded via DSMCC object carousel, the origin shall be the DVB URI in the form (as defined in TS 102 851 [xx] section 6.3.1): "dvb" ":" "//" original_network_id "." transport_stream_id "." service_id "." component_tag [¶] NOTE 1: In this case, the "host" is the DVB triplet plus the component_tag. [¶] For resources loaded via DSM-CC, this origin shall be used in all cases where a document or resource origin is used in web specifications including but not limited to cross-origin resource sharing [38]. HBBTV,section A.2.8.1: The support for XMLHttpRequest shall include cross-origin resource sharing (CORS) as defined in CORS [38]. HBBTV,section 6.3.2: For resources loaded via DSM-CC object carousel, the origin shall be the DVB URI in the form (as defined in TS 102 851 [10] clause 6.3.1): "dvb" ":" "//" original_network_id "." transport_stream_id "." service_id "." component_tag [¶] NOTE 1: In this case, the "host" is the DVB triplet plus the component_tag. [¶] Hexadecimal digits in the DVB triplet and the component_tag shall be encoded using lower case characters. [¶] This origin shall be used in all cases where a document or resource origin is used in web specifications including but not limited to Cross-Origin Resource Sharing [42] and with Web Storage. HBBTV,section 6.3.3: Extensions to the application boundary shall have no effect on the origin that is used for the enforcement of the same-origin security policy. CORS,section 5.7: The Origin header indicates where the cross-origin request or preflight request originates from. [ORIGIN] | |||
| org.hbbtv_V15E20070 | 1 | XHR and HTTP Delivered Apps | Code in an HTML page loaded from HTTP attempts to make an XMLHttpRequest call to another HTTP server than the one it is delivered from. The HTML page is part of an HbbTV application delivered via broadband. The origin header of the XHR request is set to the origin of the HTML page in the form of an HTTP URL according to the CORS specification. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: For resources loaded via HTTP or HTTPS, the origin shall be derived from the URL as defined in the "The Web Origin Concept" specification [25]. HBBTV,section 6.3.2: For resources loaded via HTTP and HTTPS, the origin shall be as defined in 5.3 of the HTML5 Recommendation [54] CORS,section 5.7: The Origin header indicates where the cross-origin request or preflight request originates from. [ORIGIN] | |||
| org.hbbtv_V15E20080 | 3 | XHR and HTTPS Delivered Apps | Code in an HTML page loaded from HTTPS attempts to make an XMLHttpRequest call to an HTTPS server. The HTML page is part of an HbbTV application delivered via broadband. The origin header of the XHR request is set to the origin of the HTML page in the form of an HTTPS URL according to the CORS specification. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: For resources loaded via HTTP or HTTPS, the origin shall be derived from the URL as defined in the "The Web Origin Concept" specification [25]. HBBTV,section 6.3.2: For resources loaded via HTTP and HTTPS, the origin shall be as defined in 5.3 of the HTML5 Recommendation [54] CORS,section 5.7: The Origin header indicates where the cross-origin request or preflight request originates from. [ORIGIN] | |||
| org.hbbtv_V15E20090 | 1 | PlaySpeedChanged | An application calls the play method on an A/V control object twice with the same speed. An onPlaySpeedChanged event is generated in response to the second call even though the speed has not changed. The argument of the event is the previous play speed. | 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-3 2019-2 2019-1 2018-3 2018-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 4.8.21: An onPlaySpeedChanged event shall be generated for all calls to the play() method regardless of the value returned by the method call and whether the play speed changes or not. HBBTV,section A.1: State diagram for A/V Control objects [...] 7.14.1.1 [...] M(*) [...] An onPlaySpeedChanged event shall be generated for all calls to the play() method regardless of the value returned by the method call and whether the play speed changes or not. OIPF-DAE,section 7.14.1: Boolean play(Number speed) Plays the media referenced by data, starting at the current play position denoted by playPosition, at the supported speed closest to the value of attribute speed. Negative speeds reverse playback. If no speed is specified, it defaults to 1. A speed of 0 will pause playback. This method SHALL always return true. If the playback reached the beginning of the media at rewind playback speed, then the play state SHALL be changed to 2 ('paused'). A play speed event (see section 7.14.3.2 of this specification) SHALL be generated when the operation has completed, regardless of the new play speed. If the play speed is not changed, the argument of the event SHALL be set to the previous play speed. | |||
| org.hbbtv_VIDEO_COMMUTING0010 | 1 | AV Components: Selecting video components from an HTTP MP4 stream with two video components | Using the AV Control object functions getComponents and selectComponent, the terminal shall correctly switch to presenting the unplayed video component from a HTTP MP4 stream containing 2 video components that is currently being presented. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 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,section A1: 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: The switching video adaptation set in a single manifest should be seamless, avoiding video freezes, delays or black screens in between videos. Example: Multi-camera selection. | |||
| org.hbbtv_VIDEO_COMMUTING0020 | 1 | AV Components: Selecting video components from an HbbTV ISOBMFF DASH Live stream with 2 video adaptation sets | Using the A/V Control object functions getComponents and selectComponent, the terminal shall correctly switch to presenting the unplayed video component from a HbbTV ISOBMFF DASH Live stream containing 2 video adaptation sets. | 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,section A1: 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: The switching video adaptation set in a single manifest should be seamless, avoiding video freezes, delays or black screens in between videos. Example: Multi-camera selection. | |||
| org.hbbtv_VIDEO-DISPLAY0010 | 1 | Video display format element(s) are present in XML capabilities for UHD terminals | When an HbbTV application reads the XML capabilities document, it contains at least one video_display_format element and all of the video_display_format elements are schema compliant. | 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 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.4: Terminals that can decode UHD video shall include one or more elements of the following form to describe the highest quality video formats that can be displayed: <video_display_format width="w" height="h" frame_rate="f" bit_depth="b" colorimetry="c-list"/> HBBTV,section A.2.15: A.2.15 Extensions to the OIPF-defined capability negotiation mechanism The following schema is an extension of the schema defined by annex F of the OIPF DAE specification [1]: ... | +HEVC_UHD | ||
| org.hbbtv_VIDEO-DISPLAY0020 | 1 | Video display format elements have non-empty @colorimetry attributes for UHD terminals with integrated display | When an HbbTV application reads the XML capabilities document, it contains at least one video_display_format element and all of the video_display_format elements have @colorimetry attributes whose values are not the empty string. | 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 | HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 10.2.4: Terminals that can decode UHD video shall include one or more elements of the following form to describe the highest quality video formats that can be displayed: <video_display_format width="w" height="h" frame_rate="f" bit_depth="b" colorimetry="c-list"/> ... An empty colorimetry list shall not be used to describe an integrated display, nor for an HDMI-connected display that indicates the colorimetry that it supports. | +HAS_DISPLAY +HEVC_UHD | ||
| org.hbbtv_VIDEO-DISPLAY0030 | 1 | 10-bit BT.2020 display capability for terminals with integrated displays and support for UHD HEVC | When an HbbTV application reads the XML capabilities document, it contains at least one video_display_format element whose @width attribute is greater than 1920, @height is greater than 1080, @frame_rate is 50 or a multiple thereof, @bit_depth is 10 or greater and @colorimetry includes the string "bt2020" | 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 | 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: |Broadcast IRD reqirement from TS 101 154|Related DASH Requirement|Labels in XML capabilities| |HEVC UHDTV IRD|hevc_uhd player conformance point as defined in clause L.2 of TS 101 154 ...|HEVC_UHD_25, HEVC_UHD_30 HBBTV,section 10.2.4: Terminals that can decode UHD video shall include one or more elements of the following form to describe the highest quality video formats that can be displayed: <video_display_format width="w" height="h" frame_rate="f" bit_depth="b" colorimetry="c-list"/> where w, h, f and b are integer values such that video content that complies with the requirements of the present document and has a combination of resolution, frame rate and bit depth that do not exceed the values indicated can be expected to be reproduced on the display without loss of resolution, frame rate or bit depth, and where c-list is a list of strings defining the colour primaries and matrix coefficients that are supported with these values. c-list may include "bt709" to indicate a capability for BT.709 colour primaries and matrix coefficients, and/or "bt2020" to indicate a capability for BT.2020 non-constant luminance colour primaries and matrix coefficients. ... At least one video_display_format element shall be present for each frame rate family (50 Hz or 60 Hz) that the terminal uses for video display. ... If the signal path from the video decoder to the display involves the use of different resolutions, frame rates, bit depths, or colorimetry, the values used in the video_display_format elements shall reflect the most constraining values. TS-103-285,section 10.14: For the purposes of this clause, a player is considered to support ITU-R BT.2020 colour if one or more of the following is true: * The player has an integrated display and the picture that is displayed when ITU-R BT.2020 is signalled is different from the picture displayed when ITU-R BT.709 colour is signalled for an otherwise identical elementary stream. * A BT.2020 picture is passed over an HDMI connection operating with BT.2020 colorimetry to an HDMI Sink that indicates support for BT.2020. * A BT.2020 picture is colour space converted prior to passing over an HDMI connection operating with different colorimetry. TS-101-154,section L.2.1: hevc_uhd|HEVC Main and Main 10 Profile up to level 5.1|Progressive|BT.709 and BT.2020|Up to 3840x2160|50 Hz and 60 Hz families | +HAS_UHD_DISPLAY +HEVC_UHD | ||
| org.hbbtv_VIDEO-DISPLAY0040 | 1 | Display capability reporting and content playback when a terminal with integrated display claims support for 3840x2160 UHD 10-bit | When an HbbTV application reads the XML capabilities document and it contains at least one video_display_format element whose @width attribute is 3840 or greater, @height is 2160 or greater, @frame_rate is 50 or a multiple thereof, @bit_depth is 10 or greater, then when a stream defined by a static DASH MPD containing 3840x2160p50 Main10 10-bit HEVC media with AAC audio is played using an HTML5 video element, video and audio is played back and displayed without loss of resolution or dropped frames and with either (a) no visible banding, or (b) banding that is finer than a reference grey scale that has luminance values whose bottom two bits are zero. | 2024-1 2023-3 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 10.2.4: Terminals that can decode UHD video shall include one or more elements of the following form to describe the highest quality video formats that can be displayed: <video_display_format width="w" height="h" frame_rate="f" bit_depth="b" colorimetry="c-list"/> where w, h, f and b are integer values such that video content that complies with the requirements of the present document and has a combination of resolution, frame rate and bit depth that do not exceed the values indicated can be expected to be reproduced on the display without loss of resolution, frame rate or bit depth, and where c-list is a list of strings defining the colour primaries and matrix coefficients that are supported with these values. c-list may include "bt709" to indicate a capability for BT.709 colour primaries and matrix coefficients, and/or "bt2020" to indicate a capability for BT.2020 non-constant luminance colour primaries and matrix coefficients. ... At least one video_display_format element shall be present for each frame rate family (50 Hz or 60 Hz) that the terminal uses for video display. ... If the signal path from the video decoder to the display involves the use of different resolutions, frame rates, bit depths, or colorimetry, the values used in the video_display_format elements shall reflect the most constraining values. | +HAS_DISPLAY +HEVC_UHD | ||
| org.hbbtv_VIDEO-DISPLAY0050 | 1 | Display capability reporting and content playback when a terminal with integrated display claims support for 3200x1800 UHD 10-bit | When an HbbTV application reads the XML capabilities document and it contains at least one video_display_format element whose @width attribute is 3200 or greater, @height is 1800 or greater, @frame_rate is 50 or a multiple thereof, @bit_depth is 10 or greater, then when a stream defined by a static DASH MPD containing 3200x1800p50 Main10 10-bit HEVC media with AAC audio is played using an HTML5 video element, video and audio is played back and displayed without loss of resolution or dropped frames and with either (a) no visible banding, or (b) banding that is finer than a reference grey scale that has luminance values whose bottom two bits are zero. | 2024-1 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 10.2.4: Terminals that can decode UHD video shall include one or more elements of the following form to describe the highest quality video formats that can be displayed: <video_display_format width="w" height="h" frame_rate="f" bit_depth="b" colorimetry="c-list"/> where w, h, f and b are integer values such that video content that complies with the requirements of the present document and has a combination of resolution, frame rate and bit depth that do not exceed the values indicated can be expected to be reproduced on the display without loss of resolution, frame rate or bit depth, and where c-list is a list of strings defining the colour primaries and matrix coefficients that are supported with these values. c-list may include "bt709" to indicate a capability for BT.709 colour primaries and matrix coefficients, and/or "bt2020" to indicate a capability for BT.2020 non-constant luminance colour primaries and matrix coefficients. ... At least one video_display_format element shall be present for each frame rate family (50 Hz or 60 Hz) that the terminal uses for video display. ... If the signal path from the video decoder to the display involves the use of different resolutions, frame rates, bit depths, or colorimetry, the values used in the video_display_format elements shall reflect the most constraining values. | +HAS_DISPLAY +HEVC_UHD | ||
| org.hbbtv_VIDEO-DISPLAY0100 | 1 | Display capability reporting and content playback when a connected display supports 3840x2160 UHD 10-bit | When an HbbTV application reads the XML capabilities document, it contains at least one video_display_format element whose @width attribute is 3840 or greater, @height is 2160 or greater, @frame_rate is 50 or a multiple thereof, @bit_depth is 10 or greater, and then when a stream defined by a static DASH MPD containing 3840x2160p50 Main10 10-bit HEVC media with AAC audio is played using an HTML5 video element, video and audio is played back and displayed without loss of resolution or dropped frames and with either (a) no visible banding, or (b) banding that is finer than a reference grey scale that has luminance values whose bottom two bits are zero. | 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 10.2.4: Terminals that can decode UHD video shall include one or more elements of the following form to describe the highest quality video formats that can be displayed: <video_display_format width="w" height="h" frame_rate="f" bit_depth="b" colorimetry="c-list"/> where w, h, f and b are integer values such that video content that complies with the requirements of the present document and has a combination of resolution, frame rate and bit depth that do not exceed the values indicated can be expected to be reproduced on the display without loss of resolution, frame rate or bit depth, and where c-list is a list of strings defining the colour primaries and matrix coefficients that are supported with these values. c-list may include "bt709" to indicate a capability for BT.709 colour primaries and matrix coefficients, and/or "bt2020" to indicate a capability for BT.2020 non-constant luminance colour primaries and matrix coefficients. ... At least one video_display_format element shall be present for each frame rate family (50 Hz or 60 Hz) that the terminal uses for video display. ... If the signal path from the video decoder to the display involves the use of different resolutions, frame rates, bit depths, or colorimetry, the values used in the video_display_format elements shall reflect the most constraining values. | -HAS_DISPLAY +HEVC_UHD | ||
| org.hbbtv_VIDEO-DISPLAY0110 | 1 | Display capability reporting when a connected display supports a maximum resolution of 1920x1080 | When an HbbTV application reads the XML capabilities document, it contains at least one video_display_format element whose @width attribute is 1920, @height is 1080, @frame_rate is 50 or a multiple thereof, @bit_depth is 10 or greater, and contains no video_display_format element with a value of @width that is higher than 1920 or a value of @height that is higher than 1080 in combination with a @bit_depth attribute with value 10. | 2024-1 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 10.2.4: Terminals that can decode UHD video shall include one or more elements of the following form to describe the highest quality video formats that can be displayed: <video_display_format width="w" height="h" frame_rate="f" bit_depth="b" colorimetry="c-list"/> where w, h, f and b are integer values such that video content that complies with the requirements of the present document and has a combination of resolution, frame rate and bit depth that do not exceed the values indicated can be expected to be reproduced on the display without loss of resolution, frame rate or bit depth, and where c-list is a list of strings defining the colour primaries and matrix coefficients that are supported with these values. c-list may include "bt709" to indicate a capability for BT.709 colour primaries and matrix coefficients, and/or "bt2020" to indicate a capability for BT.2020 non-constant luminance colour primaries and matrix coefficients. ... At least one video_display_format element shall be present for each frame rate family (50 Hz or 60 Hz) that the terminal uses for video display. ... If the signal path from the video decoder to the display involves the use of different resolutions, frame rates, bit depths, or colorimetry, the values used in the video_display_format elements shall reflect the most constraining values. | -HAS_DISPLAY +HEVC_UHD | ||
| org.hbbtv_VIDEO-DISPLAY0120 | 1 | Display capability reporting and content playback when a connected display supports BT.2020 | When an HbbTV application reads the XML capabilities document, it contains at least one video_display_format element whose @width attribute is 1920 or greater, @height is 1080 or greater, @frame_rate is 50 or a multiple thereof, @bit_depth is 10 or greater and @colorimetry includes the string "bt2020", and when a stream defined by a static DASH MPD containing 1920x1080p50 Main10 10-bit HEVC BT.2020 video containing coloured areas that fall within the BT.2020 colour gamut but which do not fall within the BT.709 colour gamut is played using an HTML5 video element, then the HDMI colorimetry signalling indicates BT.2020. | 2024-1 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 10.2.4: Terminals that can decode UHD video shall include one or more elements of the following form to describe the highest quality video formats that can be displayed: <video_display_format width="w" height="h" frame_rate="f" bit_depth="b" colorimetry="c-list"/> where w, h, f and b are integer values such that video content that complies with the requirements of the present document and has a combination of resolution, frame rate and bit depth that do not exceed the values indicated can be expected to be reproduced on the display without loss of resolution, frame rate or bit depth, and where c-list is a list of strings defining the colour primaries and matrix coefficients that are supported with these values. c-list may include "bt709" to indicate a capability for BT.709 colour primaries and matrix coefficients, and/or "bt2020" to indicate a capability for BT.2020 non-constant luminance colour primaries and matrix coefficients. ... If the signal path from the video decoder to the display involves the use of different resolutions, frame rates, bit depths, or colorimetry, the values used in the video_display_format elements shall reflect the most constraining values. 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.14: For the purposes of this clause, a player is considered to support ITU-R BT.2020 colour if one or more of the following is true: * A BT.2020 picture is passed over an HDMI connection operating with BT.2020 colorimetry to an HDMI Sink that indicates support for BT.2020. * A BT.2020 picture is colour space converted prior to passing over an HDMI connection operating with different colorimetry. | -HAS_DISPLAY +HEVC_UHD | ||
| org.hbbtv_VIDEO-DISPLAY0130 | 1 | Display capability reporting when a connected display does not support BT.2020 | When an HbbTV application reads the XML capabilities document, it does not contain any video_display_format element whose @colorimetry attribute includes the string "bt2020". | 2024-1 2023-3 2023-2 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 10.2.4: Terminals that can decode UHD video shall include one or more elements of the following form to describe the highest quality video formats that can be displayed: <video_display_format width="w" height="h" frame_rate="f" bit_depth="b" colorimetry="c-list"/> where w, h, f and b are integer values such that video content that complies with the requirements of the present document and has a combination of resolution, frame rate and bit depth that do not exceed the values indicated can be expected to be reproduced on the display without loss of resolution, frame rate or bit depth, and where c-list is a list of strings defining the colour primaries and matrix coefficients that are supported with these values. c-list may include "bt709" to indicate a capability for BT.709 colour primaries and matrix coefficients, and/or "bt2020" to indicate a capability for BT.2020 non-constant luminance colour primaries and matrix coefficients. ... If the signal path from the video decoder to the display involves the use of different resolutions, frame rates, bit depths, or colorimetry, the values used in the video_display_format elements shall reflect the most constraining values. | -HAS_DISPLAY +HEVC_UHD | ||
| org.hbbtv_VIS0010 | 1 | visibilitychange events on hiding - basic | The user invokes a terminal user interface or application that either (i) fully covers the running HbbTV application such that no part of it is visible or (ii) removes the running HbbTV application from the screen. If the application continues to run then: The application is sent a visibilitychange event with document.visibilityState='hidden' and when the terminal user interface or application is dismissed or terminated it is sent a visibilitychange event with document.visibilityState='visible'. | 2024-1 | HBBTV 1.7.1 | 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 ... A visibilitychange event shall be sent when an HbbTV application that was previously hidden becomes visible again. PAGE-VISIBILITY,section 6: When the user agent determines that the visibility of the Document of the top-level browsing context has changed, the user agent MUST run the following steps: ... Fire an event named "visibilitychange" that bubbles, isn't cancelable, and has no default action, at the doc. PAGE-VISIBILITY,section 4: 4. VisibilityState enum WebIDLenum VisibilityState { "hidden", "visible" }; The VisibilityState enum is used to represent the visibility states. The "hidden" enum value represents the hidden visibility state. Likewise, the "visible" enum value represents the visible visibility state. PAGE-VISIBILITY,section 5: 5. Extensions to the Document interface This specification extends the Document interface: WebIDLpartial interface Document { readonly attribute boolean hidden; readonly attribute VisibilityState visibilityState; attribute EventHandler onvisibilitychange; }; | |||
| org.hbbtv_VIS0030 | 1 | visibilitychange events when application survives standby | An application is arranged to receive periodic events. The terminal is placed in a standby mode. If the application continues to run then: A visibilitychange event with document.visibilityState='hidden' is sent to the application and when the terminal is brought out of standby approximately 15 seconds later either (i) all expected periodic events and a visibilitychange event with document.visibilityState='visible' have been sent to the application or (ii) a 'freeze' event, a 'resume' event and a visibilitychange event with document.visibilityState='visible' have been sent to the application. | 2024-1 | HBBTV 1.7.1 | 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) A visibilitychange event shall be sent when an HbbTV application that was previously hidden becomes visible again. ... An application that is hidden should continue to receive events, though it may run with reduced performance. • If the terminal freezes a hidden application such that it does not receive events, the terminal shall implement the Page Lifecycle API [93]. PAGE-LIFECYCLE,section 5.4: 5.4. Page lifecycle processing model 5.4.1. FROZENNESS state A document can be in one of the following FROZENNESS states: true: the document is frozen, any tasks associated with the document will not run false: the document is unfrozen, tasks associated with the document will run as usual ... 5.4.2. Changing the frozenness of documents ... To change the frozenness of a document, given a Document doc, a boolean frozenness state frozenness, and a boolean auto resume frozen media: If frozenness is true, run the freeze steps for doc given auto resume frozen media. Otherwise, run the resume steps given doc. To run the freeze steps for a Document doc, given a boolean auto resume frozen media: ... 2. Fire an event named freeze at doc. ... To run the resume steps for a Document doc: ... 2. Fire an event named resume at doc. PAGE-VISIBILITY,section 6: When the user agent determines that the visibility of the Document of the top-level browsing context has changed, the user agent MUST run the following steps: ... Fire an event named "visibilitychange" that bubbles, isn't cancelable, and has no default action, at the doc. PAGE-VISIBILITY,section 4: 4. VisibilityState enum WebIDLenum VisibilityState { "hidden", "visible" }; The VisibilityState enum is used to represent the visibility states. The "hidden" enum value represents the hidden visibility state. Likewise, the "visible" enum value represents the visible visibility state. PAGE-VISIBILITY,section 5: 5. Extensions to the Document interface This specification extends the Document interface: WebIDLpartial interface Document { readonly attribute boolean hidden; readonly attribute VisibilityState visibilityState; attribute EventHandler onvisibilitychange; }; | |||
| org.hbbtv_VTRANSFORM0020 | 1 | Video CSS transform - 2D downscale and translate | An application is playing video using an HTML5 video element that is positioned at (0,0) with width 1280px and height 720px. CSS "transform: matrix(0.5, 0, 0, 0.5, 320, 180);" is then applied to the video element. The video plays normally, scaled to a quarter of the screen area and positioned in the bottom right hand corner of the screen. | 2024-1 | HBBTV 1.7.1 | HBBTV,section A.3.22: Applying CSS transforms to video elements shall be supported where the transform meets the following constraints: * The transform subjects the video element to pure 2D translation and scaling, i.e. only those combinations of transforms for which the video element's current transformation matrix (see clause 3, "The Transform Rendering Model", of CSS Transforms [] as referenced from the CTA Web Media API Snapshot [76]) is of the form: a 0 0 e 0 d 0 f 0 0 1 0 0 0 0 1 * Scaling factors resulting from the transformation (a and d in the above matrix) fall within the ranges specified in Table 11 "Minimum terminal capabilities". HBBTV,section 10.2.1: Video scaling|... Terminals shall be able to scale video down to 1/4 by 1/4 ... Within these limits, any arbitrary scaling factor shall be allowed. CSSTransforms,section 14: * A 2D 3x2 matrix with six parameters a, b, c, d, e and f is equivalent to the matrix: [ a c 0 e ] [ b d 0 f ] [ 0 0 1 0 ] [ 0 0 0 1 ] | |||
| org.hbbtv_WEBAUDIO0010 | 1 | Audio from memory mixed with broadcast video - PCM | A broadcast-related HbbTV application that is connected to the broadcast of the current channel loads some 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 is either mixed with the broadcast audio or temporarily replaces it. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. | |||
| org.hbbtv_WEBAUDIO0020 | 1 | Audio from memory mixed with broadcast video - MP3 | A broadcast-related HbbTV application that is connected to the broadcast of the current channel loads some 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 is either mixed with the broadcast audio or temporarily replaces it. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: 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. | |||
| org.hbbtv_WEBSTORAGE1000 | 1 | Access to cookies and web storage with navigator.cookieEnabled set to true (Web) | An application loaded via broadband reads navigator.cookieEnabled and confirms it is equal to true. Then it stores information in cookies as well as in local storage persistently. After a power cycle the app restores the information from both storage locations successfully. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.3.20: Activation and deactivation of local persistent storage of cookies and web storage by the user shall be reliably detectable by HbbTV applications through the navigator.cookieEnabled property as defined in the WHATWG living HTML standard [82]. The value returned by navigator.cookieEnabled shall be false if and only if all of the following bullets are true • the terminal supports deactivating local persistent storage of cookies and web storage, • and the user has deactivated local persistent storage of cookies and web storage. Otherwise, navigator.cookieEnabled shall be true. NOTE: Clause 12.1.4 requires that by default persistent storage of cookies and web storage is not deactivated. Local persistent storage of web storage shall be disabled if and only if local persistent storage of cookies is disabled. HBBTV,section 12.1.4: Terminals may offer the user the option to disable persistent storage (cookies, Web Storage) on a per-application or per site basis. While this may improve user privacy, it will likely result in a worse user-experience, for example loss of personalization and inability to remember a user's agreement to a site's terms and conditions. Persistent storage shall not be disabled by default. If the user has disabled persistent storage in this way then either (a) access to the localStorage attribute shall fail with a SecurityError exception or (b) a call to setItem on the localStorage object shall fail with a QuotaExceededError exception as defined in the Web Storage specification as referenced through the OIPF DAE specification [1]. Storage attempts shall not fail silently as a result of user preferences. WHATWG,section 8.9.1.4: The cookieEnabled attribute must return true if the user agent attempts to handle cookies according to HTTP State Management Mechanism, and false if it ignores cookie change requests. | |||
| org.hbbtv_WEBSTORAGE1010 | 1 | Access to web storage with navigator.cookieEnabled set to true (DSMCC) | An application loaded via DSMCC oc reads navigator.cookieEnabled and confirms it is equal to true. Then it stores information in local storage persistently. After a power cycle the app restores that information from local storage successfully. | 2024-1 2023-3 2023-2 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.3.20: Activation and deactivation of local persistent storage of cookies and web storage by the user shall be reliably detectable by HbbTV applications through the navigator.cookieEnabled property as defined in the WHATWG living HTML standard [82]. The value returned by navigator.cookieEnabled shall be false if and only if all of the following bullets are true • the terminal supports deactivating local persistent storage of cookies and web storage, • and the user has deactivated local persistent storage of cookies and web storage. Otherwise, navigator.cookieEnabled shall be true. NOTE: Clause 12.1.4 requires that by default persistent storage of cookies and web storage is not deactivated. Local persistent storage of web storage shall be disabled if and only if local persistent storage of cookies is disabled. HBBTV,section 12.1.4: Terminals may offer the user the option to disable persistent storage (cookies, Web Storage) on a per-application or per site basis. While this may improve user privacy, it will likely result in a worse user-experience, for example loss of personalization and inability to remember a user's agreement to a site's terms and conditions. Persistent storage shall not be disabled by default. If the user has disabled persistent storage in this way then either (a) access to the localStorage attribute shall fail with a SecurityError exception or (b) a call to setItem on the localStorage object shall fail with a QuotaExceededError exception as defined in the Web Storage specification as referenced through the OIPF DAE specification [1]. Storage attempts shall not fail silently as a result of user preferences. HBBTV,section 6.3.2: [...] For resources loaded via DSM-CC object carousel, the origin shall be a URI of the form: "hbbtv-carousel" ":" "//" organisation_id ":" carousel_id [...] This origin shall be used in all cases where a document or resource origin is used in web specifications including but not limited to [...] and with Web Storage. WHATWG,section 8.9.1.4: The cookieEnabled attribute must return true if the user agent attempts to handle cookies according to HTTP State Management Mechanism, and false if it ignores cookie change requests. | |||
| org.hbbtv_WEBSTORAGE1020 | 1 | Access to cookies and web storage with navigator.cookieEnabled set to false | An application loaded via broadband reads navigator.cookieEnabled and confirms it is equal to false. After that it writes information in cookies as well as in local storage. The applications catches either a SecurityError or a QuotaExceededError as a result of writing to localStorage. After a power cycle the app cannot read the information from both storage locations. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 | HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section A.3.20: Activation and deactivation of local persistent storage of cookies and web storage by the user shall be reliably detectable by HbbTV applications through the navigator.cookieEnabled property as defined in the WHATWG living HTML standard [82]. The value returned by navigator.cookieEnabled shall be false if and only if all of the following bullets are true • the terminal supports deactivating local persistent storage of cookies and web storage, • and the user has deactivated local persistent storage of cookies and web storage. Otherwise, navigator.cookieEnabled shall be true. NOTE: Clause 12.1.4 requires that by default persistent storage of cookies and web storage is not deactivated. Local persistent storage of web storage shall be disabled if and only if local persistent storage of cookies is disabled. HBBTV,section 12.1.4: Terminals may offer the user the option to disable persistent storage (cookies, Web Storage) on a per-application or per site basis. While this may improve user privacy, it will likely result in a worse user-experience, for example loss of personalization and inability to remember a user's agreement to a site's terms and conditions. Persistent storage shall not be disabled by default. If the user has disabled persistent storage in this way then either (a) access to the localStorage attribute shall fail with a SecurityError exception or (b) a call to setItem on the localStorage object shall fail with a QuotaExceededError exception as defined in the Web Storage specification as referenced through the OIPF DAE specification [1]. Storage attempts shall not fail silently as a result of user preferences. WHATWG,section 8.9.1.4: The cookieEnabled attribute must return true if the user agent attempts to handle cookies according to HTTP State Management Mechanism, and false if it ignores cookie change requests. | +PERSISTENT_STORAGE_CAN_BE_DISABLED | ||
| tv.oipf_AVC-AAC-003 | 1 | Audio From Memory - HE-AAC | The terminal shall correctly decode memory audio encoded according to HE-AAC | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 8: ... MPEG-4 AAC or HE-AAC [AAC] (audio format label: HEAAC) is the preferred audio codec for A/V content and is the mandatory audio content format. Decoding support for HE-AAC is a mandatory minimum OITF capability with regard to A/V media formats ... OIPF-Media-Formats,section 8.1.1: AAC, HE-AAC and HE-AAC v2 audio coding SHALL be in accordance with [AAC], which contains the audio object types AAC LC, SBR and PS. Its use is constrained according to [TS101154] clause 6.4. Either the MPEG-4 AAC Profile, the MPEG-4 HE-AAC Profile or the MPEG-4 HE-AACv2 Profile SHALL be used ... HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | |||
| tv.oipf_AVC-AAC-004-001 | 1 | 5.1 multi-channel audio output on S/PDIF | The terminal shall correctly output 5.1 multi-channel HE-AAC audio on an S/PDIF output | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 8.2.4: For stereo output interfaces, 5.1 surround audio streams SHALL be down-mixed to stereo. For digital outputs (e.g. S/PDIF [SPDIF] or HDMI) one of the following conversions MAY be used: OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5 [...] The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | +SPDIF | ||
| tv.oipf_AVC-AAC-004-002 | 1 | 5.1 multi-channel audio with DRC parameters output on S/PDIF | The terminal shall correctly output 5.1 multi-channel HE-AAC audio (containing Dynamic Range Control parameters and specified prog_ref_level) on an S/PDIF output | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 8.2.4: For stereo output interfaces, 5.1 surround audio streams SHALL be down-mixed to stereo. For digital outputs (e.g. S/PDIF [SPDIF] or HDMI) one of the following conversions MAY be used: OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5 [...] The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | +SPDIF | ||
| tv.oipf_AVC-AAC-004-003 | 2 | 5.1 multi-channel audio with DRC parameters and prog_ref_level unspecified output on S/PDIF | The terminal shall correctly output 5.1 multi-channel HE-AAC audio (containing Dynamic Range Control parameters and prog_ref_level not specified) on an S/PDIF output | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 8.2.4: For stereo output interfaces, 5.1 surround audio streams SHALL be down-mixed to stereo. For digital outputs (e.g. S/PDIF [SPDIF] or HDMI) one of the following conversions MAY be used: OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5 [...] The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. TS-101-154,section 6.4.3: The MPEG-4 AAC Dynamic Range Control (DRC) tool is defined in ISO/IEC 14496-3 [17], clause 4.5.2.7. For more detailed information on the MPEG-4 AAC Dynamic Range Control tool see ISO/IEC 14496-3 [17]. [...] HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | +SPDIF | ||
| tv.oipf_AVC-AAC-005-001 | 2 | HE-AAC downmixing - matrix coefficient = 0 | The terminal shall downmix audio when down-mix parameters are present in the HE-AAC metadata with the matrix coefficient set to 0 | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5, Down-mix parameters as defined in [AAC] section 4.5.1.2.2 or [TS101154] Annex C.5. The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | |||
| tv.oipf_AVC-AAC-005-002 | 2 | HE-AAC downmixing - matrix coefficient = 1 | The terminal shall downmix audio when down-mix parameters are present in the HE-AAC metadata with the matrix coefficient set to 1 | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5, Down-mix parameters as defined in [AAC] section 4.5.1.2.2 or [TS101154] Annex C.5. The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | |||
| tv.oipf_AVC-AAC-005-003 | 2 | HE-AAC downmixing - matrix coefficient = 2 | The terminal shall downmix audio when down-mix parameters are present in the HE-AAC metadata with the matrix coefficient set to 2 | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5, Down-mix parameters as defined in [AAC] section 4.5.1.2.2 or [TS101154] Annex C.5. The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | |||
| tv.oipf_AVC-AAC-005-004 | 2 | HE-AAC downmixing - matrix coefficient = 3 | The terminal shall downmix audio when down-mix parameters are present in the HE-AAC metadata with the matrix coefficient set to 3 | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5, Down-mix parameters as defined in [AAC] section 4.5.1.2.2 or [TS101154] Annex C.5. The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. ISO/IEC-14496-3,section 4.5.1.2.2.2: A derived stereo signal can be generated within a matrix-mixdown decoder by use of one of the two following sets of equations. [...] Where L, C, R, LS and RS are the source signals, L’ and R’ are the derived stereo signals and A is the matrix coefficient indicated by matrix_mixdown_idx. LFE channels are omitted from the mixdown. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | ||
| tv.oipf_AVC-AAC-005-005 | 2 | HE-AAC downmixing - center_mix_level = 0 dB (000), surround_mix_level = 0 dB (000) | The terminal shall downmix audio when down-mix parameters are present in the HE-AAC metadata with center mix and surround mix channels enabled and their corresponding sound levels both set to 0 dB | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5, Down-mix parameters as defined in [AAC] section 4.5.1.2.2 or [TS101154] Annex C.5. The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | |||
| tv.oipf_AVC-AAC-005-006 | 2 | HE-AAC downmixing - center_mix_level = -3 dB (010), surround_mix_level = -3 dB (010) | The terminal shall downmix audio when down-mix parameters are present in the HE-AAC metadata with center mix and surround mix channels enabled and their corresponding sound levels both set to -3 dB | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5, Down-mix parameters as defined in [AAC] section 4.5.1.2.2 or [TS101154] Annex C.5. The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | |||
| tv.oipf_AVC-AAC-005-007 | 2 | HE-AAC downmixing - center_mix_level = -6 dB (100), surround_mix_level = -6 dB (100) | The terminal shall downmix audio when down-mix parameters are present in the HE-AAC metadata with center mix and surround mix channels enabled and their corresponding sound levels both set to -6 dB | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5, Down-mix parameters as defined in [AAC] section 4.5.1.2.2 or [TS101154] Annex C.5. The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | |||
| tv.oipf_AVC-AAC-005-008 | 2 | HE-AAC downmixing - center_mix_level = -6 dB (100), surround_mix_level = -4.5 dB (011) | The terminal shall downmix audio when down-mix parameters are present in the HE-AAC metadata with center mix and surround mix channels enabled and their corresponding sound levels set to -6 dB and -4.5 dB respectively | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5, Down-mix parameters as defined in [AAC] section 4.5.1.2.2 or [TS101154] Annex C.5. The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | |||
| tv.oipf_AVC-AAC-005-009 | 2 | HE-AAC downmixing - center_mix_level = -3 dB (010), surround_mix_level = -7.5 dB (101) | The terminal shall downmix audio when down-mix parameters are present in the HE-AAC metadata with center mix and surround mix channels enabled and their corresponding sound levels set to -3 dB and -7.5 dB respectively | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5, Down-mix parameters as defined in [AAC] section 4.5.1.2.2 or [TS101154] Annex C.5. The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | |||
| tv.oipf_AVC-AAC-005-010 | 2 | HE-AAC downmixing - center_mix_level = -infinity dB (111), surround_mix_level -infinity dB (111) | The terminal shall downmix audio when down-mix parameters are present in the HE-AAC metadata with center mix and surround mix channels enabled and their corresponding sound levels both set to -infinity dB | 2024-1 2023-3 2023-2 2023-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-Media-Formats,section 8.1.1.3: HEAAC format audio MAY contain metadata as specified in [AAC] or [TS101154], specifically: Dynamic Range Control parameters as defined in [AAC] section 4.5.2.7 or [TS101154] section 6.4.3 and Annex C.5, Down-mix parameters as defined in [AAC] section 4.5.1.2.2 or [TS101154] Annex C.5. The Dynamic Range Control metadata SHALL be used, if present in the encoded audio data. For stereo output of 5.1 surround audio streams, the down-mix parameters SHALL be used, if present in the encoded audio data. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | +HAS_SPEAKER | ||
| tv.oipf_AVC-AC3-001 | 1 | Decode AC-3 audio from an MPEG-2 transport stream | Terminal shall decode AC-3 audio from an MPEG-2 transport stream | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 8: MPEG-1 Audio Layer II [MPEG1] (audio format label: MPEG1_L2) or AC-3 (Dolby Digital) [AC3] (audio format label: AC3) MAY be used when appropriate, for example when legacy equipment or content in that format has already been deployed, or due to regulatory or contractual considerations. OIPF-Media-Formats,section 8.1.2: AC-3 audio coding SHALL be compliant with [AC3], constrained according to [TS101154] clause 6.2, with the following additional constraints: AC-3 audio streams shall be encoded at a sample rate of 48 kHz. This format corresponds to the audio format label AC3. HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | +EAC3 | ||
| tv.oipf_AVC-CPT-001-001 | 1 | DVB subtitles | Terminal shall correctly present DVB formatted subtitle information encoded in an MPEG-2 transport stream which also contains standard definition video encoded according to H.264/AVC | 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 | The challenge exists but not validated | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | OIPF-Media-Formats,section 6: Subtitle content MAY be provided with any IPTV service OIPF-Media-Formats,section 6.1: Either of the following subtitle formats SHALL be used in an IPTV service: Based on DVB subtitles [DVBSUBT] and EBU Teletext [DVBTTXT] ... HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | ||
| tv.oipf_AVC-CPT-001-002 | 1 | DVB subtitles (HD) | Terminal shall correctly present DVB formatted subtitle information encoded in an MPEG-2 transport stream which also contains high definition video encoded according to H.264/AVC | 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 | OIPF-Media-Formats,section 6: Subtitle content MAY be provided with any IPTV service OIPF-Media-Formats,section 6.1: Either of the following subtitle formats SHALL be used in an IPTV service: Based on DVB subtitles [DVBSUBT] and EBU Teletext [DVBTTXT] ... HBBTV,section 7.3.1.1: The system formats and their labels are specified in the OIPF Media Formats specification [2] with the restrictions in clause 7.3.1.2. [...] | |||
| tv.oipf_AVC-GIF-001-001 | 2 | Image rendering - GIF - 20 x 20 px | Terminal shall correctly render a 20 x 20 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-001-002 | 2 | Image rendering - GIF - 40 x 20 px | Terminal shall correctly render a 40 x 20 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-001-003 | 2 | Image rendering - GIF - 20 x 40 px | Terminal shall correctly render a 20 x 40 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-001-004 | 2 | Image rendering - GIF - 40 x 40 px | Terminal shall correctly render a 40 x 40 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-001-005 | 2 | Image rendering - GIF - 347 x 131 px | Terminal shall correctly render a 347 x 131 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-001-006 | 2 | Image rendering - GIF - 640 x 50 px | Terminal shall correctly render a 640 x 50 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-001-007 | 2 | Image rendering - GIF - 50 x 480 px | Terminal shall correctly render a 50 x 480 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-001-008 | 2 | Image rendering - GIF - 320 x 240 px | Terminal shall correctly render a 320 x 240 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-001-009 | 2 | Image rendering - GIF - 240 x 320 px | Terminal shall correctly render a 240 x 320 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-001-010 | 2 | Image rendering - GIF - 640 x 480 px | Terminal shall correctly render a 640 x 480 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-001-011 | 2 | Image rendering - GIF (Animated) - 50 x 50 px | Terminal shall correctly render an animated 50 x 50 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-001-012 | 2 | Image rendering - GIF (Transparent) - 50 x 50 px | Terminal shall correctly render a 50 x 50 px GIF image that contains transparent pixels | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-GIF-002 | 2 | Image rendering - GIF - 720 x 576 px | Terminal shall correctly render a 720 x 576 px GIF image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.2: This format corresponds to the graphics format label GIF. The mime type of "image/gif" SHALL be used for compliant GIF images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-JPG-001-001 | 2 | Image rendering - JPEG - 20 x 20 px | Terminal shall correctly render a 20 x 20 px JPEG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.1: This format corresponds to the graphics format label JPEG. The mime type of "image/jpeg" SHALL be used for compliant JPEG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-JPG-001-002 | 2 | Image rendering - JPEG - 40 x 20 px | Terminal shall correctly render a 40 x 20 px JPEG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.1: This format corresponds to the graphics format label JPEG. The mime type of "image/jpeg" SHALL be used for compliant JPEG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-JPG-001-003 | 2 | Image rendering - JPEG - 20 x 40 px | Terminal shall correctly render a 20 x 40 px JPEG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.1: This format corresponds to the graphics format label JPEG. The mime type of "image/jpeg" SHALL be used for compliant JPEG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-JPG-001-004 | 2 | Image rendering - JPEG - 40 x 40 px | Terminal shall correctly render a 40 x 40 px JPEG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.1: This format corresponds to the graphics format label JPEG. The mime type of "image/jpeg" SHALL be used for compliant JPEG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-JPG-001-005 | 2 | Image rendering - JPEG - 347 x 131 px | Terminal shall correctly render a 347 x 131 px JPEG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.1: This format corresponds to the graphics format label JPEG. The mime type of "image/jpeg" SHALL be used for compliant JPEG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-JPG-001-006 | 2 | Image rendering - JPEG - 640 x 50 px | Terminal shall correctly render a 640 x 50 px JPEG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.1: This format corresponds to the graphics format label JPEG. The mime type of "image/jpeg" SHALL be used for compliant JPEG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-JPG-001-007 | 2 | Image rendering - JPEG - 50 x 480 px | Terminal shall correctly render a 50 x 480 px JPEG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.1: This format corresponds to the graphics format label JPEG. The mime type of "image/jpeg" SHALL be used for compliant JPEG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-JPG-001-008 | 2 | Image rendering - JPEG - 320 x 240 px | Terminal shall correctly render a 320 x 240 px JPEG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.1: This format corresponds to the graphics format label JPEG. The mime type of "image/jpeg" SHALL be used for compliant JPEG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-JPG-001-009 | 2 | Image rendering - JPEG - 240 x 320 px | Terminal shall correctly render a 240 x 320 px JPEG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.1: This format corresponds to the graphics format label JPEG. The mime type of "image/jpeg" SHALL be used for compliant JPEG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-JPG-001-010 | 2 | Image rendering - JPEG - 640 x 480 px | Terminal shall correctly render a 640 x 480 px JPEG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.1: This format corresponds to the graphics format label JPEG. The mime type of "image/jpeg" SHALL be used for compliant JPEG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-JPG-002 | 2 | Image rendering - JPEG - 720 x 576 px | Terminal shall correctly render a 720 x 576 px JPEG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.1: This format corresponds to the graphics format label JPEG. The mime type of "image/jpeg" SHALL be used for compliant JPEG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-PNG-001-001 | 2 | Image rendering - PNG - 20 x 20 px | Terminal shall correctly render a 20 x 20 px PNG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.3: This format corresponds to the graphics format label PNG. The mime type of "image/png" SHALL be used for compliant PNG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-PNG-001-002 | 2 | Image rendering - PNG - 40 x 20 px | Terminal shall correctly render a 40 x 20 px PNG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.3: This format corresponds to the graphics format label PNG. The mime type of "image/png" SHALL be used for compliant PNG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-PNG-001-003 | 2 | Image rendering - PNG - 20 x 40 px | Terminal shall correctly render a 20 x 40 px PNG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.3: This format corresponds to the graphics format label PNG. The mime type of "image/png" SHALL be used for compliant PNG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-PNG-001-004 | 2 | Image rendering - PNG - 40 x 40 px | Terminal shall correctly render a 40 x 40 px PNG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.3: This format corresponds to the graphics format label PNG. The mime type of "image/png" SHALL be used for compliant PNG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-PNG-001-005 | 2 | Image rendering - PNG - 347 x 131 px | Terminal shall correctly render a 347 x 131 px PNG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.3: This format corresponds to the graphics format label PNG. The mime type of "image/png" SHALL be used for compliant PNG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-PNG-001-006 | 2 | Image rendering - PNG - 640 x 50 px | Terminal shall correctly render a 640 x 50 px PNG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.3: This format corresponds to the graphics format label PNG. The mime type of "image/png" SHALL be used for compliant PNG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-PNG-001-007 | 2 | Image rendering - PNG - 50 x 480 px | Terminal shall correctly render a 50 x 480 px PNG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.3: This format corresponds to the graphics format label PNG. The mime type of "image/png" SHALL be used for compliant PNG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-PNG-001-008 | 2 | Image rendering - PNG - 320 x 240 px | Terminal shall correctly render a 320 x 240 px PNG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.3: This format corresponds to the graphics format label PNG. The mime type of "image/png" SHALL be used for compliant PNG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-PNG-001-009 | 2 | Image rendering - PNG - 240 x 320 px | Terminal shall correctly render a 240 x 320 px PNG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.3: This format corresponds to the graphics format label PNG. The mime type of "image/png" SHALL be used for compliant PNG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-PNG-001-010 | 2 | Image rendering - PNG - 640 x 480 px | Terminal shall correctly render a 640 x 480 px PNG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.3: This format corresponds to the graphics format label PNG. The mime type of "image/png" SHALL be used for compliant PNG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_AVC-PNG-002 | 2 | Image rendering - PNG - 720 x 576 px | Terminal shall correctly render a 720 x 576 px PNG image | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: The present volume just notes the labels applied to the used formats - JPEG [JFIF], GIF [GIF] and PNG [PNG]. OIPF-Media-Formats,section 9.1.3: This format corresponds to the graphics format label PNG. The mime type of "image/png" SHALL be used for compliant PNG images. HBBTV,section 7.1.1: The graphics formats used shall comply with clause 9.1 of the OIPF media formats specification [2]. [...] | |||
| tv.oipf_CSP-CSPG-CIPLUS-002-001 | 1 | Signalling of CSPG-CI+ support using CEA-2014 capability negotiation and extensions with no CI+ CAM inserted | With no CI+ CAM inserted in the terminal, the CEA-2014 capabilities shall not contain a 'drm' element with 'ci+' in the 'protectionGateways' attribute in the 'ext' element of the 'ui_profile' element and the video_profile element for MPEG2-TS shall not contain any CSPG-CI+ DRMSystemID attribute values. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section 10.2.4: The support of CI+ shall be indicated using the <drm> element defined in Annex F of the OIPF DAE specification [1] and providing the protectionGateways attribute with "ci+" string OIPF-DAE,section 9.3.10: The OITF SHALL indicate support for handling DRM-protected content through the base profile and UI profile name fragment strings as defined in section 9.2 "Default UI Profiles" and the 'drm' element defined in Annex F [...] 'drm' - indicates whether or not the client supports a DRM content protection system for downloading and streaming content [...] attribute "DRMSystemID" SHALL include a supported DRM system. Valid values [are defined] in Table 6 of [META] [...this attribute] SHALL be specified in the case that the DRM System indicated by the "DRMSystemID" attribute is supported by the CSP Gateway. Valid values for the scheme for the Gateway centric approach defined by [CSP] are "dtcp-ip" and 'ci+'. OIPF-DAE,section 9.3.11: The video_profile and audio_profile elements SHALL support a new attribute called "DRMSystemID" [which] SHALL correspond to a drm element (as defined in section 9.3.10 [...]) with the same value for attribute "DRMSystemID". OIPF-CSP,section 4.2.1: DAE SHALL signal which CA_System_ID values [MPEG2TS] and optionally the type of CSP Gateway are supported in the OITF including those available via Gateway-Centric Approach as defined in section 9 of [DAE] document. OIPF-CSP,section 4.2.3.10.1: For CSPG-CI+, the DVB CA_System_ID in DRMSystemID SHALL be the one of the specific content protection solution in the CSPG-CI+. | |||
| tv.oipf_CSP-CSPG-CIPLUS-002-002 | 1 | Signalling of CSPG-CI+ support using CEA-2014 capability negotiation and extensions following successful CSPG-CI+ discovery | Following successful CSPG-CI+ discovery, the CEA-2014 capabilities shall contain three 'drm' elements each with 'ci+' in the 'protectionGateways' attribute in the 'ext' element of the 'ui_profile' element and a unique 'DRMSystemID' attribute corresponding to the CAM supported ca_system_id values (4096, 4097, 4098). The media profile capability indication video_profile for MPEG2-TS shall include a DRMSystemID attribute with value 'urn:dvb:casystemid:4096'. | 2024-1 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,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section 10.2.4: The support of CI+ shall be indicated using the <drm> element defined in Annex F of the OIPF DAE specification [1] and providing the protectionGateways attribute with "ci+" string OIPF-DAE,section 9.3.10: The OITF SHALL indicate support for handling DRM-protected content through the base profile and UI profile name fragment strings as defined in section 9.2 "Default UI Profiles" and the 'drm' element defined in Annex F [...] 'drm' - indicates whether or not the client supports a DRM content protection system for downloading and streaming content [...] attribute "DRMSystemID" SHALL include a supported DRM system. Valid values [are defined] in Table 6 of [META] [...this attribute] SHALL be specified in the case that the DRM System indicated by the "DRMSystemID" attribute is supported by the CSP Gateway. Valid values for the scheme for the Gateway centric approach defined by [CSP] are "dtcp-ip" and "ci+". OIPF-DAE,section 9.3.11: The video_profile and audio_profile elements SHALL support a new attribute called "DRMSystemID" [which] SHALL correspond to a drm element (as defined in section 9.3.10 [...]) with the same value for attribute "DRMSystemID". OIPF-CSP,section 4.2.1: DAE SHALL signal which CA_System_ID values [MPEG2TS] and optionally the type of CSP Gateway are supported in the OITF including those available via Gateway-Centric Approach as defined in section 9 of [DAE] document. OIPF-CSP,section 4.2.3.10.1: For CSPG-CI+, the DVB CA_System_ID in DRMSystemID SHALL be the one of the specific content protection solution in the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-002-003 | 2 | Signalling of CSPG-CI+ support using CEA-2014 capability negotiation and extensions following unsuccessful CSPG-CI+ discovery | Following unsuccessful CSPG-CI+ discovery (CAM inserted without CI+ support), the CEA-2014 capabilities shall not contain a 'drm' element with 'ci+' in the 'protectionGateways' attribute in the 'ext' element of the 'ui_profile' element. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section 10.2.4: The support of CI+ shall be indicated using the <drm> element defined in Annex F of the OIPF DAE specification [1] and providing the protectionGateways attribute with "ci+" string OIPF-DAE,section 9.3.10: The OITF SHALL indicate support for handling DRM-protected content through the base profile and UI profile name fragment strings as defined in section 9.2 "Default UI Profiles" and the 'drm' element defined in Annex F [...] 'drm' - indicates whether or not the client supports a DRM content protection system for downloading and streaming content [...] attribute "DRMSystemID" SHALL include a supported DRM system. Valid values [are defined] in Table 6 of [META] [...this attribute] SHALL be specified in the case that the DRM System indicated by the "DRMSystemID" attribute is supported by the CSP Gateway. Valid values for the scheme for the Gateway centric approach defined by [CSP] are "dtcp-ip" and "ci+". OIPF-DAE,section 9.3.11: The video_profile and audio_profile elements SHALL support a new attribute called "DRMSystemID" [which] SHALL correspond to a drm element (as defined in section 9.3.10 [...]) with the same value for attribute "DRMSystemID". | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-007-001 | 2 | Correct DRMMessageResult event sent (0x00) when a 'reply_msg' with an oipf_status of 0x00 "Successful" is received from the CICAM | When the CICAM sends a 'reply_msg' with an oipf_status of 0x00 "Successful" and an empty oipf_ca_vendor_specific_information string, a 'DRMMessageResult' event shall be dispatched with the 'resultCode' property set to 0x00 "Successful", the 'resultMsg' property set to an empty string and the 'msgID' property matching the value returned by the call to sendDRMMessage. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-DAE,section 7.6.1.1: function onDRMMessageResult [...] The function that is called when the underlying DRM agent has a result message to report to the current HTML document as a consequence of a call to sendDRMMessage [...] OIPF-DAE,section 7.6.1.2: String sendDRMMessage [...] Send message to DRM agent, using a message type as defined by the DRM system [...] Applications will be notified of the results of the operation via events dispatched to onDRMMessageResult and corresponding DOM level 2 events. OIPF-CSP,section 4.2.3.4.1: HNI-CSP is an interface to exchange control information and media between the CSPG-CI+ and the OITF. OIPF-CSP,section 4.2.3.4.1.1: OITF controls the CSPG-CI+ using resources defined in [DVB-CI] as well as resources as defined in section 11 of [CI+]. OITF and CSPG-CI+ SHALL use the SAS resource, defined in [CI+] section 11.4, to handle messages as specified in this section. ... any further exchanges between the OITF and the CSPG-CI+ are completed through the use of the SAS_async_msg() APDU. Syntax of this APDU is reminded in... OIPF-CSP,section 4.2.2: When a DAE application uses the DRM Agent API and event, sendDRMMessage and onDRMMessageResult, defined in [DAE] section 7.6.1, to handle a DRM Message (see section 7.6.1 in [DAE]) for a given CA_System_ID that is supported by a CSPG, the OITF SHALL forward these messages to the appropriate function, CSP or CSPG. OIPF-CSP,section 4.2.3.4.1.1.1: The OITF and CSPG-CI+ SHALL support the messages listed [...] send_msg (with) command_id value 0x01 [...] reply_msg (with) command_id value 0x02 OIPF-CSP,section 4.2.3.4.1.1.2: Mapping of messages to DAE API or Events: The OITF SHALL map the specific messages listed [...] to DAE API or Events as described [...] The DRMSystemID attribute in DAE API or Events are mapped to the ca_system_id field in the SAS_async_msg APDU. OIPF-CSP,section 4.2.3.4.1.1.3: send_msg: A native application or DAE application SHOULD use the send_msg message to provide DRM specific messages to the CSPG-CI+. When requested by either a native or DAE application, the OITF SHALL send the send_msg message to the CSPG-CI+ to exchange DRM messages. The data types for the send_msg message are [...] oipf_ca_vendor_specific_information When a DAE application calls the sendDRMMessage API with msgType set to the MIME type "application/vnd.oipf.cspg-hexbinary" and a DRMSystemId set to a ca system id supported by the CSPG-CI+, the OITF SHALL send a send_msg message to the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-007-002 | 2 | Correct DRMMessageResult event sent (0x00) when a 'reply_msg' with an oipf_status of 0x00 "Successful" and oipf_ca_vendor_specific_information present is received from the CICAM | When the CICAM sends a 'reply_msg' with an oipf_status of 0x00 "Successful" and oipf_ca_vendor_specific_information "TEST_RESPONSE", a 'DRMMessageResult' event shall be dispatched with the 'resultCode' property set to 0x00 "Successful", the 'resultMsg' property set to "TEST_RESPONSE" and the 'msgID' property matching the value returned by the call to sendDRMMessage. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-DAE,section 7.6.1.1: function onDRMMessageResult [...] The function that is called when the underlying DRM agent has a result message to report to the current HTML document as a consequence of a call to sendDRMMessage [...] OIPF-DAE,section 7.6.1.2: String sendDRMMessage [...] Send message to DRM agent, using a message type as defined by the DRM system [...] Applications will be notified of the results of the operation via events dispatched to onDRMMessageResult and corresponding DOM level 2 events. OIPF-CSP,section 4.2.3.4.1: HNI-CSP is an interface to exchange control information and media between the CSPG-CI+ and the OITF. OIPF-CSP,section 4.2.3.4.1.1: OITF controls the CSPG-CI+ using resources defined in [DVB-CI] as well as resources as defined in section 11 of [CI+]. OITF and CSPG-CI+ SHALL use the SAS resource, defined in [CI+] section 11.4, to handle messages as specified in this section. ... any further exchanges between the OITF and the CSPG-CI+ are completed through the use of the SAS_async_msg() APDU. Syntax of this APDU is reminded in... OIPF-CSP,section 4.2.2: When a DAE application uses the DRM Agent API and event, sendDRMMessage and onDRMMessageResult, defined in [DAE] section 7.6.1, to handle a DRM Message (see section 7.6.1 in [DAE]) for a given CA_System_ID that is supported by a CSPG, the OITF SHALL forward these messages to the appropriate function, CSP or CSPG. OIPF-CSP,section 4.2.3.4.1.1.1: The OITF and CSPG-CI+ SHALL support the messages listed [...] send_msg (with) command_id value 0x01 [...] reply_msg (with) command_id value 0x02 OIPF-CSP,section 4.2.3.4.1.1.2: Mapping of messages to DAE API or Events: The OITF SHALL map the specific messages listed [...] to DAE API or Events as described [...] The DRMSystemID attribute in DAE API or Events are mapped to the ca_system_id field in the SAS_async_msg APDU. OIPF-CSP,section 4.2.3.4.1.1.3: send_msg: A native application or DAE application SHOULD use the send_msg message to provide DRM specific messages to the CSPG-CI+. When requested by either a native or DAE application, the OITF SHALL send the send_msg message to the CSPG-CI+ to exchange DRM messages. The data types for the send_msg message are [...] oipf_ca_vendor_specific_information When a DAE application calls the sendDRMMessage API with msgType set to the MIME type "application/vnd.oipf.cspg-hexbinary" and a DRMSystemId set to a ca system id supported by the CSPG-CI+, the OITF SHALL send a send_msg message to the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-007-003 | 2 | Correct DRMMessageResult event sent (0x01) when a 'reply_msg' with an oipf_status of 0x01 "Unspecified error" and oipf_ca_vendor_specific_information present is received from the CICAM | When the CICAM sends a 'reply_msg' with an oipf_status of 0x01 "Unspecified error" and oipf_ca_vendor_specific_information "TEST_RESPONSE", a 'DRMMessageResult' event shall be dispatched with the 'resultCode' property set to 0x01 "Unknown error", the 'resultMsg' property set to "TEST_RESPONSE" and the 'msgID' property matching the value returned by the call to sendDRMMessage. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-DAE,section 7.6.1.1: function onDRMMessageResult [...] The function that is called when the underlying DRM agent has a result message to report to the current HTML document as a consequence of a call to sendDRMMessage [...] OIPF-DAE,section 7.6.1.2: String sendDRMMessage [...] Send message to DRM agent, using a message type as defined by the DRM system [...] Applications will be notified of the results of the operation via events dispatched to onDRMMessageResult and corresponding DOM level 2 events. OIPF-CSP,section 4.2.3.4.1: HNI-CSP is an interface to exchange control information and media between the CSPG-CI+ and the OITF. OIPF-CSP,section 4.2.3.4.1.1: OITF controls the CSPG-CI+ using resources defined in [DVB-CI] as well as resources as defined in section 11 of [CI+]. OITF and CSPG-CI+ SHALL use the SAS resource, defined in [CI+] section 11.4, to handle messages as specified in this section. ... any further exchanges between the OITF and the CSPG-CI+ are completed through the use of the SAS_async_msg() APDU. Syntax of this APDU is reminded in... OIPF-CSP,section 4.2.2: When a DAE application uses the DRM Agent API and event, sendDRMMessage and onDRMMessageResult, defined in [DAE] section 7.6.1, to handle a DRM Message (see section 7.6.1 in [DAE]) for a given CA_System_ID that is supported by a CSPG, the OITF SHALL forward these messages to the appropriate function, CSP or CSPG. OIPF-CSP,section 4.2.3.4.1.1.1: The OITF and CSPG-CI+ SHALL support the messages listed [...] send_msg (with) command_id value 0x01 [...] reply_msg (with) command_id value 0x02 OIPF-CSP,section 4.2.3.4.1.1.2: Mapping of messages to DAE API or Events: The OITF SHALL map the specific messages listed [...] to DAE API or Events as described [...] The DRMSystemID attribute in DAE API or Events are mapped to the ca_system_id field in the SAS_async_msg APDU. OIPF-CSP,section 4.2.3.4.1.1.3: send_msg: A native application or DAE application SHOULD use the send_msg message to provide DRM specific messages to the CSPG-CI+. When requested by either a native or DAE application, the OITF SHALL send the send_msg message to the CSPG-CI+ to exchange DRM messages. The data types for the send_msg message are [...] oipf_ca_vendor_specific_information When a DAE application calls the sendDRMMessage API with msgType set to the MIME type "application/vnd.oipf.cspg-hexbinary" and a DRMSystemId set to a ca system id supported by the CSPG-CI+, the OITF SHALL send a send_msg message to the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-007-004 | 2 | Correct DRMMessageResult event sent (0x02) when a 'reply_msg' with an oipf_status of 0x02 "Out of time" is received from the CICAM | When the CICAM sends a 'reply_msg' with an oipf_status of 0x02 "Out of time" and an empty oipf_ca_vendor_specific_information string, a 'DRMMessageResult' event shall be dispatched with the 'resultCode' property set to 0x02 "Cannot process request", the 'resultMsg' property set to an empty string and the 'msgID' property matching the value returned by the call to sendDRMMessage. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-DAE,section 7.6.1.1: function onDRMMessageResult [...] The function that is called when the underlying DRM agent has a result message to report to the current HTML document as a consequence of a call to sendDRMMessage [...] OIPF-DAE,section 7.6.1.2: String sendDRMMessage [...] Send message to DRM agent, using a message type as defined by the DRM system [...] Applications will be notified of the results of the operation via events dispatched to onDRMMessageResult and corresponding DOM level 2 events. OIPF-CSP,section 4.2.3.4.1: HNI-CSP is an interface to exchange control information and media between the CSPG-CI+ and the OITF. OIPF-CSP,section 4.2.3.4.1.1: OITF controls the CSPG-CI+ using resources defined in [DVB-CI] as well as resources as defined in section 11 of [CI+]. OITF and CSPG-CI+ SHALL use the SAS resource, defined in [CI+] section 11.4, to handle messages as specified in this section. ... any further exchanges between the OITF and the CSPG-CI+ are completed through the use of the SAS_async_msg() APDU. Syntax of this APDU is reminded in... OIPF-CSP,section 4.2.2: When a DAE application uses the DRM Agent API and event, sendDRMMessage and onDRMMessageResult, defined in [DAE] section 7.6.1, to handle a DRM Message (see section 7.6.1 in [DAE]) for a given CA_System_ID that is supported by a CSPG, the OITF SHALL forward these messages to the appropriate function, CSP or CSPG. OIPF-CSP,section 4.2.3.4.1.1.1: The OITF and CSPG-CI+ SHALL support the messages listed [...] send_msg (with) command_id value 0x01 [...] reply_msg (with) command_id value 0x02 OIPF-CSP,section 4.2.3.4.1.1.2: Mapping of messages to DAE API or Events: The OITF SHALL map the specific messages listed [...] to DAE API or Events as described [...] The DRMSystemID attribute in DAE API or Events are mapped to the ca_system_id field in the SAS_async_msg APDU. OIPF-CSP,section 4.2.3.4.1.1.3: send_msg: A native application or DAE application SHOULD use the send_msg message to provide DRM specific messages to the CSPG-CI+. When requested by either a native or DAE application, the OITF SHALL send the send_msg message to the CSPG-CI+ to exchange DRM messages. The data types for the send_msg message are [...] oipf_ca_vendor_specific_information When a DAE application calls the sendDRMMessage API with msgType set to the MIME type "application/vnd.oipf.cspg-hexbinary" and a DRMSystemId set to a ca system id supported by the CSPG-CI+, the OITF SHALL send a send_msg message to the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-007-005 | 2 | Correct DRMMessageResult event sent (0x03) and send_msg not sent when a sendDRMMessage is attempted with an unknown MIME type | When a sendDRMMessage is attempted with an unknown MIME type, a 'DRMMessageResult' event shall be dispatched with the 'resultCode' property set to 0x03 "Unknown MIME type" and the 'msgID' property matching the value returned by the call to sendDRMMessage, and a send_msg message shall not be sent by the terminal. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-DAE,section 7.6.1.1: function onDRMMessageResult [...] The function that is called when the underlying DRM agent has a result message to report to the current HTML document as a consequence of a call to sendDRMMessage [...] OIPF-DAE,section 7.6.1.2: String sendDRMMessage [...] Send message to DRM agent, using a message type as defined by the DRM system [...] Applications will be notified of the results of the operation via events dispatched to onDRMMessageResult and corresponding DOM level 2 events. OIPF-CSP,section 4.2.3.4.1: HNI-CSP is an interface to exchange control information and media between the CSPG-CI+ and the OITF. OIPF-CSP,section 4.2.3.4.1.1: OITF controls the CSPG-CI+ using resources defined in [DVB-CI] as well as resources as defined in section 11 of [CI+]. OITF and CSPG-CI+ SHALL use the SAS resource, defined in [CI+] section 11.4, to handle messages as specified in this section. ... any further exchanges between the OITF and the CSPG-CI+ are completed through the use of the SAS_async_msg() APDU. Syntax of this APDU is reminded in... OIPF-CSP,section 4.2.2: When a DAE application uses the DRM Agent API and event, sendDRMMessage and onDRMMessageResult, defined in [DAE] section 7.6.1, to handle a DRM Message (see section 7.6.1 in [DAE]) for a given CA_System_ID that is supported by a CSPG, the OITF SHALL forward these messages to the appropriate function, CSP or CSPG. OIPF-CSP,section 4.2.3.4.1.1.1: The OITF and CSPG-CI+ SHALL support the messages listed [...] send_msg (with) command_id value 0x01 [...] reply_msg (with) command_id value 0x02 OIPF-CSP,section 4.2.3.4.1.1.2: Mapping of messages to DAE API or Events: The OITF SHALL map the specific messages listed [...] to DAE API or Events as described [...] The DRMSystemID attribute in DAE API or Events are mapped to the ca_system_id field in the SAS_async_msg APDU. OIPF-CSP,section 4.2.3.4.1.1.3: send_msg: A native application or DAE application SHOULD use the send_msg message to provide DRM specific messages to the CSPG-CI+. When requested by either a native or DAE application, the OITF SHALL send the send_msg message to the CSPG-CI+ to exchange DRM messages. The data types for the send_msg message are [...] oipf_ca_vendor_specific_information When a DAE application calls the sendDRMMessage API with msgType set to the MIME type "application/vnd.oipf.cspg-hexbinary" and a DRMSystemId set to a ca system id supported by the CSPG-CI+, the OITF SHALL send a send_msg message to the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-007-006 | 2 | Correct DRMMessageResult event sent (0x04) when a 'reply_msg' with an oipf_status of 0x04 "User consent needed" is received from the CICAM | When the CICAM sends a 'reply_msg' with an oipf_status of 0x04 "User consent needed" and an empty oipf_ca_vendor_specific_information string, a 'DRMMessageResult' event shall be dispatched with the 'resultCode' property set to 0x04 "User consent needed" and the 'resultMsg' property set to an empty string, and the 'msgID' property matching the value returned by the call to sendDRMMessage. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-DAE,section 7.6.1.1: function onDRMMessageResult [...] The function that is called when the underlying DRM agent has a result message to report to the current HTML document as a consequence of a call to sendDRMMessage [...] OIPF-DAE,section 7.6.1.2: String sendDRMMessage [...] Send message to DRM agent, using a message type as defined by the DRM system [...] Applications will be notified of the results of the operation via events dispatched to onDRMMessageResult and corresponding DOM level 2 events. OIPF-CSP,section 4.2.3.4.1: HNI-CSP is an interface to exchange control information and media between the CSPG-CI+ and the OITF. OIPF-CSP,section 4.2.3.4.1.1: OITF controls the CSPG-CI+ using resources defined in [DVB-CI] as well as resources as defined in section 11 of [CI+]. OITF and CSPG-CI+ SHALL use the SAS resource, defined in [CI+] section 11.4, to handle messages as specified in this section. ... any further exchanges between the OITF and the CSPG-CI+ are completed through the use of the SAS_async_msg() APDU. Syntax of this APDU is reminded in... OIPF-CSP,section 4.2.2: When a DAE application uses the DRM Agent API and event, sendDRMMessage and onDRMMessageResult, defined in [DAE] section 7.6.1, to handle a DRM Message (see section 7.6.1 in [DAE]) for a given CA_System_ID that is supported by a CSPG, the OITF SHALL forward these messages to the appropriate function, CSP or CSPG. OIPF-CSP,section 4.2.3.4.1.1.1: The OITF and CSPG-CI+ SHALL support the messages listed [...] send_msg (with) command_id value 0x01 [...] reply_msg (with) command_id value 0x02 OIPF-CSP,section 4.2.3.4.1.1.2: Mapping of messages to DAE API or Events: The OITF SHALL map the specific messages listed [...] to DAE API or Events as described [...] The DRMSystemID attribute in DAE API or Events are mapped to the ca_system_id field in the SAS_async_msg APDU. OIPF-CSP,section 4.2.3.4.1.1.3: send_msg: A native application or DAE application SHOULD use the send_msg message to provide DRM specific messages to the CSPG-CI+. When requested by either a native or DAE application, the OITF SHALL send the send_msg message to the CSPG-CI+ to exchange DRM messages. The data types for the send_msg message are [...] oipf_ca_vendor_specific_information When a DAE application calls the sendDRMMessage API with msgType set to the MIME type "application/vnd.oipf.cspg-hexbinary" and a DRMSystemId set to a ca system id supported by the CSPG-CI+, the OITF SHALL send a send_msg message to the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-007-007 | 2 | Correct DRMMessageResult event sent (0x05) when a 'reply_msg' with an oipf_status of 0x05 "Unknown DRM system" is received from the CICAM | When the CICAM sends a 'reply_msg' with an oipf_status of 0x05 "Unknown DRM system" and an empty oipf_ca_vendor_specific_information string, a 'DRMMessageResult' event shall be dispatched with the 'resultCode' property set to 0x05 "Unknown DRM system", the 'resultMsg' property set to an empty string, and the 'msgID' property matching the value returned by the call to sendDRMMessage. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-DAE,section 7.6.1.1: function onDRMMessageResult [...] The function that is called when the underlying DRM agent has a result message to report to the current HTML document as a consequence of a call to sendDRMMessage [...] OIPF-DAE,section 7.6.1.2: String sendDRMMessage [...] Send message to DRM agent, using a message type as defined by the DRM system [...] Applications will be notified of the results of the operation via events dispatched to onDRMMessageResult and corresponding DOM level 2 events. OIPF-CSP,section 4.2.3.4.1: HNI-CSP is an interface to exchange control information and media between the CSPG-CI+ and the OITF. OIPF-CSP,section 4.2.3.4.1.1: OITF controls the CSPG-CI+ using resources defined in [DVB-CI] as well as resources as defined in section 11 of [CI+]. OITF and CSPG-CI+ SHALL use the SAS resource, defined in [CI+] section 11.4, to handle messages as specified in this section. ... any further exchanges between the OITF and the CSPG-CI+ are completed through the use of the SAS_async_msg() APDU. Syntax of this APDU is reminded in... OIPF-CSP,section 4.2.2: When a DAE application uses the DRM Agent API and event, sendDRMMessage and onDRMMessageResult, defined in [DAE] section 7.6.1, to handle a DRM Message (see section 7.6.1 in [DAE]) for a given CA_System_ID that is supported by a CSPG, the OITF SHALL forward these messages to the appropriate function, CSP or CSPG. OIPF-CSP,section 4.2.3.4.1.1.1: The OITF and CSPG-CI+ SHALL support the messages listed [...] send_msg (with) command_id value 0x01 [...] reply_msg (with) command_id value 0x02 OIPF-CSP,section 4.2.3.4.1.1.2: Mapping of messages to DAE API or Events: The OITF SHALL map the specific messages listed [...] to DAE API or Events as described [...] The DRMSystemID attribute in DAE API or Events are mapped to the ca_system_id field in the SAS_async_msg APDU. OIPF-CSP,section 4.2.3.4.1.1.3: send_msg: A native application or DAE application SHOULD use the send_msg message to provide DRM specific messages to the CSPG-CI+. When requested by either a native or DAE application, the OITF SHALL send the send_msg message to the CSPG-CI+ to exchange DRM messages. The data types for the send_msg message are [...] oipf_ca_vendor_specific_information When a DAE application calls the sendDRMMessage API with msgType set to the MIME type "application/vnd.oipf.cspg-hexbinary" and a DRMSystemId set to a ca system id supported by the CSPG-CI+, the OITF SHALL send a send_msg message to the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-007-008 | 2 | Correct DRMMessageResult event sent (0x05) and send_msg not sent when a sendDRMMessage is attempted with a non matching DRMSystemId | When a sendDRMMessage is attempted with a non matching ca_system_id, a 'DRMMessageResult' event shall be dispatched with the 'resultCode' property set to 0x05 "Unknown DRM system", 'msgID' property matching the value returned by the call to sendDRMMessage, and a send_msg message shall not be sent by the terminal. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-DAE,section 7.6.1.1: function onDRMMessageResult [...] The function that is called when the underlying DRM agent has a result message to report to the current HTML document as a consequence of a call to sendDRMMessage [...] OIPF-DAE,section 7.6.1.2: String sendDRMMessage [...] Send message to DRM agent, using a message type as defined by the DRM system [...] Applications will be notified of the results of the operation via events dispatched to onDRMMessageResult and corresponding DOM level 2 events. OIPF-CSP,section 4.2.3.4.1: HNI-CSP is an interface to exchange control information and media between the CSPG-CI+ and the OITF. OIPF-CSP,section 4.2.3.4.1.1: OITF controls the CSPG-CI+ using resources defined in [DVB-CI] as well as resources as defined in section 11 of [CI+]. OITF and CSPG-CI+ SHALL use the SAS resource, defined in [CI+] section 11.4, to handle messages as specified in this section. ... any further exchanges between the OITF and the CSPG-CI+ are completed through the use of the SAS_async_msg() APDU. Syntax of this APDU is reminded in... OIPF-CSP,section 4.2.2: When a DAE application uses the DRM Agent API and event, sendDRMMessage and onDRMMessageResult, defined in [DAE] section 7.6.1, to handle a DRM Message (see section 7.6.1 in [DAE]) for a given CA_System_ID that is supported by a CSPG, the OITF SHALL forward these messages to the appropriate function, CSP or CSPG. OIPF-CSP,section 4.2.3.4.1.1.1: The OITF and CSPG-CI+ SHALL support the messages listed [...] send_msg (with) command_id value 0x01 [...] reply_msg (with) command_id value 0x02 OIPF-CSP,section 4.2.3.4.1.1.2: Mapping of messages to DAE API or Events: The OITF SHALL map the specific messages listed [...] to DAE API or Events as described [...] The DRMSystemID attribute in DAE API or Events are mapped to the ca_system_id field in the SAS_async_msg APDU. OIPF-CSP,section 4.2.3.4.1.1.3: send_msg: A native application or DAE application SHOULD use the send_msg message to provide DRM specific messages to the CSPG-CI+. When requested by either a native or DAE application, the OITF SHALL send the send_msg message to the CSPG-CI+ to exchange DRM messages. The data types for the send_msg message are [...] oipf_ca_vendor_specific_information When a DAE application calls the sendDRMMessage API with msgType set to the MIME type "application/vnd.oipf.cspg-hexbinary" and a DRMSystemId set to a ca system id supported by the CSPG-CI+, the OITF SHALL send a send_msg message to the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-007-009 | 2 | Correct DRMMessageResult event sent (0x06) when a 'reply_msg' with an oipf_status of 0x03 "Wrong format" is received from the CICAM | When the CICAM sends a 'reply_msg' with an oipf_status of 0x03 "Wrong format" and an empty oipf_ca_vendor_specific_information string, a 'DRMMessageResult' event shall be dispatched with the 'resultCode' property set to 0x06 "Wrong format", the 'resultMsg' property set to an empty string, and the 'msgID' property matching the value returned by the call to sendDRMMessage. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-DAE,section 7.6.1.1: function onDRMMessageResult [...] The function that is called when the underlying DRM agent has a result message to report to the current HTML document as a consequence of a call to sendDRMMessage [...] OIPF-DAE,section 7.6.1.2: String sendDRMMessage [...] Send message to DRM agent, using a message type as defined by the DRM system [...] Applications will be notified of the results of the operation via events dispatched to onDRMMessageResult and corresponding DOM level 2 events. OIPF-CSP,section 4.2.3.4.1: HNI-CSP is an interface to exchange control information and media between the CSPG-CI+ and the OITF. OIPF-CSP,section 4.2.3.4.1.1: OITF controls the CSPG-CI+ using resources defined in [DVB-CI] as well as resources as defined in section 11 of [CI+]. OITF and CSPG-CI+ SHALL use the SAS resource, defined in [CI+] section 11.4, to handle messages as specified in this section. ... any further exchanges between the OITF and the CSPG-CI+ are completed through the use of the SAS_async_msg() APDU. Syntax of this APDU is reminded in... OIPF-CSP,section 4.2.2: When a DAE application uses the DRM Agent API and event, sendDRMMessage and onDRMMessageResult, defined in [DAE] section 7.6.1, to handle a DRM Message (see section 7.6.1 in [DAE]) for a given CA_System_ID that is supported by a CSPG, the OITF SHALL forward these messages to the appropriate function, CSP or CSPG. OIPF-CSP,section 4.2.3.4.1.1.1: The OITF and CSPG-CI+ SHALL support the messages listed [...] send_msg (with) command_id value 0x01 [...] reply_msg (with) command_id value 0x02 OIPF-CSP,section 4.2.3.4.1.1.2: Mapping of messages to DAE API or Events: The OITF SHALL map the specific messages listed [...] to DAE API or Events as described [...] The DRMSystemID attribute in DAE API or Events are mapped to the ca_system_id field in the SAS_async_msg APDU. OIPF-CSP,section 4.2.3.4.1.1.3: send_msg: A native application or DAE application SHOULD use the send_msg message to provide DRM specific messages to the CSPG-CI+. When requested by either a native or DAE application, the OITF SHALL send the send_msg message to the CSPG-CI+ to exchange DRM messages. The data types for the send_msg message are [...] oipf_ca_vendor_specific_information When a DAE application calls the sendDRMMessage API with msgType set to the MIME type "application/vnd.oipf.cspg-hexbinary" and a DRMSystemId set to a ca system id supported by the CSPG-CI+, the OITF SHALL send a send_msg message to the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-007-010 | 2 | 'send_msg' is sent to CICAM when sendDRMMessage is called with an empty 'msg' | When sendDRMMessage is called with msgType set to application/vnd.oipf.cspg-hexbinary, an empty 'msg' and DRMSystemId set to "urn:dvb:casystemid:4096", a 'send_msg' shall be sent to the CICAM with a ca_system_id of 4096 and an empty oipf_ca_vendor_specific_information string. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-DAE,section 7.6.1.1: function onDRMMessageResult [...] The function that is called when the underlying DRM agent has a result message to report to the current HTML document as a consequence of a call to sendDRMMessage [...] OIPF-DAE,section 7.6.1.2: String sendDRMMessage [...] Send message to DRM agent, using a message type as defined by the DRM system [...] Applications will be notified of the results of the operation via events dispatched to onDRMMessageResult and corresponding DOM level 2 events. OIPF-CSP,section 4.2.3.4.1: HNI-CSP is an interface to exchange control information and media between the CSPG-CI+ and the OITF. OIPF-CSP,section 4.2.3.4.1.1: OITF controls the CSPG-CI+ using resources defined in [DVB-CI] as well as resources as defined in section 11 of [CI+]. OITF and CSPG-CI+ SHALL use the SAS resource, defined in [CI+] section 11.4, to handle messages as specified in this section. ... any further exchanges between the OITF and the CSPG-CI+ are completed through the use of the SAS_async_msg() APDU. Syntax of this APDU is reminded in... OIPF-CSP,section 4.2.2: When a DAE application uses the DRM Agent API and event, sendDRMMessage and onDRMMessageResult, defined in [DAE] section 7.6.1, to handle a DRM Message (see section 7.6.1 in [DAE]) for a given CA_System_ID that is supported by a CSPG, the OITF SHALL forward these messages to the appropriate function, CSP or CSPG. OIPF-CSP,section 4.2.3.4.1.1.1: The OITF and CSPG-CI+ SHALL support the messages listed [...] send_msg (with) command_id value 0x01 [...] reply_msg (with) command_id value 0x02 OIPF-CSP,section 4.2.3.4.1.1.2: Mapping of messages to DAE API or Events: The OITF SHALL map the specific messages listed [...] to DAE API or Events as described [...] The DRMSystemID attribute in DAE API or Events are mapped to the ca_system_id field in the SAS_async_msg APDU. OIPF-CSP,section 4.2.3.4.1.1.3: send_msg: A native application or DAE application SHOULD use the send_msg message to provide DRM specific messages to the CSPG-CI+. When requested by either a native or DAE application, the OITF SHALL send the send_msg message to the CSPG-CI+ to exchange DRM messages. The data types for the send_msg message are [...] oipf_ca_vendor_specific_information When a DAE application calls the sendDRMMessage API with msgType set to the MIME type "application/vnd.oipf.cspg-hexbinary" and a DRMSystemId set to a ca system id supported by the CSPG-CI+, the OITF SHALL send a send_msg message to the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-007-011 | 2 | 'send_msg' is sent to CICAM when sendDRMMessage is called with 'msg' data present | When sendDRMMessage is called with msgType set to application/vnd.oipf.cspg-hexbinary, 'msg' set to "TEST_REQUEST" and DRMSystemId set to "urn:dvb:casystemid:4096", a 'send_msg' shall be sent to the CICAM with a ca_system_id of 4096 and an oipf_ca_vendor_specific_information string "TEST_REQUEST". | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-DAE,section 7.6.1.1: function onDRMMessageResult [...] The function that is called when the underlying DRM agent has a result message to report to the current HTML document as a consequence of a call to sendDRMMessage [...] OIPF-DAE,section 7.6.1.2: String sendDRMMessage [...] Send message to DRM agent, using a message type as defined by the DRM system [...] Applications will be notified of the results of the operation via events dispatched to onDRMMessageResult and corresponding DOM level 2 events. OIPF-CSP,section 4.2.3.4.1: HNI-CSP is an interface to exchange control information and media between the CSPG-CI+ and the OITF. OIPF-CSP,section 4.2.3.4.1.1: OITF controls the CSPG-CI+ using resources defined in [DVB-CI] as well as resources as defined in section 11 of [CI+]. OITF and CSPG-CI+ SHALL use the SAS resource, defined in [CI+] section 11.4, to handle messages as specified in this section. ... any further exchanges between the OITF and the CSPG-CI+ are completed through the use of the SAS_async_msg() APDU. Syntax of this APDU is reminded in... OIPF-CSP,section 4.2.2: When a DAE application uses the DRM Agent API and event, sendDRMMessage and onDRMMessageResult, defined in [DAE] section 7.6.1, to handle a DRM Message (see section 7.6.1 in [DAE]) for a given CA_System_ID that is supported by a CSPG, the OITF SHALL forward these messages to the appropriate function, CSP or CSPG. OIPF-CSP,section 4.2.3.4.1.1.1: The OITF and CSPG-CI+ SHALL support the messages listed [...] send_msg (with) command_id value 0x01 [...] reply_msg (with) command_id value 0x02 OIPF-CSP,section 4.2.3.4.1.1.2: Mapping of messages to DAE API or Events: The OITF SHALL map the specific messages listed [...] to DAE API or Events as described [...] The DRMSystemID attribute in DAE API or Events are mapped to the ca_system_id field in the SAS_async_msg APDU. OIPF-CSP,section 4.2.3.4.1.1.3: send_msg: A native application or DAE application SHOULD use the send_msg message to provide DRM specific messages to the CSPG-CI+. When requested by either a native or DAE application, the OITF SHALL send the send_msg message to the CSPG-CI+ to exchange DRM messages. The data types for the send_msg message are [...] oipf_ca_vendor_specific_information When a DAE application calls the sendDRMMessage API with msgType set to the MIME type "application/vnd.oipf.cspg-hexbinary" and a DRMSystemId set to a ca system id supported by the CSPG-CI+, the OITF SHALL send a send_msg message to the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-009-001 | 2 | DRMRightsError handling following a CICAM rights_info message with a null 'oipf-rights_issuer_url', where descrambling is stopped | When the CICAM sends a 'rights_info' message with 'oipf_access_status' 0 ('program not descrambled'), a 'ca_system_id' of 4096 and a null 'oipf_rights_issuer_url', a 'DRMRightsError' event shall be dispatched with errorState 0 ('No license'), 'DRMSystemID' set to 'urn:dvb:casystemid:4096' and undefined 'rightsIssuerURL'. | 2024-1 2023-3 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.6: The CSPG-CI+ SHALL send a rights_info message to advise the OITF that access conditions or rights changed and that the CSPG-CI+ is no longer able or is able again to descramble all requested elementary streams. Once this message is received and if a DAE application is launched, the OITF SHALL send the relevant event onDRMRightsError, as defined in [DAE] sections 7.13.6 and 7.14.7, to the DAE application. If the program is descrambled again, the OITF SHOULD display the program again. If the program is no longer being descrambled, the OITF MAY decide to stop the program and SHOULD use the oipf_rights_issuer_url, which may provide for the CSPG-CI+ information to let it retrieve missing rights. [...] When the right_info message is received and a DAE application is launched, the OITF SHALL issue the onDRMRightsError event to the DAE application. [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, rights update etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. OIPF-CSP,section 4.2.3.10.1: For CSPG-CI+, the DVB CA_System_ID in DRMSystemID SHALL be the one of the specific content protection solution in the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-009-003 | 2 | DRMRightsError handling following a CICAM rights_info message with a null 'oipf-rights_issuer_url', where descrambling is stopped and then re-enabled | When the CICAM sends a 'rights_info' message with 'oipf_access_status' 0 ('program not descrambled') and a null 'oipf-rights_issuer_url'. When the CICAM sends a 'rights_info' with 'oipf_access_status' 1 ('program descrambled'), a 'ca_system_id' of 4096 and an empty 'oipf_rights_issuer_url', a 'DRMRightsError' event shall be dispatched with errorState 2 ('valid license'), 'DRMSystemID' set to 'urn:dvb:casystemid:4096' and an empty 'rightsIssuerURL'. | 2024-1 2023-3 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.6: The CSPG-CI+ SHALL send a rights_info message to advise the OITF that access conditions or rights changed and that the CSPG-CI+ is no longer able or is able again to descramble all requested elementary streams. Once this message is received and if a DAE application is launched, the OITF SHALL send the relevant event onDRMRightsError, as defined in [DAE] sections 7.13.6 and 7.14.7, to the DAE application. If the program is descrambled again, the OITF SHOULD display the program again. If the program is no longer being descrambled, the OITF MAY decide to stop the program and SHOULD use the oipf_rights_issuer_url, which may provide for the CSPG-CI+ information to let it retrieve missing rights. [...] When the right_info message is received and a DAE application is launched, the OITF SHALL issue the onDRMRightsError event to the DAE application. [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, rights update etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. OIPF-CSP,section 4.2.3.10.1: For CSPG-CI+, the DVB CA_System_ID in DRMSystemID SHALL be the one of the specific content protection solution in the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-009-004 | 2 | DRMRightsError handling following a CICAM rights_info message with a valid 'oipf-rights_issuer_url' HTTP URL where descrambling is stopped | When the CICAM sends a 'rights_info' message with 'oipf_access_status' 0 ('program not descrambled'), a 'ca_system_id' of 4096 and 'oipf_rights_issuer_url' set to a valid HTTP URL, a 'DRMRightsError' event shall be dispatched with errorState 0 ('no license'), DRMSystemID set to 'urn:dvb:casystemid:4096' and 'rightsIssuerURL' set to the same valid HTTP URL. | 2024-1 2023-3 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.6: The CSPG-CI+ SHALL send a rights_info message to advise the OITF that access conditions or rights changed and that the CSPG-CI+ is no longer able or is able again to descramble all requested elementary streams. Once this message is received and if a DAE application is launched, the OITF SHALL send the relevant event onDRMRightsError, as defined in [DAE] sections 7.13.6 and 7.14.7, to the DAE application. If the program is descrambled again, the OITF SHOULD display the program again. If the program is no longer being descrambled, the OITF MAY decide to stop the program and SHOULD use the oipf_rights_issuer_url, which may provide for the CSPG-CI+ information to let it retrieve missing rights. [...] When the right_info message is received and a DAE application is launched, the OITF SHALL issue the onDRMRightsError event to the DAE application. [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, rights update etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. OIPF-CSP,section 4.2.3.10.1: For CSPG-CI+, the DVB CA_System_ID in DRMSystemID SHALL be the one of the specific content protection solution in the CSPG-CI+. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-001 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x00 (mandatory DVB parental rating type) and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x00 (mandatory DVB parental rating type), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingChange' event shall be sent with matching parameters and a 'ParentalRatingError' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore. If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-003 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x00 (mandatory DVB parental rating type) and a null 'oipf_parental_control_url' where descrambling is stopped and then re-enabled | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x00 (mandatory DVB parental rating type), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingChange' event shall be sent with matching parameters and a 'ParentalRatingError' event shall not be sent. When the CICAM then sends a 'parental_control_info' message with 'oipf_access_status' 1 (program descrambled), shall send a 'ParentalRatingChange' event with parameters matching the 'parental_control_info' message and shall not send a 'ParentalRatingError' event. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore. If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-004 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x01 (Japanese Motion Picture Parental Rating) and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x01 (Japanese Motion Picture Parental Rating), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingChange' event shall be sent with matching parameters and a 'ParentalRatingError' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-005 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x02 (Internet Content Rating Association Parental Rating) and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x02 (Internet Content Rating Association Parental Rating), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingChange' event shall be sent with matching parameters and a 'ParentalRatingError' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-006 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x03 (MPAA Parental Rating) and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x03 (MPAA Parental Rating), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingChange' event shall be sent with matching parameters and a 'ParentalRatingError' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-007 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x04 (Internet Content Rating Association Parental Rating for Nudity) and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x04 (Internet Content Rating Association Parental Rating for Nudity), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingChange' event shall be sent with matching parameters and a 'ParentalRatingError' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-008 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x05 (RIAA Parental Rating) and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x05 (RIAA Parental Rating), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingChange' event shall be sent with matching parameters and a 'ParentalRatingError' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-009 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x06 (Internet Content Rating Association Parental Rating for Sex) and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x06 (Internet Content Rating Association Parental Rating for Sex), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingChange' event shall be sent with matching parameters and a 'ParentalRatingError' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-010 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x07 (MPAA Parental Rating for TV) and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x07 (MPAA Parental Rating for TV), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingChange' event shall be sent with matching parameters and a 'ParentalRatingError' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-011 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x08 (Internet Content Rating Association Parental Rating for Violence) and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x08 (Internet Content Rating Association Parental Rating for Violence), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingChange' event shall be sent with matching parameters and a 'ParentalRatingError' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-012 | 3 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x09 (German Freiwillige Selbstkontrolle der Filmwirtschaft Rating System) and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x09 (German Freiwillige Selbstkontrolle der Filmwirtschaft Rating System), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingChange' event shall be sent with matching parameters and a 'ParentalRatingError' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-013 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x01 (Japanese Motion Picture Parental Rating) that is unsupported by the terminal and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x01 (Japanese Motion Picture Parental Rating), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingError' event shall be sent with matching parameters and a 'ParentalRatingChange' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-014 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x02 (Internet Content Rating Association Parental Rating) that is unsupported by the terminal and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x02 (Internet Content Rating Association Parental Rating), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingError' event shall be sent with matching parameters and a 'ParentalRatingChange' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-015 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x03 (MPAA Parental Rating) that is unsupported by the terminal and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x03 (MPAA Parental Rating), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingError' event shall be sent with matching parameters and a 'ParentalRatingChange' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-016 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x04 (Internet Content Rating Association Parental Rating for Nudity) that is unsupported by the terminal and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x04 (Internet Content Rating Association Parental Rating for Nudity), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingError' event shall be sent with matching parameters and a 'ParentalRatingChange' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-017 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x05 (RIAA Parental Rating) that is unsupported by the terminal and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x05 (RIAA Parental Rating), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingError' event shall be sent with matching parameters and a 'ParentalRatingChange' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-018 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x06 (Internet Content Rating Association Parental Rating for Sex) that is unsupported by the terminal and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x06 (Internet Content Rating Association Parental Rating for Sex), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingError' event shall be sent with matching parameters and a 'ParentalRatingChange' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-019 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x07 (MPAA Parental Rating for TV) that is unsupported by the terminal and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x07 (MPAA Parental Rating for TV), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingError' event shall be sent with matching parameters and a 'ParentalRatingChange' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-020 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x08 (Internet Content Rating Association Parental Rating for Violence) that is unsupported by the terminal and a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x08 (Internet Content Rating Association Parental Rating for Violence), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingError' event shall be sent with matching parameters and a 'ParentalRatingChange' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_CSP-CSPG-CIPLUS-011-021 | 2 | Management of parental_control_info message sent by the CICAM with oipf_rating_type 0x09 (German Freiwillige Selbstkontrolle der Filmwirtschaft Rating System) that is unsupported by the terminal with a null 'oipf_parental_control_url' where descrambling is stopped | When the CICAM sends a 'parental_control_info' message with 'oipf_rating_type' 0x09 (German Freiwillige Selbstkontrolle der Filmwirtschaft Rating System), 'oipf_access_status' 0 (program not descrambled) and a null 'oipf_parental_control_url', a 'ParentalRatingError' event shall be sent with matching parameters and a 'ParentalRatingChange' event shall not be sent. | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 2018-3 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | HBBTV,section 11.4.1: Terminals supporting CI+ shall support the following mapping from the application/oipfDrmAgent embedded object to the CI+ protocol as defined by clause 4.2.3 "CI+ based Gateway" of the OIPF CSP specification HBBTV,section A.3.1: Clause 4.2.3.4.1.1.5 of the OIPF CSP specification is revised as shown; If the program is no longer being descrambled (oipf_access_status=0), the native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). OIPF-CSP,section 4.2.2: [...] When protected content is used (played, time-shifted, recorded) from a DAE application, the OITF SHALL forward events (no rights or parental control locking) from the CSPG to the DAE application via the A/V or video/broadcast object. The DRM events onDRMRightsError, onParentalRatingChange and onParentalRatingError are defined in [DAE] sections 7.13.5, 7.13.6, 7.14.5 and 7.14.6. The DRM events (No rights or Parental Control) SHALL include the CA_System_ID information. OIPF-CSP,section 4.2.3.4.1.1.5: The CSPG-CI+ SHALL send a parental_control_info message to advise the OITF whenever the selected program's rating changes. If the new rating does not meet the parental rating criterion (e.g. rating is at or above a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is not descrambled anymore . If the new rating meets the parental rating criterion (e.g. rating is under a certain threshold, for a rating system that is ordered from lower viewer age to higher viewer age), the program is descrambled again. The data types for the parental_control_info message are listed in the following table. [...] The OITF SHALL support at least the parental rating system identified by the oipf_rating_type 0x00, which maps to the parental rating system in DVB Systems [EN300468]. If an oipf_parental_control_url is provided and the event is raised to a native application, the native application SHOULD launch the DAE with the oipf_parental_control_url that might allow to unlock parental control in the CSPGCI+[...] The OITF SHALL set the attributes of the issued event as follows: [...] If the program is no longer being descrambled (oipf_access_status=0), the OITF SHALL blank the video decoder output. The native or DAE application SHOULD not stop playing the program, as the program may become descrambled again later (access criteria change, parental unlocking etc). If the program being played is descrambled again (oipf_access_status=1), the OITF SHALL display the video again. | +CI_PLUS | ||
| tv.oipf_DAE-APP_MGMT-002 | 1 | getOwnerApplication() method of application/oipfApplicationManager | The getOwnerApplication() method shall be available on the application/oipfApplicationManager object | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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: Applications Management APIs OIPF-DAE,section 7.2.1.3: Application getOwnerApplication( Document document ). Description | Get the application that the specified document is part of. If the document is not part of an application, or the calling application does not have permission to access that application, this method will return null. Arguments | document | The document for which the Application object should be obtained. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-APP_MGMT-010 | 1 | A/V Control object audio is silenced when destroyApplication() is called | An A/V Control object's associated audio shall no longer be audible after destroyApplication() has been called on the owner Application object | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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: Applications Management APIs. An OITF providing DAE application capability SHALL implement the behaviour of the classes defined in this section. OIPF-DAE,section 7.2.2.2: void destroyApplication(). Terminate the application, detach it from the application tree, and make any resources used available to other applications. When an application is terminated, any child applications shall also be terminated. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-APP_MGMT-013 | 2 | Application only receives registered key set events | When a keyset is registered to the application using the setValue() method of the Keyset object, only key events for registered keys shall be sent to the currently focused DOM Window object | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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: Applications Management APIs OIPF-DAE,section 7.2.5.3: Integer setValue( Integer value, Integer otherKeys[] ). | Description | Sets the value of the keyset which this DAE application requests to receive ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-CAPABILITY-003-001 | 1 | HD output supports HD graphics with HD video | Terminal shall support 1280x720 graphics on its HD output while a HD video is being decoded | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: OITFs with an HD output SHALL support 1280x720 graphics on that output when HD video is being decoded or when no video is being decoded. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-CAPABILITY-005 | 3 | PNG / A/V Control object - Per-pixel alpha | The terminal shall correctly apply alpha compositing, when a PNG image with fully-transparent pixels is positioned on top of a playing video | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 9.1: Minimum DAE capability requirements ... The present document does not define requirements for pixel depth in the graphics system except that OITFs SHALL support at least one bit of per-pixel alpha. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-CE_HTML_DEV-040-001 | 2 | A/V Control object - play() - Unsupported A/V Format | When calling play() on the A/V Control object, if all of the tracks in the MP4 file are unsupported, the A/V Control object shall dispatch a PlayStateChange event, its 'playState' property shall be set to 6 (ERROR) and its 'error' property shall be equal to 0 (A/V format not supported), 2 (unidentified error) or 4 (content corrupt or invalid). | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-DAE,section B: Requirement 5.7.1.f bullet 5) 'error' SHALL be modified as follows; 5) Number error [R] - error details; only significant if the value of playState equals 6: [...] 0 - A/V format not supported [...] 2 - unidentified error [...] 4 - content corrupt or invalid. [...] OIPF-DAE,section 7.14.1: Table 9: readonly Number error; 0 - A/V format not supported. [...] 2 - unidentified error. [...] 4 - content corrupt or invalid [...] HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-CE_HTML_DEV-040-002 | 2 | A/V Control object - play() - Content Corrupt or Invalid | When calling play() on the A/V Control object, if the file specified by the 'data' attribute of the A/V Control object does not have a valid MP4 header, the A/V Control object shall dispatch a PlayStateChange event with its 'state' context equal to 6 (ERROR) and its 'error' context equal to 0 (A/V format not supported), 2 (unidentified error) or 4 (content corrupt or invalid). | 2024-1 2023-3 2023-2 2018-1 | HBBTV 1.4.1 HBBTV 1.5.1 HBBTV 1.6.1 HBBTV 1.7.1 | OIPF-DAE,section B: Requirement 5.7.1.f bullet 5) 'error' SHALL be modified as follows; 5) Number error [R] - error details; only significant if the value of playState equals 6: [...] 0 - A/V format not supported [...] 2 - unidentified error [...] 4 - content corrupt or invalid. [...] OIPF-DAE,section 7.14.1: Table 9: readonly Number error; 0 - A/V format not supported. [...] 2 - unidentified error. [...] 4 - content corrupt or invalid [...] HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-CE_HTML_DEV-042 | 2 | Seek to play position greater than duration (MP4) | When calling the seek() method on the A/V Control object to seek to a play position greater than the duration of an MP4 video, the A/V Control object shall dispatch a 'PlayPositionChanged' event and the 'playPosition' property of the A/V Control object shall be set to the play position at the moment the seek() method was called (with a tolerance of +/-10 seconds) | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 B: Requirement 5.7.1.f bullet 11) A play position event (see section 7.14.3.2 of the DAE specification) will be generated when the operation has completed, regardless of the success of the operation. If the operation fails, the argument of the event SHALL be set to the previous play position. OIPF-DAE,section 7.14.1: Table 11: Boolean seek(Number pos); A play position event (see section 7.14.3.2 of this specification) will be generated when the operation has completed, regardless of the success of the operation. If the operation fails, the argument of the event SHALL be set to the previous play position. OIPF-DAE,section 7.14.3.2: Intrinsic event: onPlayPositionChanged; Corresponding DOM event: PlayPositionChanged; Bubbles: No; Cancellable: No; Context Info: position. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-CONFIGURATION_SETTING-021 | 2 | Configuration - preferredAudioLanguage | The 'preferredAudioLanguage' property of the Configuration object shall contain a comma separated set of valid language codes, as defined in ISO 639.2 | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. OIPF-DAE,section 7.3.2.1: String preferredAudioLanguage - A comma-separated set of languages to be used for audio playback, in order of preference. Each language SHALL be indicated by its ISO 639.2 language code as defined in [ISO 639.2]. | |||
| tv.oipf_DAE-CONFIGURATION_SETTING-022-001 | 2 | Configuration - preferredSubtitleLanguage (OIPF 1) | The 'preferredSubtitleLanguage' property of the Configuration object shall contain a comma separated set of valid language codes, as defined in ISO 639.2 (OIPF 1) | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. OIPF-DAE,section 7.3.2.1: String preferredSubtitleLanguage - A comma-separated set of languages to be used for subtitle playback, in order of preference. Each language SHALL be indicated by its ISO 639.2 language code as defined in [ISO 639.2]. | |||
| tv.oipf_DAE-CONFIGURATION_SETTING-023 | 2 | Configuration - preferredUILanguage | The 'preferredUILanguage' property of the Configuration object shall contain a comma separated set of valid language codes, as defined in ISO 639.2 | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. OIPF-DAE,section 7.3.2.1: String preferredUILanguage - A comma-separated set of languages to be used for the user interface of a service, in order of preference. Each language SHALL be indicated by its ISO 639.2 language code as defined in [ISO 639.2]. If present, the HTTP Accept-language header shall contain the same languages as the preferredUILanguage property with the same order of preference. NOTE: The order of preference in the Accept-language header is indicated using the quality factor. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-006-001 | 2 | Audio plays if A/V object is positioned outside of viewport | When an A/V Control object is positioned outside of the DOM viewport and the play() method is called on it with a playSpeed of 1, the associated audio shall still be outputted by the terminal | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media playback APIs. This section specifies several extensions to the audio object and the video object defined in section 5.7.1 of [CEA2014A]. It also contains a subsection (i.e section 7.14.10) that defines the audio playback from memory API. OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects. The visibility of an A/V object SHALL NOT affect its state or its use of scarce resources. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-006-002 | 2 | Audio still plays if an A/V Control object's 'visibility' style attribute is set to 'hidden' | When the 'visibility' style attribute of the A/V Control object is set to 'hidden' and the play() method is called on it with a playSpeed of 1, the associated audio shall still be outputted by the terminal | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media playback APIs. This section specifies several extensions to the audio object and the video object defined in section 5.7.1 of [CEA2014A]. It also contains a subsection (i.e section 7.14.10) that defines the audio playback from memory API. OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects. The visibility of an A/V object SHALL NOT affect its state or its use of scarce resources. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-006-003 | 2 | Audio plays if A/V object's CSS opacity property is set to 0 (fully transparent) | When an A/V Control object CSS opacity property is set to 0 and the play() method is called on it with a playSpeed of 1, the associated audio shall still be outputted by the terminal | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media playback APIs. This section specifies several extensions to the audio object and the video object defined in section 5.7.1 of [CEA2014A]. It also contains a subsection (i.e section 7.14.10) that defines the audio playback from memory API. OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects. The visibility of an A/V object SHALL NOT affect its state or its use of scarce resources. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-006-006 | 2 | A/V Control object obscured by an HTML element does not release its resources | When the A/V Control object is in play state 'playing' and is completely obscured by another fully opaque HTML element with a higher Z-index, it shall continue to present the associated audio | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media playback APIs. This section specifies several extensions to the audio object and the video object defined in section 5.7.1 of [CEA2014A]. It also contains a subsection (i.e section 7.14.10) that defines the audio playback from memory API. OIPF-DAE,section 7.14.1.1: State diagram for A/V control objects. The visibility of an A/V object SHALL NOT affect its state or its use of scarce resources. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-007-001 | 2 | Calling play(0) on A/V Control object in 'buffering' state puts the object into 'paused' state | When a A/V Control object has a playState of 4 (buffering) and the play() method is called on it with its 'speed' argument set to 0, its playState shall change to 2 (paused) | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media playback APIs. This section specifies several extensions to the audio object and the video object defined in section 5.7.1 of [CEA2014A]. It also contains a subsection (i.e section 7.14.10) that defines the audio playback from memory API. OIPF-DAE,section 7.14.1.2: Using an A/V control object to play streaming content. If an A/V control object is used to play streamed content using either RTSP or HTTP the OITF then the following holds: [...] If play(0) is called in the connecting or buffering state, the A/V object SHALL automatically go to play state 2 ('paused'). HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-007-002 | 2 | Calling play(0) on A/V Control object in 'connecting' state puts the object into 'paused' state | When an A/V Control object has a playState of 3 (connecting) and the play() method is called on it with its 'speed' argument set to 0, its playState shall change to 2 (paused) | 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 1.6.1 HBBTV 1.7.1 | OIPF-DAE,section 7.14: Media playback APIs. This section specifies several extensions to the audio object and the video object defined in section 5.7.1 of [CEA2014A]. It also contains a subsection (i.e section 7.14.10) that defines the audio playback from memory API. OIPF-DAE,section 7.14.1.2: Using an A/V control object to play streaming content. If an A/V control object is used to play streamed content using either RTSP or HTTP the OITF then the following holds: [...] If play(0) is called in the connecting or buffering state, the A/V object SHALL automatically go to play state 2 ('paused') HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-007-003 | 2 | Calling play(0) on A/V Control object in 'stopped' state puts the object into 'paused' state | When an A/V Control object has a playState of 0 ('stopped') and the play() method is called on it with its playSpeed parameter set to 0, its playState shall change to 2 ('paused') | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media playback APIs. This section specifies several extensions to the audio object and the video object defined in section 5.7.1 of [CEA2014A]. It also contains a subsection (i.e section 7.14.10) that defines the audio playback from memory API. OIPF-DAE,section 7.14.1.2: Using an A/V control object to play streaming content. If an A/V control object is used to play streamed content using either RTSP or HTTP the OITF then the following holds: If play(0) is called in state 0 ('stopped'), the A/V object SHALL automatically go to play state 2 ('paused'). The necessary resources are secured and no external signalling is performed. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-008 | 2 | play() method of A/V Control called before sufficient data is available for 'playable_download' acquisition | When a download is initiated using a Content Access Download descriptor with its <TransferType> element set to 'playable_download'; setting the A/V Control object's source to the download and calling play() before sufficient data has been downloaded to initiate playback - shall cause the A/V Control object to go to play state 6 (error) with an error code of 5 (content not available) | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media playback APIs OIPF-DAE,section 7.14.1.3: If an A/V control object is used to play content that has been downloaded and stored on the OITF (by using method setSource() as defined in section 7.14.7) then the following holds: 1. If the download was triggered using registerDownloadURL or the download was triggered using a Content Access Download Descriptor with <TransferType> value "playable_download" as defined in Annex E.1, then: a) if the play() method is called before sufficient data has been download to initiate playback, then the play state of the A/V object SHALL be set to 6 ('error') with a detailed error code of 5 ("content not available"). HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | +DL | ||
| tv.oipf_DAE-MEDIA_PLAYBACK-009 | 2 | play() method of A/V Control called before sufficient data is available for 'full_download' acquisition | When a download is initiated using a Content Access Download descriptor with its <TransferType> element set to 'full_download'; setting the A/V Control object's source to the download and calling play() before sufficient data has been downloaded to initiate playback - shall cause the A/V Control object to go to play state 6 (error) with an error code of 5 (content not available) | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media playback APIs OIPF-DAE,section 7.14.1.3: If an A/V control object is used to play content that has been downloaded and stored on the OITF (by using method setSource() as defined in section 7.14.7) then the following holds: [...] 2. if the downloaded content was triggered using a Content Access Download Descriptor with <TransferType> value "full_download" as defined in Annex E.1, then: a) if the play() method is called whilst the content is still downloading and has not yet successfully completed, then the play state of the A/V object SHALL be set to 6 ('error') with a detailed error code of 5 ("content not available"). HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | +DL | ||
| tv.oipf_DAE-MEDIA_PLAYBACK-023 | 1 | HE-AAC memory audio loop parameter | When an A/V Control object plays HE-AAC memory audio, it shall loop the audio as many times as specified in the 'loop' parameter | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media playback APIs. This section specifies several extensions to the audio object and the video object defined in section 5.7.1 of [CEA2014A]. It also contains a subsection (i.e section 7.14.10) that defines the audio playback from memory API. OIPF-DAE,section 7.14.10.1: Usage of CE-HTML tags. The AV Control object SHALL be used to play audio clips from memory. ... The <object> element representing the AV Control object MAY contain <param> elements, ... valid parameters are: ... loop - indicates the number of times the audio clip SHALL be played when play() is called. The value SHALL be positive integers or the case sensitive string "infinite", which SHALL play the audio clip continuously until stop() is called or the data property is set to null. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-025-001 | 1 | Stopping playing memory audio | Terminal shall be able to stop memory audio before it finishes playing | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media playback APIs. This section specifies several extensions to the audio object and the video object defined in section 5.7.1 of [CEA2014A]. It also contains a subsection (i.e section 7.14.10) that defines the audio playback from memory API. OIPF-DAE,section 7.14.10.2: For AV Control objects used to play audio from memory, the following properties and methods SHALL be supported: The properties data, playState, error and onPlayStateChange, as defined in Req. 5.7.1.f of [CEA2014A]. The methods play() and stop(), as defined in Req. 5.7.1.f of [CEA2014A]. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-025-002 | 1 | <param> element is accessible through the A/V control object | <param> element of the A/V Control object shall be accessible after memory audio has been played, then stopped | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media playback APIs This section specifies several extensions to the audio object and the video object defined in section 5.7.1 of [CEA2014A]. It also contains a subsection (i.e section 7.14.10) that defines the audio playback from memory API. OIPF-DAE,section 7.14.10.2: The <param> element as defined in section 7.14.10.2 of this document SHALL be made accessible through a DOM HTMLParamElement object HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-026 | 1 | Audio from memory - Playing after previously stopped (HE-AAC) | Terminal shall play HE-AAC after it was previously played, then stopped | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.14: Media Playback APIs OIPF-DAE,section 7.14.10.2: Usage of DOM interface. The methods play() and stop(), as defined in Req. 5.7.1.f of [CEA2014A] HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-027 | 2 | AV Object Seeking (MP4 Forward 5s) correctly reports its position via onPlayPositionChanged | When the seek() method is called on the A/V Control object specifying the position as the current position plus 5 seconds, and an AVC_SD_25 MP4 is currently being streamed over HTTP; an 'onPlayPositionChanged' event shall be dispatched and its 'position' parameter shall report the expected position | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: The mapping from the APIs for unicast streaming to the protocols shall be as defined in clause 8.2.3.1 of the OIPF DAE specification [1] for HTTP streaming. OIPF-DAE,section 7.14.3: The following additional properties SHALL be supported on the audio object and video object defined in section 5.7.1 of [CEA2014A]. [...] function onPlayPositionChanged( Integer position ) The function that is called when change occurs in the play position of the media due to the use of trick play functions. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-028 | 2 | AV Object Seeking (MP4 Forward 180s) correctly reports its position via onPlayPositionChanged | When the seek() method is called on the A/V Control object specifying the position as the current position plus 180 seconds, and an AVC_SD_25 MP4 is currently being streamed over HTTP; an 'onPlayPositionChanged' event shall be dispatched and its 'position' parameter shall report the expected position | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: The mapping from the APIs for unicast streaming to the protocols shall be as defined in clause 8.2.3.1 of the OIPF DAE specification [1] for HTTP streaming. OIPF-DAE,section 7.14.3: The following additional properties SHALL be supported on the audio object and video object defined in section 5.7.1 of [CEA2014A]. [...] function onPlayPositionChanged( Integer position ) The function that is called when change occurs in the play position of the media due to the use of trick play functions. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-029 | 2 | AV Object Seeking (MP4 Backward 180s) correctly reports its position via onPlayPositionChanged | When the seek() method is called on the A/V Control object specifying the position as the current position minus 180 seconds, and an AVC_SD_25 MP4 is currently being streamed over HTTP; an 'onPlayPositionChanged' event shall be dispatched and its 'position' parameter shall report the expected position | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: The mapping from the APIs for unicast streaming to the protocols shall be as defined in clause 8.2.3.1 of the OIPF DAE specification [1] for HTTP streaming. OIPF-DAE,section 7.14.3: The following additional properties SHALL be supported on the audio object and video object defined in section 5.7.1 of [CEA2014A]. [...] function onPlayPositionChanged( Integer position ) The function that is called when change occurs in the play position of the media due to the use of trick play functions. | |||
| tv.oipf_DAE-MEDIA_PLAYBACK-030 | 2 | AV Object Seeking (MP4 Backward 5s) correctly reports its position via onPlayPositionChanged | When the seek() method is called on the A/V Control object specifying the position as the current position minus 5 seconds, and an AVC_SD_25 MP4 is currently being streamed over HTTP; an 'onPlayPositionChanged' event shall be dispatched and its 'position' parameter shall report the expected position | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.2: The mapping from the APIs for unicast streaming to the protocols shall be as defined in clause 8.2.3.1 of the OIPF DAE specification [1] for HTTP streaming. OIPF-DAE,section 7.14.3: The following additional properties SHALL be supported on the audio object and video object defined in section 5.7.1 of [CEA2014A]. [...] function onPlayPositionChanged( Integer position ) The function that is called when change occurs in the play position of the media due to the use of trick play functions. | |||
| tv.oipf_DAE-MISCELLANEOUS-010-002-001 | 3 | hasCapability() - +PVR - Supported | If the terminal supports the +PVR capability, the hasCapability() method of the application/oipfCapabilities object shall return true when called with its 'profileName' argument set to '+PVR' | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The strings defined in table 13 shall be used to indicate which options are supported by a terminal. They shall be used [...] as parameters of the hasCapability() method of the application/oipfCapabilities embedded object to dynamically query the options supported by the terminal. [...] "+PVR" - Support for PVR feature OIPF-DAE,section 7.15.3: The OITF SHALL support following non-visual embedded object with the mime type "application/oipfCapabilities". OIPF-DAE,section 7.15.3.2: Boolean hasCapability( String profileName ): Check if the OITF supports the passed capability. Returns true if the OITF supports the passed capability, false otherwise. profileName: An OIPF base UI profile string or a UI Profile name fragment string as defined in section 9.2. OIPF-DAE,section 9.2: Default UI profiles [...] Table 15: Complementary UI Profile Name Fragments [...] "+PVR" | +PVR | ||
| tv.oipf_DAE-MISCELLANEOUS-010-002-002 | 1 | hasCapability() - +PVR - Not Supported | If the terminal does not support the +PVR capability, the hasCapability() method of the application/oipfCapabilities object shall return false when called with its 'profileName' argument set to '+PVR' | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: The strings defined in table 13 shall be used to indicate which options are supported by a terminal. They shall be used [...] as parameters of the hasCapability() method of the application/oipfCapabilities embedded object to dynamically query the options supported by the terminal. [...] "+PVR" - Support for PVR feature OIPF-DAE,section 7.15.3: The OITF SHALL support following non-visual embedded object with the mime type "application/oipfCapabilities". OIPF-DAE,section 7.15.3.2: Boolean hasCapability( String profileName ): Check if the OITF supports the passed capability. Returns true if the OITF supports the passed capability, false otherwise. profileName: An OIPF base UI profile string or a UI Profile name fragment string as defined in section 9.2. OIPF-DAE,section 9.2: Default UI profiles [...] Table 15: Complementary UI Profile Name Fragments [...] "+PVR" | -PVR | ||
| tv.oipf_DAE-OBJECT_FACTORY-001-001 | 1 | isObjectSupported() (true) - application/oipfApplicationManager | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfApplicationManager, it shall return true and the createApplicationManagerObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-OBJECT_FACTORY-001-002 | 1 | isObjectSupported() (true) - application/oipfCapabilities | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfCapabilities, it shall return true and the createCapabilitiesObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-OBJECT_FACTORY-001-003 | 1 | isObjectSupported() (true) - application/oipfConfiguration | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfConfiguration, it shall return true and the createConfigurationObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-OBJECT_FACTORY-001-004 | 2 | isObjectSupported() (true) - application/oipfDownloadManager | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfDownloadManager, it shall return true and the createDownloadManagerObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | +DL | ||
| tv.oipf_DAE-OBJECT_FACTORY-001-005 | 2 | isObjectSupported() (true) - application/oipfDownloadTrigger | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfDownloadTrigger, it shall return true and the createDownloadTriggerObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | +DL | ||
| tv.oipf_DAE-OBJECT_FACTORY-001-006 | 2 | isObjectSupported() (true) - application/oipfDrmAgent | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfDrmAgent, it shall return true and the createDrmAgentObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | +DRM | ||
| tv.oipf_DAE-OBJECT_FACTORY-001-007 | 1 | isObjectSupported() (true) - application/oipfParentalControlManager | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfParentalControlManager, it shall return true and the createParentalControlManagerObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-OBJECT_FACTORY-001-008 | 2 | isObjectSupported() (true) - application/oipfRecordingScheduler | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfRecordingScheduler, it shall return true and the createRecordingSchedulerObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | +PVR | ||
| tv.oipf_DAE-OBJECT_FACTORY-001-009 | 1 | isObjectSupported() (true) - application/oipfSearchManager | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfSearchManager, it shall return true and the createSearchManagerObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-OBJECT_FACTORY-001-010 | 1 | isObjectSupported() (true) - video/broadcast | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to video/broadcast, it shall return true and the createVideoBroadcastObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-OBJECT_FACTORY-001-011 | 1 | isObjectSupported() (true) - video/mpeg | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to video/mpeg, it shall return true and the createVideoMpegObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-OBJECT_FACTORY-001-012 | 1 | isObjectSupported() (true) - video/mp4 | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to video/mp4, it shall return true and the createVideoMpegObject() method of the OipfObjectFactory object shall not return null or undefined | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-OBJECT_FACTORY-001-013 | 1 | isObjectSupported() (true) - audio/mpeg | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to audio/mpeg, it shall return true | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-OBJECT_FACTORY-001-014 | 1 | isObjectSupported() (true) - audio/mp4 | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to audio/mp4, it shall return true | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | |||
| tv.oipf_DAE-OBJECT_FACTORY-001-018 | 1 | isObjectSupported() (false) - application/oipfDownloadManager | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfDownloadManager, it shall return false and the createDownloadManagerObject() method of the OipfObjectFactory object shall throw an error with its name property set to the value 'TypeError' | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | -DL | ||
| tv.oipf_DAE-OBJECT_FACTORY-001-019 | 1 | isObjectSupported() (false) - application/oipfDownloadTrigger | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfDownloadTrigger, it shall return false and the createDownloadTriggerObject() method of the OipfObjectFactory object shall throw an error with its name property set to the value 'TypeError' | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | -DL | ||
| tv.oipf_DAE-OBJECT_FACTORY-001-020 | 2 | isObjectSupported() (false) - application/oipfDrmAgent | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfDrmAgent, it shall return false and the createDrmAgentObject() method of the OipfObjectFactory object shall throw an error with its name property set to the value 'TypeError' | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | -DRM | ||
| tv.oipf_DAE-OBJECT_FACTORY-001-022 | 1 | isObjectSupported() (false) - application/oipfRecordingScheduler | When the isObjectSupported() method of the OipfObjectFactory object is called with the mimeType parameter set to application/oipfRecordingScheduler, it shall return false and the createRecordingSchedulerObject() method of the OipfObjectFactory object shall throw an error with its name property set to the value 'TypeError' | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface with the API as defined in this section OIPF-DAE,section 7.1.1: Boolean isObjectSupported( String mimeType ). | Description | This method SHALL return true if and only if an object of the specified type is supported by the OITF. The method SHALL return false if the MIME type passed as a parameter is not supported by the client. | ... HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | -PVR | ||
| tv.oipf_DAE-OBJECT_FACTORY-002-001 | 3 | OipfObjectFactory - createVideoBroadcastObject() | When calling the createVideoBroadcastObject() method of the OipfObjectFactory object, the terminal shall return an object which has a 'type' attribute equal to 'video/broadcast' and a 'playState' property equal to 0 | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. OIPF-DAE,section 7.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface OIPF-DAE,section 7.1.1.1: [...] HTMLObjectElement createVideoBroadcastObject() [...] If the object type is supported, each of these methods shall return an instance of the corresponding embedded object. Since objects do not claim scarce resources when they are instantiated, instantiation shall never fail if the object type is supported. If the method name to create the object is not supported, the OITF SHALL throw an error with the error.name set to the value "TypeError". If the object type is supported, the method shall return an HTMLObjectElement equivalent to the specified object. The value of the type attribute of the HTMLObjectElement SHALL match the mimetype of the instantiated object OIPF-DAE,section 7.13.1.2: Integer playState; The current play state of the video/broadcast object. Valid values are: 0 - unrealized; | |||
| tv.oipf_DAE-OBJECT_FACTORY-003 | 3 | OipfObjectFactory - createVideoMpegObject() | When calling the createVideoMpegObject() method of the OipfObjectFactory object, the terminal shall return an object which has a 'type' attribute equal to 'video/mpeg' and a 'playState' property equal to 0 | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. OIPF-DAE,section 7.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface OIPF-DAE,section 7.1.1.1: [...] HTMLObjectElement createVideoMpegObject() [...] If the object type is supported, each of these methods shall return an instance of the corresponding embedded object. Since objects do not claim scarce resources when they are instantiated, instantiation shall never fail if the object type is supported. If the method name to create the object is not supported, the OITF SHALL throw an error with the error.name set to the value "TypeError". If the object type is supported, the method shall return an HTMLObjectElement equivalent to the specified object. The value of the type attribute of the HTMLObjectElement SHALL match the mimetype of the instantiated object OIPF-DAE,section B: Requirement 5.7.1.f bullet 4) 'playState' SHALL be modified as follows to fit the state diagram as specified in section 7.14.1; 4) Number playState [R] - indication of the current play state as follows: 0 - stopped; user (or script) has stopped playback of the current media, or playback has not yet started | |||
| tv.oipf_DAE-OBJECT_FACTORY-007-001 | 3 | OipfObjectFactory - createConfigurationObject() | When calling the createConfigurationObject() method of the OipfObjectFactory object, the terminal shall return an object with a 'configuration' property; the 'configuration' property shall contain an object with a 'countryId' property; the 'countryId' property shall contain a string | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. OIPF-DAE,section 7.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface OIPF-DAE,section 7.1.1.2: [...] Object createConfigurationObject() [...] If the object type is supported, each of these methods SHALL return an instance of the corresponding embedded object. This may be a new instance or existing instance. For example, the object will likely be a global singleton object and calls to this method may return the same instance. OIPF-DAE,section 7.3.2.1: String countryId | |||
| tv.oipf_DAE-OBJECT_FACTORY-009 | 2 | createDownloadTriggerObject() API method | The terminal shall return a DownloadTrigger object when using the createDownloadTriggerObject() method on the globally accessible OipfObjectFactory object and calling registerDownloadURL() with valid parameters shall return a string | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface OIPF-DAE,section 7.1.1.2: [...] Object createDownloadTriggerObject() [...] If the object type is supported, each of these methods SHALL return an instance of the corresponding embedded object. This may be a new instance or existing instance. For example, the object will likely be a global singleton object and calls to this method may return the same instance. OIPF-DAE,section 7.4.1.1: String registerDownloadURL( String URL, String contentType, Date downloadStart ). This method triggers the OITF to initiate a download of the content pointed to by the URL and the given content type. HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | +DL | ||
| tv.oipf_DAE-OBJECT_FACTORY-015-001 | 3 | OipfObjectFactory - createRecordingSchedulerObject() | When calling the createRecordingSchedulerObject() method of the OipfObjectFactory object, the terminal shall return an object with a record() method | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. OIPF-DAE,section 7.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface OIPF-DAE,section 7.1.1.2: [...] Object createRecordingSchedulerObject() [...] If the object type is supported, each of these methods SHALL return an instance of the corresponding embedded object. This may be a new instance or existing instance. For example, the object will likely be a global singleton object and calls to this method may return the same instance. OIPF-DAE,section 7.10.1: The OITF SHALL support the scheduling of recordings of broadcasts through the use of the following non-visual embedded object: <object type="application/oipfRecordingScheduler"/> [...] OIPF-DAE,section 7.10.1.1: Methods: ScheduledRecording record( Programme programme ). Description: Requests the scheduler to schedule the recording of the programme identified by the programmeID property of the programme. [...] | +PVR | ||
| tv.oipf_DAE-OBJECT_FACTORY-015-002 | 2 | OipfObjectFactory - createRecordingSchedulerObject() - TypeError | When the 'application/oipfRecordingScheduler' object is not supported and the createRecordingSchedulerObject() method of the OipfObjectFactory object is called, the terminal shall throw an exception. The error object's 'name' property shall be equal to 'TypeError' | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. OIPF-DAE,section 7.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface OIPF-DAE,section 7.1.1.2: [...] Object createRecordingSchedulerObject() [...] If the object type is supported, each of these methods SHALL return an instance of the corresponding embedded object. This may be a new instance or existing instance. For example, the object will likely be a global singleton object and calls to this method may return the same instance. OIPF-DAE,section 7.10.1: The OITF SHALL support the scheduling of recordings of broadcasts through the use of the following non-visual embedded object: <object type="application/oipfRecordingScheduler"/> [...] | -PVR | ||
| tv.oipf_DAE-OBJECT_FACTORY-017-001 | 3 | OipfObjectFactory - createSearchManagerObject() | When calling the createSearchManagerObject() method of the OipfObjectFactory object, the terminal shall return an object with a createSearch() method; the createSearch() method shall return an object with a 'searchTarget' property equal to 1 | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. OIPF-DAE,section 7.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface OIPF-DAE,section 7.1.1.2: [...] Object createSearchManagerObject() [...] If the object type is supported, each of these methods SHALL return an instance of the corresponding embedded object. This may be a new instance or existing instance. For example, the object will likely be a global singleton object and calls to this method may return the same instance. OIPF-DAE,section 7.12.1: OITFs SHALL implement the "application/oipfSearchManager" embedded object. This object provides a mechanism for applications to create and manage metadata searches. OIPF-DAE,section 7.12.1.2: Methods: MetadataSearch createSearch( Integer searchTarget ), Description: Create a MetadataSearch object that can be used to search the metadata. [...] | |||
| tv.oipf_DAE-OBJECT_FACTORY-018 | 3 | OipfObjectFactory - createCapabilitiesObject() | When calling the createCapabilitiesObject() method of the OipfObjectFactory object, the terminal shall return an object with a hasCapability() method; the hasCapability() method shall return a boolean | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. OIPF-DAE,section 7.1: The OITF SHALL support a globally accessible object of type "OipfObjectFactory" as a static property "oipfObjectFactory" of the Window interface OIPF-DAE,section 7.1.1.2: [...] Object createCapabilitiesObject() [...] If the object type is supported, each of these methods SHALL return an instance of the corresponding embedded object. This may be a new instance or existing instance. For example, the object will likely be a global singleton object and calls to this method may return the same instance. OIPF-DAE,section 7.15.3: The OITF SHALL support following non-visual embedded object with the mime type "application/oipfCapabilities". OIPF-DAE,section 7.15.3.2: Boolean hasCapability( String profileName ): Check if the OITF supports the passed capability. Returns true if the OITF supports the passed capability, false otherwise. profileName: An OIPF base UI profile string or a UI Profile name fragment string as defined in section 9.2. | |||
| tv.oipf_DAE-OVERVIEW-018 | 2 | Download resumes after a power cycle | When a download is in progress and the terminal is powered off, the terminal shall resume the download after the terminal is powered on again | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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 4.6.1: Download manager. An OITF SHALL support a native download manager (i.e. "Content Download" component) to perform the actual download and storage of the content, and which allows the user to manage (e.g. suspend/resume, cancel) and monitor the download, in a consistent manner across different service providers. The download manager SHALL continue downloading as a background process even if the browser does not have an active session with the server that originated the download request anymore (e.g. has switched to another DAE application), even after a device power-down or network failure, until it succeeds or the user has given permission to terminate the download. (see 4.6.4 on HTTP Range support to resume HTTP downloads after a power/network failure). HBBTV,section 8.1: The OIPF DAE specification [1] shall be supported as defined in annex A of the present document. | +DL | ||
| tv.oipf_DAE-SCHEDULED_RECORDING-002-DVB | 1 | ScheduledRecording - recordAt() - Schedule a Recording | The recordAt() method of the application/oipfRecordingScheduler object shall return a ScheduledRecording object, when used to schedule a recording of a future period on the current DVB broadcast channel | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 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.10.1.1: ScheduledRecording recordAt( Integer startTime, Integer duration, Integer repeatDays, String channelID ) [...] Requests the scheduler to schedule the recording of the broadcast to be received over the channel identified by channelID, starting at startTime and stopping at startTime + duration. If the recording was scheduled successfully, the resulting ScheduledRecording object is returned. If the recording could not be scheduled due to a scheduling conflict or lack of resources the value null is returned. HBBTV,section A.1: application/oipfRecordingScheduler embedded object M-P [...] M-P - Mandatory if the PVR feature is supported otherwise not included.[...] | +PVR | ||
| tv.oipf_DAE-SCHEDULED_RECORDING-005-DVB | 1 | ScheduledRecording - remove() - Remove a Newly Scheduled Recording | If a recording is newly scheduled on the current DVB channel and then deleted using the remove() method of the application/oipfRecordingScheduler object, the associated ScheduleRecording object shall not be present in the ScheduledRecordingCollection object returned by getScheduledRecordings() | 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 | OIPF-DAE,section 7.10.1.1: void remove( ScheduledRecording recording ) [...] Remove a recording (either scheduled, in-progress or completed). HBBTV,section A.1: application/oipfRecordingScheduler embedded object [...] M-P | +PVR | ||
| tv.oipf_DAE-SCHEDULED_RECORDING-021-001 | 1 | application/oipfRecordingScheduler - 'recordings' Property - ScheduledRecordingCollection | The 'recordings' property of the application/oipfRecordingScheduler object shall contain a ScheduledRecordingCollection object | 2024-1 2023-3 2023-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 | OIPF-DAE,section 7.10.1: The OITF SHALL support the scheduling of recordings of broadcasts through the use of the following non-visual embedded object [...] OIPF-DAE,section 7.10.3: The ScheduledRecordingCollection class represents a collection of ScheduledRecording objects. See Annex K for the definition of the collection template. HBBTV,section A.1: application/oipfRecordingScheduler embedded object [...] M-P | +PVR | ||
| tv.oipf_DAE-SHARED_UTILITY-003-001 | 2 | EIT - getSIDescriptors() - Descriptor Not Found | The current programme in the EIT only contains a Short Event Descriptor (0x4d). When the getSIDescriptors() method is called on the respective Programme object and its 'descriptorTag' argument is specified as 0x4e (Extended Event Descriptor), the method shall return null | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 2021-3 2021-2 2021-1 2020-3 2020-2 2020-1 2019-3 2019-2 2019-1 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: DVB-SI extensions to Programme OIPF-DAE,section 7.16.1: A StringCollection object represents a read-only collection of strings. Items in the collection can be accessed using array notation. Next to the properties and methods defined below a StringCollection object SHALL support the array notation to access the strings in this collection. OIPF-DAE,section 7.16.2.4: StringCollection getSIDescriptors( Integer descriptorTag, Integer descriptorTagExtension ) [...] Get the contents of the descriptor specified by descriptorTag from the DVB SI EIT programme's descriptor loop. [...] If the descriptor specified by descriptorTag [...] does not exist, [...] this method SHALL return null. | |||
| tv.oipf_DAE-SHARED_UTILITY-003-002 | 2 | EIT - getSIDescriptors() - Descriptor Found | The current programme in the EIT contains a Short Event Descriptor (0x4d) and an Extended Event Descriptor (0x4e). When the getSIDescriptors() method is called on the respective Programme object and its 'descriptorTag' argument is specified as 0x4e (Extended Event Descriptor), the method shall return a string representation of the descriptor's content bytes, as defined in OIPF DAE section 7.16.2.4 | 2024-1 2023-3 2023-2 2023-1 2022-3 2022-2 2022-1 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: DVB-SI extensions to Programme OIPF-DAE,section 7.16.1: A StringCollection object represents a read-only collection of strings. Items in the collection can be accessed using array notation. Next to the properties and methods defined below a StringCollection object SHALL support the array notation to access the strings in this collection. OIPF-DAE,section 7.16.2.4: StringCollection getSIDescriptors( Integer descriptorTag, Integer descriptorTagExtension ) [...] Get the contents of the descriptor specified by descriptorTag from the DVB SI EIT programme's descriptor loop. If more than one descriptor with the specified tag is available for the given programme, the contents of all matching descriptors SHALL be returned in the order the descriptors are found in the stream. The descriptor content bytes SHALL be encoded in a string whose characters shall be restricted to the ISO Latin-1 character set. Each character in the string represents a byte of a DVB-SI descriptor, such that a byte at position "i" in the descriptor is equal the Latin-1 character code of the character at position "i" in the string. |
Copyright HbbTV 2024. All Rights Reserved.