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
Mr. Baese, experts,
For evaluation of error protection schemes, it really make sense to use video codec that are mature and widely used instead of a particular video codec that is still early in development stage.
The sole reason that there is a software implementation of H.26L does not at all make it a suitable criteria for selection of error protection schemes. The current development status of H.26L and its complexity (which means it is not likely to be used on mobile environment immediately even after it is finished) indicates that it is currently not the proper platform to judge the algorithms for Annex I - no matter it has an implementation or not.
Also, I would like to remind Mr. Baese that the the joint discussion between Q.13 and Q.15 on video codec issue has reached conclusion at Geneva. Here I quote the last paragraph of the related section from the meeting report:
"The Q.15 Rapporteur's final comment was that if you want to do testing that requires error resilience, then H.263 is the clear choice. There needed to be strong justification for using another codec."
I hope there should be agreement on the testing codec soon.
Regards,
Adam Li
---------- Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax)
Just a thought:
would it be possible to use a common implementation of H.263+, e.g. by a third-party company that could volunteer to provide encoded streams for parties implementing the H.323-I simulations and decoding transmission-disturbed bitstreams provided back to it? This would circumvent the unavailability of a common, publicly available H.263 implementation and provide that the same H.263 implementation is used by all parties.
Another option would be that one company provides e.g. an executable version of H.263 (under a specific NDA for this particular purpose) to the parties simulating H.323-I. This would accomplish the same purpose.
All in support of a good spirit of cooperation!
Best regards, Simao
-- =========================================================================== Simao Ferraz de Campos Neto, Scientist *All comments are strictly my own* LMGT/COMSAT Laboratories Tel: +1-301-428-4516 22300 Comsat Drive Fax: +1-301-428-9287 Clarksburg MD 20871 - USA E-mail: simao.campos@labs.comsat.com =========================================================================== ******** Practice random kindness and senseless acts of beauty ******** ===========================================================================
Hi, Simao,
Thank you very much for your email. That would be a great idea. Enclosed is the document that discribed the detailed simulation scenario condition. Time seems to be quite tight for the document deadline of this meeting now.
I think most of the issues in the testing condition documents are settled now. We have both agreed on use H.263 profile 3 and 4, generating bitstream with packets fits the MTU, and ploting the rate distortion curve. If there is any details in this document that Mr. Baese would like to discuss, he is very welcome to bring it up.
See you in Tasmania.
Adam
---------- Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax)
-----Original Message----- From: Simao Campos-Neto [mailto:simao.campos@labs.comsat.com] Sent: Wednesday, February 21, 2001 2:20 AM To: Adam Li Cc: ITU-SG16@mailbag.cps.INTEL.COM Subject: Re: Video codec for H.323 Annex I
Just a thought:
would it be possible to use a common implementation of H.263+, e.g. by a third-party company that could volunteer to provide encoded streams for parties implementing the H.323-I simulations and decoding transmission-disturbed bitstreams provided back to it? This would circumvent the unavailability of a common, publicly available H.263 implementation and provide that the same H.263 implementation is used by all parties.
Another option would be that one company provides e.g. an executable version of H.263 (under a specific NDA for this particular purpose) to the parties simulating H.323-I. This would accomplish the same purpose.
All in support of a good spirit of cooperation!
Best regards, Simao
--
========= Simao Ferraz de Campos Neto, Scientist *All comments are strictly my own* LMGT/COMSAT Laboratories Tel: +1-301-428-4516 22300 Comsat Drive Fax: +1-301-428-9287 Clarksburg MD 20871 - USA E-mail: simao.campos@labs.comsat.com ================================================================== =========
******** Practice random kindness and senseless acts of beauty ********
=========
participants (3)
-
Adam Li -
Baese Gero -
Simao Campos-Neto