H.245 for videoFastUpdateMB, videoFastUpdateGOB, videoNotDeco dedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800)
Gary Sullivan
garysull at MICROSOFT.COM
Thu Feb 17 12:55:17 EST 2000
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 at 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 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