February 2000 - sg16-avd - lists.packetizer.com

Re: H.245 for videoFastUpdateMB, videoFastUpdateGOB, videoNotDeco dedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800)
by Gary Sullivan 17 Feb '00

17 Feb '00

Roni et al, Yes, but it is not proper to make a "normative reference" to an appendix. If the only definition in H.263 that is consistent with the intended interpretation is the definition in an appendix, then H.263 must not be referenced as the source of the definition. An appendix is "advice" not "prescription". It does not have the force that the body text or an annex has. The H.245 text needs to be changed so that it contains the definition right in the H.245 text, not just a reference to H.263. Also there are two definitions of macroblock numbering in H.263. The one that's not in the appendix starts its numbering from zero. Since that's the only one that is proper for referencing, the usual presumption would be that it is the one to look at for the definition. (It's in Annex K.) -Gary +> -----Original Message----- +> From: Roni Even [mailto:Roni_e@accord.co.il] +> Sent: Thursday, February 17, 2000 1:51 AM +> To: 'Mailing list for parties associated with ITU-T Study Group 16' +> Cc: Gary Sullivan +> Subject: RE: H.245 for videoFastUpdateMB, videoFastUpdateGOB, +> videoNotDeco dedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800) +> +> +> Gary, +> +> About videoNotDecodedMBs Appendix I/H.263 explains the +> macroblocks numbering +> from 1 to N, it looks consistent with H.245 to me. +> +> Appendix I/H.263 +> +> Assume N macroblocks within each frame enumerated mb = 1...N +> from top-left +> to bottom-right. Let {nerr, mbfirst, mblast} be the feedback +> message to the +> encoder, where mbfirst * mb * mblast indicates a set of erroneous +> macroblocks in frame nerr. +> +> H.245 +> videoNotDecodedMBs indicates to the far-end video encoder +> that a set of MBs +> has been received erroneously and that any MB in the +> specified set has been +> treated as not coded. The encoder may use this information +> to compensate +> transmission errors, as illustrated in Appendix I/H.263. +> firstMB indicates +> the number of the first MB treated as not coded, and +> numberOfMBs indicates +> the number of MBs treated as not coded. The MB numbering is +> done according +> to H.263. The temporal reference of the picture containing +> not decoded MBs +> is indicated in temporalReference. This indication shall +> only be used with +> the H.263 video compression algorithm. +> +> I see the problem with videoFastUpdateMB +> Roni Even +> +> +> +> ********************************************** +> Roni Even +> VP Product Marketing +> Accord Networks +> Email: roni_e(a)accord.co.il +> Tel: +972-3-9251412 +> Fax: +972-3-9211571 +> *************************************************** +> +> > -----Original Message----- +> > From: Gary Sullivan [SMTP:garysull@MICROSOFT.COM] +> > Sent: Sun, February 13, 2000 9:31 PM +> > To: ITU-SG16(a)MAILBAG.INTEL.COM +> > Subject: H.245 for videoFastUpdateMB, videoFastUpdateGOB, +> > videoNotDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 +> 19:24:45 -0800) +> > +> > +> > +> > +> > +> > This time copying the APC people as well, since they +> should be the H.245 +> > gurus: +> > +> > +> -----Original Message----- +> > +> From: Gary Sullivan [mailto:garysull@microsoft.com] +> > +> Sent: Saturday, February 12, 2000 7:29 PM +> > +> To: Thomas Wiegand (E-mail) +> > +> Cc: ITU-T Q. 15/SG16 Advanced Video Coding Experts +> Group (E-mail) +> > +> Subject: Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800 +> > +> +> > +> +> > +> ITU-T Advanced Video Coding Experts Group (Q.15/SG16) +> > +> Email from Gary Sullivan <garysull(a)microsoft.com>: +> > +> +> > +> +> > +> To the U. Erlangen folks and other video experts, +> > +> +> > +> I have the strong impression that we have been here +> before discussing +> > +> this same issue. I thought we clarified these issues in H.245. +> > +> However, I'm looking at H.245 and I'm seeing what looks +> like some old +> > +> (pre-1998) text. Since the records on this would be at +> > +> least a couple +> > +> of years old, I don't seem to be able to track them all down. +> > +> +> > +> I have questions about two paragraphs in H.245. Here's the +> > +> first one: +> > +> +> > +> videoFastUpdateGOB SEQUENCE +> > +> { +> > +> firstGOB INTEGER (0..17), +> > +> numberOfGOBs INTEGER (1..18) +> > +> }, +> > +> +> > +> videoFastUpdateMB SEQUENCE +> > +> { +> > +> firstGOB INTEGER (0..255) OPTIONAL, +> > +> firstMB INTEGER (1..8192) OPTIONAL, +> > +> numberOfMBs INTEGER (1..8192), +> > +> ... +> > +> }, +> > +> +> > +> "videoFastUpdateMB commands the far-end video encoder +> to perform a +> > +> fast update of one or more MBs. firstGOB indicates +> the number of +> > +> the first GOB to be updated and is only relative to +> H.263, firstMB +> > +> indicates the number of the first MB to be updated and is only +> > +> relative to H.261 and numberOfMBs indicates the +> number of MBs to +> > +> be updated. It shall only be used with video compression +> > +> algorithms that define MBs, for example, H.261 and H.263. +> > +> Terminals may respond to this command with a GOB update which +> > +> includes the MBs requested." +> > +> > +> > (If I now recall correctly, it was not U. Erlangen that +> put the above +> > ambiguous statements into H.245 -- I believe they pre-dated the +> > error tracking work.) +> > +> > Let me try a little more on the above: +> > +> > A GOB in H.261 is not a raster-scan-order set of macroblocks +> > in a picture (instead it is a raster-scan-order set of +> > macroblocks in a rectangle within the picture). But a GOB +> > in H.263 is a raster-scan-order set of macroblocks in a picture. +> > +> > Reviewing GOB layout in H.261, each GOB contains 33 MBs. +> > +> > In H.261 CIF, GOBs are laid out in the picture like this: +> > +> > 1 2 +> > 3 4 +> > 5 6 +> > 7 8 +> > 9 10 +> > 11 12 +> > +> > In H.261 QCIF the layout is +> > +> > 1 +> > 3 +> > 5 +> > +> > and each GOB has a vertical size of 3 macroblocks and a horizontal +> > size of 11 macroblocks. In H.261, MBs are numbered from 1 to 33 +> > in raster scan order within each GOB. +> > +> > In H.263, GOBs are numbered like this in all picture sizes: +> > +> > 0 +> > 1 +> > 2 +> > . +> > . +> > . +> > +> > The height of a GOB in H.263 depends on the height of the picture, +> > with QCIF and CIF containing a single row of macroblocks per GOB +> > and taller pictures containing 2 or 4 rows of macroblocks per GOB. +> > +> > So my guess is that when it is saying firstGOB is "only relative to +> > H.263", +> > it is saying that we should assume the GOB layout is in +> the manner of +> > H.263. So that a GOB is synonymous with one or more rows +> of macroblocks. +> > +> > Then when it says firstMB is "only relative to H.261" I'm +> guessing it is +> > saying that the MBs should be numbered starting from MB +> number 1 being the +> > first MB in the GOB and then proceeding in raster scan +> order within the +> > GOB. +> > +> > Does the above interpretation seem correct? +> > +> > If firstMB + numberOfMBs > 11, it's not clear what to assume. In +> > H.261 this would address a GOB in the next row of MBs in +> the picture, +> > but in H.263 there are other MBs in the same GOB and jumping to the +> > next row of MBs in the picture would break my assumption +> that bitstream +> > order would be the most reasonable. So my guess is that the order +> > assumed in the scanning of MBs should depend on the bitstream order +> > normal for the particular video codec in use. +> > +> > +> +> > +> What the heck does "only relative to H.263" mean? +> > +> What does "only relative to H.261" mean? +> > +> What values are you supposed to send with this command? +> > +> +> > +> Here's the next one: +> > +> +> > +> videoNotDecodedMBs SEQUENCE +> > +> { +> > +> firstMB INTEGER (1..8192), +> > +> numberOfMBs INTEGER (1..8192), +> > +> temporalReference INTEGER (0..255), +> > +> ... +> > +> }, +> > +> +> > +> "videoNotDecodedMBs indicates to the far-end video +> encoder that a +> > +> set of MBs has been received erroneously and that any +> MB in the +> > +> specified set has been treated as not coded. The +> encoder may use +> > +> this information to compensate transmission errors, +> as illustrated +> > +> in Appendix I of H.263. firstMB indicates the number +> of the first +> > +> MB treated as not coded, and numberOfMBs indicates +> the number of +> > +> MBs treated as not coded. The MB numbering is done +> according to +> > +> H.263. The temporal reference of the picture containing not +> > +> decoded MBs is indicated in temporalReference. This indication +> > +> shall only be used with the H.263 video compression +> algorithm." +> > +> +> > +> What does "numbering according to H.263 mean"? The +> only numbering +> > +> defined in H.263 starts with macroblock number 0, not 1. +> > +> > +> > Here my guess would be that MBs are numbered in raster scan order +> > from 1 to the number of MBs in a picture. +> > +> > +> > +> +> > +> I really thought we fixed both of these problems two years ago. +> > +> +> > +> Best Wishes, +> > +> +> > +> Gary Sullivan +> > +> +> > +> +> > +> ------------------------------------------------------------- +> > +> ------------------- +> > +> *** ITU-T Advanced Video Coding Experts Group (Q.15/SG16) +> > +> Email List Message *** +> > +> To send messages, address them to +> > +> "itu-adv-video(a)standard.pictel.com". +> > +> To subscribe or unsubscribe, send email to +> > +> "majordomo(a)standard.pictel.com". +> > +> Note: Only people whose exact email address is subscribed to +> > +> the list can post. +> > +> Subscriptions: "subscribe itu-adv-video +> > +> YOUR-EMAIL-ADDRESS" in message body. +> > +> Unsubscriptions: "unsubscribe itu-adv-video +> > +> YOUR-EMAIL-ADDRESS" in message body. +> > +> ------------------------------------------------------------- +> > +> ------------------- +> > +> +>

1 0

H.323: Annex-H editor
by Edgar Martinez [1] 17 Feb '00

17 Feb '00

Dear SG16 Mobility: I was informed that: >Dale Skran, the Q13 > Rapporteur, was not happy in that he only learnt that you were not coming > after the meeting started - he did not get any message from you. I had sent email to Dale and AT&T one week before the meeting started that I could not attend (copy below). I been re-assigned to help out in other IP area's in Motorola. The work in SG16 is very important to Motorola and will continue to support SG16 and the Mobility-Ahoc Group. As for the editorship for Annex-H. I request that a permanent Editor be assign, since I will be more heavily involved in more ALL IP mobile standards. Standard meeting conflicts are already taking a toll on my time. I will still be kept informed on the SG16 mobility work, and will provide contributions and comments at the appropriate times. In our profession reassignment happens all the time, and I am happy to say that IP support is growing so fast that we have become value resources. Best Regards to all, Ed > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@cig.mot.com] > Sent: Tuesday, February 01, 2000 1:13 PM > To: Roy, Radhika R, ALARC; dskran(a)ascend.com > Subject: Geneva-2000 ITU > Importance: High > > Dear Dale and Radhika, > > I having work related problems here, and at the moment > I am not planning to go Geneva. Please put a > Temporary Editor in my place. > > Best Regrads, > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: H.245 for videoFastUpdateMB, videoFastUpdateGOB, videoNotDeco dedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800)
by Roni Even 17 Feb '00

17 Feb '00

Gary, About videoNotDecodedMBs Appendix I/H.263 explains the macroblocks numbering from 1 to N, it looks consistent with H.245 to me. Appendix I/H.263 Assume N macroblocks within each frame enumerated mb = 1...N from top-left to bottom-right. Let {nerr, mbfirst, mblast} be the feedback message to the encoder, where mbfirst * mb * mblast indicates a set of erroneous macroblocks in frame nerr. H.245 videoNotDecodedMBs indicates to the far-end video encoder that a set of MBs has been received erroneously and that any MB in the specified set has been treated as not coded. The encoder may use this information to compensate transmission errors, as illustrated in Appendix I/H.263. firstMB indicates the number of the first MB treated as not coded, and numberOfMBs indicates the number of MBs treated as not coded. The MB numbering is done according to H.263. The temporal reference of the picture containing not decoded MBs is indicated in temporalReference. This indication shall only be used with the H.263 video compression algorithm. I see the problem with videoFastUpdateMB Roni Even ********************************************** Roni Even VP Product Marketing Accord Networks Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: Gary Sullivan [SMTP:garysull@MICROSOFT.COM] > Sent: Sun, February 13, 2000 9:31 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.245 for videoFastUpdateMB, videoFastUpdateGOB, > videoNotDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800) > > > > > > This time copying the APC people as well, since they should be the H.245 > gurus: > > +> -----Original Message----- > +> From: Gary Sullivan [mailto:garysull@microsoft.com] > +> Sent: Saturday, February 12, 2000 7:29 PM > +> To: Thomas Wiegand (E-mail) > +> Cc: ITU-T Q. 15/SG16 Advanced Video Coding Experts Group (E-mail) > +> Subject: Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800 > +> > +> > +> ITU-T Advanced Video Coding Experts Group (Q.15/SG16) > +> Email from Gary Sullivan <garysull(a)microsoft.com>: > +> > +> > +> To the U. Erlangen folks and other video experts, > +> > +> I have the strong impression that we have been here before discussing > +> this same issue. I thought we clarified these issues in H.245. > +> However, I'm looking at H.245 and I'm seeing what looks like some old > +> (pre-1998) text. Since the records on this would be at > +> least a couple > +> of years old, I don't seem to be able to track them all down. > +> > +> I have questions about two paragraphs in H.245. Here's the > +> first one: > +> > +> videoFastUpdateGOB SEQUENCE > +> { > +> firstGOB INTEGER (0..17), > +> numberOfGOBs INTEGER (1..18) > +> }, > +> > +> videoFastUpdateMB SEQUENCE > +> { > +> firstGOB INTEGER (0..255) OPTIONAL, > +> firstMB INTEGER (1..8192) OPTIONAL, > +> numberOfMBs INTEGER (1..8192), > +> ... > +> }, > +> > +> "videoFastUpdateMB commands the far-end video encoder to perform a > +> fast update of one or more MBs. firstGOB indicates the number of > +> the first GOB to be updated and is only relative to H.263, firstMB > +> indicates the number of the first MB to be updated and is only > +> relative to H.261 and numberOfMBs indicates the number of MBs to > +> be updated. It shall only be used with video compression > +> algorithms that define MBs, for example, H.261 and H.263. > +> Terminals may respond to this command with a GOB update which > +> includes the MBs requested." > > > (If I now recall correctly, it was not U. Erlangen that put the above > ambiguous statements into H.245 -- I believe they pre-dated the > error tracking work.) > > Let me try a little more on the above: > > A GOB in H.261 is not a raster-scan-order set of macroblocks > in a picture (instead it is a raster-scan-order set of > macroblocks in a rectangle within the picture). But a GOB > in H.263 is a raster-scan-order set of macroblocks in a picture. > > Reviewing GOB layout in H.261, each GOB contains 33 MBs. > > In H.261 CIF, GOBs are laid out in the picture like this: > > 1 2 > 3 4 > 5 6 > 7 8 > 9 10 > 11 12 > > In H.261 QCIF the layout is > > 1 > 3 > 5 > > and each GOB has a vertical size of 3 macroblocks and a horizontal > size of 11 macroblocks. In H.261, MBs are numbered from 1 to 33 > in raster scan order within each GOB. > > In H.263, GOBs are numbered like this in all picture sizes: > > 0 > 1 > 2 > . > . > . > > The height of a GOB in H.263 depends on the height of the picture, > with QCIF and CIF containing a single row of macroblocks per GOB > and taller pictures containing 2 or 4 rows of macroblocks per GOB. > > So my guess is that when it is saying firstGOB is "only relative to > H.263", > it is saying that we should assume the GOB layout is in the manner of > H.263. So that a GOB is synonymous with one or more rows of macroblocks. > > Then when it says firstMB is "only relative to H.261" I'm guessing it is > saying that the MBs should be numbered starting from MB number 1 being the > first MB in the GOB and then proceeding in raster scan order within the > GOB. > > Does the above interpretation seem correct? > > If firstMB + numberOfMBs > 11, it's not clear what to assume. In > H.261 this would address a GOB in the next row of MBs in the picture, > but in H.263 there are other MBs in the same GOB and jumping to the > next row of MBs in the picture would break my assumption that bitstream > order would be the most reasonable. So my guess is that the order > assumed in the scanning of MBs should depend on the bitstream order > normal for the particular video codec in use. > > +> > +> What the heck does "only relative to H.263" mean? > +> What does "only relative to H.261" mean? > +> What values are you supposed to send with this command? > +> > +> Here's the next one: > +> > +> videoNotDecodedMBs SEQUENCE > +> { > +> firstMB INTEGER (1..8192), > +> numberOfMBs INTEGER (1..8192), > +> temporalReference INTEGER (0..255), > +> ... > +> }, > +> > +> "videoNotDecodedMBs indicates to the far-end video encoder that a > +> set of MBs has been received erroneously and that any MB in the > +> specified set has been treated as not coded. The encoder may use > +> this information to compensate transmission errors, as illustrated > +> in Appendix I of H.263. firstMB indicates the number of the first > +> MB treated as not coded, and numberOfMBs indicates the number of > +> MBs treated as not coded. The MB numbering is done according to > +> H.263. The temporal reference of the picture containing not > +> decoded MBs is indicated in temporalReference. This indication > +> shall only be used with the H.263 video compression algorithm." > +> > +> What does "numbering according to H.263 mean"? The only numbering > +> defined in H.263 starts with macroblock number 0, not 1. > > > Here my guess would be that MBs are numbered in raster scan order > from 1 to the number of MBs in a picture. > > > +> > +> I really thought we fixed both of these problems two years ago. > +> > +> Best Wishes, > +> > +> Gary Sullivan > +> > +> > +> ------------------------------------------------------------- > +> ------------------- > +> *** ITU-T Advanced Video Coding Experts Group (Q.15/SG16) > +> Email List Message *** > +> To send messages, address them to > +> "itu-adv-video(a)standard.pictel.com". > +> To subscribe or unsubscribe, send email to > +> "majordomo(a)standard.pictel.com". > +> Note: Only people whose exact email address is subscribed to > +> the list can post. > +> Subscriptions: "subscribe itu-adv-video > +> YOUR-EMAIL-ADDRESS" in message body. > +> Unsubscriptions: "unsubscribe itu-adv-video > +> YOUR-EMAIL-ADDRESS" in message body. > +> ------------------------------------------------------------- > +> ------------------- > +>

