test conditions provided
Stephan Wenger
stewe at CS.TU-BERLIN.DE
Mon Oct 16 07:13:01 EDT 2000
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 at mailbag.intel.com
More information about the sg16-avd
mailing list