HLS compliance

[kqyang]

This bug tracks HLS compliance failures.

Here is one of the failures:

Shaka Packager generates FRAME-RATE tag for EXT-I-FRAME-STREAM-INF which violates the spec:

HLS Spec 4.3.4.3:

#EXT-X-I-FRAME-STREAM-INF:

All attributes defined for the EXT-X-STREAM-INF tag (Section 4.3.4.2)
are also defined for the EXT-X-I-FRAME-STREAM-INF tag, except for the
FRAME-RATE, AUDIO, SUBTITLES, and CLOSED-CAPTIONS attributes.

[koln67]

The first issue is fixed, #EXT-X-I-FRAME-STREAM-INF no longer generates a FRAME-RATE attribute

Another "Must fix" error:

Each EXT-X-STREAM-INF tag MUST have a FRAME-RATE attribute: Master Playlist

This was caused because the frame rate was 0, due to a bug in the generation of ts segments. Fixed in #823.

[koln67]

Additional errors generated from HEVC input files (some of these errors may be from the mediastreamvalidator tool)

Checked against HLS Authoring Specification for Apple Devices
General Requirements
Must Fix Issues
1. The server MUST deliver playlists using gzip content-encoding
All Variants
All Renditions
All I-Frame Variants
Master Playlist
2. Playlist codec type doesn't match content codec type
All Variants
All I-Frame Variants

Should Fix Issues
3. Captions SHOULD be provided with your streams to make content accessible to the deaf or hard of hearing.
Master Playlist
4. For backward compatibility some video content SHOULD be encoded with AVC/H.264
Master Playlist
5. Key frames (IDRs) SHOULD be present every two seconds
All Variants
6. The default video variant(s) SHOULD be the 2000 kb/s variant.
Variant #1
7. You SHOULD have one frame per second "dense" I-frame renditions.
All I-Frame Variants
8. You SHOULD support stream failover
All Variants
All I-Frame Variants
9. Media segments SHOULD be delivered over TLS
All Variants
All Renditions
All I-Frame Variants
10. Content protection SHOULD follow the FairPlay Streaming (FPS) specification
All Variants
All Renditions
All I-Frame Variants
11. Target durations SHOULD be 6 seconds.
All Variants
All Renditions
12. (Segment) You SHOULD use the recommended MIME types.
All Renditions, Received: video/mp4, Expected audio/mp4
13. Audio loudness information SHOULD be provided
All Renditions

Additional requirements for iOS
Must Fix Issues
14. Master playlists that are delivered over cellular networks MUST contain a variant whose peak BANDWIDTH is less than or equal to 192kb/s.
Master Playlist

Should Fix Issues
15. For WiFi delivery, the default video variant(s) SHOULD be the 2000 kb/s variant.
Variant #1 

[koln67]

Errors generated from h264 input. Some may overlap with errors generated from HEVC input.

From this list, it appears that "16. All video variants and renditions MUST have segment boundaries at the same points in time
Variant #1, Start time 0.0 does not match -0.083" is an error with the MediaStreamValidator tool (on OSX)

Checked against HLS Authoring Specification for Apple Devices
General requirements
Must Fix Issues
1. The server MUST deliver playlists using gzip content-encoding
All Variants
All Renditions
All I-Frame Variants
Master Playlist

Should Fix Issues
2. Captions SHOULD be provided with your streams to make content accessible to the deaf or hard of hearing.
Master Playlist
3. For H.264 you SHOULD use High Profile in preference to Main or Baseline Profile
Variant #2
Variant #3
I-Frame #7
I-Frame #8
4. Key frames (IDRs) SHOULD be present every two seconds
All Variants
5. The default video variant(s) SHOULD be the 2000 kb/s variant.
Variant #1
6. You SHOULD have one frame per second "dense" I-frame renditions.
All I-Frame Variants
7. You SHOULD support stream failover
All Variants
All I-Frame Variants
8. Media segments SHOULD be delivered over TLS
All Variants
All Renditions
All I-Frame Variants
9. Content protection SHOULD follow the FairPlay Streaming (FPS) specification
All Variants
All Renditions
All I-Frame Variants
10. Target durations SHOULD be 6 seconds.
All Variants
All Renditions
11. All video variants and renditions SHOULD have segment boundaries at the same points in time
Variant #1, Start time 0.0 does not match -0.083
12. (Segment) You SHOULD use the recommended MIME types.
All Renditions, Received: video/mp4, Expected audio/mp4
13. Audio loudness information SHOULD be provided
All Renditions

Additional requirements for iOS
Must Fix Issues
14. Master playlists that are delivered over cellular networks MUST contain a variant whose peak BANDWIDTH is less than or equal to 192kb/s.
Master Playlist

Should Fix Issues
15. For WiFi delivery, the default video variant(s) SHOULD be the 2000 kb/s variant.
Variant #1

Additional requirements for AirPlay 2
Must Fix Issues
16. All video variants and renditions MUST have segment boundaries at the same points in time
Variant #1, Start time 0.0 does not match -0.083

[koln67]

As a note, most of these issues appear to be in one of two categories, neither of which can be fixed through shaka packager.

1. Issues with delivery, such as issues relating to the server, network, Wifi, or other methods of delivery. These are separate from the packager.
2. Content issues, where the input content does not satisfy the spec. These issues also cannot be fixed through shaka packager.

[kqyang]

@koln67 Thanks for the analysis. The only exception I notice is "13. Audio loudness information SHOULD be provided". Can you look into what it is about?

[koln67]

According to https://developer.apple.com/documentation/http_live_streaming/hls_authoring_specification_for_apple_devices, section 2.19, a loudness box ('ludt') should be provided for loudness information. However, there does not seem to be any additional information in the spec about 'ludt.'

[koln67]

In addition, the following two parts of the spec mention how this conformance warning could potentially be resolved.

2.20. In the absence of a loudness box, Dolby Digital and Dolby Digital Plus loudness SHOULD be specified by the dialnorm field (ATSC A/52:2012).

2.21. In the absence of a loudness box, AAC dialog loudness SHOULD be specified by either AAC prog_ref_level (ISO 14496-3 subclause 4.5.2.7), as specified by SCTE 193-1 section 7.4.1; or by the loudnessInfo() payload as specified by ISO 23003-4, in which case, samplePeakLevel or truePeakLevel MUST be present, measurementSystem MUST be 2, and methodDefinition MUST be 1 or 2.

At a first glance, it appears that Dynamic Range Control (DRC), which is mentioned in both ISO 23003-4 and ISO 14496-3 subclause 4.5.2.7, is not yet supported/implemented in shaka packager.

[jeiea]

I recently ran mediastreamvalidator to shaka-packager m3u8 file and got the following.

hls.html.zip