[Mp4-tech][video][MPEG4] MV limitation and bounding rectangle of a rectangular VOP

Mon Mar 17 09:17:03 EDT 2008

Hi Pankaj Bajpai,
Thank you for your answers. Sorry for the confusion of coded/decoded area.
What I am referring to it simply the full area covered by the full
macroblocks, so in the example of an actual displayable size of 800×600, the
"coded/decoded area" would be the 800×608 to get complete macroblocks in the
height (38 MBs high). This is the actual full picture that is coded and
there may be some picture information in the last 8 lines of the coded area.
But as I understand you, these lines will always be overwritten by the
padding process, i.e. extending the borders of the actual displayable area.
So in my example, the last lines of the picture will look like this right
after initial decoding (before padding):
. . . . . . . .
0 0 0 0 0 0 0 0
1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2
3 3 3 3 3 3 3 3
4 4 4 4 4 4 4 4
5 5 5 5 5 5 5 5
6 6 6 6 6 6 6 6
7 7 7 7 7 7 7 7
8 8 8 8 8 8 8 8
9 9 9 9 9 9 9 9
A A A A A A A A
B B B B B B B B
C C C C C C C C
D D D D D D D D
E E E E E E E E
F F F F F F F F
X X X X X X X X
X X X X X X X X
. . . . . . . .
The lines 0-F is the last 16 lines (last MB) of the coded area (picture),
and X marks any lines completely outside of the coded area. Only the lines
0-7 should be in the final displayable picture area. The padding process for
the lines outside of the coded area (X) will consist of repeated boundary
lines. For a rectangular VOP, this will be equal to limiting the motion
vectors to the last line inside the coded area. If I understand you
correctly, the padding process for such a rectangular VOP will repeat line 7
downwards (and outside) to the final padded picture being as ilustrated
below, which will again be equal to limiting the motion vectors to the last
line of the actual 'displayable' part (line 7 in the example). This was
where I found the Standard unclear, as it could also have been the last
'coded' line (i.e. line F) that would be repeated outside the coded area,
which would be equal to a limitation of the MV to this last 'coded' line...
After padding:
. . . . . . . .
0 0 0 0 0 0 0 0
1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2
3 3 3 3 3 3 3 3
4 4 4 4 4 4 4 4
5 5 5 5 5 5 5 5
6 6 6 6 6 6 6 6
7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7
7 7 7 7 7 7 7 7
. . . . . . . .
Have I understood this correctly, and is it correct that the actual coded
information in the last 8 lines is completely discarded? Do you (or anyone
else) know of any test sequence that actually utilize this, so I can test
it?
Thanks.
Jay
On Wed, Mar 12, 2024 at 6:07 AM, pankaj bajpai <
pankaj_bajpai_iet operamail.com> wrote:
> Hi Jay,
>
> I am trying to answer your question.
> Request group members to correct me wherever i am wrong.
>
> 1) What is the 'decoded VOP area' of a rectangular VOP? Is it the area of
> > the so-called 'displayable part' of the VOP (800×600), or is it the full
> > coded VOP area (800×608)?
>
> Ans: I am not very clear from your question about decoded area.
> Still i'll try to answer. Yes initial decoded area is the coded area, ie
> area  including padding to satisfy multiplicity with 16. However, all post
> processing should be done wrt displayable area.
>
> >   2) If the 'decoded VOP area' refers to the full coded VOP area
> including
> > extensions, what would the extended parts contain? Would they contain
> the
> > actual coded information (I assume that there are no requirements to
> what
> > that would be), or should the so-called repetitive padding process of
> > section 7.6.1 be applied to the extended parts (although that section
> begins
> > with that the padding process is defined for "...samples outside the VOP
> for
> > prediction of arbitrarily shaped objects")?
>
> ans: The extended portion is always generated using repetitive Padding
> process. However, for rectangual VOP case, this lead to just extending
> boundaries , and hence, is same as restricting the motion vectors.
>
>
> > ----- Original Message -----
> > From: mp4-tech-request lists.mpegif.org
> > To: mp4-tech lists.mpegif.org
> > Subject: Mp4-tech Digest, Vol 56, Issue 9
> > Date: Tue, 11 Mar 2024 12:07:13 -0400 (EDT)
> >
> >
> > Send Mp4-tech mailing list submissions to
> >       mp4-tech lists.mpegif.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >       http://lists.mpegif.org/mailman/listinfo/mp4-tech
> > or, via email, send a message with subject or body 'help' to
> >       mp4-tech-request lists.mpegif.org
> >
> > You can reach the person managing the list at
> >       mp4-tech-owner lists.mpegif.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Mp4-tech digest..."
> >
> > Today's Topics:
> >
> >     1. [Mp4-tech][video][MPEG4] MV limitation and bounding rectangle
> >        of a   rectangular VOP (J. Miles)
> >
> > From: J. Miles <video.codec.help gmail.com>
> > To: mp4-tech lists.mpegif.org
> > Subject: [Mp4-tech][video][MPEG4] MV limitation and bounding rectangle
> of a rectangular VOP
> > Date: Tue, 11 Mar 2024 09:50:53 +0100
> >
> > Hi everyone!
> >
> >
> > While working with MPEG-4 (Part 2, not AVC) decoding, I have been
> looking at
> > the use of unrestricted motion vectors in relation to the MV limitation
> to
> > bounding rectangles and find that the Standard (sections 7.6.1-7.6.4) is
> not
> > entirely clear on that. Let me try to describe the case:
> >
> >
> > The video bitstreams handled are purely coded as usual rectangular
> objects
> > (no sprites or shapes). In the situation, where the
> video_object_layer_width
> > and/or video_object_layer_height are not dividable by 16, the coded size
> is
> > extended so that it is dividable by 16 and fits with complete MBs. For
> > instance, a VOL size of 800×600 would have the coded size being 800×608
> to
> > fit with an integral number of MBs in the height. As motion vectors are
> > allowed to be unrestricted, they may point outside the actual VOL area
> and
> > into the extended VOL area and actually also outside that area. This has
> an
> > impact on the MV limitation described in section 7.6.4 for unrestricted
> > motion vectors because the MV is limited "...to the last full pel
> position
> > inside the decoded VOP area". In that section and the other related
> sections
> > of the Standard, there are mostly references to arbitrarily shaped
> objects
> > and not that many to rectangular objects. Although in section 7.6.4, the
> > bounding rectangle of a rectangular VOP is defined as being equal to the
> > coded (and extended) area.
> >
> >
> >
> >   1) What is the 'decoded VOP area' of a rectangular VOP? Is it the area
> of
> > the so-called 'displayable part' of the VOP (800×600), or is it the full
> > coded VOP area (800×608)?
> >
> >
> >   2) If the 'decoded VOP area' refers to the full coded VOP area
> including
> > extensions, what would the extended parts contain? Would they contain
> the
> > actual coded information (I assume that there are no requirements to
> what
> > that would be), or should the so-called repetitive padding process of
> > section 7.6.1 be applied to the extended parts (although that section
> begins
> > with that the padding process is defined for "...samples outside the VOP
> for
> > prediction of arbitrarily shaped objects")?
> >
> >
> > I do hope someone can help me in understanding this better.
> >
> >
> > Thanks.
> >
> > Jay
> >
> > _______________________________________________
> > Please use clear subject lines for your posts. Include [audio,
> > [video], [systems], [general] or another apppropriate identifier to
> > indicate the type of question you have.
> >
> > Conduct on the mailing list is subject to the Antitrust guidelines
> > found at
> > http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
>
> >
>
>
>
> Pankaj Kumar Bajpai
> Mulitimedia Engineer
> India
>
>
> --
> _______________________________________________
> Surf the Web in a faster, safer and easier way:
> Download Opera 9 at http://www.opera.com
>
> Powered by Outblaze
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20080317/064bdb4f/attachment-0001.html