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@mailbag.intel.com