ISE write-up for: draft-pantos-http-live-streaming-20
"This document describes a protocol for transferring unbounded streams
of multimedia data. It specifies the data format of the files and
the actions to be taken by the server (sender) and the clients
(receivers) of the streams. It describes version 7 of this protocol."
This draft has IANA Considerations - it requests modifying an MIME type,
IANA have considered it, the authors have responded to the Expert Reviewer's
comments on it.
The draft has not been discussed in any IETF WG, but it has had a
lengthy discussion among its contributors, hence its high version number.
It was reviewed for me by three people closely involved with live
streaming. All three gave 'public' comments, but did so as anonymous
The authors have made the changes suggested by the reviewers and those
requested by the ISE.
- - - - - - -
Reviewer 1's comments
* Overall, this specification is topical for the RFC series, and does not conflict with current work in the IETF.
* The choice of name ("HTTP Live Streaming") is unfortunate; what described is limited to neither HTTP nor live streaming. Really, it's a pair of media manifest formats, not a protocol.
* The processing model of the format is a bit unclear; e.g., the cardinality of the URIs in a media segment is only mentioned briefly in passing, and no normative constraints are put on them. It would be nice to have this more clearly specified, as this is often the source of interop problems in formats.
* There is no mechanism for accommodating new formats in Media Segments; Section 3 says:
Each Media Segment MUST be formatted as an MPEG-2 Transport Stream [ISO_13818], a WebVTT [WebVTT] file, or a Packed Audio file, which is a file containing packed encoded audio samples and ID3 tags, such as AAC with ADTS framing [ISO_13818_7], MP3 [ISO_13818_3], AC-3 [AC_3], or Enhanced AC-3 [AC_3]. Transport of other media file formats is not defined.
Given the relatively fast evolution of media formats, this MUST means that this specification will be quickly outdated, and strictly read, means that a new specification and media type would need to be defined to accommodate new formats. The authors should consider making this advisory (e.g., removing the MUST and replacing it with prose), or explicitly introducing extensibility here.
- - - - -
Reviewer 2's comments
I think this is an important document to publish as this is a common and well deployed defacto standard. I did note some things that I find quite unclear and can benefit from improved text.
I think the two important issues is
A. what is done about "audio/mpegurl". I don't like squatting on name spaces. And something should be done to ensure that this registered or the practice removed, or at least recommended against.
B. The security consideration and discussion of what security mechanisms needs to be supported by an implementation.
- - - - -
Reviewer 3's comments
Q. Is this document technically competent, as far as you can tell?A. Yes.
Q. Is this document in reasonable (not necessarily final) editorial shape?A. Yes.
Q. Are the Abstract and Introduction of this document reasonably clear for those Internet techies who may not be experts in the particular subject matter?A. Since I am familiar with this topic it is difficult for me to judge. There are some sections that mention industry terms (ie: “bit rate of media”) that may that may not be reasonably clear to someone outside of the industry. However, overall, I would say yes.
Q. Do the Title and Abstract fairly and accurately summarize the contents?A. Yes.
Q. Is it technically sound? Are there any obvious mistakes that need to be fixed, or changes that would improve it?A. 1. The use of “ideally” make some requirements unclear. The H.264 reference is mentioned as an example but it looks like a requirement.
Section 3(last para):Any Media Segment that contains video SHOULD include enough information to initialize a video decoder and decode a continuous set of frames that includes the final frame in the Segment, and ideally all frames in the Segment. For example, any Media Segment containing H.264 video SHOULD contain an IDR, ideally at the beginning of the Segment.
Section 3.2(last para)Transport Stream Segments MUST contain a single MPEG-2 Program; playback of Multi-Program Transport Streams is not defined. Each Transport Stream Segment MUST contain a PAT and a PMT, ideally at the start of the Segment, or have an EXT-X-MAP (Section 188.8.131.52) tag applied to it.
2. ---Section 184.108.40.206.CHANNELS
The value is a quoted-string that specifies an ordered, "/"-separated list of parameters. If the TYPE attribute is AUDIO then the first parameter is the count of independent audio channels expressed as a decimal-integer. For example, an AC-3 5.1 rendition would have a CHANNELS="6" attribute. No other parameters are currently defined.
All audio EXT-X-MEDIA tags SHOULD have a CHANNELS attribute. If a Master Playlist contains two renditions encoded with the same codec but a different number of channels, then the CHANNEL attribute is REQUIRED; otherwise it is OPTIONAL.---The last use of "CHANNEL" seems to be a typo.
I will provide additional comments during the detailed review.
Q. Is the subject of this document relevant to the RFC Series?A. Yes
Q. Does it have content of interest to people in the Internet Community, especially (but not limited to) in the IETF?A. Yes
Q. Does the document make clear up front how the specification does/does not relate to past or current IETF activities?Q. Was it discussed in an IETF Working Group? Why did the authors choose to send it to the Independent Stream?A. I do not have enough information to be able to answer the above two questions.
In general this version of the spec is an update for a few things. Some of these are1. Allow for another transport stream(fMP4) in HLS and hence some parts (including transport stream specification & encryption) of the spec are updated.2. Addition of more attributes (CHANNELS, HDCP) to pass on more information that can be used by the clients.
- It is unclear if Section 3.3 describes requirements over and above the ISOBMFF.
- There are now two transport formats supported. There seems to be nothing in the spec to identify the format of the segments in a particular media playlist.
- - - - -