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@NOKIA.COM [mailto:ari.hourunranta@NOKIA.COM] +> Sent: Wednesday, February 16, 2000 12:59 AM +> To: ITU-SG16@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@nokia.com +> ------------------------------------------------------------ +>