[M4IF Technotes] Interpretation of vop_coded

[Gary Sullivan]

When you refer to "The Microsoft reference code", what
version are you referring to?  Are you sure you
have the correct version?  (We have found that most
bug reports have been obsoleted by the latest version.)
-G.
+> -----Original Message-----
+> From: Kris Huber [mailto:khuber   sorenson.com] 
+> Sent: Monday, February 11, 2024 1:24 PM
+> To: 'ykgupta   noida.hcltech.com'
+> Cc: 'technotes   lists.m4if.org'
+> Subject: Re: [M4IF Technotes] Interpretation of vop_coded
+> 
+> 
+> Dear Yogender,
+> 
+> The 2001 edition of the video spec., at least, describes the 
+> behavior you
+> were expecting (i.e., if rectangular then "the luminance and 
+> chrominance
+> planes of the reconstructed VOP shall be filled with the 
+> forward reference
+> VOP..." - look under vop_coded in subclause 6.3.5).  Filling 
+> a vop_coded=0
+> rectangular VOP with 128's is not standard, and is a bug in 
+> the reference
+> software if it is happening.  Even if vop_coding_type=0 
+> (I-VOP), I think
+> vop_coded=0 in the header causes  a copy of the most recent 
+> VOP in the past
+> for which vop_coded=1 to be displayed.  Anything other than that is
+> unspecified by the standard.
+> 
+> As for when an encoder should use vop_coded=0 in the 
+> rectangular VOP case, I
+> notice that it allows you to effectively drop a frame even if
+> fixed_vop_rate=1 in the VOL header.  This might be necessary 
+> or convenient
+> to use for meeting profile complexity constraints.  It is a 
+> more efficient
+> way of skipping the coding of a VOP than constructing a 
+> P-frame consisting
+> entirely of not-coded macroblocks.  Alternatively, if 
+> fixed_vop_rate=0 is
+> used, one can still produce a sequence of VOPs with a  fixed 
+> VOP rate, and
+> not have to insert the (small) vop_coded=0 headers.  In some 
+> systems where
+> MPEG-4 video is used (including mp4 files I believe) the time-code
+> information in the VOP headers is redundant anyway, which is the only
+> information that comes in the vop_coded=0 VOP header.
+> 
+> Regards,
+> Kris Huber
+> 
+> -----Original Message-----
+> From: Yogendra Kumar Gupta <ykgupta   noida.hcltech.com>
+> To: technotes   lists.m4if.org
+> Date: Mon, 11 Feb 2024 19:40:19 +0530
+> Subject: [M4IF Technotes] Interpretation of vop_coded
+> 
+> Dear All,
+> 
+> Can anyone please explain the interpretation of the flag 
+> vop_coded (when
+> vop_coded = 0) when video_object_layer_shape == RECTANGULAR. 
+> The standard
+> gives details of the construction of reconstructed frame but 
+> does not give
+> any interpretation regarding the construction of the current 
+> frame (that
+> would be used for display). The Microsoft reference code 
+> puts a grey image
+> of colour 128 in the o/p which doesn't look very nice in 
+> between while
+> watching a video. One of the conformance bitstreams contains 
+> frames where
+> every alternate frame the flag vop_coded is set to 0 and the 
+> o/p looks like
+> a blinking one where you get a decoded image and a gray 
+> image alternatively.
+> Could a better solution be use the previous frame itself for 
+> display when
+> vop_coded = 0. Also I would like to know when the flag 
+> vop_coded needs to be
+> set to 0 on the encoding side.
+> 
+> Regards
+> Yogender Kumar Gupta
+> 
+> 
+> _______________________________________________
+> Technotes mailing list
+> Technotes   lists.m4if.org
+> http://lists.m4if.org/mailman/listinfo/technotes
+>