1 0

Re: Q15: H.245 for videoFastUpdateMB, videoFastUpdateGOB, videoNo tDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800)
by ari.hourunranta＠NOKIA.COM 16 Feb '00

16 Feb '00

Hi I am not giving any answers, but rather pointing out more problems related to the topic. In videoFastUpdateMBs, the statement saying that firstGOB is only relative to H.263 and firstMB is only relative to H.261 sounds weird. You could interpret it so that if you are using H.263 Annex K (slices), you should still request updates for GOBs, although MB-level start index would be much more natural. In case of MPEG-4 visual, use of videoFastUpdateMBs seems to be forbidden, although there is no technical reason why it should be (maybe political?). I am sure most of the implementors use common sense when interpreting the specifications, but still it wouldn't harm if the specification would be understandable. Regards, Ari ------------------------------------------------------------ Ari Hourunranta Nokia Mobile Phones ari.hourunranta(a)nokia.com ------------------------------------------------------------

1 0

question on video transcoder or gateway
by wmshen 15 Feb '00

15 Feb '00

Hello, all experts, I am a Ph.D student working on video communication. I am wondering about how the video transcoder/gateway works between H.261 and H.263, and between IP network and PSTN or ISDN, in paticular i wonder whether there is a method by which bitstreams can be translated directly between H.261 and H.263 format. Who knows the technique details on above topics or where may i get some useful reference infomation? Any help will be approciated. Weiming Shen

