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 available H.263/L. 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.
Best Wishes Gero Baese
-----Ursprüngliche Nachricht----- Von: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] Gesendet am: Freitag, 16. Februar 2001 03:12 An: Baese Gero Cc: ITU-SG16@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
standard.
I don't believe it be wise to resort on H.26L, for at least three reasons:
- 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
Dear Mr. Baese, experts,
For those who has not been in this discussion for a while, the topic now is which video codec to be used for simulation and performance evaluation for H.323 Annex I (Transmission over Error Prone Channels).
Mr. Baese (and UXP team from Siemens) requists to use H.26L as the testing codec. However, it is our believe and general agreement in the group that H.26L is in its early development stage. For this reason, it is not wise to evaluate protection schemes based on a video codec which has features added constantly and will likely to have different behavior under error environment in the future.
H.263 version 3 is the latest video codec just recently published by Q.6. H.263 is a well established video coding standard orignally published in 1996. It is a very stable and mature standard, and is widely used in video conferencing and other applications. The algoritms are detailed in the H.263 and TMN documents from Q.6, and has been implemented and verified by many labs and companies. It is obvious that it is a more proper video codec to be used to evaluate the protection scheme than H.26L. This is also the opinion of Q.6.
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.
Regards,
Adam
---------- Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax)
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Baese Gero Sent: Friday, February 16, 2001 5:19 AM To: ITU-SG16@mailbag.cps.INTEL.COM Subject: AW: AW: H.323 Annex I
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 available H.263/L. 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.
Best Wishes Gero Baese
-----Ursprüngliche Nachricht----- Von: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] Gesendet am: Freitag, 16. Februar 2001 03:12 An: Baese Gero Cc: ITU-SG16@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
standard.
I don't believe it be wise to resort on H.26L, for at least three reasons:
- 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
All,
For packet-switched multimedia services in 3GPP, the only mandatory video codec is H.263 baseline. MPEG-4 Simple Profile @ Level 0 and H.263 Profile 3 @ Level 10 are optional. Since Annex I is for error prone channels (which will most likely be 3G cellular channels), I suggest one of the 3GPP codecs be used. Better yet, both MPEG-4 Simple Profile and H.263 Profile 3 should be used. MPEG-4 Simiple Profile should show good improvement with unequal error protection using data partitioning. H.263 Profile 3 is less suited for error prone environments. However, increased protection of the packet containing the picture header in combination with slice structuring should yield better results than without error protection.
You may also want to think about using header RTP header compression for error-prone channels (when I last looked, this was still in the draft stage).
Barry
At 12:00 PM 2/16/01 -0800, Adam Li wrote:
Dear Mr. Baese, experts,
For those who has not been in this discussion for a while, the topic now is which video codec to be used for simulation and performance evaluation for H.323 Annex I (Transmission over Error Prone Channels).
Mr. Baese (and UXP team from Siemens) requists to use H.26L as the testing codec. However, it is our believe and general agreement in the group that H.26L is in its early development stage. For this reason, it is not wise to evaluate protection schemes based on a video codec which has features added constantly and will likely to have different behavior under error environment in the future.
H.263 version 3 is the latest video codec just recently published by Q.6. H.263 is a well established video coding standard orignally published in 1996. It is a very stable and mature standard, and is widely used in video conferencing and other applications. The algoritms are detailed in the H.263 and TMN documents from Q.6, and has been implemented and verified by many labs and companies. It is obvious that it is a more proper video codec to be used to evaluate the protection scheme than H.26L. This is also the opinion of Q.6.
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.
Regards,
Adam
Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax)
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Baese Gero Sent: Friday, February 16, 2001 5:19 AM To: ITU-SG16@mailbag.cps.INTEL.COM Subject: AW: AW: H.323 Annex I
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 available H.263/L. 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.
Best Wishes Gero Baese
-----Ursprüngliche Nachricht----- Von: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] Gesendet am: Freitag, 16. Februar 2001 03:12 An: Baese Gero Cc: ITU-SG16@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
standard.
I don't believe it be wise to resort on H.26L, for at least three reasons:
- 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
Barry Aronson Barry Aronson Consulting, Inc. 33 Lake Shore Ave. Beverly, MA 01915-1907 USA
E-mail: baronson@ieee.org Voice: +1 978-232-3994 Fax: +1 978-232-9220 Video: H.320, H.323, and H.324
Hello,
Do you know when I can see an example for Fax call flow diagram
Thank you all.
Arie Reches Program Manager Voice Systems Division, Com21 P.O Box 45138 Jerusalem 91450 Israel
Tel : +972 2 541 1568 Fax: +972 2 586 7590 E-mail: areches@com21.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Hello,
Do you know where can I see an example for Fax call flow diagram ?
Thank you all.
Arie Reches Program Manager, Voice Systems Division, Com21 P.O Box 45138 Jerusalem 91450 Israel
Tel : +972 2 541 1568 Fax: +972 2 586 7590 E-mail: areches@com21.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (4)
-
Adam Li -
Arie Rehes -
Baese Gero -
Barry Aronson