More Ben K comments
Closed this issue · 0 comments
Section 3
nit: The subsequent discussion seems to indicate that at least some of
these mechanisms are already specified and not new in this document; (if
so) it would be nice to have the exposition reflect that.Section 3.3
For Opus, packets deemed as important are re-encoded at a lower
bitrate and added to the subsequent packet, allowing partial recoveryIs "added" supposed to be something other than "appended" (which strongly
resembles the "redundant encoding" of the previous section)?
It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level.
Section 4.1
Does it make sense to give subsection backreferences when talking about
(e.g.) redundant encoding?
Yes, this could be done easily.
Section 5.2
Support for a SSRC-multiplexed flexfec stream to protect a given RTP
stream SHOULD be indicated by including one of the formats described
in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as annit: Since this Section 5 is solely for video, is it more appropriate to
refer to Section 5.1.2 ("Registration of video/flexfec") of
draft-ietf-payload-flexible-fec-scheme?
Agreed - earlier versions of flexfec were slightly different.