[M4IF Technotes] Some puzzles about stuffing macroblock at end of VOP

[Gary Sullivan]

+> -----Original Message-----
+> From: Lefan Zhong [mailto:Lefan   mediaq.com] 
+> Sent: Wednesday, February 05, 2024 5:44 PM
+> To: technotes   lists.m4if.org
+> Subject: [M4IF Technotes] Some puzzles about stuffing 
+> macroblock at end of VOP
+> 
+> 
+> Hi folks,
+> 
+> I have some questions about stuffing macroblocks in the end 
+> of VOP. The official document (14496-2, 2001) and the 
+> reference softwares conflict at the issue. I would like to 
+> share my opinions here. I would like to hear your comments too.
I don't know to what extent this issue was actually really considered
in the drafting of the standard, but your analysis looks reasonable.
If I were writing a decoder, I would allow for the stuffing
to be there.  If I were writing an encoder, I would try to avoid using
it, as I would be afraid some decoders would not be built to allow it.
I do remember the topic coming up before.  I don't remember whether
there was this much information provided analyzing the spec and
reference software when the subject came up, and I don't remember
whether MPEG decided to do anything to alter the document or the
software.
+> 
+> 1) It is legal to insert some stuffing macroblocks after the 
+> last non-stuffing macroblock in the VOP if the data 
+> bitstream is not data partition format and not short video 
+> header. Since in the document section 6.2.5.3, the function 
+> combined_motion_shape_texture( ) uses do...while loop to 
+> keep checking until resyn_marker of start_new_VOP. But 
+> Momusys reference software doesn't skip the stuffing and go 
+> to next VOP.
So it sounds like there is a bug in that software or a
problem in the document.  This is a case where the document
and software appear to conflict.  Both are "normative", so
it is up to the MPEG committee to decide which is right.
+> 
+> 2) If the bitstream is short video header, it is illegal to 
+> insert the stuffing macroblocks after the last non-stuffing 
+> macroblock in VOP. Since in the document section 6.2.5.2, 
+> the function gob_layer( ) use for loop for macroblock 
+> decoding. After the last non-stuffing macroblock is decoded, 
+> the decoder should go out of the loop and shouldn't checking 
+> any stuffing macroblock.  But Microsoft reference software 
+> processes further skipping for the stuffing macroblocks.
The fact that the Microsoft reference software skips over it
does not necessarily mean anything in terms of whether it is
allowed or not.  We would only consider something in the
decoding software to be a bug if the decoder did not respond
correctly to a conforming bitstream.  Here you're talking
about something else - how the decoder responds to what appears
to be a non-conforming bitstream.
+> 
+> 3) If the bitstream is data partitioned, it is illegal to 
+> insert the stuffing macroblocks after the last non-stuffing 
+> macroblock in VOP. Since in the document section 6.2.5.3, 
+> function data_partitioned_i_vop() and 
+> data_partitioned_p_vop( ), the stuffing macroblocks should 
+> be in mcbpc, and should not at the end of packet. But both 
+> Momusys and Microsoft reference software check the stuffing 
+> macroblocks and skip them.
Interesting.  Again, since there is no requirement for what
the decoder should do when given a non-conforming bitstream,
the status quo may be OK in this case.
+> 
+> Maybe there is some amendment on this issue but I don't know yet.
+> 
+> Thank you for your time.
+> 
+> --Lefan
+> _______________________________________________
+> Technotes mailing list
+> Technotes   lists.m4if.org
+> http://lists.m4if.org/mailman/listinfo/technotes
+>