[Mp4-tech] [video]AVC field selection
Gary Sullivan
garysull windows.microsoft.com
Wed Jun 27 03:48:59 EDT 2007
I think this is basically the same issue raised by Alan Yan on 7 November 2023 as reported in item 100 of JVT-U210 (and the newly-available JVT-W210), and the remainder of this thread is discussed in item 117 of JVT-W210. I think your comments may be useful in achieving further clarity.
There are some cases when the mb_field_decoding_flag is present for odd-numbered macroblocks. Specifically, I think this includes the case when the even-numbered MB of a pair is skipped and the odd-numbered MB of the pair is not.
And yes, mb_field_decoding_flag has an MB pair as its scope.
And yes, if mb_field_decoding_flag is 1 and the odd numbered MB uses Pred_L0 prediction, ref_idx_l0 will be present for the odd-numbered MB.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: Andrew Palfreyman [mailto:anpalfre cisco.com]
+> Sent: Wednesday, June 27, 2023 12:27 AM
+> To: John Cox; Gary Sullivan
+> Cc: mp4-tech lists.mpegif.org
+> Subject: Re: [Mp4-tech] [video]AVC field selection
+>
+> Gary,
+>
+> Took another look at this, and, aside from the "definition
+> of default"
+> issue, there appears to be another issue that needs
+> resolution, in the case
+> where MbaffFrameFlag=1...
+>
+> In 7.3.4, mb_field_decoding_flag is only instantiated for
+> even-numbered MBs
+> (assuming no MBs are skipped). Referring back to the instantiation
+> expression above for ref_idx_lX, what is deemed to be the truth of
+> mb_field_decoding_flag for the odd-numbered MB of the MB
+> pair, where this
+> field is absent? According to the spec, if its absent, it's
+> inferred to be
+> zero. If, on the other hand, mb_field_decoding_flag is
+> understood to have
+> macroblock-pair scope (as opposed to macroblock-only scope),
+> then the answer
+> is clear. The spec does not make this scope explicit.
+>
+> One simplified form of this question might be:
+> "when mb_field_decoding_flag=1 and MbPartPredMode(..) ==
+> Pred_L0, for an
+> even MB, does ref_idx_l0 appear in the RBSP for the
+> associated odd MB of
+> this MB pair?"
+>
+> Also note that the "inference from neighbours" semantics
+> section 7.4.4,
+> dealing as it does exclusively with MB pairs, does not
+> contribute to an
+> answer to this question.
+>
+> Also, I found confusing the phrase
+> "When mb_field_decoding_flag is not present for either
+> macroblock of a
+> macroblock pair,...".
+> This hinges on the meaning of "either", used imprecisely (IMHO) here.
+> This phrase could be interpreted to mean
+> "When both MBs of a pair have mb_field_decoding_flag not present"
+> or could be interpreted to mean
+> "When one or both MBs of a pair have mb_field_decoding_flag
+> not present".
+>
+> The confusion is inherent in the fact that this flag isn't
+> present for odd
+> MBs (no skips) in any case, so this semantic explanation is
+> particularly
+> troublesome to interpret in that light. It all comes down to
+> scope, right?
+>
+> Best,
+> Andrew Palfreyman
+>
+> ----- Original Message -----
+> From: "John Cox" <jc sj.co.uk>
+> To: "Gary Sullivan" <garysull windows.microsoft.com>
+> Cc: <mp4-tech lists.mpegif.org>
+> Sent: Friday, June 22, 2023 3:10 AM
+> Subject: Re: [Mp4-tech] [video]AVC field selection
+>
+>
+> > Gary,
+> >
+> > I hadn't thought of renaming the flag but it gets my vote.
+> Having it
+> > called field_mb_pair_flag and being always zero if
+> MbaffFrameFlag is
+> > zero cuts through all the confusion nicely.
+> >
+> > Regards
+> >
+> > John Cox
+> >
+> >
+> >>Barry et al,
+> >>
+> >>I guess perhaps you could read 7.4.4 that was, but its
+> inference rules is
+> >>only specified for "When mb_field_decoding_flag is not
+> present for either
+> >>macroblock of a macroblock pair". When MbaffFrameFlag is
+> equal to 0, we
+> >>don't have macroblock pairs. And the inference rule
+> itself refers to
+> >>things relating to "the current macroblock pair" and "the
+> macroblock pair
+> >>immediately to the left of the current macroblock pair" and "the
+> >>macroblock pair immediately above the current macroblock
+> pair", which are
+> >>concepts that do not apply.
+> >>
+> >>Inferring mb_field_decoding_flag to be zero whenever
+> MbaffFrameFlag is
+> >>equal to 0 would be good in the sense that it would take
+> care of the logic
+> >>flow in 7.3.5.1 without needing to change what is stated
+> in 7.3.5.1. But
+> >>it might be kind of counter-intuitive, since people might
+> expect something
+> >>called mb_field_decoding_flag not to be 0 for a field macroblock.
+> >>
+> >>Another possibility is to change the name of
+> mb_field_decoding_flag to
+> >>something like field_mb_pair_flag. Then it would make
+> more intuitive
+> >>sense to have it be 0 when the MB is not part of a pair.
+> >>
+> >>Best Regards,
+> >>
+> >>Gary Sullivan
+> >>
+> >>+> -----Original Message-----
+> >>+> From: bhaskell [mailto:bhaskell apple.com]
+> >>+> Sent: Thursday, June 21, 2023 9:49 AM
+> >>+> To: Gary Sullivan
+> >>+> Cc: dzung.hoang xilient.com; Andrew Palfreyman (cisco);
+> >>+> mp4-tech lists.mpegif.org
+> >>+> Subject: Re: [Mp4-tech] [video]AVC field selection
+> >>+>
+> >>+> Gary Sullivan wrote:
+> >>+>
+> >>+> >Just for completeness, we might also want to define an
+> >>+> inferred value of mb_field_decoding_flag for cases with
+> >>+> MbaffFrameFlag equal to 0, although the actual value in such
+> >>+> cases may not be used for anything other than the evaluation
+> >>+> of the expression in 7.3.5.1. Right now, I believe it only
+> >>+> has a defined value for cases with MbaffFrameFlag equal to 1.
+> >>+> >
+> >>+> >
+> >>+>
+> >>+> 7.4.4. seems to say that if mb_field_decoding_flag is not
+> >>+> present in
+> >>+> any macroblock, then it should be inferred to be zero in all
+> >>+> macroblocks. I'm sure that's what everyone has assumed so far.
+> >>+>
+> >>+> Cheers, Barry
+> >>+>
+> >>+> --
+> >>+> Barry G. Haskell tel +1 408 974 6333
+> >>+> Apple Inc. fax " " " 1756
+> >>+> 2 Infinite Loop MS: 302-3KS
+> >>+> Cupertino, CA 95014
+> >>+> bhaskell apple.com (also B.Haskell ieee.org)
+> >>+>
+> >>+>
+> >>+>
+> >>+>
+> >>
+> >>_______________________________________________
+> >>NOTE: 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.
+> >>
+> >>Note: Conduct on the mailing list is subject to the
+> Antitrust guidelines
+> >>found at
+> >>http://www.mpegif.org/public/documents/vault/mp-out-30042-A
+> ntitrust.php
+> >
+> >
+>
+>
More information about the Mp4-tech
mailing list