test conditions provided
Dear experts,
the long lasting diskussion about the superiority of one of the proposals concerning error resilient transmission of progressive multimedia streams(H.323 Annex I) needs to be decided on an objective basis soon.
Therefor we are providing reasonable and fair test conditions.
The test conditions are focused on a common UMTS scenario with video input and PSNR as an objective quality measurement. Furthermore every step in between is well defined and a graphic visualization of the outcome is the ideal and easy basis, with not much room for interpretation, for the decision process.
Comments, questions and supplements are welcome.
Best wishes Gero Baese
Dear experts and Mr. Gero,
It seems that the conditions described in the document can hardly be called "reasonable and fair conditions".
For example, for Media codecs, it specifies H.263 with Annex O. As we all know, Annex O (with spatial, temporal and SNR scalability) is NOT in the Wireless Profiles of H.263. Indeed, it is not in ANY of the profiles defined in H.263.
The whole Annex O is such a very complex algorithm, that it is NOT even in the most complex profiles where complexity is not that much a concern. It is really unimaginable that any mobile applications will use Annex O.
If the Siemens proposal needed such a un-realistic scenario to provide any possible gain, the wireless connection oriented Annex I seems is not the right place for it.
Since Mr. Gero have just proposed the condition now, he may have enough resource to test it before the document submission date. Maybe you can test it also without Annex O, Mr. Gero?
Sincerely,
Adam Li
---------- Adam H. Li, Ph.D. Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax)
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Baese Gero Sent: Friday, October 13, 2000 7:38 AM To: ITU-SG16@mailbag.cps.intel.com Subject: test conditions provided
Dear experts,
the long lasting diskussion about the superiority of one of the proposals concerning error resilient transmission of progressive multimedia streams(H.323 Annex I) needs to be decided on an objective basis soon.
Therefor we are providing reasonable and fair test conditions.
The test conditions are focused on a common UMTS scenario with video input and PSNR as an objective quality measurement. Furthermore every step in between is well defined and a graphic visualization of the outcome is the ideal and easy basis, with not much room for interpretation, for the decision process.
Comments, questions and supplements are welcome.
Best wishes Gero Baese
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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
participants (3)
-
Adam Li -
Baese Gero -
Stephan Wenger