H.323: Annex-H editor
Edgar Martinez [1]
martinze at CIG.MOT.COM
Thu Feb 17 10:35:50 EST 2000
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 at accord.co.il
Tel: +972-3-9251412
Fax: +972-3-9211571
***************************************************
> -----Original Message-----
> From: Gary Sullivan [SMTP:garysull at MICROSOFT.COM]
> Sent: Sun, February 13, 2000 9:31 PM
> To: ITU-SG16 at 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 at 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 at 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 at standard.pictel.com".
> +> To subscribe or unsubscribe, send email to
> +> "majordomo at 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.
> +> -------------------------------------------------------------
> +> -------------------
> +>
More information about the sg16-avd
mailing list