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@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@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@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@standard.pictel.com". +> To subscribe or unsubscribe, send email to +> "majordomo@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. +> ------------------------------------------------------------- +> ------------------- +>