1 0

[Fwd: Re:ALL-IP workshop held on 7-9 Feb 2000 in Nice (News release & Docs)]
by Edgar Martinez [1] 15 Feb '00

15 Feb '00

FYI -------- Original Message -------- From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Subject: Re:ALL-IP workshop held on 7-9 Feb 2000 in Nice (News release & Docs) To: TIPHON : Entirely <TIPHON(a)LIST.ETSI.FR> Dear Scott, The work shop I believe was done to benefit both MWIF and 3GPP. What do they have that we do not? 3GPP and MWIF are addressing the Radio Access interface on IP. Motorola has try to include the Radio Access into TIPHON WG7 but have not progress too far. If TIPHON really wants to get into the full end to end fixed and wireless/mobility network All IP solution. We need to address IP Radio Access. We need to work with Tiphon's WG2 architecture team and add a Radio Access Plane. So we can recommend requirements around the Radio (wireless) access plane. In any event without the Radio access on IP we have "no real Wireless mobility with handover" same problem in SG16. Right now both SG16 and TIPHON is working only on Roaming! Motorola will again try to bring up the issue of the direct radio access IP interface to the IP network and adding a Radio Access Plane to the TIPHON architecture. In the next TIPHON meeting and I hope we can get more support. I hope we also Liaison with MWIF and other wireless all IP groups looking for an "real" all IP end to end solution. And not just use the IP network (TIPHON) as a simple VoIP/media Transport or simple Home Location database depository for a 3G Hybrid Mobile Network as it has been proposed in other groups. Ed Scott Cadzow wrote: > This is a summary and pointer to the 3GPP all IP network workshop. It should > be stressed that TIPHON on offering to present our work were brushed aside > and not invited to this workshop. > > Regards, > > Scott > > -----Original Message----- > From: Adrian Zoicas [mailto:Adrian.Zoicas@ETSI.FR] > Sent: 15 February 2000 17:09 > To: UMTS(a)LIST.ETSI.FR > Subject: UMTS mail#15: ALL-IP workshop held on 7-9 Feb 2000 in Nice > (News release & Docs) > > Will the next generation be ALL-IP? > [2000-02-11] A workshop held on 7-9 February 2000 in Nice - France hosted by > Microsoft gathered together over 350 participants to investigate what is one > of the biggest things to hit the 3rd Generation Partnership Project (3GPP) > since its creation! The Internet Protocol (IP) has the ability to achieve > seamlessness across networks, it is believed to be the solution for reducing > the cost of creating and expanding mobile networks and to allow IP-based > services to be rapidly developed for use upon them. > There is already a substantial amount of IP equipment installed for internet > infrastructure and the new challenge is how to re-use this for mobile > networks? > The aim of this workshop was to firstly come up with some clear ideas of > what an All-IP network is - a common understanding is essential to commence > work. It is also necessary to have a common vision with regard to future > phases of All-IP. > The next step will be to integrate the results of these discussions into the > work of each of the 3GPP TSGs. The first phase of the work, establishing > detailed requirements, will be part of 3GPP release 2000. This is due for > completion in December 2000. Co-operation with other bodies, such as the > Internet Engineering Task Force (IETF), will certainly be required. > There are still issues that need to be resolved regarding where to use IP > transport, the requirements for naming and addressing; Mobility Management, > which IP version to use (IPv4 or IPv6) and how to migrate to the chosen IP > version, ..... > http://www.etsi.org/tbnews/Previous/all-IP2000feb.htm > > PS: Documents from the workshop can be found at: > ftp://ftp.3gpp.org/WORKSHOP/0002IP/Docs/ > e.g.: > > AIP-000002 > List of presentations > > AIP-000003 > Defining standards that merge Mobile systems with Internet > Ericsson > > AIP-000004 > Architectural principles > Ericsson > > AIP-000006 > Liaison on All-IP from GSM North America > GSM North America > > AIP-000007 > Next Generation Wireless: Business Drivers for an All-IP network > Lucent Technologies > > AIP-000008 > All IP: Issues Requiring Direction and Decision > Lucent Technologies > > AIP-000009 > Requirements for IP Based UMTS. A Consensus View from the Industry > UMTS Forum > > AIP-000011 > Business Drivers for the IP Based 3G Vision > BT > > AIP-000012 > Evolving Towards the IP Vision > BT > > AIP-000013 > Naming/Numbering and Identification of UMTS Users > BT > > AIP-000014 > Web-Based Network Management for IP Networks > Motorola > > AIP-000015 > Voice and Data legacy Systems - IP interworking > MATRA Nortel Communications > > AIP-000016 > All IP Networks Vision and Migration > Motorola > > AIP-000017 > IP Wireless Network > Cisco Wireless Architecture > > AIP-000020 > All-IP standardisation > GSMA ISG > > AIP-000021 > Report of SA WG2/CN Release 2000 ad-hoc/T WG2 Joint meeting on Release 2000 > > MCC > > AIP-000022 > All-IP Networks Architectures Convergence Mid term vision > Alcatel > > AIP-000023 > 3G TR 22.976 V0.5.0 (ad-hoc group draft) > R Wohlert > > AIP-000024 > Key Results from CN R'00 Ad-Hoc > TSG CN Vice Chairman > > AIP-000025 > Requirements for All-IP. A view of a "Legacy Network" Operator > Mannesmann Mobilfunk > > AIP-000026 > Mobile Wireless Internet Forum (MWIF) Architectural Principles > Vodafone AirTouch > > AIP-000027 > IP based unified networking > Nortel Networks > > AIP-000028 > Nokia Vision of the Mobile Information Society > Nokia > > AIP-000029 > Nokia All-IP System Design Principles > Nokia > > AIP-000030 > Defining standards that merge Mobile systems with Internet > Ericsson > > Best regards > Adrian ZOICAS > ETSI Mobile Competence Centre > mailto:adrian.zoicas@etsi.fr Tel:+33492944221 Fax:+33492385221 > http://www.etsi.org/umts > http://www.3gpp.org > > ------------------------------------------------------------------- > Mail archive for TIPHON can be browsed at the following url : > > http://www.etsi.org/tiphon/mailing.htm > ------------------------------------------------------------------- -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0

