please send information on h.323

Larry Govedich lgovedi1 at TAMPABAY.RR.COM
Mon Oct 16 08:39:04 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