- sg16-avd - lists.packetizer.com

Guidance from the Dalai Lama
by Greg Ratta 18 Feb '00

18 Feb '00

As we are finishing the ITU-T SG 16 meeting and observing the recent activity moving forward ITU-T Recommendation H.248 / Megaco, I found this gem attributed to be from the Dalai Lama. I hope you find it as enjoyable and relevant as I did. My only regret is that this did not pass my way two weeks ago. I N S T R U C T I O N S F O R L I F E 1. Take into account that great love and great achievements involve great risk. 2. When you lose, don't lose the lesson. 3. Follow the three Rs: - Respect for self - Respect for others and - Responsibility for all your actions. 4. Remember that not getting what you want is sometimes a wonderful stroke of luck. 5. Learn the rules so you know how to break them properly. 6. Don't let a little dispute injure a great friendship. 7. When you realize you've made a mistake, take immediate steps to correct it. 8. Spend some time alone every day. 9. Open your arms to change, but don't let go of your values. 10. Remember that silence is sometimes the best answer. 11. Live a good, honorable life. Then when you get older and think back, you'll be able to enjoy it a second time. 12. A loving atmosphere in your home is the foundation for your life. 13. In disagreements with loved ones, deal only with the current situation. Don't bring up the past. 14. Share your knowledge. It's a way to achieve immortality. 15. Be gentle with the earth. 16. Once a year, go someplace you've never been before. 17. Remember that the best relationship is one in which your love for each other exceeds your need for each other. 18. Judge your success by what you had to give up in order to get it. 19. Approach love and cooking with reckless abandon. Greg Ratta, Vice Chairman, ITU-T WP 1/11, Broadband Signalling Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta(a)lucent.com

1 0

One endpoint with multiple Connections.
by Hans Viens 18 Feb '00

18 Feb '00

Hi Folks! I have an endpoint that support 3 ports for H.323 connections and 1 port that support PSTN. Then I introduce the PSTN/H.323 gateway functionnality. Now, I would like to register that endpoint to a GK. How could I do this for the GK to know that I support 1 gateway port and 3 H.323 connections ??? Thanks for your support, Hope to get some news soon, Hans ------------------------------------------------ Hans Viens, Ing. St. Concepteur en logiciel / Software Designer Mediatrix Peripherals, Inc. / Mediatrix Telecom, Inc. 4229 Garlock Street, Sherbrooke QC J1L 2C8 Canada Tel.: (819) 829-8749 ext. 255, Fax: (819) 829-5100 E-Mail: hviens(a)mediatrix.com

2 1

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

17 Feb '00

Ari, I suppose it is understandable that it might be difficult to reconcile videoFastUpdateMBs with H.263 Annex K or with MPEG-4, since videoFastUpdateMB was specified years before either one of those existed. That's history, not politics. In the case of MPEG-4 visual, I'm not sure whether specifying a macroblock number is sufficiently explicit. Even the "simple" profile of MPEG-4 requires support of more than one "visual object". I am not sure how you would know which "visual object" you were referring to when you sent the command. I'm not an expert on how MPEG-4 is handled in the system. I believe the intent is for MPEG-4 visual to be able to be handled either by carrying an MPEG-4 Systems stream or by H.245 itself without MPEG-4 Systems, but I'm not sure just how. -Gary S. +> -----Original Message----- +> From: ari.hourunranta(a)NOKIA.COM [mailto:ari.hourunranta@NOKIA.COM] +> Sent: Wednesday, February 16, 2000 12:59 AM +> To: ITU-SG16(a)MAILBAG.INTEL.COM +> Subject: Re: Q15: H.245 for videoFastUpdateMB, videoFastUpdateGOB, +> videoNo tDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800) +> +> +> 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

Re: question on video transcoder or gateway
by Gary Sullivan 17 Feb '00

17 Feb '00

Weiming Shen et al, The only real way to translate in either direction in general is to decode (including IDCT) and then re-encode. This is because H.261 cannot represent the half-pel motion used in H.263, and H.263 cannot represent the loop filter in H.261. Unless you can somehow stop the original encoder from using features that aren't found in both standards, you're stuck doing real transcoding. The re-encoding complexity can be reduced significantly by re-using the motion vectors and prediction mode selections from the incoming video rather than doing a new motion estimation in the re-encoder. Since motion estimation and mode selection can take a lot of processing power, getting rid of some of that can help. For best performance it would be good to have the re-encoder do a local refinement of the incoming motion vectors and to try different prediction modes. There are standards for gateways and multipoint conferencing units. I don't think they give much advice in them about this issue. I don't recall which standards those are, but if you look at a list of the H-series standards list at www.itu.int <http://www.itu.int> you'll probably spot them. -Gary -----Original Message----- From: wmshen [mailto:wmshen@PUBLIC.WH.HB.CN] Sent: Tuesday, February 15, 2000 7:04 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: question on video transcoder or gateway 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

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