ISE write-up for: draft-pantos-http-live-streaming-20
Abstract:
"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
reviewers.
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 4.3.2.5) tag applied to it.
2. ---Section 4.3.4.1.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.
- - - - -