Re: Description of URQ??
by Henri M�enp�� 14 Feb '00

14 Feb '00

Hello, I asked this a while ago, but with no success. So, let's try again... This is about callSignalAddress in URQ. H.225v3 states in URQ 7.10.1: "callSignalAddress - This is one or more of the transport call signalling addresses for this endpoint which are to be unregistered." So, unlike I have understood, this sentence would seem to say that I can not just unregister a single alias, but I must have "a spare" callSignalAddress to unregister as well... Does anybody else think this is not the way it should be? /Henri Mäenpää > -----Original Message----- > From: EXT Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: 11. February 2000 19:33 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Description of EndpointAlias in URQ?? > > > Frank, > > > Frank> The "explanatory" text of the EndpointAlias element in the > > Frank> URQ message, contains the following sentence: "The E.164 > > Frank> address, if assigned, is required. " This sentence > would seem > > Frank> to indicate that if I am unregistering, I always have to > > Frank> unregister the assigned E.164 address??? The sentence that > > Frank> follows, contradicts this: "Only values listed here are > > Frank> unregistered; this allows, for example, an H323_ID to be > > Frank> unregistered while leaving the E.164 address registered." > > > > Frank> What is the intention of this sentence? Should I simply > > Frank> ignore it? > > > > IMO, the sentence means "The E.164 address, if assigned [dynamically > > by the GK during registration procedure], is required". > > I wonder what this is doing here at all... > > Action that I consider sensible at a gatekeeper: > If any aliases are mentioned in URQ, just unregister those > aliases; if no > aliases are mentioned, unregister the user altogether (ie all > aliases). > > Action I consider sensible at an endpoint: > Mention all aliases that are currently registered! > > This may or may not tally with the way people read the spec!!! > > Regards > Chris > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 >

