Dear Mr. Li, experts,
thank you very much for the response of our questions. The software problem still exists.
All the algorithms for H.263 are detailed in the H.263 and TMN documents in Q.6. As far as I know,UBC (University of British Columbia) has a (semi-official) sample software implementation of the codec.
Hope it helps.
Unfortunately not. This informations were available at the Geneva meeting already - hence we raised the question there.
We need an official version of the software. Using different types of software leads to not comparable results and will delay the work of the group anymore. Our interest is to finish the test before the next meeting. 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 standard. Hopefully you can agree on that, so that we can now start with the simulations.
Best Wishes Gero Baese
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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 standard.
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.
Stephan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Baese Gero -
Stephan Wenger