Dear Experts,
Adam Li:
It seems that the conditions described in the document can hardly be called "reasonable and fair conditions".
Strong language, Adam, but not completely unfair. Here my comments:
0. General: Q.15 has an extensive set of simulation conditions for video. I would strongly recommend that you, Gero, and others working on simulation conditions involving video quality take a look at these, before coming up with something different. I understand that you are evaluating transport stack extensions, but as Adam said, it is unfair to do so based on video assumptions that are unrealistic. 1. Annex O, Scalability: should go. There is really no evidence at all, that Annex O was ever used in a product design (true for most layered codecs). Also, as far as I know, there is no "simple scalable profile" in any ITU recommendation or associated document -- this sounds more like MPEG. Terminology counts here -- this should be edited. Finally, MPEG-oriented folk may not be aware, but whenever spatial or SNR sclability in H.263 is involved then there are at least two independent coding loops running. This is not a good idea for any battery powered device. (In fact, as the market tells us, it is not a good idea for ANY device :-) 2. Section 3 does not use any RTP payload format. The use of RFC2429 should be added here. Along with information which mechanisms of RFC2429 should be used, whether interleaved GOB packetization etc. etc. This section clearly needs more work. Take a look at TMN12 on this issue. 3. Section 4, PDCP, no header compression: I'm not sure that this is a good idea as it stands. The header overhead is substantial, and the need for much of the header information is not so critical, especially on the link between base station and terminal. Also, damaged IP-UDP-RTP headers are similarly critical to bit errors as conmpressed heasders -- what happens, if a bit error hits RTP's PT field (or the destin IP address)? As the minimum I would suggest to assume bit error free header transmission. Better would be to specify a concealment/repair strategy fore those headers. 4. RLC: soudsd reasonable to me. 5. Physical simu: sound reasonable to me 6. Frame loss: a scale should be provided, i.e. simulations shall be performed at a p of 0.01 0.03 0.1. 7: Section 7: it#s good that uyou use TMN11 modified PSNR. However, subjective assessment should be added. Ask Q.154 for help on this.
My two cents.
Stephan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com