suscribe

[Aziz ABOUCHI]

Dear Mr. Li, experts,

we are really happy to see some more people are interested
in the Annex I discussion now. Unfortunately, at the moment
the discussion is not focussing on the exact point.

Without any doubt H.263 is stable and well documented.
Our proposals intention was not(!) using H.26L instead of H.263.
It was to find a practical solution to get useful results till
the next meeting.

Only H.26L software is officially available for both parties. Using
proprietary H.263 software would lead to not comparable results. In
other words, the basis for the decision of the group will be missing.
We really aim at providing the group with what is necessary for the
decision, therefore our proposal is to restrict ourselves to H.26L
for practical reasons.


> This topic has been discussed in the meeting last time
> in Geneva. I think a conclusion has been reached then.
> If Mr. Baese haven't read the study group meeting report,
> I suggest you go ahead and read it. Hope we can get over
> this soon, and focus on producing more solid results for
> this meeting.

A conclusion has been reached at the Geneva meeting and we don't think
any misinterpretation is possible.
Citation of the Geneva meeting report of Dale Skran:
        "The coders compared shall be H.263++ (the standard ITU-T code)
        and H.26L (as recommended by Q15)."

There is no appropriate "standard ITU-T code" for H.263 available as
we learned from Stephan Wenger. Using proprietary H.263 software is
considered being unfair. Our proposals intention was to escape this
quandary for the moment.
By the time the H.263 software is available at the ITU-T we strongly
support testing H.323 Annex I with it.


Best Wishes
Gero Baese


PS: Mr. Li, are there open questions concerning the simulation
    scenario still or do you agree on that document ?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com