2 1

Re: Description of EndpointAlias in URQ??
by Frank Derks 14 Feb '00

14 Feb '00

Hi "Fix", I don't think that I understand your reply. Do I always have to unregister my E.164 (if assigned) address and if so why? Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | ----------------------------------------------------- fxk@TIDWEB.GRENOBLE.HP.COM@SMTP@MAILBAG.INTEL.COM on 11/02/2000 16:41:07 Please respond to ITU-SG16@MAILBAG.INTEL.COM@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: Description of EndpointAlias in URQ?? Classification: Restricted >>>>> "Frank" == Frank Derks <frank.derks(a)PHILIPS.COM> writes: Frank> The "explanatory" text of the EndpointAlias element in the Frank> URQ message, contains the following sentence: "The E.164 Frank> address, if assigned, is required. " This sentence would seem Frank> to indicate that if I am unregistering, I always have to Frank> unregister the assigned E.164 address??? The sentence that Frank> follows, contradicts this: "Only values listed here are Frank> unregistered; this allows, for example, an H323_ID to be Frank> unregistered while leaving the E.164 address registered." Frank> What is the intention of this sentence? Should I simply Frank> ignore it? IMO, the sentence means "The E.164 address, if assigned [dynamically by the GK during registration procedure], is required". Regards. Fix. -- Francois-Xavier KOWALSKI __________ Telecom Engineer Hewlett-Packard Company //_ o \\/ Telecom Infrastructure Division Tel:+33 (0) 4 76 14 63 27 // // /\\ Fax:+33 (0) 4 76 14 16 86 mailto:fxk@tidweb.grenoble.hp.com http://www.hp.com/go/opencall/

