I have been reading draft-ietf-avt-uxp-02.txt and have the following comments:
0. About the document structure, I think that the document could benefit from moving the introduction (section 3)
before the very useful but also quite long "conventions used in this document" part
1. Since one of the key features of the payload format is that it distributes errors
using *interleaving* I think that this key word should be found in the abstract
and the introduction.
2. There is a substancial amont of confusion introduced by using several words
to say same/different things, for example in section 2.7 we find "block" to mean "frame"
then "bitstream of certain length" then "elements" which apparently are pieces thereof (?)
Then in the next paragraph (2.8) "block" is a RS block etc..
I would recommend the usage of "encoded frame" and "encoded frame fragment"
3. section 2.15 defines an "info stream" (and then the term "info byte" is used a lot
in the whole document) which looks to me like a rather extreme short cut
especially if it is meant to lead the reader to assume that this level of abstraction
can serve as some proof that this specification can work with *any* media stream.
Specifically recent audio codecs dont have a "bitstreams" structure (or byte-stream either)
in the traditional sense that if encoded frame boundaries are not transported
explicitely the decoder cannot find them.
Then there is this extremely mysterious parenthesis:
"(e.g. as specified in the respective RTP profile
for the media codec in use)" which confuses me rather badly.
Is that the "normal" RTP payload format for the media ?
if yes, say so, then explain why and how it would help.
if no, (which I suspect) the way a receiver can reconstruct the media stream structure i.e.
at least encoded frames boundaries and time line after de-packetization must be specified.
As mentioned (a bit late) in section 9 UXP creates a completely "new packetization"
(by contrast with ULP) of the original media stream, therefore it would be useful to
at least add a few paragraphs about how one is supposed to "replace" the
functionality that RTP packets play when transporting the *same media* in
"normal" RTP i.e. transport of encoded frame boundaries and associated media time....
For example section 6.12 says in another mysterious parenthesis
"(the source decoder may be informed about the missing info stream,
if required)". Informed of what ? And how ?
If -as I suspect- this scheme works only for self-timed self-framed media
streams, this should be clearly indicated preferably much early than in
the discussion comparing it with ULP (section 9), i.e. in the abstract
and introduction (!)
3bis. The document would greatly benefit from a few numerical examples based
on realistic media streams. Examples covering the usage of existing "real life" codecs
would be very useful for both audio and video (create an Appendix ?)
4.The document does not mention anything about the complexity of RS
computations (especially by comparison with XOR ?) and that could be
badly misleading for naive potential implementers (Is not it so that
the RS processing complexity is several orders of magnitude
higher than XOR ?)
4bis.The document does not clearly explain if RS code computation is
required when no losses occur (I hope not).
Could there be a security consequences that an attacker could, by creating
excess traffic, trigger losses, themselves triggering more RS computations,
which in turn would create significant additional ressource usage in decoders ...
a kind of Degradation Of Ressource Attack
Replace all occurences of "byte" with "octet"
Some acronyms/names are not fully explained/explicit or localized:
* there is a "forward" declaration of "TB" (point 9)
* CA_i is not expanded (IMHO variable names should either
have a meaning or be based on a well known convention right ?)
* AV is not expanded (while SI is )
Section 5 mention scalability in MPEG-4: Can MPEG-4 Video Packet and data Partition be used as example ?
In the references there is a MPEG working document (M4204) which status should be checked (maybe hard to *legally* get it no ?)
philippe.gentric <at> philips.com