[XviD-devel] B frame help

[Christoph Lampert]

On Sat, 8 Feb 2003, Zoltan Kocsi wrote:
>  > * co-located block skipping semantics
> 
> Well, with that I have also some problems. 
> According to the standard MB-s that were not encoded in the last P

If "last"="last in encoding order", then yes. 
If "last"="last in viewing order", then no, then it has to be "next". 

> frame should be skipped in all B-s that have that P as backward
> reference.
> 
> I have to apologise for the long ASCII art, but here is a testcase. 
> My test image is a 16x16 square moving by 8,8 in every frame. In
> the ASCII a macroblock is 4x4 chars.
> 
> The frame sequence is I1 b0 P3 B2 P5 B4 I7 B6 P9 B8 ... where b0 is 
> thrown away.
> 
> ####....             I1
> ####....
> ####....
> ####....
> ........
> ........
> ........
> ........
> 
> ........             P3, the square moved 16 pixels			
> ........
> ........
> ........
> ....####
> ....####
> ....####
> ....####
> 
> ........             The B between the two. The top right and bottom
> ........             left of the square are missing because those
> ..##....             macroblocks were not encoded in the P and hence
> ..##....             they are not encoded in the B either, even though
> ....##..             they changed. 
> ....##..
> ........
> ........

You're right on this one. MPEG-4 sucks, doesn't it? 

There are two known solutions:

1) Do not use not_coded blocks for co-located blocks if intermediate
   blocks should not be skipped (computationally expensive and also ugly).

2) Use S(GMC)-VOPs instead of P-VOPs, but most likely you don't support
   those.  

 
> In addition, the standard (and the XviD code as well), explicitly refers 
> to the last P frame and not the last reference frame.

_That_ I believe is either a mistake in the standard or in your
interpretation. B-frame encoding usually speaks about "co-located" block,
and that is either in backwards P- or I-frame, but never in the past and
never further in the future. 


gruel