1 0

Re: H.323 Overhead
by Gary Sullivan 13 Feb '00

13 Feb '00

I don't entirely agree with the video comments below. Video codecs operating at low bit rates typically vary their frame rate (and thus their GOB rate) depending on the degree of visual activity in the scene. The overhead from H.323 packetization is far from negligible. Packetization schemes for video often allow the encoder to decide how much data to place in each packet. For example, RFC 2429 for H.263 allows up to a full picture in one packet. (It also allows the picture to be chopped into multiple packets if desired.) The larger the packet size, the lower the overhead (and the higher the delay). The overhead is *not* negligible -- I believe each H.323 packet adds a minimum of 40 bytes of overhead. (Stephan Wenger would be the authority on the packet overhead.) Some packetization schemes (see RFC 2190) advocate using a packet for every GOB. That's a bad idea. If you're running CIF resolution H.263 (18 GOBs per picture) at 15 frames per second, and if I'm right about the 40 bytes overhead per GOB, then that seems to work out to 86.4 kbits per second just for the overhead if you send each GOB in its own packet. That overhead rate is enough to send a second CIF resolution H.263 video stream! -Gary Sullivan +> -----Original Message----- +> From: Ami Amir [mailto:Amir@TLV.RADVISION.COM] +> Sent: Friday, February 11, 2000 11:46 PM +> To: ITU-SG16(a)MAILBAG.INTEL.COM +> Subject: Re: H.323 Overhead +> +> +> Hi Steve and All +> +> Video does not gain from silence suppression. The equivalent +> to "silence" is +> no motion. H.261 was really designed for constant GOBS per +> second (Group of +> Blocks). The number of GOBs varies by the level of +> compression and quality +> (CIF vs QCIF). No motion = a GOB which is practically empty +> - which creates +> a packet that is only overhead => not very efficient. Since +> this the 'best +> case" situation as far as total bandwidth taken up by the +> video stream, I +> would not worry about it. +> +> When there is lots of motion - the GOBS are very big, and +> the frame size is +> really the maximum RTP frame allowed by the network. When +> this occurs, the +> overhad is negligible. +> +> To summarize - for H.323 (it is really for RTP - since all +> protocols i.e. +> SIP and MEGACO/MGCP/.... use RTP) the more data you send - +> the lower the +> overhead. +> +> H.323 signaling overhead is practically nill (again like SIP +> and MGCP). +> Signaling information is sent only when there are changes - +> e.g. call set up +> or tear down. +> +> As Steve correctly states - the only real issue is at the +> edge (say PPP +> connections via RAS - remote access modems). This is the +> place where the +> attention needs to be placed, i.e. header compression etc. +> +> H.320 (H.221 really) was designed for maximum efficiency in +> TDM circuits. +> H.221 sacrifices simplicity for bandwidth. The data is NOT +> organized in +> bytes and requires a lot of bit manipulation. Overhead is +> really neglible. +> As far as I remember - for 128kbps - it is less than 5%. +> +> Ami +> +> -----Original Message----- +> From: Stephen Casner [mailto:casner@CISCO.COM] +> Sent: Friday, February 11, 2000 6:34 PM +> To: ITU-SG16(a)MAILBAG.INTEL.COM +> Subject: Re: H.323 Overhead +> +> +> On Fri, 11 Feb 2000, Francois Menard List Account wrote: +> +> > In terms of the overhead related to +> > packets transmission, it is RTP encapsulation which is +> causing a lot of +> > overhead. +> +> Actually, the 12 bytes of RTP aren't the biggest part. +> There's also 8 +> for UDP, 20 for IP, and some more for a link-level header. But the +> IP/UDP/RTP part can be compressed down to a few bytes across links +> where that matters. +> +> This compares to the H.221 overhead for H.323 -- I don't +> know that number. +> +> But in the IP case, you also gain from silence suppression, which I +> believe is only done on specialized links in the circuit case. +> +> In my opinion, the focus on transmission overhead is misguided. If +> you believe predictions that voice bandwidth will be a small fraction +> of the converged IP network, then that overhead in the +> backbone should +> not be an issue. Header ompression can be used on narrow +> links at the +> edges. +> -- Steve +>

