AW: AW: H.323 Annex I
Gero.X.Baese at MCHP.SIEMENS.DE
Fri Feb 16 08:18:54 EST 2001
Dear Stephan, experts,
thank you for your exact description of the current
situation concerning the H.263 software.
Unfortunately, other parts of your email are quite
confusing I guess. I will try to clarify several points.
First of all - fairness. We consider it unfair to
use a professional, for speed and quality, optimized
version of the software instead of an officially
I myself are involved in H.26L standardization, as
you know. It's not a secret. I was involved in H.263
standardization as well. I can't see any unfairness
in working for different groups of the ITU or knowing
other people working for other parts of the organisation.
Several times we stressed the point that the results
have to be reproducible by everybody. An official version
of the software should be used. The test scenario should
be agreed on by both parties. If there is anything missing
to exclude one-sided advantages please let us know.
We are completely aware of possibly technical changes of
H.26L. We are not going to optimize Annex I for any special
video codec. Using it is a pragmatic solution to the problem
of the lack of officially available software for H.263.
>From a university point of view it might look different. For
companies H.263 is reality and H.26L will be the next standard
used in products. Caused by the AAP adopted by the ITU
standards will arrive much earlier at the market now.
Hope this helps everybody to understand our intentions.
> -----Ursprüngliche Nachricht-----
> Von: Stephan Wenger [mailto:stewe at cs.tu-berlin.de]
> Gesendet am: Freitag, 16. Februar 2001 03:12
> An: Baese Gero
> Cc: ITU-SG16 at mailbag.cps.INTEL.COM
> Betreff: Re: AW: H.323 Annex I
> Dear Gero,
> At 05:32 PM 2/14/2001 +0100, Baese Gero wrote:
> >If there is no official software available for H.263 containing
> >all annexes needed for the tests, as Stephan Wenger pointed
> out, we can
> >only restrict ourselves to H.26L. Otherwise we are not comparing our
> >methods but rather special implementations of a video coding
> I don't believe it be wise to resort on H.26L, for at least
> three reasons:
> 1. H.26L is in a relatively early stage of standardization,
> and especially
> the network adaptation layers are bound to change
> significantly. While
> there is a controlled software available, this software is
> going to change
> often at least for another year. Not a good start if you
> want to have
> reproducible results.
> 2. Due to its computational complexity and due to the timing of
> standardization and development of H.26L, it will likely take
> several years before the first H.26L products will be
> available. Hence
> there is little point to rush out an Annex I that is optimized
> (explicitly or implicitly) for H.26L. And, once it is out, it will
> probably not see deployment in the mobile field at first, again
> due to its computational complexity.
> 3. An argument of fairness: Thomas Stockhammer, one of the key
> contributors of the error resilience / NAL work in H.26L,
> is somewhat
> attached to the Siemens/HHI/TU Muenchen group. Not exactly fair,
> considering that, as far as I know, UCLA and Samsung are not
> directly involved in the H.26L standardization process. H.263++,
> in contrast, is a ratified standard and thus gives anyone a chance
> to implement it the best way he/she can.
> I don't really know why I bother to write this EMail at all; you know
> my position on Annex I in general... I guess, point #3 and a personal
> inclination to fairness is my main reason.
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