[M4IF Technotes] GMC

[Rob Koenen]

> I basically agree to adding the limitation on the memory access for GMC. 
> However the standard has been already released, and it could not be added 
> as corrigendum, but may be as the new amendment since it is a technical 
> issue.

Indeed. Changing the standard in this way would be an amendment, not
a corrigendum. It is not common to change a standard in retrospect,
if it breaks existing products.
> So, I think that such the limitation had better be set by each association

> specifying the application, e.g. ISMA, for avoiding the problem on
encoding 
> pointed out by Kris if it is necessary. 
> I think that this is a realistic solution in the current situation.

With all respect for that suggestion, it would pose interoperability 
problems, as it would amount to an external body defining its own Levels. 
(ISMA already sort of did that once, but then went to MPEG to ask to 
formalize this new definition, which becomes Level 3b for Advanced Simple)
If anyone, MPEG should fix its own levels (if there is indeed a problem)
or create additional ones if fixes would create problems for existing
products.
Kind Regards,
Rob 
> 
> Best regards,
> 
> Yoshinori Suzuki
> Hitachi, Ltd.
> 
> > -----Original Message-----
> > From: "Sorin C. Cismas" <sorin   mobilygen.com>
> > To: <technotes   lists.m4if.org>
> > Subject: RE: [M4IF Technotes] GMC
> > Date: Sun, 12 May 2024 00:00:04 -0700
> > 
> > I don't think there are any restrictions on the motion 
> vectors.  I have
> > the same concern about the need to fetch 64 non-contiguous 2x2 pels
> > to predict a macroblock.  To reduce complexity and 
> bandwidth requirements,
> > it is highly desirable to put some limits on du[i] and 
> dv[i] for i>0.
> > 
> > 2 and 3 warping points are usefull for zoom-in and 
> zoom-out, however, it is
> > not realistic to assume, for example, a 10x zoom-out on an S(GMC)
> > prediction.
> > A 50% or even 25% zoom-out restriction will be more than sufficient.
> > For 50%, this will translate to du[i]<W    and dv[i]<H    for i>0.
> > For 25%, this will translate to du[i]<W//2 and dv[i]<H//2 for i>0.
> > The 50% restriction will limit the macroblock luma 
> prediction to 25x25.
> > The 25% restriction will limit the macroblock luma 
> prediction to 21x21.
> > 
> > Can these or similar restrictions be considered for a 
> future corrigendum?
> > 
> > Thanks,
> > Sorin Cismas
> > 
> > > -----Original Message-----
> > > From: technotes-admin   lists.m4if.org
> > > [mailto:technotes-admin   lists.m4if.org]On Behalf Of Kasturi Rangam
> > > Sent: Friday, May 10, 2024 2:46 PM
> > > To: technotes   lists.m4if.org
> > > Subject: [M4IF Technotes] GMC
> > >
> > >
> > > I am trying to under GMC in MPEG4.
> > > Looks like you can have 0, 1, 2 or 3 sprite_warping_points.
> > >
> > > To decode a 0 and 1 sprite_warping_points macroblock, you can
> > > fetch the whole macroblock data from the reference to do pixel
> > > prediction.
> > >
> > > However, for 2 and 3 warping_points, the motion vector for each
> > > pixel can be anywhere in the reference frame. Thus we might need
> > > to perform 64 data fetches to predict one macroblock.
> > >
> > > Is there a range that can be calculated for each 
> macroblock, so that
> > > we can fetch data only once?
> > >
> > > Thanks,
> > >
> > > Kasturi
> > > _______________________________________________
> > > Technotes mailing list
> > > Technotes   lists.m4if.org
> > > http://lists.m4if.org/mailman/listinfo/technotes
> > 
> > _______________________________________________
> > Technotes mailing list
> > Technotes   lists.m4if.org
> > http://lists.m4if.org/mailman/listinfo/technotes
> _______________________________________________
> Technotes mailing list
> Technotes   lists.m4if.org
> http://lists.m4if.org/mailman/listinfo/technotes
>