1 0

H.245 for videoFastUpdateMB, videoFastUpdateGOB, videoNotDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800)
by Gary Sullivan 13 Feb '00

13 Feb '00

This time copying the APC people as well, since they should be the H.245 gurus: +> -----Original Message----- +> From: Gary Sullivan [mailto:garysull@microsoft.com] +> Sent: Saturday, February 12, 2000 7:29 PM +> To: Thomas Wiegand (E-mail) +> Cc: ITU-T Q. 15/SG16 Advanced Video Coding Experts Group (E-mail) +> Subject: Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800 +> +> +> ITU-T Advanced Video Coding Experts Group (Q.15/SG16) +> Email from Gary Sullivan <garysull(a)microsoft.com>: +> +> +> To the U. Erlangen folks and other video experts, +> +> I have the strong impression that we have been here before discussing +> this same issue. I thought we clarified these issues in H.245. +> However, I'm looking at H.245 and I'm seeing what looks like some old +> (pre-1998) text. Since the records on this would be at +> least a couple +> of years old, I don't seem to be able to track them all down. +> +> I have questions about two paragraphs in H.245. Here's the +> first one: +> +> videoFastUpdateGOB SEQUENCE +> { +> firstGOB INTEGER (0..17), +> numberOfGOBs INTEGER (1..18) +> }, +> +> videoFastUpdateMB SEQUENCE +> { +> firstGOB INTEGER (0..255) OPTIONAL, +> firstMB INTEGER (1..8192) OPTIONAL, +> numberOfMBs INTEGER (1..8192), +> ... +> }, +> +> "videoFastUpdateMB commands the far-end video encoder to perform a +> fast update of one or more MBs. firstGOB indicates the number of +> the first GOB to be updated and is only relative to H.263, firstMB +> indicates the number of the first MB to be updated and is only +> relative to H.261 and numberOfMBs indicates the number of MBs to +> be updated. It shall only be used with video compression +> algorithms that define MBs, for example, H.261 and H.263. +> Terminals may respond to this command with a GOB update which +> includes the MBs requested." (If I now recall correctly, it was not U. Erlangen that put the above ambiguous statements into H.245 -- I believe they pre-dated the error tracking work.) Let me try a little more on the above: A GOB in H.261 is not a raster-scan-order set of macroblocks in a picture (instead it is a raster-scan-order set of macroblocks in a rectangle within the picture). But a GOB in H.263 is a raster-scan-order set of macroblocks in a picture. Reviewing GOB layout in H.261, each GOB contains 33 MBs. In H.261 CIF, GOBs are laid out in the picture like this: 1 2 3 4 5 6 7 8 9 10 11 12 In H.261 QCIF the layout is 1 3 5 and each GOB has a vertical size of 3 macroblocks and a horizontal size of 11 macroblocks. In H.261, MBs are numbered from 1 to 33 in raster scan order within each GOB. In H.263, GOBs are numbered like this in all picture sizes: 0 1 2 . . . The height of a GOB in H.263 depends on the height of the picture, with QCIF and CIF containing a single row of macroblocks per GOB and taller pictures containing 2 or 4 rows of macroblocks per GOB. So my guess is that when it is saying firstGOB is "only relative to H.263", it is saying that we should assume the GOB layout is in the manner of H.263. So that a GOB is synonymous with one or more rows of macroblocks. Then when it says firstMB is "only relative to H.261" I'm guessing it is saying that the MBs should be numbered starting from MB number 1 being the first MB in the GOB and then proceeding in raster scan order within the GOB. Does the above interpretation seem correct? If firstMB + numberOfMBs > 11, it's not clear what to assume. In H.261 this would address a GOB in the next row of MBs in the picture, but in H.263 there are other MBs in the same GOB and jumping to the next row of MBs in the picture would break my assumption that bitstream order would be the most reasonable. So my guess is that the order assumed in the scanning of MBs should depend on the bitstream order normal for the particular video codec in use. +> +> What the heck does "only relative to H.263" mean? +> What does "only relative to H.261" mean? +> What values are you supposed to send with this command? +> +> Here's the next one: +> +> videoNotDecodedMBs SEQUENCE +> { +> firstMB INTEGER (1..8192), +> numberOfMBs INTEGER (1..8192), +> temporalReference INTEGER (0..255), +> ... +> }, +> +> "videoNotDecodedMBs indicates to the far-end video encoder that a +> set of MBs has been received erroneously and that any MB in the +> specified set has been treated as not coded. The encoder may use +> this information to compensate transmission errors, as illustrated +> in Appendix I of H.263. firstMB indicates the number of the first +> MB treated as not coded, and numberOfMBs indicates the number of +> MBs treated as not coded. The MB numbering is done according to +> H.263. The temporal reference of the picture containing not +> decoded MBs is indicated in temporalReference. This indication +> shall only be used with the H.263 video compression algorithm." +> +> What does "numbering according to H.263 mean"? The only numbering +> defined in H.263 starts with macroblock number 0, not 1. Here my guess would be that MBs are numbered in raster scan order from 1 to the number of MBs in a picture. +> +> I really thought we fixed both of these problems two years ago. +> +> Best Wishes, +> +> Gary Sullivan +> +> +> ------------------------------------------------------------- +> ------------------- +> *** ITU-T Advanced Video Coding Experts Group (Q.15/SG16) +> Email List Message *** +> To send messages, address them to +> "itu-adv-video(a)standard.pictel.com". +> To subscribe or unsubscribe, send email to +> "majordomo(a)standard.pictel.com". +> Note: Only people whose exact email address is subscribed to +> the list can post. +> Subscriptions: "subscribe itu-adv-video +> YOUR-EMAIL-ADDRESS" in message body. +> Unsubscriptions: "unsubscribe itu-adv-video +> YOUR-EMAIL-ADDRESS" in message body. +> ------------------------------------------------------------- +> ------------------- +>

1 0